Coordination vs Coordinationnumber

[Djurre...@yahoo.com]

Dear,
Using Gromacs 4.6 and PLUMED2 I'm simulating a system containing 200 LJ-particles of type A and 200 of type B. A and B demix and I'm trying to use COORDINATION or COORDINATIONNUMBER to enforce mixing.

I would have expected that restraining the COORDINATION or the mean of COORDINATIONNUMBER, possibly with a different 'Kappa' would have the same effect. However, this is not the case: while constraining COORDINATION gives reasonably good results, restraining the mean of COORDINATIONNUMBER 1) still gives demixing (for low Kappa) or 2) gives unwanted behavior, like the thermostat not being able to keep the correct temperature (for high Kappa). I'm restraining COORDINATION and COORDINATIONNUMBER to their correct goal values (e.g. a factor 200 different), as observed in a free simulations where A & B do mix. I'm using the same switching function in both cases.

As an extra test I've calculated both COORDINATION and the mean COORDINATIONNUMBER for one simulation. When dividing one by the other for the interactions between A and B this gives a stable value (200, the number of particles in one group). However for this ratio calculated over interactions between A and A or B and B fluctuates over time and is not 200 (rather: 236.6+/0.8).

What is the difference between both that I am missing? If useful I can provide a MWE.

Groetnis/Best regards,
Djurre de Jong

[gareth....@gmail.com]

Hi

If you can provide the example that would be really helpful. These are obvious things I am suggesting. Sorry if they're a bit patronising. For A with A the coordination number command should be:

COORDINATIONNUMBER SPECIES=

It's only when you have A and B that you need SPECIESA and SPECIESB.

Secondly are you running with any kind of tolerance or neighbor list?

In general coordination should be faster than coordination number. However, with coordination number you can do less than, more than and between, which would not be possible with coordination.

Gareth

Sent from my iPad

--
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.

[Djurre...@yahoo.com]

Hey Gareth,
Thanks a lot for helping on this. Attached you'll find the files for the MWE. When preparing the MWE I wasn't able to reproduce some of yesterdays problems, but part remains. Sorry about that... I did indeed specify SPECIESA/B separately, but I've checked and it doesn't matter for the results. I'm not using a neighborlist or anything like that right now.

With the files provided (simple.top, simple.mdp, LJ400.gro, plumed.dat) I've simulated a mixed system, measuring COORDINATION and COORDINATIONNUMBER.mean between AA, BB and AB. For COORDINATION.mean the average for all is 5.5, for COORDINATION the averages are 1292,1292 and 1099, for AA,BB and AB respectively. Dividing the datasets shows fluctuations for AA and BB, but steady value of 200 for AB.

Next, changing the the interaction between A&B in simple.top (comment the other line), the system will demix. By un-commenting one of the restraint sections in plumed.dat I restrain the mixing either via COORDINATION or COORDINATIONNUMBER. The given kappas (0.1 vs 4000) give (rather) good results and as I understand it, it is logical that they are factor 200^2 different? However, the results for AB are almost the same, while for AA/BB they differ. Using kappa 0.2 vs 8000 also AB starts to differ, with COORDINATIONNUMBER.mean giving results closer to the goal.

The problems with thermostatting etc. I reported yesterday in the case of COORDINATIONNUMER I can not reproduce and might be due to the fact I also restraint some higher moment in that run. Again sorry for that.

[Gareth Tribello]

Hello

I have found a problem. As you know your system better would you mind
testing how this works with your restraints and reporting back.

The problem is with COORDINATION. If you write:

COORDINATION GROUPA=1-2 GROUPB=1-2 etc

Then the coordination is calculated as:

s(r_11) + s(r_12) + s(r_22)

where r_11 is the distance between atom 1 and itself (i.e. zero), r_12
is the distance between atoms 1 and 2 and r_22 is the distance between
atom 2 and itself (i.e. zero). As a consequence if atoms 1 and 2 are
within the cutoff of your switching function the coordination is
measured (in my view wrongly) as 3.

By contrast if you use COORDINATIONNUMBER you correctly find that the
average coordination numbers of atoms 1 and 2 is 1. This is regardless
of whether or not you use SPECIES or SPECIESA/SPECIESB.

This is why if I take your plumed.dat file:

AA: COORDINATION GROUPA=1-200 GROUPB=1-200 R_0=0.1 D_0=0.55
AAn: COORDINATIONNUMBER SPECIES=1-200 R_0=0.1 D_0=0.55 MEAN

and do the calculation you suggest:

AA / AAn.mean

you don't get the expected 200. To get 200 you have to do the following:

(AA - 200 ) / AAn.mean

The 200 is removing all the spurious bonds between atom 1 and itself,
atom 2 and itself and so on. (I tried this - it works).

I think this is a bug but it is one that I am not certain how to fix. (I
didn't write COORDINATION I wrote COORDINATIONNUMBER). Unfortunately I
think the fix we come up with might be to put a warning or error in the
output if you try to do this. I can't see anyway to make COORDINATION
ignore bonds between atoms and themselves, which wont affect the
performance of the routine. Also I don't think the majority of users
don't do this sort of thing).

Anyway, point is if you set the AT values for these sort of restraints to:

200*5.5 + 200

The behaviour with COORDINATION and COORDINATIONNUMBER should be the same.

Thanks for pointing this out

Gareth

[Giovanni Bussi]

Hi all,

a quick comment on the behavior of COORDINATION.

I think the fix to avoid double counting is simple, I can add it (I mean: to skip identical pairs in the double sum of COORDINATION).

Anyway, the real fix would be to add the possibility to do COORDINATION on a *single* group (all with all, except with itself). This could be done exploiting a feature that I think is already available in the neighbor list and that should allow for a 50% cut in the computational cost, by avoiding to compute both (i,j) and (j,i) terms.

I add this to the list of required features on github.

Ciao!

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+unsubscribe@googlegroups.com.

[Djurre de Jong-Bruinink]

Hi Gareth, Giovanni,
Thanks for solving this problem.

I've checked and the COORDINATION and COORDINATIONNUMBER.mean can indeed be converted by using (AA-200)/200 = AAn. Using the corresponding numbers for the restraints I do get very similar behavior for COORDINATION and COORDINATIONNUMBER.mean, but not the same (not the same = significantly different). But that might be due to the choice of Kappa, which I currently choose a factor of 40,000 (=N^2) different. This is more or less right, but maybe also not exactly.

About the code of COORDINATIONNUMBER. I saw that there is some start of a neighborlist there. Did you decide not the implement it to reduce the time need to write/debug/maintain or is there some other specific difficulty that makes it impossible?

Best regards,
Djurre

 

****************************************
Djurre H. de Jong, PhD
Westfälische Wilhelms-Universität Münster
Institut für Physikalische Chemie
Corrensstr. 28/30
D-48149 Münster
*****************************************

---

From: Giovanni Bussi <giovann...@gmail.com>
To: "plumed...@googlegroups.com" <plumed...@googlegroups.com>
Sent: Friday, 31 January 2014, 19:08
Subject: Re: [plumed-users] Coordination vs Coordinationnumber

--
You received this message because you are subscribed to a topic in the Google Groups "PLUMED users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/plumed-users/n3DXMXHKls4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to plumed-users...@googlegroups.com.

[Gareth Tribello]

Hello

For the neighbour list the situation depends on the particular version you are using.  I had the neighbour list hidden in v2.0 because it wasn’t very thoroughly tested.  On top of this I changed the way it works in the master version of the code - so in version 2.1 the code will be different.  It still isn’t as thoroughly tested as I would like it to be and I am still not 100% happy with the way it works. (Ideally I would have it work out when it needs to be updated instead of having the user specify a frequency of update.)  All that said it should work.  So if you want to download the master version of the code (instructions on the website), recompile and give it a try be my guest.  I also have some instructions, which I can send you if you need them.

Thanks

Gareth

To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.