This is related to the issue @jpotoff brought up. If you run energy minimization on a system containing water, the angles and bond distances in water will incorrect.
The notebook linked below shows how I have handled "fixing" the water-models post energy minimization. Basically, using force_overlap (with add_bond=False) to translate and reorient a copy of the original water model and updating the coordinates in the energy minimized configuration.
1) in the energy minimization routine, check contains_rigid; if True issue a warning. I'll note this is false for the water models. I'm not sure if we should mark these as rigid in the recipe, and/or have the energy minimize routine search the successors for anything with a name that contains "water" or "SPC", "TIP3P", etc. and producing a warning.
2) create a tutorial specifically about water and how to handle it correctly. (e.g., expanding upon above)
3) put in the code from the notebook above into the energy minimize function, where a user can pass the water model they want to be "fixed". I'll note, even though open babel can handle constraints, they are just strong harmonic bonds/angles, so they won't truly preserve the right model configuration. Similar to my rationale for the water_box routine PR, water is common enough that it seems worthwhile to add some specific functionality.
This is related to the issue @jpotoff brought up. If you run energy minimization on a system containing water, the angles and bond distances in water will incorrect.
The notebook linked below shows how I have handled "fixing" the water-models post energy minimization. Basically, using force_overlap (with add_bond=False) to translate and reorient a copy of the original water model and updating the coordinates in the energy minimized configuration.
https://github.com/chrisiacovella/mbuild_energy_minimization/blob/main/water_model_energy_minimization.ipynb
A few changes could be made to avoid issues:
1) in the energy minimization routine, check contains_rigid; if True issue a warning. I'll note this is false for the water models. I'm not sure if we should mark these as rigid in the recipe, and/or have the energy minimize routine search the successors for anything with a name that contains "water" or "SPC", "TIP3P", etc. and producing a warning.
2) create a tutorial specifically about water and how to handle it correctly. (e.g., expanding upon above)
3) put in the code from the notebook above into the energy minimize function, where a user can pass the water model they want to be "fixed". I'll note, even though open babel can handle constraints, they are just strong harmonic bonds/angles, so they won't truly preserve the right model configuration. Similar to my rationale for the water_box routine PR, water is common enough that it seems worthwhile to add some specific functionality.