AMBER Archive (2009)

Subject: Re: [AMBER] pmemd

From: Robert Duke (rduke_at_email.unc.edu)
Date: Mon Aug 24 2009 - 08:42:05 CDT

Hi Michael,
Sorry to be so slow in responding; I just got back from a long vacation
without access to source. Ross pretty much covered the problem, but
mentioned something about me commenting on things. Regarding the fix for
the uninitialized inerr variable - absolutely a screwup on my part; thanks
to Ross for the fix. Everyone should pick up bugfix 24; I have never seen
conditions that cause this error, but it is a clear and obvious possibility.
In general there should be no referencing of uninitialized variables in
pmemd, and any such references are a screwup. The case of ep_frames is a
bit more complex in that dynamically allocated arrays in fortran are a bit
more complicated than say a c ptr that can (and should) be set to NULL if
not used. So probably the best practice would be to alloc these structures
to 0 length if not used, but I don't do that throughout the code because it
basically makes the allocation code significantly more complicated.
Instead, there is some variable associated with all dynamically allocated
storage that can be used to determine if it is in use (basically, a
counter), and this is always referenced before referencing such storage.
This always works, except for when you compile to check for uninitialized
storage at compile time (as opposed to runtime). In an ideal world, I
suppose we would take the hit on allocation complexity in order to get
around the "-check all" bug.
Regards - Bob Duke
----- Original Message -----
From: "michael" <michael.bane_at_manchester.ac.uk>
To: "AMBER Mailing List" <amber_at_ambermd.org>
Sent: Saturday, August 15, 2009 7:30 AM
Subject: Re: [AMBER] pmemd

>
> On 11 Aug 2009, at 01:00, Ross Walker wrote:
>
>> Hi Michael,
>>
>> > a) does pmemd presume some variables initialised to zero? On our
>> > system
>> > with `ifort -O0 -g` this appears not to be the case and caused
>> > immediate
>> > abort. Initialising inerr to zero in file mdin_ewald_dat.fpp fixes
>> > this.
>>
>> See bugfix.24: http://ambermd.org/bugfixes/10.0/bugfix.24
>
>
> :)
> thanks!
>
>>
>>
>> > b) using `ifort -O0 -g -check all` throws error at line 144 of
>> > pmeall_tasks_setup.f90 where it calls a sub with arg EP_FRAMES but
>> > EP_FRAMES is dynamic and hasn't been declared. Tracing back shows
>> > gbl_frame_cnt is zero in bcast_extra_pnts_nb14_dat() in file
>> > extra_pnts_nb14.fpp/f90 meaning alloc_nb14_mem_only() is called
>> > rather
>> > than alloc_extra_pnts_nb14_mem (which is the one that allocates
>> > EP_FRAMES)
>>
>> I will let Bob comment on this some more. It seems to me this comes
>> about
>> because it is only required when extra points are in use. In other
>> words
>> when frame_cnt > 0. Thus although frames is passed in as unallocated
>> it is
>> never referenced in the file.
>
>
> Noted
>
>> Thus I believe it is legal code and just the
>> -check all being too overzealous.
>
>
> Possibly but I can see that if EP_FRAMES is not allocated that a
> 'random' mem loc will be used in the sub call (but also that said mem
> loc isn't being read from)
>
>> Do you see problems because this array is
>> not allocated?
>
>
> I'm no chemistry nor pmemd expert but if I remove the array bounds check
> then it does seem to run
>
>> Does the fortran style require all arguments to a subroutine
>> to have been allocated even if they are not used? I am not sure on
>> this last
>> point and it would be interesting to know. Perhaps it isn't allowed,
>> or it
>> should be initialized as null for example.
>
> I'm not 100% of the spec but it was Intel's run-time check that was
> pulling it as an error.
>
> Thanks, Michael
>
>> All the best
>> Ross
>>
>> /\
>> \/
>> |\oss Walker
>>
>> | Assistant Research Professor |
>> | San Diego Supercomputer Center |
>> | Tel: +1 858 822 0854 | EMail:- ross_at_rosswalker.co.uk |
>> | http://www.rosswalker.co.uk | PGP Key available on request |
>>
>> Note: Electronic Mail is not secure, has no guarantee of delivery, may
>> not
>> be read every day, and should not be used for urgent or sensitive
>> issues.
>>
>>
>>
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER_at_ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER_at_ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>

_______________________________________________
AMBER mailing list
AMBER_at_ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber