You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the sake of making progress I'm going to leave the design as is; however, there is room for improvement. Right now FragmentedSystem stores everything is in terms of atoms, that is we store an "atom to number-of-electrons" map, an "atom to AOs" map, and the fragments are defined in terms of which atoms are in that fragment. The NMerSystem is defined in terms of the fragments in the FragmentedSystem.
Realistically we should also be able to define the n-mers in terms of the fragments, the fragments in terms of pseudoatoms, and pseudoatoms in terms of atoms (when the pseudoatoms are themselves not just a trivial mapping to the atoms). This actually makes the fragments more analogous to the n-mers in terms of storage. Basically, I feel like there's some sort of recursive structure that could be designed which models what's going on here better and would probably perform better (if you figure a pseudoatom contains around three atoms, that means you're getting a 3x reduction in data you need to look at when you write the fragments in terms of pseudoatoms). The exact storage strategy should probably be in a PIMPL so user's don't need to know about it.
The text was updated successfully, but these errors were encountered:
For the sake of making progress I'm going to leave the design as is; however, there is room for improvement. Right now
FragmentedSystem
stores everything is in terms of atoms, that is we store an "atom to number-of-electrons" map, an "atom to AOs" map, and the fragments are defined in terms of which atoms are in that fragment. TheNMerSystem
is defined in terms of the fragments in theFragmentedSystem
.Realistically we should also be able to define the n-mers in terms of the fragments, the fragments in terms of pseudoatoms, and pseudoatoms in terms of atoms (when the pseudoatoms are themselves not just a trivial mapping to the atoms). This actually makes the fragments more analogous to the n-mers in terms of storage. Basically, I feel like there's some sort of recursive structure that could be designed which models what's going on here better and would probably perform better (if you figure a pseudoatom contains around three atoms, that means you're getting a 3x reduction in data you need to look at when you write the fragments in terms of pseudoatoms). The exact storage strategy should probably be in a PIMPL so user's don't need to know about it.
The text was updated successfully, but these errors were encountered: