Hi Thomas -
Issue 1):
I recently had the same question in my mind regarding some new code I am
developing. None of the various ways I can think of to avoid this is
particularly elegant, and they all further obfuscate the code (which is
already fairly obfuscated, unfortunately). I tried looking at the standards
to determine whether this is allowed - I could not find a definitive
statement, and I have never seen a compiler refuse to compile code that does
this. So here's the deal. A perfectly good test case on something like
this is the allocated() intrinsic. If you can pass stuff in and check it's
allocation status, that basically says this is okay - and I think you can.
Something to remember about using extensive checks is that the checks code
itself often does not get everything right. Anyway, I will play with this
issue some to insure there is no real issue here, but I think there is not a
real issue here (access to igrp(*) is guarded by the ibelly flag,
essentially).
Issue 2):
There is extensive code in loadbal to guard against just this sort of thing.
Did you observe an out-of-range value for my_img_lo in an actual run?
Please send me your config.h and your test case as well as the output of
ifort -V and an exact description of what happened, and I will look into it
further. This is in the category of something that is possible, but the
code has already taken the issue into consideration and been extensively
tested at very high processor count where this sort of thing would be likely
to happen (the basic problem is in dividing up the image workload - you have
to be sure that it sums exactly to img_cnt, and if it doesn't all sorts of
pandemonium would be expected).
Regards - Bob Duke
----- Original Message -----
From: "Thomas Zeiser" <thomas.zeiser.rrze.uni-erlangen.de>
To: <amber.scripps.edu>
Sent: Wednesday, May 09, 2007 7:33 AM
Subject: AMBER: pmemd source issues
> Dear All,
>
> I compiled pmemd9 (including Amber9 patches 1-34) using the latest
> Intel EM64T compiler and enabled extensive runtime error checking
> (-g -traceback -check all). Two types of issues came up:
>
> 1) contraints.f90 only allocates "amt_igroup" if "ibelly" is set.
> degcnt() is called from runmd.f90 and "amt_igroup" is passed in all
> cases. The Intel compiler now complains (if ibelly is not set)
> that "integer :: igrp(*)" is not allowed as an unallocated variable
> is accessed.
> An "allocate(atm_igroup(0))" in constraints.f90 solves this issue.
>
> A similar behaviour is observed for "gbl_loadbal_node_dat" which
> gets only allocated on the master process (alltasks_setup.f90).
>
> I did not check the Fortran standard if using "type :: var(*)" is
> allowed or not (I guess "no" as an unallocated variable does not
> have any defined ranges which can be used for the assumed shape) -
> but passing a valid variable seems to be a good idea anyway.
>
>
> 2) The probably more sever issue was detected in find_img_range()
> from img.f90. At least for the testcase I got from our chemistry
> people, "my_img_lo" is one unit larger than "img_cnt", thus, the
> check "img_atm_map(img_i) .lt. 0" causes an array bound violation.
> No idea about the implication of that (or a correct fix).
>
>
> Kind regards,
>
> Thomas Zeiser
>
> --
> Regionales Rechenzentrum Erlangen / HPC-Services
> Martensstr. 1, 91058 Erlangen, GERMANY
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sun May 13 2007 - 06:07:09 PDT
