mosdef-hub / foyer

A package for atom-typing as well as applying and disseminating forcefields
https://foyer.mosdef.org
MIT License
118 stars 77 forks source link

Changing how foyer handle `combining_rules` when loading in multiple forcefield #441

Closed daico007 closed 3 years ago

daico007 commented 3 years ago

A summary of the question or discussion topic. Stemming from this bug #440 here. Currently, when loading in multiple forcefield, their combining rules are stored in a list and then pass into other downstream methods. The list itself can cause an error when it get passed to parmed Structure during the parametrization step. The fix for this bug would be to collapsing the combining_rules list to become a string before proceeding to the later steps. However, this is only doable if all the combining rule is the same (either `"lorentz"' or '"geometric"'). I think the more fundamental discussion we should have is to what extent should we allow for the combination of multiple forcefields? I agree with @mphoward in #440, that we the combining should only be possible if the forcefields have the same combining rules(I will have a PR open going for that direction), but I really need everybody's thoughts on this topic.
@justinGilmer @umesh-timalsina @mosdef-hub/mosdef-contributors

bc118 commented 3 years ago

In my opinion, if the mixing rules do not match foyer should not infer anything and should fail to build the system. In general, using different mixing rules should likely be frowned upon, with minor exceptions (TIP3P's standard FF, which is the exact same LB vs geometric mixing, where H-H epsilon is zero). For this TIP3P water or similar cases, it may make more sense to have two separate XML files for LB and geometric mixing.

If non-standard mixing rules (not LB or geometric) are applied, they need to be done via an NBFIX (Example: CHARMM FF) and/or manually setting the specific pair potentials in the simulation engine control file. The best example is in LAMMPS using a hybrid pair potentials with the same mixing rules. Despite it being the same mixing rules, LAMMPS will still make you specify all the pair potential constants that are not the same (i.e., Ca to O). Therefore, I believe that there is no reason to make any assumptions on mixing or custom pair potential constants and make the user change them manually or via a FF XMLs specific custom pair interactions.

We need an option to read custom pair potentials from an XML file into the foyer and write out parameter and control files. This is currently the major hurdle in utilizing MoSDeF for the CHARMM FF. I also assume this is a limiting factor for other FFs.

daico007 commented 3 years ago

That is the current implementation I have over #442 (failed upon merging FF with different combining rule), so we are in agreement in that matter. I don't think we have a way to handle non-standard mixing rules yet, but I guess that can be implemented in the future as need arise.