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
mBuild typically infers elements from readers, such as xyz files. As we've updated to GMSO as the backend file handler, that inference is not always handled the same way, with xyz files being an example of that. In order to regain that consistency, element inference will need to be encoded into GMSO where appropriate, taking into account that default behavior for either coarse-grained or atomistic systems should be clear how those will effect related GMSO and mBuild functions and interconversions.
There are two ways to handle this, and we should discuss which we think will be the best route forward. I think we could:
handle at the readers level
pros: will immediately have the correct element information for workflows that just read into GMSO and don't do much in mBuild.
cons: may have to worry about subtle differences in this inference, such as naming conventions. Hopefully will mostly be handled by ele though.
handle when we convert from GMSO to mBuild
pros: will be a uniform conversion process in mBuild to GMSO. Also, doesn't force the element handling into the equation earlier than necessary.
cons: May be reasons to not set the elements in mBuild, such as with oddly named coarse grained systems.
I also think some broader discussion of the element/coarse-grained tagging in different systems could be done. We have relied on this implicit underscore naming conversion for awhile now, but I'm starting to think that more explicit handling might be useful in the long run, as we're adding more distinct methods for cg vs atomistic workflows, and subtle inferred differences might cause unidentified setting of various values, such as overwriting mass in cg systems.
The text was updated successfully, but these errors were encountered:
mBuild typically infers elements from readers, such as xyz files. As we've updated to GMSO as the backend file handler, that inference is not always handled the same way, with xyz files being an example of that. In order to regain that consistency, element inference will need to be encoded into GMSO where appropriate, taking into account that default behavior for either coarse-grained or atomistic systems should be clear how those will effect related GMSO and mBuild functions and interconversions.
There are two ways to handle this, and we should discuss which we think will be the best route forward. I think we could:
I also think some broader discussion of the element/coarse-grained tagging in different systems could be done. We have relied on this implicit underscore naming conversion for awhile now, but I'm starting to think that more explicit handling might be useful in the long run, as we're adding more distinct methods for cg vs atomistic workflows, and subtle inferred differences might cause unidentified setting of various values, such as overwriting mass in cg systems.
The text was updated successfully, but these errors were encountered: