Add pairpotential parsing to hoomd, and parse dpd forces#965
Add pairpotential parsing to hoomd, and parse dpd forces#965CalCraven wants to merge 1 commit intomosdef-hub:mainfrom
Conversation
|
@StephMcCallum I added gamma and kT parameters to the potential. Let me know if you think those look right. It's hard to write the exact form of the equation, so I may keep tweaking that so we can handle some of the generalization parameters, such as the dot product, for ensuring that people use this correctly. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #965 +/- ##
==========================================
- Coverage 93.47% 93.47% -0.01%
==========================================
Files 67 67
Lines 7785 7812 +27
==========================================
+ Hits 7277 7302 +25
- Misses 508 510 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hi @CalCraven! I'm working on understanding how gmso works so that I can help with this. I agree that gamma and kT will need to be given to HOOMD. How does the forcefield parameterization work? Does it use only the given equations or the HOOMD forcefield directly? My initial thought is that we would parameterize with just the conservative force and store parameter values for the rest of the forcefield. This would not give the full force-field and maybe we can make an adjustment to account for that. |
| "expected_parameters_dimensions": { | ||
| "A": "force", | ||
| "r_cut": "length", | ||
| "γ": "mass / length / time" |
There was a problem hiding this comment.
On this line, why has "/ length" been added? Does this need to be added in other places if it is for unit conversion?
There was a problem hiding this comment.
From lammps, https://docs.lammps.org/pair_dpd.html, gamma is force/velocity.
force = mass * length / time**2
velocity = length / time
force/velocity = mass / time
This is the correct fundamental units for this parameter (not mass / length/ time). You're right "/ length" should get removed.
These values are to validate that a given parameter in an actual forcefield matches the form in our library, and helps the writers validate any conversions applied from different forcefield styles.
| @@ -0,0 +1,10 @@ | |||
| { | |||
| "name": "HOOMDDPDConservativeForce", | |||
| "expression": "A * (1-(r/r_cut)) - γ", | |||
There was a problem hiding this comment.
" - gamma" has been added. My understanding from the equations is that "A * (1-(r/r_cut))" is the non-zero conservative force. The gamma variable is part of the dissipative force, but the full equation for dissipative force is not included here. Can you explain this more?
If we are including the dissipative force, should we also include the random force?
There was a problem hiding this comment.
Yeah, the reason it's not included is because it has terms which could be expressed in different ways. We have to figure out a reasonable way to express them in the equation. There will probably be just 4 or 5 independent variables.
This was just my quick and easy way to get it in there so the form of the equation is usable in simulations. The actual expression is only used for converting one equation to the other. What's written to hoomd is just the force objects, so the representation is hoomd's native one. At that stage, the expression we used isn't a applied, which is why this works as a quick and dirty working approach. But like you said, we should probably include the whole dissipative force, for the sake of being clear what is here.
2 participants
PR Summary: This PR will add type checking for pairpotentials in general, and add the pair_potential HOOMDDPDConservativeForce to the list of compatible templates
PR Checklist