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

Handlers for template potentials that are different forms of the same equation. #855

Merged
merged 12 commits into from
Oct 15, 2024

Conversation

CalCraven
Copy link
Contributor

@CalCraven CalCraven commented Oct 1, 2024

Add support for modifying template expression via set expression, and testing for handling accepted_potentials as scaled versions of template potentials.
For example:

expression1 = "epsilon*((sigma/r)**12 - (sigma/r)**6)" # missing scalar 4
expression2 = "4*epsilon*((sigma/r)**12 - (sigma/r)**6)" # standard lj

If expression1 is the atomtype potential, and expression2 is the accepted potential, since it is the same form as the LennardJonesPotential in lib/jsons, then this was previously handled okay.

However, if expression2 was the atomtype potential, and you were trying to write to a format for _accepted_potentials that is expression1, then this was not supported unless we added a .json file for this modified LJ equation. The current PR seeks to allow a list of accepted_potentials where the expression can be reset to and therefore the original LJ template form can be used, but then slightly tweaked for each individual writer. Necessary for PR #848.

This PR also adds the ability to automate scalar equation conversions by loading templates from the name, or directly passing a template object. This allows the user to load the template in the writer, modify the equation slightly, then pass that template for conversion.

Thoughts on ways to regulate the overwriting of the expression? Should we throw errors if the expression cannot be validated with the independent variables? If so, we'll need to explicitly switch the templates over to _parametric_potentials, since they are currently treated as non_parameteric_potentials

TODO:

  • Tests for all new functionality

… testing for handling accepted_potentials as scaled versions of template potentials
gmso/lib/potential_templates.py Fixed Show fixed Hide fixed
gmso/utils/conversions.py Fixed Show fixed Hide fixed
@CalCraven CalCraven requested a review from Zeerakkhan47 October 1, 2024 18:20
Copy link

codecov bot commented Oct 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.52%. Comparing base (c8c62ae) to head (8a66997).
Report is 6 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #855      +/-   ##
==========================================
- Coverage   94.07%   93.52%   -0.56%     
==========================================
  Files          65       65              
  Lines        6953     6976      +23     
==========================================
- Hits         6541     6524      -17     
- Misses        412      452      +40     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@CalCraven
Copy link
Contributor Author

I think this code is ready for final review @Zeerakkhan47 and @chrisjonesBSU, if you two want to have a look. The failing codecov test is for updating the hoomd version to 4.5 for the impropers testing, which reduces are coverage slightly, but we are okay with that since it's more accurate at checking the correct versions of hoomd.

Copy link
Contributor

@chrisjonesBSU chrisjonesBSU left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played around with this a bit with similar examples we talked about on the dev call a couple of weeks ago. Everything seems to work as expected.

LGTM! Thanks for adding this.

@CalCraven CalCraven merged commit 602039b into mosdef-hub:main Oct 15, 2024
14 of 15 checks passed
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

Successfully merging this pull request may close these issues.

2 participants