[gmx-developers] Re: gmx-developers Digest, Vol 74, Issue 6

Carlo Camilloni carlo.camilloni at gmail.com
Thu Jun 3 10:56:17 CEST 2010


I meant, "there is a problem in"

int calc_gb_chainrule_sse2_double

Carlo



On 3 Jun 2010, at 10:49, gmx-developers-request at gromacs.org wrote:

> Send gmx-developers mailing list submissions to
> 	gmx-developers at gromacs.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.gromacs.org/mailman/listinfo/gmx-developers
> or, via email, send a message with subject or body 'help' to
> 	gmx-developers-request at gromacs.org
> 
> You can reach the person managing the list at
> 	gmx-developers-owner at gromacs.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gmx-developers digest..."
> 
> 
> Today's Topics:
> 
>   1. re: implicit solvent (Carlo Camilloni)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 3 Jun 2010 10:48:56 +0200
> From: Carlo Camilloni <carlo.camilloni at gmail.com>
> Subject: [gmx-developers] re: implicit solvent
> To: gmx-developers at gromacs.org
> Message-ID: <C0F4E9F8-D7E3-4C5E-BD93-84EBE85A0630 at gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 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>
>> Date: 1 June 2010 13:43:45 CEST
>> To: Per Larsson <per.larsson at sbc.su.se>
>> Subject: Re: gmx-developers Digest, Vol 74, Issue 1
>> 
>> 
>> 
>> 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>
>>>>> Subject: [gmx-developers] implicit solvent in the git version of
>>>>> 	gromacs
>>>>> To: gmx-developers at gromacs.org
>>>>> Message-ID: <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
>>>> 
>>> 
>> 
> 
> -------------- next part --------------
> Skipped content of type multipart/mixed
> 
> ------------------------------
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> 
> 
> End of gmx-developers Digest, Vol 74, Issue 6
> *********************************************




More information about the gromacs.org_gmx-developers mailing list