Plumed can't seem to read input file plumed.dat

516 views
Skip to first unread message

sohang kundu

unread,
May 23, 2024, 5:35:06 PM5/23/24
to PLUMED users
Hi everyone, 
I have just installed PLUMED 2.9, and patched it in with Quantum ESPRRESSO 7.0. 
I was trying to run metadynamics for a standard SN2 reaction from the plumed tutorials on the internet. But it seems I can't get plumed to read the plumed.dat file. I am getting error messages that look like the following: 


terminate called after throwing an instance of 'PLMD::ExceptionError'

  what():

(core/PlumedMain.cpp:823) void PLMD::PlumedMain::readInputWords(const std::vector<std::__cxx11::basic_string<char> >&)

ERROR

I cannot understand line: HILLS HEIGHT 0.001 W_STRIDE 2

Maybe a missing space or a typo?

forrtl: error (76): Abort trap signal


And


terminate called after throwing an instance of 'PLMD::ExceptionError'

  what():

(core/Action.cpp:243) void PLMD::Action::error(const string&) const

ERROR in input to action PRINT with label @0 : cannot understand the following words from the input line : W_STRIDE, 1

forrtl: error (76): Abort trap signal


Clearly plumed seems to be running because the PLUMED.OUT file is generated and it looks something like this:


PLUMED: PLUMED is starting

PLUMED: Version: 2.9.0 (git: Unknown) compiled on May 23 2024 at 15:48:48

PLUMED: Please cite these papers when using PLUMED [1][2]

PLUMED: For further information see the PLUMED web page at http://www.plumed.org

PLUMED: Root: /burg/home/sk5389/opt/lib/plumed

PLUMED: For installed feature, see /burg/home/sk5389/opt/lib/plumed/src/config/config.txt

PLUMED: Molecular dynamics engine: qespresso

PLUMED: Precision of reals: 8

PLUMED: Running over 1 node

PLUMED: Number of threads: 1

PLUMED: Cache line size: 512

PLUMED: Number of atoms: 6

PLUMED: File suffix:

PLUMED: FILE: plumed.dat

PLUMED: Action PRINT

PLUMED:   with label @0

PLUMED:   with stride 1

PLUMED:   on plumed log file

PLUMED:   with format  %f

PLUMED: ERROR in input to action PRINT with label @0 : cannot understand the following words from the input line 



And for clarity, my plumed.dat file was:


HILLS W_STRIDE 2 HEIGHT 0.001

PRINT W_STRIDE 1

DISTANCE LIST 1 3 SIGMA 0.3

DISTANCE LIST 2 3 SIGMA 0.3

UWALL CV 1 LIMIT 7.0 KAPPA 100.0

LWALL CV 1 LIMIT 2.5 KAPPA 100.0

UWALL CV 2 LIMIT 7.0 KAPPA 100.0

LWALL CV 2 LIMIT 2.5 KAPPA 100.0

ENDMETA


Any idea what this issue could be about?


Best, 


Sohang

Giovanni Bussi

unread,
May 23, 2024, 5:37:28 PM5/23/24
to plumed...@googlegroups.com
Please check the manual for plumed 2. You are using the syntax for plumed 1

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/57475afa-7e4e-4b83-9b5a-db0b29b9e613n%40googlegroups.com.

sohang kundu

unread,
May 24, 2024, 1:35:36 AM5/24/24
to PLUMED users
Thanks so much! 

sohang kundu

unread,
May 26, 2024, 10:23:41 AM5/26/24
to PLUMED users
Hi, 

I am getting an error like this from using Plumed 2.9 with Quantum ESPRESSO 7.0  where out of 46 total atoms, I have frozen 27 (by using zeroes in the QE in put file). Plumed killed the PWMD run after its first SCF cycle with the following error message. Does anyone know where this might be coming from? I don't want to set the type safe check to ignore=yes, without understanding if my MD settings were wrong or incompatible. 

This command wants to access 46 from this pointer, but only 10 have been passed

PLUMED: If you are sure your code is correct you can disable this check with export PLUMED_TYPESAFE_IGNORE=yes

PLUMED: In case this is necessary, please report an issue to developers of PLUMED and of the MD code

PLUMED: See also https://github.com/plumed/plumed2/pull/653


Thanks! 
Best, 
Sohang

Giovanni Bussi

unread,
May 26, 2024, 10:26:29 AM5/26/24
to plumed...@googlegroups.com
Hi it looks there might be a problem.

You can try to use DUMPATOMS to see if the array with positions is passed correctly, after having set the environment variable to skip the test. In any case we should have a look at this, would you mind sharing a complete input (both QE and plumed)?


Thanks!

Sent from Gmail mobile


sohang kundu

unread,
May 26, 2024, 10:45:05 AM5/26/24
to PLUMED users
Hi Dr. Bussi, 

Thanks! I have since found that the problem persists even in a simpler calculation (I attached the input files from QE and plumed below). 
It seems no matter what, 10 positions are passed. I confirmed using a simpler tutorial that when the # atoms <= 10 this issue does not exist. So, there is a size issue of the array perhaps?

Also, using something like this runtime modification is not disabling the check. How should I disable it?

pw.x -plumed export PLUMED_TYPESAFE_IGNORE=yes < PW.in > PW.out


Best, 
Sohang
plumed.dat
PW.in
R.pdb

sohang kundu

unread,
May 26, 2024, 12:57:22 PM5/26/24
to PLUMED users
And is there an older version of PLUMED that I can use (that is free of this error)  until this issue is fixed?

Thanks!

Giovanni Bussi

unread,
May 26, 2024, 1:04:43 PM5/26/24
to plumed...@googlegroups.com
You should first export the env var then run pw.x

Sent from Gmail mobile


sohang kundu

unread,
May 26, 2024, 1:34:27 PM5/26/24
to PLUMED users
Yes, sorry. I did figure that out. The code runs now and I can confirm that indeed all 11 atoms are getting printed using DUMPATOMS in a .xyz file. So, I am not sure if something is wrong. Maybe the flag is not of consequence?

Sohang

Giovanni Bussi

unread,
May 27, 2024, 7:10:42 AM5/27/24
to plumed...@googlegroups.com
Could you please run again with the following variables set:

export PLUMED_TYPESAFE_DEBUG=yes # will add some info about information passed from QE to plumed
export PLUMED_STACK_TRACE=yes # will show where in the code the error is triggered
export -n PLUMED_TYPESAFE_IGNORE # '-n' is 'unexporting' so that the code crashes in the right point

The code will crash. If you paste here what you see on the standard error we can try to understand better. There should be:

- a full stack trace (explaining the chain of function calls before the crash), included in the error message
- a series of lines beginning with "+++ PLUMED_TYPESAFE_DEBUG" that report all the messages sent to PLUMED.

Thanks

Giovanni


 

Daniele Rapetti

unread,
May 27, 2024, 10:54:57 AM5/27/24
to PLUMED users
Hi!
I dived into the problem:
If you export PLUMED_TYPESAFE_DEBUG=yes you should get an output like:

+++ PLUMED_TYPESAFE_DEBUG setRealPrecision 0xcbc354 0 ( 1 ) 4030004 (nil)
+++ PLUMED_TYPESAFE_DEBUG setMDEnergyUnits 0x7ffc19af5c50 0 ( 1 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG setMDLengthUnits 0x7ffc19af5c58 0 ( 1 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG setMDTimeUnits 0x7ffc19af5c60 0 ( 1 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG setPlumedDat 0xcbc26e 0 ( 11 ) 4030001 (nil)
+++ PLUMED_TYPESAFE_DEBUG setLogFile 0xcbc286 0 ( 11 ) 4030001 (nil)
+++ PLUMED_TYPESAFE_DEBUG setNatoms 0x17c4358 0 ( 1 ) 4030004 (nil)
+++ PLUMED_TYPESAFE_DEBUG setMDEngine 0xcbc2a6 0 ( 9 ) 4030001 (nil)
+++ PLUMED_TYPESAFE_DEBUG setTimestep 0x1464590 0 ( 1 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG init 0xcbc358 0 ( 1 ) 4030004 (nil)
+++ PLUMED_TYPESAFE_DEBUG setStep 0x15ada7c 0 ( 1 ) 4030004 (nil)
+++ PLUMED_TYPESAFE_DEBUG setMasses 0x17c45a0 0 ( 10 ) 4040008 (nil)          <----- 10 masses
+++ PLUMED_TYPESAFE_DEBUG setForces 0x2cf1290 0 ( 11 3 ) 4040008 (nil)         <----- 11 forces
+++ PLUMED_TYPESAFE_DEBUG setPositions 0x36c44e0 0 ( 11 3 ) 4040008 (nil)     <----- 11 positions
+++ PLUMED_TYPESAFE_DEBUG setBox 0x7ffc19af5ce0 0 ( 3 3 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG setVirial 0x7ffc19af5d30 0 ( 3 3 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG setEnergy 0x12f1c68 0 ( 1 ) 4040008 (nil)
+++ PLUMED_TYPESAFE_DEBUG calc 0xcd1188 0 ( 1 ) 4030004 (nil)

The problem may be on our side, since the release version 2.9.0 does not have the qe patch corrected for the masses that is in the v2.9 development branch

If you can compile plumed and qe the fastest solution is to substitute the plugin_ext_forces.f90 file in the src/ directory of quantum espresso with the updated one:
and recompile qe no need to recompile plumed

In this case, I recommend you to patch because PLUMED_TYPESAFE_IGNORE will make plumed read wrong values for the masses


I hope this can be helpful
Ciao
Daniele

sohang kundu

unread,
May 27, 2024, 12:35:54 PM5/27/24
to PLUMED users
I don't mind reinstalling Plumed or QE either. Is there a combination of slightly older Plumed and slightly older QE that works perfectly? I would be interested in using those for the time being. 
Sohang

sohang kundu

unread,
May 27, 2024, 12:36:02 PM5/27/24
to PLUMED users
Hi,  Thanks for all your help. I am seeing new errors during compilation of QE now.
To avoid old dependencies, here is that I did: I -
1. Re-extracted QE 7.0 from tar ball
2. Replaced the plugin_ext_forces.f90 file in QE/PW/src/
3. "/configure" in QE folder
4. "plumed patch --engine qespresso-7.0 -p" in QE folder
5. "make pw" 

At this point I got the error: 

make[2]: *** No rule to make target '@plumed_module@', needed by 'plugin_ext_forces.o'.  Stop.

make[2]: Leaving directory '/burg/berkelbach/users/sk5389/builds/qe-7.0/PW/src'

make[1]: *** [Makefile:12: pw-lib] Error 1

make[1]: Leaving directory '/burg/berkelbach/users/sk5389/builds/qe-7.0/PW'

make: *** [Makefile:167: pwlibs] Error 1


Just to make sure you said I DID NOT have to touch the plumed directory, right?

On Monday, May 27, 2024 at 10:54:57 AM UTC-4 Daniele Rapetti wrote:

sohang kundu

unread,
May 28, 2024, 3:39:06 AM5/28/24
to PLUMED users
I cloned and compiled the development version of plumed from https://github.com/plumed/plumed2 (and qe 7-0) and recompiled everything from scratch. Now, I no longer need the tyesafe_ignore=yes flag for the code to be running. I am hoping things are fine now?

Giovanni Bussi

unread,
May 28, 2024, 4:02:55 AM5/28/24
to plumed...@googlegroups.com
Yes this is correct.

But in this way you are using master branch that might be not fully stable yet. It's up to you. If you prefer to use a stable version you could do the same procedure cloning branch v2.9, which already contains a lot of fixes (including the QE fix on masses). We will release 2.9.1 in the nest few days, virtually identical to what v2.9 looks like today

Giovanni


Reply all
Reply to author
Forward
0 new messages