[gmx-developers] grand-canonical MC using gromacs

[René Pool]

The nice thing about the python-ctypes approach is that it is a shell 
around gromacs, leaving the gmx code almost entirely intact.
Of course you can screw things up badly in this shell, but that will not 
be gromacs' fault! Proper design and documentation/comments is 
important, I admit.

Shirts, Michael (mrs5pt) wrote:
> There's a more general formalism to perform MC with a combination of
> approximate and complete potentials that might be applicable here.
> 
> http://jcp.aip.org/resource/1/jcpsa6/v118/i17/p7747_s1
> 
> I'd just point out that it's very important to make sure extensions like
> this are incorporated well into the logic of the code, perhaps checking with
> Berk. If code isn't well designed, it ends up making it very hard to extend
> it further, and options for some functionality conflict with options for
> other functionalities.
> 
> Best,
> ~~~~~~~~~~~~
> Michael Shirts
> Assistant Professor
> Department of Chemical Engineering
> University of Virginia
> michael.shirts at virginia.edu
> (434)-243-1821
> 
> 
>> From: René Pool <r.pool at vu.nl>
>> Reply-To: "r.pool at vu.nl" <r.pool at vu.nl>, Discussion list for GROMACS
>> development <gmx-developers at gromacs.org>
>> Date: Wed, 8 Dec 2010 10:45:27 -0500
>> To: Discussion list for GROMACS development <gmx-developers at gromacs.org>
>> Subject: Re: [gmx-developers] grand-canonical MC using gromacs
>>
>> JR Schmidt wrote:
>>>> I'm planning to further increase efficiency by exploiting the test
>>>> particle insertion option of mdrun for MC insertion moves and
>>>> computing the energy of a randomly selected molecule for possible
>>>> removal during a consecutive MC removal move. The latter trick will
>>>> save single point energy calculations for MC removal moves that I
>>>> perform at the moment.
>>> As a side note, I might suggest that you NOT do what you suggest above.
>>> Although it would be more efficient, it would rule out the possibility
>>> of properly doing a particle insertion when you are using Ewald (or a
>>> polarizable potential, such as Drude oscillators!).  This is because the
>>> gromacs insertion code explicitly assumes a pair-wise additive
>>> potential.  While one might argue that the polarizable potential is of
>>> minor interest, the Ewald issue is quite a bit more serious.
>>>
>> Okay, thanks for the advise!
>> I could make the use of tpi optional for simulations that don't use
>> ewald or polarizable potentials...
>>
>> Cheers,
>> Rene
>>
>> -- 
>> =====================================================
>> René Pool
>> IBIVU/Bioinformatics
>> Vrije Universiteit Amsterdam
>> De Boelelaan 1081a
>> 1081HV AMSTERDAM, the Netherlands
>> Room P120
>> E: r.pool at few.vu.nl
>> T: +31 20 59 83714
>> F: +31 20 59 87653
>> =====================================================
>> -- 
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
>