RESTRAINED dynamic perfomances on a Plumed(2.0b1) version of LAMMPS.

[matteo amabili]

Dear all,
I am using a plumed (v2.0b1) version of LAMMPS.
What that I need is to calculate the number of particle in a specified part of the simulation box and to run a restrained dynamic using this value.
To do that I am using the following input file:

DENSITY SPECIES=35344-81070 LABEL=c
AROUND ARG=c ATOM=1 YLOWER=0 YUPPER=38.5  SIGMA=0.01  LABEL=s
RESTRAINT ARG=s AT=2400 KAPPA=0.2 LABEL=rest
PRINT ARG=s STRIDE=50 FILE=colvar

Where ATOM=1 can be considered fixed.
To check the parallel performance of plumed I run some test (on CINECA Fermi) and i see the following result.
The code has good performance if NO RESTRAINT is applied to the system (so I do only the DENSITY check and the PRINT), instead if I apply the RESTRAINED the simulation time is increased of a factor 20 respect to the previous one and plumed use order 90% of all the time-machine.
I know that i am asking plumed to do a big work on order 40000 atoms (...i am also using order 1024 MPI process), but from my test seem that there are some problem only in the communication from PLUMED to LAMMPS, while the communication in in the other direction seems good.
So I would like to Know if there are some experience of this problem  with other MD engine (GROMACS...)  or if the other MD engine work fine with colvar similar to mine.
There are any suggestion to fix this on LAMMPS ?
Moreover I expect that, on the big amount of the atoms that i check, only a small portion of it will have a restrained force different from 0 so is there any way in which i can tell to plumed to not send this force to LAMMPS.
Thanks in advance for any reply.
Best Regards.

Matteo.

[Giovanni Bussi]

Hi,

the reason why with no force you have no penalty is that in that case plumed computes the variable (and ask the atoms to lammps) only when you print it (every 50 steps in your case). If you try with PRINT STRIDE=1, you will probably get a similar overhead with/without restraint.

Concerning the overhead: it is due to the fact that you are asking lammps too many atoms. I think Gareth was working on some trick to use sort of neighbor list also on these kinds of variables, so as to only ask for the relevant atoms at each step, but I am not sure this is already in the public version.

Hope this helps,

regards,

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 post to this group, send email to plumed...@googlegroups.com.
Visit this group at http://groups.google.com/group/plumed-users.
For more options, visit https://groups.google.com/groups/opt_out.