Skip to content
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

Issue in element inference in readers #841

Open
CalCraven opened this issue Aug 26, 2024 · 0 comments
Open

Issue in element inference in readers #841

CalCraven opened this issue Aug 26, 2024 · 0 comments

Comments

@CalCraven
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@CalCraven and others