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

About automating consolidation of parameters while using GMSO ForceField XML. #674

Open
umesh-timalsina opened this issue Jul 5, 2022 · 0 comments

Comments

@umesh-timalsina
Copy link
Member

Since GMSO forcefields are generic with expressions or parameters, it might be nice to figure out a way to include this information while dealing with them. For example, take for example a periodic torsion, with the current version of the XML schema, we have to use a section like this for the whole representation.

   <DihedralType name="DihedralType_Periodic_Proper_CH3_CH_O_H" class1="CH3" class2="CH" class3="O" class4="H">
      <Parameters>
        <Parameter name="k0" value="0.0"/>
        <Parameter name="k1" value="0.416955197548017"/>
        <Parameter name="phi_eq1" value="0.0"/>
        <Parameter name="k2" value="-0.0579667482245528"/>
        <Parameter name="phi_eq2" value="180"/>
        <Parameter name="k3" value="0.37345529632637"/>
        <Parameter name="phi_eq3" value="0.0"/>
        <Parameter name="k4" value="0.0"/>
        <Parameter name="phi_eq4" value="0.0"/>
        <Parameter name="k5" value="0.0"/>
        <Parameter name="phi_eq5" value="0.0"/>
      </Parameters>
    </DihedralType>

This is great and all, but it might be difficult to cumbersome all these all the long-form equations like these:

k0 + k1 * (1 + cos(1 * phi - phi_eq1)) + k2 * (1 + cos(2 * phi - phi_eq2)) + k3 * (1 + cos(3 * phi - phi_eq3)) + k4 * (1 + cos(4 * phi - phi_eq4)) + k5 * (1 + cos(5 * phi - phi_eq5))

It might make sense to allow the writing of consolidated parameters as a list, where a parameter will have a name and value associated with it. Alternatively, one can also consider consolidating parameters based on alpha-numeric selection, which will inevitably lead to edge cases as well as potential bugs. For example, the above periodic dihedral can also be written as:

 <DihedralType name="DihedralType_Periodic_Proper_CH3_CH_O_H" class1="CH3" class2="CH" class3="O" class4="H">
      <Parameters>
        <Parameter name="k0" value="[0.0, 0.416955197548017, -0.0579667482245528, 0, 0]"/>
	 <Parameter name=”phi_eq”, value=”[0.0, 0.0, 0.0, 0.0, 0.0, 0.0]”/>
      </Parameters>
    </DihedralType>

So, this can be achieved by relaxing the schema definition for parameters to optionally include a list of floats. However, the minutia of the validation code (length) should be left up to the user.

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

1 participant