[gmx-developers] re: implicit solvent

[Berk Hess]

Also, I see no point in using double precision for production GB simulations
and single precision currently works correctly.

Berk

Per Larsson wrote:
> Hi Mark and Carlo!
>
> I'm working on this, please be patient a little while longer.
>
> Cheers
> /Per
>
>
> 3 jun 2010 kl. 10.48 skrev Carlo Camilloni:
>
>> Dear Mark,
>>
>> I send you the same input files that I sent to Per Larsson.
>> after the last commits on git the problems still appears
>> after more or less 200 steps, always as a big increment
>> in "fshift after SR[   22]".
>>
>> applying a patch in genborn.c:1562-1563:
>>
>>      nj0     = nl->jindex[ai];
>>         nj1  = nl->jindex[ai+1];
>>
>> -->
>>
>>      nj0     = nl->jindex[i];
>>         nj1  = nl->jindex[i+1];
>>
>>
>> and compiling in double without optimizations,
>> all works well. Maybe there is a problem in 
>>
>>
>> Regards,
>> Carlo
>>
>> Begin forwarded message:
>>
>>> *From: *Carlo Camilloni <carlo.camilloni at gmail.com
>>> <mailto:carlo.camilloni at gmail.com>>
>>> *Date: *1 June 2010 13:43:45 CEST
>>> *To: *Per Larsson <per.larsson at sbc.su.se <mailto:per.larsson at sbc.su.se>>
>>> *Subject: **Re: gmx-developers Digest, Vol 74, Issue 1*
>>>
>> <hp.tgz>
>>>
>>> Hi,
>>>
>>> this is the system I was using. I have also done some
>>> debugging:
>>> by using -debug 10 flag in mdrun I got this result in mdrun.debug
>>>
>>>
>>>
>>> Increasing GB neighbourlist j size to 3190
>>> Increasing GB neighbourlist j size to 7986
>>> Increasing GB neighbourlist j size to 18489
>>> Increasing GB neighbourlist j size to 41490
>>> fshift after SR (45x3):
>>>    fshift after SR[    0]={ 0.00000e+00,  0.00000e+00,  0.00000e+00}
>>>    fshift after SR[    1]={ 0.00000e+00,  0.00000e+00,  0.00000e+00}
>>>    fshift after SR[    2]={ 0.00000e+00,  0.00000e+00,  0.00000e+00}
>>>    fshift after SR[    3]={ 0.00000e+00,  0.00000e+00,  0.00000e+00}
>>>    fshift after ...
>>>
>>>    fshift after SR[   22]={-3.59985e+269, 7.91323e+269, -1.16757e+270}
>>>   and all the other 0.00
>>>
>>> vir_part (3x3):
>>>    vir_part[    0]={1.52302e+270, 6.71165e+268, -9.94015e+268}
>>>    vir_part[    1]={6.71165e+268, 1.38159e+270, -5.32724e+267}
>>>    vir_part[    2]={-9.94015e+268, -5.32724e+267, 1.03656e+270}
>>> Guessed pbc = xyz from the box matrix
>>> Guessed pbc = xyz from the box matrix
>>> constraint virial (3x3):
>>>    constraint virial[    0]={-1.06645e+269, -6.31248e+267, 5.52275e+267}
>>>    constraint virial[    1]={-6.31248e+267, -1.16995e+269,
>>> -5.31208e+267}
>>>    constraint virial[    2]={5.52275e+267, -5.31208e+267, -1.01260e+269}
>>> dekin (3x3):
>>>    dekin[    0]={        -inf,         -inf,          inf}
>>>    dekin[    1]={        -inf,         -inf,          inf}
>>>    dekin[    2]={         inf,          inf,         -inf}
>>>  ekin (3x3):
>>>     ekin[    0]={ 1.07090e+02, -1.28235e+01,  2.44544e+00}
>>>     ekin[    1]={-1.28235e+01,  9.93836e+01, -4.73968e+00}
>>>     ekin[    2]={ 2.44544e+00, -4.73968e+00,  8.31171e+01}
>>> dekin = -inf, ekin = 289.591  vcm =
>>> (37724423208582392295386276764510319211320417140435671882380328320812381594880211169413371
>>> 358679334568178120349284174636383420665585500528416721787062413484436933391583994571739322882089364956909490686430616721178287
>>> 5654860436192621173254981676957696.0000
>>> 31180390611175245501077433199741281911130739631997505115600164449706783479065192251777
>>> 314796409899660965811414664650242000195439480951995994394538761200379988057180467500001038548378320832492673848303062076640322
>>> 1353454826879291876975370559962480640.0000
>>> -1431266541249085767742382230423258785149802680554631655691802070662038285164031728
>>> 191772385960655935292355927541486927054477721966709871891976853820786315670152588754868888831140838914572678663771823871985711
>>> 373255227035928103075818815545438543806464.0000)
>>>
>>>
>>>
>>>
>>> moreover after having take a look at the code in genborn.c it seems
>>> to me that fr->invsqrta in not properly initialized before the first
>>> step.
>>>
>>> hope this helps,
>>> Regards,
>>> Carlo
>>>
>>> On 1 Jun 2010, at 12:58, Per Larsson wrote:
>>>
>>>> Hi!
>>>>
>>>> Could you send me your inputfiles, and I'll have a look at it.
>>>> It should work.
>>>>
>>>> Regards
>>>> /Per
>>>>
>>>>
>>>> 1 jun 2010 kl. 12.30 skrev Pär Bjelkmar:
>>>>
>>>>> Sett detta?
>>>>>
>>>>> Vidarebefordrat brev:
>>>>>
>>>>>> Message: 1
>>>>>> Date: Tue, 1 Jun 2010 11:35:13 +0200
>>>>>> From: Carlo Camilloni <carlo.camilloni at gmail.com
>>>>>> <mailto:carlo.camilloni at gmail.com>>
>>>>>> Subject: [gmx-developers] implicit solvent in the git version of
>>>>>> gromacs
>>>>>> To: gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>>>>>> Message-ID: <64B168DC-C53F-406B-BA7B-091B3F243527 at gmail.com
>>>>>> <mailto:64B168DC-C53F-406B-BA7B-091B3F243527 at gmail.com>>
>>>>>> Content-Type: text/plain; charset=us-ascii
>>>>>>
>>>>>> Dear Gromacs Developers,
>>>>>>
>>>>>> I am trying  to test, without any success, the implicit solvent
>>>>>> algorithm implemented in the git version of gromacs.
>>>>>> I am using a 16 residue beta-hairpin with the charmm forcefield
>>>>>> and all the different implicit algorithm still, ecc.
>>>>>> But the system explode within the first steps, while turning-off
>>>>>> the gbsa all goes well.
>>>>>>
>>>>>> pbc=no
>>>>>> electrostatic=reaction-field-zero or cut-off
>>>>>> vdw=shift or cut-off
>>>>>> dt=0.002 or 0.001
>>>>>> constraint=lincs
>>>>>> nstlist=1
>>>>>> rlist=rgblist=2
>>>>>> both with temperature coupling as without.
>>>>>>
>>>>>> Is the algorithm still broken?
>>>>>>
>>>>>> Best regards,
>>>>>> Carlo Camilloni
>>>>>
>>>>
>>>
>>
>> -- 
>> gmx-developers mailing list
>> gmx-developers at gromacs.org <mailto: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.
>