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

Add more padding to fix issue #949 #953

Merged
merged 11 commits into from
May 3, 2022
Merged

Add more padding to fix issue #949 #953

merged 11 commits into from
May 3, 2022

Conversation

mikemhenry
Copy link
Contributor

Description

Fix issue #949

Motivation and context

Due to a change in openmm, we need to increase the padding for our simulation boxes.

Resolves #949

How has this been tested?

Tested in CI

Change log

Increase default padding in XXXX classes

I'm trying to increase the padding as little as possible in our tests/defaults to pass without increasing CI time significantly. So it is a bit slow/some trial and error to find that sweet spot.

@jchodera
Copy link
Member

jchodera commented Mar 4, 2022

Let's hold off on merging this until we decide on openmm/openmm#3502

@codecov
Copy link

codecov bot commented Mar 4, 2022

Codecov Report

Merging #953 (a58953d) into main (06bb0f4) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@zhang-ivy
Copy link
Contributor

zhang-ivy commented Mar 29, 2022

Note from dev sync today: Mike says that some of the tests are still failing because the padding is still not large enough, but increasing the padding even more for all tests will slow the tests down. They are already taking > 45 min. Beforehand, they took ~15 min.

@mikemhenry
Copy link
Contributor Author

Good news! I've bumped up the padding and the tests don't run really any slower 😎 I'm very happy to be wrong about the increased test times, which were due to some bad luck (see openmm/openmm#3502 (comment)) However, we now have two new issues:

 >           for i in range(periodic_torsion.getNumTorsions()):
E           AttributeError: 'NonbondedForce' object has no attribute 'getNumTorsions'

From test_flattenedHybridTopologyFactory_energies in perses/tests/test_relative.py

and

>       top_proposal._old_system.getForce(3).setUseDispersionCorrection(False)
E       AttributeError: 'HarmonicAngleForce' object has no attribute 'setUseDispersionCorrection'

From test_HybridTopologyFactory_energies in perses/tests/test_relative.py

I'm going to investigate this and see where it is coming from, but that fix may be in a different PR or upstream.

@mikemhenry
Copy link
Contributor Author

mikemhenry commented Mar 31, 2022

So it looks like setUseDispersionCorrection is only a property of non-bonded forces (makes sense) and likewise it makes sense that AttributeError: 'NonbondedForce' object has no attribute 'getNumTorsions' which means that someone (on nightly) our forces are getting scrambled. So periodic_torsion = system.getForce(2) doesn't pull in a periodic torsion, but instead a non-bonded force.

I propose we make a new issue and merge this PR in to fix the issue with solvent padding.

One open question, do we change the default padding in other parts of the code? For larger systems, the padding seems to work fine.

@mikemhenry
Copy link
Contributor Author

This is ready for review! The nightly tests that are still failing are then fixed in #976 (there is one energy test failing but I think that one is just flaky (since it doesn't fail on both python versions) but if it is a problem I will address it later in another PR)

Copy link
Contributor

@ijpulidos ijpulidos left a comment

Choose a reason for hiding this comment

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

I wonder if we should also change the default padding options in other places, for example here or here or here

@@ -522,7 +522,7 @@ def generate_solvated_hybrid_test_topology(current_mol_name="naphthalene", prop
hs = [atom for atom in modeller.topology.atoms() if atom.element.symbol in ['H'] and atom.residue.name not in ['MOL','OLD','NEW']]
modeller.delete(hs)
modeller.addHydrogens(forcefield=system_generator.forcefield)
modeller.addSolvent(system_generator.forcefield, model='tip3p', padding=9.0*unit.angstroms)
modeller.addSolvent(system_generator.forcefield, model='tip3p', padding=20.0*unit.angstroms)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is it 20 A here instead of 11 A as it was with the other tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! I will double check that one!

@mikemhenry
Copy link
Contributor Author

So since those systems are "real" they seem to work fine, since we run some of these examples through CI.

@zhang-ivy
Copy link
Contributor

@mikemhenry :

Good news! I've bumped up the padding and the tests don't run really any slower 😎 I'm very happy to be wrong about the increased test times, which were due to some bad luck

Can you clarify why the test times were previously longer?

@mikemhenry
Copy link
Contributor Author

@mikemhenry :

Good news! I've bumped up the padding and the tests don't run really any slower sunglasses I'm very happy to be wrong about the increased test times, which were due to some bad luck

Can you clarify why the test times were previously longer?

I mention that here:
openmm/openmm#3502 (comment)

I hadn't merged my fix to the multistate samplers which were causing the context cache to get a miss every time which slowed everything down.

@zhang-ivy
Copy link
Contributor

zhang-ivy commented Apr 4, 2022

I hadn't merged my fix to the multistate samplers which were causing the context cache to get a miss every time which slowed everything down.

@mikemhenry : I don't see the fix in the issue comment you linked, could you point me to the PR?

@mikemhenry
Copy link
Contributor Author

I hadn't merged my fix to the multistate samplers which were causing the context cache to get a miss every time which slowed everything down.

@mikemhenry : I don't see the fix in the issue comment you linked, could you point me to the PR?

@zhang-ivy Here you go! https://github.com/choderalab/perses/pull/961/files

Because of this line https://github.com/choderalab/perses/blob/0.9.5/perses/samplers/multistate.py#L10
Importing that module caused weird behavior.

@mikemhenry
Copy link
Contributor Author

mikemhenry commented Apr 5, 2022

@ijpulidos I was able to reduce the padding in that one util from 20 A to 16 A but anything smaller fails.
Ready for re-review

@zhang-ivy
Copy link
Contributor

Noting that Peter has attempted to help resolve this with this PR: openmm/openmm#3537 that John mentioned yesterday.

I'm surprised that we need to increase padding at all, given this new PR..

@ijpulidos
Copy link
Contributor

So, from what I can see the problem is what Peter mentions here. Is it the case that Openmm is now making smaller boxes so we have the problem with the cutoff being greater than half of the box size. Then that's why increasing the padding works for these tests, we are just making larger boxes such that cutoff is smaller than half of its size. I think this is fine for the tests since they are actually fast tests (not a bottleneck), as far as I can see.

Copy link
Contributor

@ijpulidos ijpulidos left a comment

Choose a reason for hiding this comment

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

This looks good, extra padding doesn't seem to affect the time for tests. Thanks!

@zhang-ivy
Copy link
Contributor

zhang-ivy commented Apr 5, 2022

So, from what I can see the problem is what Peter mentions here. Is it the case that Openmm is now making smaller boxes so we have the problem with the cutoff being greater than half of the box size. Then that's why increasing the padding works for these tests, we are just making larger boxes such that cutoff is smaller than half of its size. I think this is fine for the tests since they are actually fast tests (not a bottleneck), as far as I can see.

Yes, I agree with everything you said.. but check out this new PR from peter. The description for the PR says: "First, it revises the method for selecting box size. When building a water box around a very small solute, it will never make the box width less than 2*padding."

My comment earlier today was referencing this revision. Peter's change should fix our problem, meaning we no longer need to increase the padding.

If there is no difference in the speed of the tests, then I guess it doesn't hurt to bump the padding, but in principle, we shouldn't have to, with Peter's revision.

@ijpulidos
Copy link
Contributor

@zhang-ivy Ah! I see what you mean. Yes, I agree. We probably just need the nightly builds to catch these changes then.

@mikemhenry
Copy link
Contributor Author

Last night's CI run is still throwing padding issues, and I really like to get our CI passing again. Given the low impact this has on our CI times, is this okay to merge @zhang-ivy @jchodera @ijpulidos ?

@zhang-ivy
Copy link
Contributor

@mikemhenry : I'm still not sure why we need to increase the padding. Happy to be overrridden on this decision, but see my comment here: #953 (comment)

@mikemhenry
Copy link
Contributor Author

I'll confirm that the nightly getting pulled in has the PR that is supposed to fix this

@jchodera
Copy link
Member

jchodera commented Apr 7, 2022

@zhang-ivy is right that we shouldn't need to change the padding. The OpenMM nightlies should be the latest master build, which includes openmm/openmm#3537.

The issue must be that openmm/openmm#3537 is an incomplete fix. Perhaps we can open another PR starting from the perses main, figure out what tests are failing and why, and then give some feedback about how openmm/openmm#3537 should be further refined?

@mikemhenry
Copy link
Contributor Author

mikemhenry commented Apr 7, 2022

I double checked our CI that runs on main https://github.com/choderalab/perses/runs/5872047384?check_suite_focus=true and we are running the latest nightly that was built last night, so openmm/openmm#3537 is not a complete fix.

@jchodera
Copy link
Member

jchodera commented Apr 7, 2022

@mikemhenry Can you give me an example of a simple test that is failing due to the box size issues? I can dive into this in more detail and propose further fixes to the OpenMM feature.

@mikemhenry
Copy link
Contributor Author

mikemhenry commented Apr 19, 2022

import numpy as np
from openmm import app, unit
from perses.tests.test_topology_proposal import (
    generate_atp, generate_dipeptide_top_pos_sys)

new_res = "ASP"
charge_diff = 1

# Make a vacuum system
atp, system_generator = generate_atp(phase="vacuum")

# Make a solvated system/topology/positions with modeller
modeller = app.Modeller(atp.topology, atp.positions)
modeller.addSolvent(
    system_generator.forcefield,
    model="tip3p",
    padding=9 * unit.angstroms,
    ionicStrength=0.15 * unit.molar,
)
solvated_topology = modeller.getTopology()
solvated_positions = modeller.getPositions()

# Canonicalize the solvated positions: turn tuples into np.array
atp.positions = unit.quantity.Quantity(
    value=np.array(
        [
            list(atom_pos)
            for atom_pos in solvated_positions.value_in_unit_system(unit.md_unit_system)
        ]
    ),
    unit=unit.nanometers,
)
atp.topology = solvated_topology

atp.system = system_generator.create_system(atp.topology)

# Make a topology proposal and generate new positions
top_proposal, new_pos, _, _ = generate_dipeptide_top_pos_sys(
    topology=atp.topology,
    new_res=new_res,
    system=atp.system,
    positions=atp.positions,
    system_generator=system_generator,
    conduct_geometry_prop=True,
    conduct_htf_prop=False,
    validate_energy_bookkeeping=True,
)

This fails with the currently nightly openmm build, let me know if you need this trimmed down more @jchodera

@jchodera
Copy link
Member

Thanks, @mikemhenry! Filed a simpler version of this as openmm/openmm#3502 (comment)

@mikemhenry mikemhenry enabled auto-merge (squash) May 3, 2022 16:38
@mikemhenry mikemhenry merged commit 285205d into main May 3, 2022
@mikemhenry mikemhenry deleted the fix/issue_949 branch May 3, 2022 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants