[gmx-developers] distance restraints and domain decomposition

Bert de Groot bgroot at gwdg.de
Thu Jun 7 15:48:41 CEST 2018


Hi,

right, but this would be expected to lead to jumps in the restraint energies, 
right? So far there are no signs of these.

cheers

Bert

On 06/07/18 14:08, Berk Hess wrote:
> Hi,
>
> But OpenMP runs could be incorrect when the restraint distance can pick up the 
> wrong PBC image.
>
> Cheers,
>
> Berk
>
> On 2018-06-07 14:06, Bert de Groot wrote:
>> Hi,
>>
>> OK, thanks, that sounds reasonable. It is admittedly a somewhat unusual 
>> setup, but as the openMP jobs ran without issues, the problems with the MPI 
>> jobs surprised us.
>> The system is small enough that we can use openMP nodes as workaround for now.
>>
>> The anticipated issues with analysis tools/trjconv have indeed showed up as 
>> well (inconsistent shift warnings), but there they can be resolved by feeding 
>> a tpr without the distance restraints.
>>
>> cheers
>>
>> Bert
>>
>> On 06/07/18 13:29, Berk Hess wrote:
>>> Hi,
>>>
>>> I "resolved" this by adding a fatal error. The error message says that the 
>>> only solution is increasing the box size.
>>> For special cases one could do better by introducing special interations 
>>> that would only link monomers together. But here you actually have 
>>> interactions that a longer than half the box size. Theoretically one could 
>>> also support this, but that gets complicated and bug-prone.
>>>
>>> Cheers,
>>>
>>> Berk
>>>
>>> On 2018-06-07 10:22, Berk Hess wrote:
>>>> Hi,
>>>>
>>>> I filed a redmine issue: https://redmine.gromacs.org/issues/2549
>>>>
>>>> Cheers,
>>>>
>>>> Berk
>>>>
>>>> On 2018-06-07 09:51, Berk Hess wrote:
>>>>> Hi,
>>>>>
>>>>> This is a complicated case. You have multiple monomers that are only 
>>>>> linked by distance restraints. Some of these restraints work over more 
>>>>> than half the box length. These interactions cause parts of monomers to be 
>>>>> shifted by a box vector in the shift code. This is obviously incorrect. 
>>>>> This can affect more things than the DD distance calculation that you 
>>>>> report, e.g. analysis tools.
>>>>> This is not easy to fix, one could image that all distance restraints are 
>>>>> at distances of more than half the box length. The least we should do is 
>>>>> detect such inconsistencies and generate a fatal error.
>>>>> I was about to say that you could use multiple molecule types and 
>>>>> intermolecular interactions, but could cause incorrect distances to be 
>>>>> used for the restraints.
>>>>> The only proper solution is to add some kind of proximity interaction the 
>>>>> user can specify to tell what part of the monomers are close, such that 
>>>>> GROMACS can set up the correct PBC.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Berk
>>>>>
>>>>>
>>>>> On 06/07/2018 08:42 AM, Berk Hess wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The code takes PBC into account, both for intra- and intermolecular 
>>>>>> interactions.
>>>>>>
>>>>>> Could you provide me with the input to grompp?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Berk
>>>>>>
>>>>>> On 06/07/2018 08:37 AM, Kutzner, Carsten wrote:
>>>>>>>
>>>>>>>> On 7. Jun 2018, at 07:02, David van der Spoel <spoel at xray.bmc.uu.se> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Den 2018-06-06 kl. 15:07, skrev Kutzner, Carsten:
>>>>>>>>> Dear developers,
>>>>>>>>> we have a ~ 40,000 atom MD system with distance restraints (bond type 6)
>>>>>>>>> that does not want to run in parallel, although I assume it should.
>>>>>>>>> It runs fine without DD, e.g. -ntmpi 1 -ntomp 20, however with DD the
>>>>>>>>> following happens:
>>>>>>>>> mdrun -ntmpi 2
>>>>>>>>> Fatal error:
>>>>>>>>> There is no domain decomposition for 2 ranks that is compatible with 
>>>>>>>>> the given
>>>>>>>>> box and a minimum cell size of 11.4939 nm
>>>>>>>>> The maximum distance restraint distance is however at 4.0 nm, so 11.49 
>>>>>>>>> nm as
>>>>>>>>> reported cannot be true, unless the PBC distance is not taken properly
>>>>>>>>> into account. Is this the expected behaviour or worth generating a 
>>>>>>>>> redmine
>>>>>>>>> issue?
>>>>>>>>> Thanks,
>>>>>>>>>   Carsten
>>>>>>>> Which version?
>>>>>>> 2018
>>>>>>>
>>>>>>>> It should work with OpenMP anyway.
>>>>>>> Yes, that works, however we might want to use multiple nodes and/or 
>>>>>>> multiple
>>>>>>> GPUs for similar setups in the future.
>>>>>>>
>>>>>>> Carsten
>>>>>>>
>>>>>>>> -- 
>>>>>>>> David van der Spoel, Ph.D., Professor of Biology
>>>>>>>> Head of Department, Cell & Molecular Biology, Uppsala University.
>>>>>>>> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
>>>>>>>> http://www.icm.uu.se
>>>>>>>> -- 
>>>>>>>> Gromacs Developers mailing list
>>>>>>>>
>>>>>>>> * Please search the archive at 
>>>>>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before 
>>>>>>>> posting!
>>>>>>>>
>>>>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>>>>>
>>>>>>>> * For (un)subscribe requests visit
>>>>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers 
>>>>>>>> or send a mail to gmx-developers-request at gromacs.org.
>>>>>>> -- 
>>>>>>> Dr. Carsten Kutzner
>>>>>>> Max Planck Institute for Biophysical Chemistry
>>>>>>> Theoretical and Computational Biophysics
>>>>>>> Am Fassberg 11, 37077 Goettingen, Germany
>>>>>>> Tel. +49-551-2012313, Fax: +49-551-2012302
>>>>>>> http://www.mpibpc.mpg.de/grubmueller/kutzner
>>>>>>> http://www.mpibpc.mpg.de/grubmueller/sppexa
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>




More information about the gromacs.org_gmx-developers mailing list