-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for storing bonding information #23
base: master
Are you sure you want to change the base?
Conversation
Topology/README.md
Outdated
|
||
For metadata, there are a few pre-defined keys with strict meanings: | ||
|
||
* `bond_type` can take values `single`, `double`, `triple` [to replace -- this is just an example], only suitable for connections involving pairs of atoms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Angle and torsions would need to be handled in a similar way
bond_type defined as is may not be necessary. Single, double, triple ... bonds are defined through the set of parameters associated with each atom type
Topology/README.md
Outdated
|
||
For metadata, there are a few pre-defined keys with strict meanings: | ||
|
||
* `bond_type` can take values `single`, `double`, `triple` [to replace -- this is just an example], only suitable for connections involving pairs of atoms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Angle and torsions would need to be handled in a similar way
bond_type defined as is may not be necessary. Single, double, triple ... bonds are defined through the set of parameters associated with each atom type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed -- I don't know if bond_type
specifically is necessary, I included it as an example. I think some pre-defined keys might be useful for GUI/visualization though.
Topology/README.md
Outdated
Each connection is defined as: | ||
|
||
* `indices`, an ordered list of length `N` of atomic indexes defining the connection | ||
* `images`, (optional, only relevant if a unit cell lattice is defined) an ordered list of length `3N` describing the periodic image of the connected atom -- by default, this is assumed to be (0,0,0), meaning that the connected atom is in the origin image, and first index is set to (0,0,0) by convention |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not a list of lists like for gemoetry
and unit_cell
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like that -- it'd make it a lot more human readable. I'm not sure if it'd have consequences for file size/loading time for large systems though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but geometry
is currently specified as a list of lists, and the same issue applies there...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it should be consistent with geometry
, I didn't realize this was list of lists.
Looks good |
|
||
For metadata, there are a few pre-defined keys with strict meanings: | ||
|
||
* `bond_type` can take values `single`, `double`, `triple` [to replace -- this is just an example], only suitable for connections involving pairs of atoms, this is useful for GUI/visualization tools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about order, and use an integer rather than a string, or are there other types being envisaged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Order sounds sensible! bond_type
was just an example to get the conversation started: some pre-defined keys would be good, I'm (personally) agnostic as to what these keys should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But order and an integer value sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like geometry should be changed following discussions from yesterday. I can make a pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any real objection to adding bond_types
as floats to allow slightly more flexibility for say aromatic compounds.
Added #28 to make these more uniform |
1. Change field `masses` to mass of molecule to mass of atoms. I think this was a typo. 2. Add fields `num_protons`, `num_electrons`, and `basis`. The ghost and dummy atoms can be constructed with the appropriate selection of these fields (plus `masses`)
1. Add examples for symbols, geometry, name, multiplicity, masses, num_protons, num_electrons, basis, comment, fragments, fragment_charges, and fragment_multiplicities,
Add more specifications for each atom
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, @cryos can you make the mentioned PR?
@mkhorton The schema layout has changed quite a bit since this PR, apologies! If you can supply 1-2 JSON examples I would be more than happy to work on incorporating this. |
This is following the 'big system' approach of large arrays containing information for all atoms.