Biasing Coordination number slowing down the simulation by 3+ times, using plumed+gromacs-5.0?

[ert...@gmail.com]

Hello,

I recently started to use plumed with gromacs-5.0. I wish to bias the coordination number around one particular atom.

So I constructed the following input file:

COORDINATIONNUMBER …

SPECIESA=1

SPECIESB=223-53763:3

R_0=0.02 NN=6 MM=12 D_0=0.6 MEAN

LABEL=coord

... COORDINATIONNUMBER

RESTRAINT ARG=coord.mean AT=0 KAPPA=0.03 LABEL=restraint

PRINT STRIDE=50 ARG=coord.mean,restraint.bias FILE=COORDNUM

I only run a short simulation to test the performance, and here is the result:

               Core t (s)   Wall t (s)        (%)

       Time:    32532.155     1017.831     3196.2

                 (ns/day)    (hour/ns)

Performance:        8.489        2.827

Finished mdrun on rank 0 Tue May 12 15:34:42 2015

PLUMED:                                               Cycles        Total      Average      Minumum      Maximum

PLUMED:                                                    1   723.226073   723.226073   723.226073   723.226073

PLUMED: 1 Prepare dependencies                         50001     0.219346     0.000004     0.000002     0.000070

PLUMED: 2 Sharing data                                 50001   257.314090     0.005146     0.004629     0.026956

PLUMED: 3 Waiting for data                             50001     1.011431     0.000020     0.000015     0.000167

PLUMED: 4 Calculating (forward loop)                   50001   357.458783     0.007149     0.005880     0.061370

PLUMED: 5 Applying (backward loop)                     50001   104.026062     0.002080     0.001102     0.005409

I noticed that the total simulation time is only ~1000 seconds, while the plumed process takes 723 seconds (70% of the total time!).

I understand that in calculating the coordination number, a large number of distances needs to be computed which may cost a lot of time.

However, the sharing data section also takes 257 seconds and the applying section takes 104 seconds, which is comparable to the calculation section. 

This significant slowdown seems unreasonable to me. I don't get why sharing and applying data take so much time in the simulation...

Could you give me some ideas what might go wrong in this simulation? Thank you!

Best,

Erte Xi

[Gareth Tribello]

Hello

For calculating a coordination number COORDINATIONNUMBER is not your best option.  I know how perverse that sounds but COORDINATIONNUMBER really only works best when you want to calculate a large number of coordination numbers and calculate the number that are more than a certain value or something similar.

As an alternative you can try either DISTANCES combined with LESS_THAN:

http://plumed.github.io/doc-v2.1/user-doc/html/_d_i_s_t_a_n_c_e_s.html

Or COORDINATION:

http://plumed.github.io/doc-v2.1/user-doc/html/_c_o_o_r_d_i_n_a_t_i_o_n.html

In both these cases (but especially with DISTANCES) you will get better performance if you specify your switching function using:

SWITCH={RATIONAL D_0=0.6 R_0=0.02 NN=6 MM=12 D_MAX=0.8 STRETCH}

What the various keywords in this command are doing is explained here:

http://plumed.github.io/doc-v2.1/user-doc/html/switchingfunction.html

Lastly, if you want to better understand the logic within COORDINATIONNUMBER and DISTANCES you might consider watching this short video.

https://www.youtube.com/watch?v=iDvZmbWE5ps 

Let us know if using these ideas helps speed up your calculation and by how much if possible.

Thanks

Gareth

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/80358357-669b-4a50-8850-d6b57dce7d2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Giovanni Bussi]

Hi all

in this case (1 atom against many)  the problem is mostly with the sharing of atomic positions. Obviously not all the water oxygens are required at every step, but only those that are close to atom 1. I would suggest to use one of the actions that implement neighbor lists.

For COORDINATION: have a look at how to setup neighbor lists. Be careful with the stride and with the cutoff. I suggest you to set D_MAX STRETCH and to verify that with or without neighbor lists you get identical results. Cutoff should be significantly larger than D_MAX.

For DISTANCES: I am not very familiar with this. Gareth, perhaps can you specify in which cases this is done with a neighbor list? Notice that Verlet cells won't help much in this case (all atoms are needed anyway at each step, and the cost of sharing won't change).

Giovanni

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/E5941267-AB67-43CD-8A1D-83037511929D%40gmail.com.

[Gareth Tribello]

Hello

The neighbour list is not implemented in DISTANCES so if you want to cut down the cost for the sharing then you are probably better off using COORDINATION.  Implementing neighbour lists is something that is on my to do list.  However, it’s not really my priority as it is difficult to do this in a generic way across all of multicolvar and implementing something that only works in the relatively simple case for DISTANCES is pointless as that functionality is already there in COORDINATION.

Gareth

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

[Erte Xi]

Hi all,

Thanks so much for the advices! 

I just tried to use COORDINATION with D_MAX=0.8 and NLIST every 10 steps, and it did save a lot of time:

Core t (s)   Wall t (s)        (%)

       Time:    11839.387      370.419     3196.2

                 (ns/day)    (hour/ns)

Performance:       23.325        1.029

Finished mdrun on rank 0 Thu May 21 16:56:37 2015

PLUMED:                                               Cycles        Total      Average      Minumum      Maximum

PLUMED:                                                    1   101.179925   101.179925   101.179925   101.179925

PLUMED: 1 Prepare dependencies                         50001    22.197908     0.000444     0.000017     0.007196

PLUMED: 2 Sharing data                                 50001    38.337150     0.000767     0.000158     0.048422

PLUMED: 3 Waiting for data                             50001     0.756165     0.000015     0.000010     0.001437

PLUMED: 4 Calculating (forward loop)                   50001    28.738192     0.000575     0.000072     0.012183

PLUMED: 5 Applying (backward loop)                     50001     9.194136     0.000184     0.000044     0.002676

Now the plumed process costs ~100 seconds instead of ~700 seconds before.

I have some concerns about the stride of the neighbour list though, as a fixed stride can lead to errors, is there a dynamic neighbout list algorithm (like Verlet list?)available in plumed?

Thank you again for the helps!

Best,

Erte Xi

[Giovanni Bussi]

Hi,

you said you used D_MAX=0.8. How about NL_CUTOFF? What really matters is their difference. Check e.g. what gromacs uses as a buffer for Verlet lists and the stride for their update, then maybe stay on the safe side (e.g. divide that stride by 2). In any case, do some test to be sure that coordination does not depend on these parameters

About automatic updates of the neighbor list: This is not available (not yet). Anyway, notice that in your case this would not help very much, since in this 1 vs many calculation a large fraction of the cost is in retrieving the many atoms from gromacs. Actually, computing the displacement of each atom to know if it is worthwhile updating the list (as described in Allen-Tildesey) would be almost as expensive as recomputing the coordination number.

Giovanni 

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/418ee7f2-ae3a-40fa-a731-2abdeb365e79%40googlegroups.com.