Plumed & DL_POLY

[l.ch...@gmail.com]

Hi,

I have heard so many good things about Plumed so I am trying to find out how I can also use it. One immediate problem is: It seems to me that Plumed 2 does not support DL_POLY which is the MD code I have been using. So, could anyone please offer some help here? I suppose there might have already been some ways of patching Plumed 2 with DL_POLY... By the way, is there any scope that DL_POLY will be supported in a near-future version of Plumed? If not, I might consider seriously changing to a different MD code.

Many thanks in advance,

Linc

[Gareth Tribello]

Hello

Which version of dlpoly are you using?  I have a patch for 2 and am in the process of testing a patch for 4.  I would be more than happy to share either of these with you.

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/09bac058-2c2e-4d0e-af58-5d0f65722e44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[l.ch...@gmail.com]

Hi Gareth,

Thank you so very much for your reply! Ideally, it is a patch for 4, as this is the one I am using. If you wanted, please feel free to e-mail me (lc...@liverpool.ac.uk) - I'd be delighted to give you more information on the things I am wishing to do and/or how I could receive your patch.

Many thanks,

Linc

[rlke...@gmail.com]

Hi Gareth,

I would also like to try out Plumed 2 with DL_POLY 4.04. I've already put a lot of time into modifying the DL_POLY code to suit our needs so I'm reluctant to use a different MD code. Have you had any luck with your Plumed 2 patch with DL_POLY 4, and would you be willing to share? I would be forever grateful!

Kind regards,

Rachel

[Gareth Tribello]

Hello

Here is the stuff to patch dlpoly 4.  Unzip this file inside the directory:

plumed2/patches

Then go to your version of dlpoly and type the following command

source $(PATH_TO_PLUMED)/sourceme.sh

plumed patch -p --runtime

You then recompile dlpoly and it should be possible to call plumed by adding the single word plumed on a line in the CONTROL file.  The only thing is that you need to make sure you source the plumed2/sourceme.sh file whenever you try to use dlpoly with plumed and your plumed input file must be called plumed.dat

Email if you have any further questions.

Gareth

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/d7f14a21-dd27-4189-9850-dc1ef8f1e220%40googlegroups.com.

[simon.bo...@gmail.com]

Hi Gareth,

I must've missed this post before. I actually went ahead and also wrote the nesseccary diff files (albeit for DL_POLY 4.07) myself before seeing this. I've scanned over your code and we essentially have the same changes (mine differs slightly in that you can assign the name of the plumed data file).

I noticed however that your code seems to have the same issues as mine, and I was wondering if you've come across the same things when doing your testing:

At the end of the simulations, I keep getting the error:

*** Error in `./DLPOLY.Z': free(): invalid pointer: 0x0000000002d730a0 ***

when calling plumed_f_gfinalize. I've tried doing a bit of searching but can't hunt down what's causing it. The plumed output files seem to be saved ok so I guess something is going wrong in PLUMED's finalizer. Have you come across this?

Also, I think there is an issue with the virial code. I ran the test suggested in http://plumed.github.io/doc-v2.1/developer-doc/html/_how_to_plumed_your_m_d.html and the volumes between the run at 1 bar and 1001 bar for my system differed markedly (at least I assume 130nm^3 is considered marked?). Any thoughts on this?

Thank you,

Simon Boothroyd

[Giovanni Bussi]

Hi!

About the pointer: are you sure you are not calling plumed_f_gfinalize() twice?

About the virial: notice that in the plumed.dat you should use nm/kj units for the instructions to be correct. Plumed assumes the "virial" variable to contain something like (-x_i*f_j). You should try to track the virial in dlpoly to find how dlpoly defines it. Actually, what plumed assumes is thus the "virial" variable to contain twice the virial.

Giovanni

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/0e246e07-76a6-49a2-bc85-22609cee5708%40googlegroups.com.

[simon.bo...@gmail.com]

Hi Giovanni,

Thanks for the speedy reply!

There is definitely only one apperance of plumed_f_gfinalize() in the code. I've alse tried making a few additions to my code to ensure that it is only being called from the primary node, and only called once (This is the first time i've programmed in FORTRAN so it is possible these checks are failing). Are there any safety checks in the method itself to ensure the global variable hasn't already been disposed of?

I think part of the problem is that I'm confused about what PLUMED is actually expecting when I call setVirial. In almost all of the other code patches, the virial is passed as a 3x3 matrix. Is this the expected format? If so what does PLUMED expect the elements to be? As far as I can tell dl poly only stores the total virial as a scalar, which is just the sum of the bond, dihedral... etc contributions to the virial (also scalars).

Interestingly I noticed Gareth simply passed the stress tensor as the virial. I wondered what the motivation behind this was?

Thank you,

Simon Boothroyd

[thatengl...@gmail.com]

Just to note my suspicion that finalize was being called from multiple processes appears to be correct, and I have now remedied this. That just leaves the virial issue..

[Giovanni Bussi]

PLUMED expects to receive a 3x3 array that contains the sums of -x_i*f_j.

I think if the variable is named "stress" and contains the stress as defined here (http://en.wikipedia.org/wiki/Virial_stress) then you need to multiply times 2V.

Namely:

multiply stress by 2V

pass it to plumed

divide stress by 2V

Notice that this will only work with finite V (that is you need a special case for system without pbc).

Also notice that if the stress in dlpoly contains also the kinetic part already, then ENERGY CV in PLUMED will not work properly. Indeed, PLUMED assumes that only the potential part of the stress is passed.

Finally, remember that arrays should be transposed when passing from C to FORTRAN.

Hope this helps!

Giovanni

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/e9f676a2-d442-4ccb-aa5b-bca02f69ecc2%40googlegroups.com.

[simon.bo...@gmail.com]

I've just done some testing to make sure the multithreading is working correctly, and it seems when enabled there is an issue with the position data. 

I set up a simple test system with nine atoms and a basic plumed.dat file as a test case:

d1: POSITION ATOM=1

d2: POSITION ATOM=2

d3: POSITION ATOM=3

d4: POSITION ATOM=4

d5: POSITION ATOM=5

d6: POSITION ATOM=6

d7: POSITION ATOM=7

d8: POSITION ATOM=8

d9: POSITION ATOM=9

 

PRINT ARG=d1.x,d1.y,d1.z FILE=COLVAR1 STRIDE=1 

PRINT ARG=d2.x,d2.y,d2.z FILE=COLVAR2 STRIDE=1 

PRINT ARG=d3.x,d3.y,d3.z FILE=COLVAR3 STRIDE=1 

PRINT ARG=d4.x,d4.y,d4.z FILE=COLVAR4 STRIDE=1 

PRINT ARG=d5.x,d5.y,d5.z FILE=COLVAR5 STRIDE=1 

PRINT ARG=d6.x,d6.y,d6.z FILE=COLVAR6 STRIDE=1 

PRINT ARG=d7.x,d7.y,d7.z FILE=COLVAR7 STRIDE=1 

PRINT ARG=d8.x,d8.y,d8.z FILE=COLVAR8 STRIDE=1 

PRINT ARG=d9.x,d9.y,d9.z FILE=COLVAR9 STRIDE=1 

For some reason, when multithreading is enabled it seems like all of the atom indices are off by 1. To elaborate, COLVAR1 incorrectly contains a list of all zeros, COLVAR2 contains the correct coordiantes of atom 1, COLVAR3 contains the correct coordinates of atom 2..  COLVAR9 contains the correct coordinates of atom 8.

I thought this might be an issue with the values I pass to setAtomsNlocal and setAtomsGatindex however they seem fine.

As an example: for the first frame all atoms are located entirely on the first node. AtomsNlocal is set to 9 and AtomsGatindex is set to {1,2,3,4,5,6,7,8,9}

I thought the plumed wrapper handled the descrepancy of FORTRAN arrays starting at 1 and C++ arrays starting at 0? I tried to subtract 1 from all sent indices myself in code, however this caused PLUMED to crash.

Do you have any thoughts on what might be causing this to happen?

Thank you,

Simon Boothroyd

[simon.bo...@gmail.com]

Perhaps some more information would be useful:

I think 'crash' was the wrong term to use - 'hang' seems more appropriate as no error is generated and the code does not terminate.

I've managed to track down where the code begins to hang. In the justApply method (PlumedMain.cpp) section 5C Update there is a loop which updates all actions.

As far as I can tell, it is (*p)->update which is hanging. It hangs on the first call. 

This seems very strange as I can't find any reference in code to the POSTION colvar even implementing the update method. I tried using a VOLUME colvar instead but the hang still occurs. Further, why would subtracting one from all indices cause an issue here?

I have tried using the latest git build and the new setAtomsFGatindex method but this yields the same results.

Any thoughts on this would be much appreciated.

Thank you,

Simon Boothroyd

[simon.bo...@gmail.com]

Ok I think I have FINALLY managed to track this issue down! My last guess with the update was way off, and the code I was using to debug plumed was insufficient.

The issue lies in Atoms.cpp with the shuffledAtoms variable:

Passing the array using setAtomsGatindex without subtracting one from all values meant that, in Atoms::setAtomsGatindex, 

if(gatindex[i] != i) 

Is always true (as gatindex[i] == i+1) and hence shuffledAtoms is always true.

When I correct the indices, this statement now behaves as intended - thus shuffledAtoms can have a value of false.

For some reason when shuffledAtoms == false, the code began to hang on the:

dd.Recv(&dd.indexToBeReceived[count],dd.indexToBeReceived.size()-count,i,666,status);

line in Atoms::wait(). Why this happens I'm not sure - I should note that I'm pretty sure this issue will only occur when a domain has zero atoms and hence is quite subtle to detect.

Simply setting shuffledAtoms always to be true seems to have completely fixed the issue. As far as I am aware, this is an internal bug in PLUMED.

My question is: what are the ramifications to shuffledAtoms always being true?

Am I correct in thinking that the only difference will be in performance, and not in the actual results?

Thank you,

Simon Boothroyd

[Giovanni Bussi]

The "ramification" is needed since LAMMPS scrambles atom order.

Did you try with setAtomsFGatindex without changing the atom index? Or you can check the patch that Gareth posted.

Giovanni

[simon.bo...@gmail.com]

I'm sorry if I didn't make it clear - I am now using setAtomsFGatindex without changing the atom index. Whether I changed the atom index in FORTRAN and use setAtomsGatindex OR leave the atom index as it is and use setAtomsFGatindex the hang occured for the reason I explained above. shuffledAtoms must be set to TRUE for the hang not to occur.

I checked out Gareths patch and unfortunately it suffers from all the same issues which I have encountered (and hopefully fixed now).

I understand that the shuffledAtoms is needed in the case of LAMMPS, but what are the consequences of it always being TRUE? Is the only consequence that the performance will be slightly lower as pre-sorted atoms may be sorted again? 

There is definitely an issue occuring when shuffledAtoms is set to FALSE, and possibly is connected to having domains which are empty. A full description is given in my previous post. As far as I can tell this needs to be filed as a bug in PLUMED itself.

Thank you,

Simon Boothroyd

[Gareth Tribello]

Hello

Firstly, sorry for not replying to earlier emails on this thread.  

Anyway, I have to confess to being a bit confused still by your emails.  In Atoms::setAtomsGatIndex you have the following code:

if(fortran){

      for(unsigned i=0;i<gatindex.size();i++) gatindex[i]=g[i]-1;

  } else {

      for(unsigned i=0;i<gatindex.size();i++) gatindex[i]=g[i];

  }

  for(unsigned i=0;i<dd.g2l.size();i++) dd.g2l[i]=-1;

  if( gatindex.size()==natoms ){

      shuffledAtoms=false;

      for(unsigned i=0;i<gatindex.size();i++){

          if( gatindex[i]!=i ){ shuffledAtoms=true; break; }

      }

  } else {

      shuffledAtoms=true;

  }

g[i] is the ltg array from dlpoly 4 - the array that tells you the indices of the atoms in the domain that is being dealt with by this processor.  The variable fortran is true when we call this routine from dlpoly as we have to use the option setFAtomsGatIndex as this ensures that gatindex[i] will be set equal to g[i]-1.  The reason for setting gatindex[i] equal to g[i]-1 is that arrays in C start at zero while arrays in fortran start at 1.  Lets say you have a system of 5 atoms and no domain decomposition.  The ltg array that you pass from dlpoly to plumed should be as follows:

ltg[1]=1

ltg[2]=2

ltg[3]=3

ltg[4]=4

ltg[5]=5

As a consequence gatindex will be:

gatindex[0]=0

gatindex[1]=1

gatindex[2]=2

gatindex[3]=3

gatindex[4]=4

Because gatindex[i]==i for all elements of this array shuffledAtoms should be set equal to false.  To be absolutely clear you cannot use setAtomsGatIndex from fortran as you will get wrong results.  You need to use setFAtomsGatIndex to convert from fortran style arrays to C style arrays.

It is difficult to comment further without understanding something about what you are trying to simulate.   For example why do you think you have empty domains?  In general I don’t think it is a good fix if you don’t understand why this has fixed the code.  This may well lead to problems later.  Is there any chance that you can send a FIELD, CONTROL and CONFIG file so I can try this myself?

Thanks

Gareth     

  

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/a03ccf3e-a630-4dcf-8536-064e3bf14912%40googlegroups.com.

[simon.bo...@gmail.com]

Hi Gareth, 

Thank you for the detailed reply. I'm sorry for the confusion I have caused, let me try and clarify a few things!

I completely understand why "setAtomsGatIndex" cannot be used from FORTRAN. The reason it first appeared in my code is that Plumed 2.1.2 does not yet contain "setAtomsFGatIndex". Only the latest code from the Git has this implemented. I have downloaded and installed this latest version.

To be clear: I am using "setAtomsFGatIndex". (The code in the patch you posted above is using setAtomsGatIndex!)

I completely agree that using setAtomsFGatIndex ensures that the correct indices are sent to PLUMED.

The problem is that even though PLUMED has the correct indices, the program hangs when Atoms::wait() is called. To be more precise - the program doesn't crash or produce an error, it simply get's stuck when calling this line:

    dd.Recv(&dd.indexToBeReceived[count],dd.indexToBeReceived.size()-count,i,666,status);

The program will never finish running unless it is killed from the terminal.

You say:

    "Because gatindex[i]==i for all elements of this array shuffledAtoms should be set equal to false." 

I completely agree with this statement. This is where the problem lies! In order to stop the code from hanging, shuffledAtoms needs to be true. This means somethings isn't being properly handled when shuffledAtoms is false! I'm not 100% sure, but my tests seem to indicate this is the case when a domain has zero atoms.

I completely agree that just blindly assigning shuffledAtoms to be true is very risky (while this temporary hack is in place I am doing very thorough regression testing). This is exactly why I am reaching out to you guys the developers! I hoped you would be able to shed some light on what the side effects of doing this would be. Surely no-one understands the code base better than you.

I have attached CONFIG, FIELD and CONTROL files as requested. You should be able to run dl_poly with 2 threads for testing (mpirun -np 2 ./DLPOLY.Z). I must stress the files are from a very simple regression test used to completely ensure that everything is correct.

I have one last piece of testing to carry out to ensure the virial and stress tensor are being set correctly, but then I will be more than happy to share the code which I have.

Thanks,

Simon

[Giovanni Bussi]

Hi,

if I understood correctly the problem can only happen in a scenario where you have domain decomposition, one domain with all the atoms (in order), all the other domains have zero atoms.

If this is the case you can safely hardcode shuffledAtoms to true. There will be a small penalty for this, but no error that I expect.

Perhaps we have to make plumed slightly smarter in detecting this problem a possibility would be the set shuffledAtoms to false only if it is false on all processes (using a comm.Sum just after shuffledAtoms has been computed).

Giovanni

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/1833669c-cd83-4360-b77e-af75aea55fe0%40googlegroups.com.

[Gareth Tribello]

Hello

I am pretty certain now that what Giovanni said is indeed the problem.  When ran on two nodes I found that one node had shuffledAtoms true and the other had it false.  I have also implemented the fix that Giovanni suggested (summing shuffledAtoms over all the nodes).  The only thing is that I had to change shuffledAtoms from a bool to an unsigned because I don’t think it is possible to do an MPI gather on a boolean variable.  Should I put these changes on the v2.1 branch?  I guess this is a bug that could also happen with other codes if you have a very uneven distribution of atoms throughout the system?

Then returning to some earlier ideas from this thread.  Did you solve the problems with the virial in the end Simon?  I would be very interested in what you are doing there as we are using dl_poly in some of our own work and it would be good to ensure that it is working properly.

Thanks

Gareth 

Thank you,

Also, I think there is an issue with the virial code. I ran the test suggested inhttp://plumed.github.io/doc-v2.1/developer-doc/html/_how_to_plumed_your_m_d.html and the volumes between the run at 1 bar and 1001 bar for my system differed markedly (at least I assume 130nm^3 is considered marked?). Any thoughts on this?

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/1833669c-cd83-4360-b77e-af75aea55fe0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<RegressionFiles.zip>

[simon.bo...@gmail.com]

Hi,

I'm glad we can use this as a quick fix without breaking anything, thanks! My concern, however, is that it still isn't clear why this fixes the problem. If we are passing an already sorted list of indices to PLUMED, why does it need sorting again by PLUMED? What is PLUMED doing when shuffledAtoms == true?

To me atleast it implies there is some subtle problem with the way PLUMED is handling these indices between nodes. I'm not 100% sure if this this only happens when a domain has zero atoms, or if it also happens in other cases as well but is more difficult to spot. 

I think it is definitely worth investigating this further to try and get to the root cause of the issue!

I think I am getting close to fixing the virial contributions - I am at a workshop for the next three days but can share what I have when I get back Gareth. There still seems to be a slight issue. When doing the volume test the two volume files are similar, but still not exactly the same (the volume can be off by normally up to 10nm^3). Furthermore, I am getting different results when using different number of nodes, while I would expect the number of nodes to not influence the outcome of the simulations. Also I think I am close to passing the correct energy value to PLUMED.

Thank you,

Simon Boothroyd

[Gareth Tribello]

Hello again

The issue as I understand it is the following.  dlpoly 4 is doing a domain decomposition of the atomic positions.  So each node will have a subset of the full set of atoms on it and whether or not the atoms are on a particular node will depend on where they are in space.  Lets consider the following 1D system to explain this more clearly each symbol below is an atom

xxxxx                            oo

Now all those xs are on node 0 because they are on the left while all the os are on node 1 because they are on the right.  What is more node 0 knows nothing about the os and node 1 knows nothing about the xs.

Now plumed does not work with a domain decomposition of the atoms.  It needs all the nodes to know the positions of all the atoms.  Consequently, when it is first called it needs to pass around data between the nodes so as to ensure that everyone knows what they need to know.  This passing around of atomic positions is what is triggered when you have shuffledAtoms set equal to true. 

Now it should be easy to tell if there is any domain decomposition going on as if there is domain decomposition the number of atom positions on the node will usually be less than the total number of atom positions.  So using my example with the xs and os from above you have 7 atoms in total but only 5 of them are on node 0.  The other two of them are on node 1.  We thus know that we have to do all this business of passing atoms about if:

gatindex.size()!=natoms

If you look in setAtomsGatindex you will see that the shuffledAtoms is true in this case.  Now the problem is that within LAMMPS (for reasons understood by the developers of that code) the indices of the atoms are shuffled round even when you are only running on a single processor.  Hence, what is done in setAtomsGatindex when gatindex.size()==natoms with the loop.  We just check to see whether or not the atom indices have been shuffled (now one might ask here why not just do all the passing of the atomic positions always - the answer to that is that if we can avoid all this passing about of atomic positions we can save ourselves some computational overhead, which is worthwhile here as this is a part of the code which is going to be used whatever you are doing.)  

The problem that you have identified with dlpoly is that the atom positions are distributed like this:

xxxxxxxxxxx               

In short there are no atoms on node 1.  All the atomic positions are on node 1.  As a consequence of this if we are running on node 0 we find:

gatindex.size()==natoms 

and hence shuffledAtoms will be set equal to false.

By contrast if we go on node 1 we find

gatindex.size()==0   or gatindex.size()!=natoms

and shuffledAtoms is set equal to true.  So the code progresses on and at some stage node 1 will try and get the atomic positions of node 0.  However, node 0 will not play ball  as he knows everything and so foolishly believes that everyone else is as well informed as he is.  In fact he simply will not understand what node 1 is asking him to do as he will already be running ahead having skipped all the passing about atom positions part of the code entirely.  

The solution to this problem is thus recognising that we need to test whether or not:

gatindex.size()==natoms

is true on all the nodes.  If this is true for all nodes then we can guarantee that there is no domain decomposition.  I have a fix that allows us to test this and I will put this in the code within the next few days.  

ciao

Gareth 

[simon.bo...@gmail.com]

Thank you that was a perfect explanation! For some reason I assumed that plumed kept the atoms on the same nodes as the domain decomposition assigned them to. That makes a lot more sense now.

Best,

Simon

[simon.bo...@gmail.com]

Hi,

I've attached the diff file I have for DL POLY 4.07. It assumes you are patching from within the source directory and have already copied Makefile_MPI from build to Makefile in source.

I'm still not entirely sure if the virial contribution is 100% correct (although at least now it is having some effect!). By doing the volume test suggested in the documentation the volumes in the two files are sort of similar (normally within 10nm for my test case) however never really exact. I'm not sure if this is an issue? 

Gareth, I guess you have other systems that this can be tested on? 

Could I also make a request for a new command to be added to plumed? 

I think currently plumed wants you to pass the potential energy of each node in domain decomposition using setEnergy. Would it be possible to get a permutation of this command (perhaps setEnergyTotal) where we can directly pass the total potential energy without the need for plumed to internally call gsum? In DL_POLY, as far as I can tell we only have access to the total potential energy of the system across all nodes.

Thank you,

Simon Boothroyd

[Giovanni Bussi]

About the addition of a command to plumed_cmd:

In principle that is easy to do. However, notice that it is not trivial to maintain all the commands and to be sure they are not broken in the future. Through our regression test suite we only validate interfaces with the "plumed driver".

As an alternative, you can just divide the energy by the number of processors before sending it to plumed.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/68d1d4b8-abe3-412e-b6ac-b16b9bead6a4%40googlegroups.com.

[Gareth Tribello]

Hello peeps

Thanks Simon for all this dl poly stuff.

I am going to Darlesbury next week (lucky me!) so I can talk to the guys over there about this interface and perhaps can get a few things clarified in terms of the virial.  At some stage there was even some talk about leaving the plumed interface inside dlpoly permanently so I can follow up on that possibility.

Thanks 

Gareth

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

[simon.bo...@gmail.com]

Hi Gareth,

That's great that you'll get to speak to them, hopefully it will help in completing this patch!

I would greatly appreciate it if you could let me know the results of your discussions regarding this? I'd hate to continue working on this if you have already found the solutions!

Thank you,

Simon

[Alin Marin Elena]

Hi Gareth and Simon,

I have now merged and added few goodies to dlpoly4 in regards to plumed. I hope to be happy enough with it to get into next release. 

If you have any pathological examples that can break it will be appreciated.

Alin

[rew...@sheffield.ac.uk]

Hi Gareth,

I have read this thread and was wondering if you could also share the patch you have for DLPOLY_2.

Best Regards,

Robyn

On Wednesday, 17 December 2014 19:31:55 UTC, Gareth Tribello wrote:

Hello

Which version of dlpoly are you using?  I have a patch for 2 and am in the process of testing a patch for 4.  I would be more than happy to share either of these with you.

Thanks

Gareth

On 17 Dec 2014, at 19:19, l.ch...@gmail.com wrote:

Hi,

I have heard so many good things about Plumed so I am trying to find out how I can also use it. One immediate problem is: It seems to me that Plumed 2 does not support DL_POLY which is the MD code I have been using. So, could anyone please offer some help here? I suppose there might have already been some ways of patching Plumed 2 with DL_POLY... By the way, is there any scope that DL_POLY will be supported in a near-future version of Plumed? If not, I might consider seriously changing to a different MD code.

Many thanks in advance,

Linc

--
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/09bac058-2c2e-4d0e-af58-5d0f65722e44%40googlegroups.com.