Re: [AMBER-Developers] Bug in LMOD do_list_update

From: Crowley, Michael <Michael_Crowley.nrel.gov>
Date: Sun, 5 Apr 2009 17:18:39 +0100

Hi guys,
I think this is probably a vestige of psander.
I will take a look and see about cleaning it up if it is warranted.
I am pretty sure it should certainly not be a parameter.
Mike


On 4/1/09 11:50 AM, "Scott Brozell" <sbrozell.rci.rutgers.edu> wrote:

> Hi,
>
> On Wed, 1 Apr 2009, Joe Krahn wrote:
>
>> lmod.f defines do_list_update as a parameter, but it is actually an
>> intent(out) argument that gets passed down to nonbond_list(), where an
>> attempt to modify the argument produces a segfault. Apparently, this part of
>> the code is not getting run in the test scripts.
>>
>> There are also several instances of do_list_update as a parameter in debug.f.
>> In looking at the code, I'm not sure that do_list_update is even useful. It
>> seems to get set inside nonbond_list(), and is otherwise ignored. Maybe it
>> was originally intent(in) to force an update?
>
> Circa 2004, I had detailed control over list building in lmod.f:
> select case ( list_control )
> case ( NBL_UPDATE_ALWAYS )
> do_list_update = .true.
> ntnb = 1
> case ( NBL_UPDATE_NEVER )
> do_list_update = .false.
> ntnb = 0
> case ( NBL_UPDATE_NORMAL )
> do_list_update = .true.
> if ( mod(n_force_calls,nsnb) == 0 ) then
> ntnb = 1
> end if
> case default
> ! invalid list_control
> ASSERT( .false. )
> end select
> which I think was correct; at least lmod worked in 2004.
>
> All of this was removed in 8.8. And then do_list_update was re-added as a
> parameter in 8.9. After only a few minutes of looking at the do_list_update
> control flow, it looks ok to just remove the parameter and see if it works.
> A more thorough investigation is merited. Perhaps Ross and Mike can comment.
>
> RCS file: /cvsroot/amber11/src/sander/lmod.f,v
> revision 8.8
> date: 2005/09/17 08:23:16; author: rcw; state: Exp; lines: +2 -6
> RCW: Major performance updates to egb.f (>25%). gb_cox2 on 1cpu landau (ifort
> 8.1, mkl6.1). Amber 8 = 627.88s, Amber 9 17th Sept 2005 = 437.50s. This has
> been done by splitting the calculation of radii and optimising this routine
> seperately. Make much more use of vectorisation. Also re-ordered array for
> more cache hits. Also store and reuse inverse effective radii to avoid
> unecessary divisions. Improved initial part of main egb routine. Moved egb_les
> out of egb.f and into its own file. Fixes to debug.f to make force calls
> consistently use the correct number of arguments. Removed do_list_update from
> force subroutine (it was never
> used). Performance updates for qmgb=2. More egb performance updates to follow
> shortly.
> revision 8.9
> date: 2005/10/17 19:45:48; author: crowley; state: Exp; lines: +4 -2
> MFC Psander code fixed, working for dhfr to 32 processors. test cases work.
>
>
> As far as testing:
>
> RCS file: /cvsroot/amber11/test/Makefile,v
> revision 9.98
> date: 2008/02/29 21:42:17; author: case; state: Exp; lines: +7 -7
> don't run the lmod tests: they don't really "test" anything know (other than
> that the program doesn't crash...)
> comment out the tgtmd tests, until Carlos (or someone) can figure these out
>
>
> I'll turn these back on after lmod.f is sorted out.
>
> BTW, here is another plug for xmin: try it instead of the old Amber
> minimization methods, you'll like it.
>
> thanks for the report, Joe.
>
> Scott
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers


_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 06 2009 - 01:09:07 PDT
Custom Search