OpenMM+PLUMED Metadynamics (Particle coordinate is NaN )

[summer houston]

Hello all,

I am trying to run MetaD simulations with OpenMM-PLUMED with one CV (COM distance between two residues) but despite so many efforts I keep getting one of the following errors:

Looking for a value outside the grid along the 0 dimension. When I check the output file I see at some point CV gets larger than the uwall limit and when I plot PES vs time, I see sudden spike around the time CV goes out of range.

So, as one the suggested solutions I increased the GRID_MAX limit (or increased Kappa) but then I get another error openmm.OpenMMException: Particle coordinate is NaN.  For more information, see https://github.com/openmm/openmm/wiki/Frequently-Asked-Questions#nan\n”

I tried different parameters and no difference. The simulation runs for a very short time (2-3 ps) before it crashes. I should mention without grid/uwall simulation runs fine but explores irrelevant parts of the phase-space.

 

Here is the PLUMED input file

script = """

UNITS LENGTH=A ENERGY=kcal/mol

 

WHOLEMOLECULES ENTITY0=2168-2179, ENTITY1=2218-2241

DUMPATOMS FILE=dump.xyz ATOMS=2168-2179,2218-2241

 

d1: COM ATOMS=2168-2179 # (incl. H)

d2: COM ATOMS=2218-2241 # (incl. H)

d: DISTANCE ATOMS=d1,d2 NOPBC

 

#d1: DISTANCE ATOMS=2170,2220 NOPBC 

UPPER_WALLS ARG=d AT=8.5 KAPPA=12.0 EXP=2 EPS=1 OFFSET=0 LABEL=uwall

FLUSH STRIDE=1

 

# Activate metadynamics in d1

METAD ...

LABEL=metad

ARG=d

PACE=500 

HEIGHT=0.24

SIGMA=0.4

FILE=HILLS

BIASFACTOR=10.0

TEMP=300.0

GRID_MIN=3.0

GRID_MAX=15.0

#Grid_BIN=1000

GRID_WSTRIDE=100

GRID_WFILE=grid.dat

... METAD

#UPPER_WALLS ARG=d AT=8.5 KAPPA=12.0 EXP=2 EPS=1 OFFSET=0 LABEL=uwall

 

PRINT STRIDE=1 ARG=d,metad.bias FILE=COLVAR

PRINT STRIDE=1 ARG=d,uwall.bias FILE=walls.dat

DUMPFORCES STRIDE=1 ARG=d FILE=force.dat"""

 

I restart an OpenMM unbiased simulation and then add PLUMED as a new force to the system. Initially, I have the following forces in my system:

Force 0 : HarmonicBondForce Force 1 : NonbondedForce Force 2 : PeriodicTorsionForce Force 3 : CMMotionRemover Force 4 : HarmonicAngleForce Force 5 : CustomExternalForce Force 6 : MonteCarloBarostat 

But before creating the “simulation context” I remove the CustomExternalForce (positional restraint on Heavy atoms) & I do have Constraints (heavyatom-H) in my system but since my CV is the distance between the COMs, I believe having constraint would be okay. 

 

Any suggestions/comments would be greatly appreciated.

 

Thanks!

Summer

[summer houston]

Hello all,

How we should select values for Kappa, EPS, EXP (Upper_Walls, Lower_Walls) for a distance based (non bonded) collective variable?

When I run my simulations without any Upper-Walls (and no grid), the simulation runs without any error but the collective variable explores irrelevant parts of phase-space (very large distances). However, as soon as I add Upper_walls, the simulation runs for a while and then crashes (Particle coordinate is NaN). I tried different values for Kappa and EXP (2 or 1(to make the wall softer)) and as I lower Kappa simulation runs for longer time but finally cashes with "NaN error" and if I monitor CV, there are times that collective variable gets way above upper_walls limit, which if I am correct means that the Upper_walls parameters are not optimal to keep the collective variable within the limit of phase-space of interest.

I am very new to PLUMED/OpenMM and my first attempts running metaD simulations. I appreciate any suggestions and help!

& Is there any existing tutorial for OpenMM/PLUMED with working example? or if someone could share such example? 

Thanks!

[ikol...@gmail.com]

Hi,

I am not sure if this is the same thing, but I am having the same problem. I have been running a large number of METAD and DRR jobs with OpenMM-PLUMED with no issues. However, with PLUMED 2.9.0 I am getting NaN exception after only a few time steps while the exact same job runs perfectly fine with PLUMED 2.8.1. I have two different setups, one where I install everything with 'conda install conda-forge::openmm-plumed', which has OpenMM 8.1.1 and PLUMED 2.9.0, and another where I override the canned plumed with one that I compile from source and include the drr module. Unfortunately, the canned plumed has no modules activated. In any case, both setups display the same error on Linux/Ubuntu and I also tested it on Apple arm64, and found the exact same problem. In all situations OpenMM runs perfectly fine by itself, until the PLUMED plugin is used. Is it possible that PLUMED 2.9.0 has a bug that is causing the NaN exceptions?

Thanks,

   Istvan

[Giovanni Bussi]

Hi this is unexpected.

Can you provide the exact version of the openmm-plumed plugin you are using and the error message that you see?

Giovanni

--
You received this message because you are subscribed to the Google Groups "PLUMED users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/c456f3d2-ed10-41f7-abf8-11143956d6a7n%40googlegroups.com.

[Istvan Kolossvary]

Hi Giovanni,

Thanks for looking at this. I attached the screen log. It is openmm-plumed 2.0. I am not sure how to give you the exact version of the openmm-plugin, I installed it yesterday via 'conda create --name openmm-plumed-drr -c conda-forge openmm-plumed' and then removed the built-in plumed via 'conda remove --force plumed' as Peter Eastman suggested, so I can link my own PLUMED that I built from source and activated the drr module. The contents of the conda-meta directory shows the version numbers of every single package included in the environment.

$ ls -l conda-meta/
total 5192
drwxrwxr-x  2 istvan istvan   4096 Feb  5 00:12 ./
drwxrwxr-x 15 istvan istvan   4096 Feb  5 00:12 ../
-rw-rw-r--  1 istvan istvan   8049 Feb  5 00:12 bzip2-1.0.8-hd590300_5.json
-rw-rw-r--  1 istvan istvan   1539 Feb  5 00:12 ca-certificates-2024.2.2-hbcca054_0.json
-rw-rw-r--  1 istvan istvan  24144 Feb  5 00:12 cudatoolkit-11.8.0-h4ba93d1_13.json
-rw-rw-r--  1 istvan istvan  19334 Feb  5 00:12 fftw-3.3.10-nompi_hc118613_108.json
-rw-rw-r--  1 istvan istvan  35698 Feb  5 00:12 gawk-5.3.0-ha916aea_0.json
-rw-rw-r--  1 istvan istvan 771147 Feb  5 00:12 gettext-0.21.1-h27087fc_0.json
-rw-rw-r--  1 istvan istvan   6462 Feb  5 00:12 gmp-6.3.0-h59595ed_0.json
-rw-rw-r--  1 istvan istvan 100759 Feb  5 00:12 gsl-2.7-he838d99_0.json
-rw-rw-r--  1 istvan istvan   2708 Feb  5 00:12 history
-rw-rw-r--  1 istvan istvan   2192 Feb  5 00:12 ld_impl_linux-64-2.40-h41732ed_0.json
-rw-rw-r--  1 istvan istvan   1710 Feb  5 00:12 libblas-3.9.0-21_linux64_openblas.json
-rw-rw-r--  1 istvan istvan   1644 Feb  5 00:12 libcblas-3.9.0-21_linux64_openblas.json
-rw-rw-r--  1 istvan istvan   1578 Feb  5 00:12 libexpat-2.5.0-hcb278e6_1.json
-rw-rw-r--  1 istvan istvan   5092 Feb  5 00:12 libffi-3.4.2-h7f98852_5.json
-rw-rw-r--  1 istvan istvan    960 Feb  5 00:12 _libgcc_mutex-0.1-conda_forge.json
-rw-rw-r--  1 istvan istvan   5221 Feb  5 00:12 libgcc-ng-13.2.0-h807b86a_5.json
-rw-rw-r--  1 istvan istvan   2295 Feb  5 00:12 libgfortran5-13.2.0-ha4646dd_5.json
-rw-rw-r--  1 istvan istvan   1071 Feb  5 00:12 libgfortran-ng-13.2.0-h69a702a_5.json
-rw-rw-r--  1 istvan istvan   2004 Feb  5 00:12 libgomp-13.2.0-h807b86a_5.json
-rw-rw-r--  1 istvan istvan   1653 Feb  5 00:12 liblapack-3.9.0-21_linux64_openblas.json
-rw-rw-r--  1 istvan istvan   4768 Feb  5 00:12 libnsl-2.0.1-hd590300_0.json
-rw-rw-r--  1 istvan istvan   1754 Feb  5 00:12 libopenblas-0.3.26-pthreads_h413a1c8_0.json
-rw-rw-r--  1 istvan istvan   3135 Feb  5 00:12 libsqlite-3.44.2-h2797004_0.json
-rw-rw-r--  1 istvan istvan   2225 Feb  5 00:12 libstdcxx-ng-13.2.0-h7e041cc_5.json
-rw-rw-r--  1 istvan istvan   3078 Feb  5 00:12 libuuid-2.38.1-h0b41bf4_0.json
-rw-rw-r--  1 istvan istvan   6478 Feb  5 00:12 libxcrypt-4.4.36-hd590300_1.json
-rw-rw-r--  1 istvan istvan   1567 Feb  5 00:12 libzlib-1.2.13-hd590300_5.json
-rw-rw-r--  1 istvan istvan   8265 Feb  5 00:12 mpfr-4.2.1-h9458935_0.json
-rw-rw-r--  1 istvan istvan 962704 Feb  5 00:12 ncurses-6.4-h59595ed_2.json
-rw-rw-r--  1 istvan istvan 612313 Feb  5 00:12 numpy-1.26.3-py311h64a7726_0.json
-rw-rw-r--  1 istvan istvan  15812 Feb  5 00:12 ocl-icd-2.3.1-h7f98852_0.json
-rw-rw-r--  1 istvan istvan   1684 Feb  5 00:12 ocl-icd-system-1.0.0-1.json
-rw-rw-r--  1 istvan istvan 225344 Feb  5 00:12 openmm-8.1.1-py311h6d2dbb8_1.json
-rw-rw-r--  1 istvan istvan   7981 Feb  5 00:12 openmm-plumed-2.0-py311he54c9da_1.json
-rw-rw-r--  1 istvan istvan   1284 Feb  5 00:12 _openmp_mutex-4.5-2_gnu.json
-rw-rw-r--  1 istvan istvan  54697 Feb  5 00:12 openssl-3.2.1-hd590300_0.json
-rw-rw-r--  1 istvan istvan 335354 Feb  5 00:12 pip-24.0-pyhd8ed1ab_0.json
-rw-rw-r--  1 istvan istvan 826898 Feb  5 00:12 python-3.11.7-hab00c5b_1_cpython.json
-rw-rw-r--  1 istvan istvan    986 Feb  5 00:12 python_abi-3.11-4_cp311.json
-rw-rw-r--  1 istvan istvan   9412 Feb  5 00:12 readline-8.2-h8228510_1.json
-rw-rw-r--  1 istvan istvan 511839 Feb  5 00:12 scipy-1.12.0-py311h64a7726_2.json
-rw-rw-r--  1 istvan istvan 162182 Feb  5 00:12 setuptools-69.0.3-pyhd8ed1ab_0.json
-rw-rw-r--  1 istvan istvan 180229 Feb  5 00:12 tk-8.6.13-noxft_h4845f30_101.json
-rw-rw-r--  1 istvan istvan 211514 Feb  5 00:12 tzdata-2024a-h0c530f3_0.json
-rw-rw-r--  1 istvan istvan  20537 Feb  5 00:12 wheel-0.42.0-pyhd8ed1ab_0.json

Of course, it can still be pilot error, I am looking into that, but this same job is running perfectly fine with openmm-plumed 1.0 and PLUMED 2.8.1.

Thanks again and best regards,

   Istvan

P.S. As I mentioned, the exact same thing happens on Apple arm64 architecture.

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/CAPLm8ZJUdEKKaMj_fgb9wwk%2BDSXyM41dVz5zEN6S5%3D-1Xj88PA%40mail.gmail.com.

[ikol...@gmail.com]

Giovanni,

I have an update. I attached two sets of plots, one with v2.9.0 that crashes, and one with v2.8.1 that behaves normally. It seems that there might be a bug in the drr module in v2.9.0.

This is actually fascinating... Look at these plots. I plot every single time step. For a while everything is fine with v2.9.0, real and fictitious distances go together, but then the real distance starts oscillating and eventually dist3 reaches resonance catastrophe and the plots blank out with NaN. On the other hand v2.8.1 behaves perfectly fine, and the simulation goes on forever.

Thanks,

   Istvan

[Giovanni Bussi]

I am not sure how this is possible. Didn’t you write that you have the problem also using the conda version of plumed (without DRR)?

Sent from Gmail mobile

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/72b23a29-b039-4358-9358-15368dc91772n%40googlegroups.com.

[summer houston]

Hi Istvan,

Since you have experience running OpenMM with PLUMED, I appreciate if you help me understand some of the concepts.

The unbiased MD simulations with OpenMM run with no error. I introduced PLUMED as a new force (standard MetaD, not well-tempered and no upper-wall, no grid) and the simulations run without any error. I plotted some properties vs. time (T, tot_E, PE, box-volume, ..) except for volume vs time which I see noticeable fluctuations (I am using NPT ensemble), all other properties behave normal. 

 However, when I try to visualize the trajectory it seems PBC is not applied correctly. I am running OpenMM simulations with PBC. Do you set NOPBC "on or off" for the distances in your simulation? & how about "WHOLEMOLECULES" setting?   I tried combinations of both but still the trajectory can not fully wrapped inside the box (see the figure). I save trajectories using DCDReporter, do we need to consider anything when saving trajectories. I am trying to understand how PBC works between PLUMED and OpenMM.

I am using OpenMM (v 8.1.1), PLUMED (2.9) and OpenMM-PLUMED (2.0).

& 

If I add Upper_walls or grid then after some time (depends on Kappa!!) the simulations run for a while and then crashes with Particle coordinate is NaN

Thanks much!!

Summer

[Istvan Kolossvary]

Hi Giovanni,

That is correct. I see the same(?) problem running the same job but using only METAD so I can use conda plumed. I'll post the METAD plots here. Maybe it has nothing to do with DRR.

   Istvan

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/CAPLm8ZJN4YVcUF-hh1m_V5zD_ux3uyo-WRp8ndfQg4%3DcsOiXxA%40mail.gmail.com.

[Istvan Kolossvary]

Hi Summer,

You shouldn't worry about PBC and WHOLEMOLECULES, PLUMED takes care of that automatically. What you see in your visualization is most likely just a well known artifact. Before visualizing your trajectory, you have to use a tool to correct for the periodic images. There are different ways of doing this, one is Amber's cpptraj. So, e.g., you have a PDB file and the associated trajectory file system.pdb and system.dcd. Then,

cpptraj -p system.pdb

trajin system.dcd

autoimage

strip :HOH,WAT,Cl-,K+,Na+,DUM

trajout solute.dcd

trajout solute.pdb onlyframes 1

go

quit

Stripping is useful to make the imaged trajectory only contain the solute.

Regarding the crashes you mention, I am having the same problem as you, and documenting it in this thread.

Best regards,

   Istvan

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/ebbf655e-3628-49cc-b3aa-65c01d7e7808n%40googlegroups.com.

[ikol...@gmail.com]

Giovanni,

I went full circle on this and have pretty good evidence---and I am pretty sure Summer has had the same problem with his crashes---that there must be a problem with some low-level functionality in PLUMED 2.9.0 that both DRR and METAD actions utilize. I ran 6 jobs with the same system and 3 CVs. 3 jobs using openmm 7.7, plugin 1.0, and plumed 2.8.1, and another 3 jobs using openmm 8.1.1, plugin 2.0, and plumed 2.9.0. (plumed 2.9.0 is not compatible with plugin 1.0) One set of jobs is pure metadynamics (METAD), another set is pure eabf (DRR), and the 3rd set is meta-eabf (DRR on the real CVs and METAD on the fictitious CVs). I attached 3 sets of plots, in each case the top represents plumed v2.9.0 and the bottom v2.8.1. The first is meta, the 2nd is eabf, and the 3rd is meta-eabf. I plotted data at every single time step until the NaNs appeared and eventually the job crashed. As you can see, something is going on with v2.9.0 while v2.8.1 is perfectly fine. METAD was well-tempered and used the grid.

Thanks for looking into this!

Best regards,

   Istvan

[summer houston]

Hi Istvan,

Thank you so much for taking the time to explain!

§  For my conventional MD simulations with OpenMM, I was using VMD to wrap and center the trajectories, but it did not work for MetaD simulations. I installed cpptraj and followed the steps you suggested but it did not work either. I monitored the CV in my simulation (CV.png attached) and it’s clear that it diffuses in phase-space (increases and decreases). I expect to see the same behavior when I visually inspect the simulation, if correctly wrapped and re-imaged, but the distance (CV) keeps getting bigger and bigger. I attached snapshots of protein at the beginning and end of my short simulation.  

The simulations are run with NPT. I monitored volume of the box with time, and I see noticeable fluctuations, even if the system has been minimized/equilibrated. Are these fluctuations expected with MetaD? I run MetaD simulations for my system and also the basic-exmaple shared in openmm-plumed Github: https://github.com/sukritsingh/openmm-plumed/tree/add-example/examples/basic-example This is supposed to be a working example for simple MetaD but I see the same behavior for this example as well. Two plots are attached (example_volume.png and my simulation_volume.png)

I attached the python script (MetaD.py) to run the simulations. I REALLY appreciate if you can take a quick look to see if sth catches your eye or anything important is missing. 

Thank you again!

Summer

[Giovanni Bussi]

I suspect there's a problem with PBCs during the simulation. I also think you used plumed 2.8 with the openmm plugin v1 and plumed 2.9 with the openmm plugin v2.

To me it is surprising that the problem is with plumed 2.9, so I suspect the problem is with the newer plugin (v2) that was released recently. You could test the old openmm-plumed plugin (v1) with your self-compiled plumed (2.9). If the problem disappears, it means that there is some issue with the openmm-plumed plugin. Unfortunately I am afraid the reverse test (openmm-plumed plugin v2 with plumed 2.8) is not feasible since openmm-plumed is linking plumed directly (so you cannot swap the plumed version with PLUMED_KERNEL). In any case, you can see the exact plumed version you are using in the log.

From the plots the problem seems mostly with dist 1 am I right? I see from screen.log that this is computed as a distance between centers of masses. Be careful when you select atoms for centers of mass. Are you sure that the selected atoms are such that consecutively listed atoms are close enough to each other to make it possible for plumed to reconstruct PBC correctly? If you are not familiar with the way PLUMED reconstructs the PBCs have a look at this: https://arxiv.org/abs/1812.08213 sec 2.7. Notice that different PLUMED versions have different defaults for PBC reconstruction and you can always sort it out manually with WHOLEMOLECULES. But I don't remember differences between 2.8 and 2.9.

Giovanni

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/bfab5375-8716-4d28-ab9e-2c7a7043a9e6n%40googlegroups.com.

[Istvan Kolossvary]

Thanks, Giovanni. I will look into the PBC issue. I had no idea that the algorithm might change from one version to another.

Best,

   Istvan

On Feb 7, 2024, at 2:20 AM, Giovanni Bussi <giovann...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/CAPLm8ZKeJr7pkJZRFt4zMVXzmzYFv0ny2N8EmAUbwKhUkrVMfA%40mail.gmail.com.

[Giovanni Bussi]

To be clear: i think it didn’t change between version 2.8 and version 2.9. But the description in the book chapter might be a bit outdated because when we wrote it we were in the process of adding more automatic reconstructions. They can all be removed with NOPBC flags though 

Sent from Gmail mobile

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/77FAF86E-D7C5-44D8-AABF-541076A7A4CB%40gmail.com.

[ikol...@gmail.com]

Hi Summer,

It looks like you are having the same issue that I also noticed, see Giovanni's response in this thread. I am not in a position to say what exactly is going on, please look at my plots.

Regarding volume fluctuations, in NPT it is perfectly normal, even with a fully equilibrated system. One good, practical way to go about it, is to run a medium length simulation with NPT (after equilibration), then calculate the average volume and pick a trajectory frame that has the closest volume to the average, and use that as the input for a long NVT simulation, which will be your production run.

Best,

   Istvan

[summer houston]

Hi Istvan and Giovanni,

Thanks for insightful comments. 

@Istvan, May I ask what versions of OpenMM, PLUMED and OpenMM-PLUMED plugin has worked for you in the past and how did you install them (conda? )

Thanks!

Summer

[ikol...@gmail.com]

My workhorse combo is OpenMM 7.7, plugin 1.0, and PLUMED 2.8.1, but I installed them a long time ago when they were the then latest versions. Unfortunately, with the newer versions of anaconda, CUDA, OS, etc., your only option within conda is downgrading. For example 'conda create --name openmm-plumed-old -c conda-forge openmm-plumed python=3.9' will install an older version (most likely OpenMM 8.0 and plugin 1.0 with PLUMED 2.8) but it depends on a lot of things on your computer and in my experience downgrading never works properly, likely there will be inconsistencies. You can also try 'conda create --name openmm-plumed-old -c conda-forge openmm-plumed openmm=7.7' but there are no guarantees. I myself keep my old version that works perfectly fine.

   Istvan

[summer houston]

Hi Istvan,

Thanks for the detailed info you provided! I'll give it a try.

Best regards,

Summer

[ikol...@gmail.com]

Hi Summer,

I tried it, and 'conda create --name openmm-plumed-old -c conda-forge openmm-plumed openmm=7.7' works perfectly fine (on Ubuntu 22.04) with my system that is crashing with the latest openmm-plumed. It installs openmm 7.7, plugin 1.0, and plumed 2.7.3. Moreover, I can remove the canned plumed via 'conda remove --force plumed' and than link any <v2.9.0 version of plumed that I built from source.

Hope this helps,

   Istvan

[summer houston]

Hi Istvan,

That was very informative. Thank you!

I could install it on Ubuntu (22.04.2). I have not tested yet. However, It was not successful on Mac M2 due to incompatible osx version (osx==13.6.4=0).

I have not figured out how to link other plumed versions with the plugin yet. 

Regarding the PBC issue that Giovanni mentioned: I read the User Manual carefully for both Plumed 2.8 and Plumed 2.9 and there is no difference between the PBC definitions. If your system has been working fine with Plumed 2.8 then it should work with Plumed 2.9 as well. 

in my simulations, I have solvated protein and I made sure the protein is intact across PB using WHOLEMOLECULES, but it did not help as well and still I got "Particle coordinate NaN". 

It seems that there is an issue with new plugin v2.

Thanks!

Leila

[Giovanni Bussi]

If you are sure the problem is with plugin v2 (and not with plumed 2.9 itself) then I would recommend posting it to this repository: https://github.com/openmm/openmm-plumed

Please mention me (@GiovanniBussi) if you do so because I might try to help, though I don't know much about how the plugin works.

--

You received this message because you are subscribed to the Google Groups "PLUMED users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/d358abcb-0227-4587-b94f-b06d952ba013n%40googlegroups.com.

[ikol...@gmail.com]

Hi Leila,

Unfortunately, like I said conda downgrading is a hit or miss. I am glad it worked on Ubuntu. On MacOS, unfortunately, only plugin 2.0 has arm64 binaries, so the downgrade is impossible on M2.

Regarding the linking, it is very simple. Assuming you have a working (downgraded) conda openmm-plumed environment, first remove plumed via 'conda remove --force plumed'. 'force' will make sure that only plumed will be removed and not dependencies. Then, assuming that you have built  plumed from source (which allows you to activate modules) you can use it with openmm-plumed by setting the following envars, e.g.,

export LD_LIBRARY_PATH=/home/istvan/opt/plumed-2.8.1_install/lib:$LD_LIBRARY_PATH;

export PATH=/home/istvan/opt/plumed-2.8.1_install/bin:$PATH

But remember, you cannot link plumed v2.9 with plugin 1.0, so your own plumed build must be < v2.9.

Hope this helps,

   Istvan

[summer houston]

Hi Istvan and Giovanni,

I tested my system with exact versions that Istvan suggested (OpenMM 7.7, Plugin v1, and PLUMED 2.7.3) and it runs perfectly fine (so far has made it to 340 ps and CV behaves as expected with applying upper wall. Yay!). The same simulation with OpenMM 8.1, Plugin v2 and PLUMED 2.9 crashes with "Particle coordinate NaN". Since I cannot run Plugin v1 with PLUMED 2.9, then It's hard to tell if the error is PLUMED 2.9 or Plugin v2. However, checking the User Manual and also the changes from 2.8 to 2.9 (ttps://www.plumed.org/doc-v2.9/user-doc/html/_c_h_a_n_g_e_s-2-9.html. I also attached the screen shots), the issue might be the newer version of the plugin. Please correct me if I am wrong.

I had opened an issue on openmm-plumed a week ago. I will post an update there and will mention you.

Very helpful! Thanks much @Istvan for clear explanation!

Best,

Leila

[Giovanni Bussi]

If you have a working openmm plugin v1 + plumed 2.7, you should be able to use it with a plumed 2.9 manually installed by you.

What happens if you use plumed 2.9 then? Do you receive an error?

Sent from Gmail mobile

--

You received this message because you are subscribed to the Google Groups "PLUMED users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/29ecac36-c94e-4646-bde8-23b5e40e5adcn%40googlegroups.com.

[ikol...@gmail.com]

Giovanni,

I am testing exactly that situation with openmm 7.7, plugin 1.0, and plumed 2.9.0. I can reproduce the crash. I am now writing out the trajectory frames so I can directly compare the CV values computed with 2.9.0 vs. 2.8.1. I will post the results here when the calculation is done.

   Istvan

[ikol...@gmail.com]

I have an update on this. I ran numerous tests using OpenMM 7.7-plugin 1.0-PLUMED 2.9.0 and three different biasing methods (METAD, DRR, and meta-EABF). Although, occasionally the simulations crashed it wasn't indicative of a bug, the vast majority of the jobs completed just fine. On the other hand using OpenMM 8.1 and plugin 2.0, all jobs invariably crash very quickly. My conclusion is that indeed plugin 2.0 might be the problem. Not sure how to go about it, though. Summer submitted an openmm ticket, but I don't think there was any response.

   Istvan

[summer houston]

Hi Istvan and Giovanni,

Thanks for the update! very informative. I have not posted recent updates to openmm-plumed GitHub. I do it today and will mention Giovanni. if I have your user, I'll mention you as well.  Here is my post there: https://github.com/openmm/openmm-plumed/issues/78

Best,

Leila