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
These items need addressed to properly finish the Charmm writer and likely other writers:
Do we want a standard check or function to see if all atom types in the same class have the same sigmas and epsilons? I am not sure of a standard FF that this should not be true, but could be wrong?
What is the final decision about the charges in the GMSO XML?
Are we leaving out the charge part of the equation in the XML? If not, how are we going to do/implement this? Is there any case/FF where the charge equation is different even by a scalar or anything?
The text was updated successfully, but these errors were encountered:
In order to clarify some things on my end in regards to your fourth bullet point, is the current treatment of charges just included in the nonbonded functionals section heading?
If it is, can charges just be put into a separate section of the xml under some "coulombics" section heading, and then we can support unique treatments of charges if any of those arise, but we don't have to have that interfere with our suite of nonbonded functional forms that are more important for the forcefields we are trying to support? I could even see a basic case where the only values stored there are the site partial charges, and not even any particular equation because most of that is handled engine by engine anyways.
These items need addressed to properly finish the Charmm writer and likely other writers:
Do we want a standard check or function to see if all atom types in the same class have the same sigmas and epsilons? I am not sure of a standard FF that this should not be true, but could be wrong?
Accept these changes and additions to the standard GMSO XMLs (Modified RB and Periodic torsions #615)?
What is the final decision about the charges in the GMSO XML?
The text was updated successfully, but these errors were encountered: