[gmx-developers] New mdp parameter

[Berk Hess]

Florian Dommert wrote:
> On 03.06.2010, at 12:20, Berk Hess wrote:
>
>   
>> Florian Dommert wrote:
>>     
>>> On 03.06.2010, at 11:50, David van der Spoel wrote:
>>>
>>>
>>>       
>>>> On 6/3/10 11:45 AM, Florian Dommert wrote:
>>>>
>>>>         
>>>>> Hello,
>>>>>
>>>>> when talking about the next release I have a small request. So far the
>>>>> splitting parameter of the Ewald routines can just be supplied
>>>>> indirectly via the parameter ewald_rtol. However as I have almost
>>>>> finished the implementation of an error estimate for the SPME it would
>>>>> be very useful to be able to input the splitting parameter beta
>>>>> directly. So far I always achieved this by patching ewald_util.c, that
>>>>> calc_ewaldcoeff returns just the positive value of dtol, if the input of
>>>>> dtol is negative.
>>>>> So what do you think bout adding a new parameter to the mdp file like,
>>>>> ewald_beta or ewald_split, that is just used if larger than zero ?
>>>>>
>>>>>
>>>>>           
>>>> For development now you can use the userreal[1234] and userint[1234]. Once it is finished and we decide this should go into gromacs (which is difficult to judge from your mail now) we can of course add options to the mdp file.
>>>>
>>>>
>>>>         
>>> The code for the error estimate is an enhancement of Carsten's g_tune_pme. We implemented most of the error estimate together and currently I am trying to overcome the last problems which arise from the MPI implementation. However if you use g_tune_pme to tune the accuracy of the electrostatic forces you will have a set of parameters: cutoff in real space, cutoff in reciprocal space, interpolation order and the splitting parameter beta. So after tuning your system you can currently input all parameters in the mdp file apart from beta, which is at the moment calculated from the cutoff in real space and ewald_rtol.
>>>
>>> The idea of Berk to include it into grompp is in my opinion not that useful because the program should be capable of using multiple processor otherwise the calculations can last very very long.
>>>
>>>       
>> But the computational time is mostly due to processing the initial
>> coordinates for one part
>> of the error estimate, right?
>> WE discussed changing that to assuming a uniform distribution, which
>> would make the estimate
>> coordinate independent as well as more efficient.
>>
>> Furthermore, the current way cut-off's are usually treated in Gromacs,
>> using charge-groups and
>> a neighborlist fixed for 10 steps, requires a very small ewald_rtol,
>> independently of the PME
>> accuracy settings. In the next version (not the version to be released
>> soon) we might change
>> to buffered, exact cut-off's which would allow the use of larger
>> ewald_rtol's set by the PME accuracy.
>>
>> Berk
>>     
>
> Oh it did not know that the neighborlist is fixed for 10 steps, so what can I change with the parameter nstlist and why is it fixed for 10 steps ?
>
>   
No, it is not fixed, that is the usual setting.
The issue is that charges might only start seeing each other at
distances of one or two angstroms
less than the cut-off. Therefore ewald_rtol has to be smaller than
required for the plain PME accuracy.
> The problem is see here is that a small ewald_rtol can produce very large errors in the reciprocal force calculation.
>   
No, effectively we increase the cut-off only (and have to decrease
ewald_rtol to compensate for that).
That is why currently it does not make much sense to automate the PME
parametrization.

Berk
> As Carsten mentioned that g_tune_pme is not a good place for the error estimate due to issues with queueing systems, I will implement another tool that allows to estimate the error for a given set of parameters or would you prefer to have a library that can be called from mdrun ?
>
> Cheers,
>
> Flo
>
>
>
>
>
>   
>>> Including it into mdrun would in my opinion require an automatic tuning algorithm, but from experience I know that a human's brain can do this much faster. However in case the algorithm should go into the mdrun routine I would suggest to introduce a new integrator mode like "tune". Then the parallel environment is present and the code has just to be enhanced by a suitable algorithm to find parameters for the requested errors and maximal speed.
>>>
>>> Cheers,
>>>
>>> Flo
>>>
>>>
>>>
>>>
>>>
>>>       
>>>>> Cheers,
>>>>> Flo
>>>>> --
>>>>> Florian Dommert
>>>>> Dipl.-Phys.
>>>>>
>>>>> Institute for Computational Physics
>>>>>
>>>>> University Stuttgart
>>>>>
>>>>> Pfaffenwaldring 27
>>>>> 70569 Stuttgart
>>>>>
>>>>> Phone: +49(0)711/685-6-3613
>>>>> Fax: +49-(0)711/685-6-3658
>>>>>
>>>>> EMail: dommert at icp.uni-stuttgart.de <mailto:dommert at fias.uni-frankfurt.de>
>>>>> Home: http://www.icp.uni-stuttgart.de/~icp/Florian_Dommert
>>>>> <http://fias.uni-frankfurt.de/~simbio/Florian_Dommert>
>>>>>
>>>>>
>>>>>           
>>>> -- 
>>>> David van der Spoel, Ph.D., Professor of Biology
>>>> Dept. of Cell & Molec. Biol., Uppsala University.
>>>> Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
>>>> spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se
>>>> -- 
>>>> 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.
>>>>
>>>>         
>>> --
>>> Florian Dommert
>>> Dipl.-Phys.
>>>
>>> Institute for Computational Physics
>>>
>>> University Stuttgart
>>>
>>> Pfaffenwaldring 27
>>> 70569 Stuttgart
>>>
>>> Phone: +49(0)711/685-6-3613
>>> Fax:   +49-(0)711/685-6-3658 
>>>
>>> EMail: dommert at icp.uni-stuttgart.de
>>> Home: http://www.icp.uni-stuttgart.de/~icp/Florian_Dommert
>>>
>>>
>>>       
>> -- 
>> 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.
>>     
>
> --
> Florian Dommert
> Dipl.-Phys.
>
> Institute for Computational Physics
>
> University Stuttgart
>
> Pfaffenwaldring 27
> 70569 Stuttgart
>
> Phone: +49(0)711/685-6-3613
> Fax:   +49-(0)711/685-6-3658 
>
> EMail: dommert at icp.uni-stuttgart.de
> Home: http://www.icp.uni-stuttgart.de/~icp/Florian_Dommert
>
>