Hi Joe,
> I generally try to follow strict Fortran95, but there are obviously a
> few extension routines that are OK to use, such as GETARG. It would be
> nice to have a list of these.
Yes but be CAREFUL about using too much of this. A lot of things that seem
perfectly reasonable on Linux / gfortran or ifort break on other machines. A
lot of this is going away now as old systems die but remember not everybody
uses Linux so if you add such things make sure it is supported across
multiple platforms and 'every' compiler. So things like AIX, MAC OSX,
Cygwin, Windows, IRIX, Unicos, Solaris etc.
> Also, the Amber9Forum section on "automatic vs allocated arrays" is not
> exactly right. First, the pointer array needs the SAVE attribute to
> ensure that the allocation is saved between calls. Second, it is better
> to use an allocatable array rather than a pointer array. Pointer arrays
> can sometime be much slower because pointers can be aliased, making some
> vectorizations unsafe. For a local pointer, the compiler may or may not
> be smart enough to assume no aliasing. Also, allocatable arrays are
> always initialized as unallocated, so there is no need for the
> 'first_call' flag. This might simplify some of the start-up code to
> avoid memory leaks with multiple calls to SANDER.
Yes this can be allocatable instead of pointer. The main issue here is that
people should NEVER use dynamically allocated arrays unless they know
exactly what they are doing and have very good control over the size of the
stack. Abuse of this is what makes CHARMM more or less unusable on most
supercomputers these days and it is a complete disaster to try and fix +
takes for ever to work out which modules etc you can compile in etc. We
should work hard to make sure AMBER does not go the same way. The biggest
problem is that if you blow the stack you just segfault and often you can
segfault in different places depending on the size of your problem (and thus
stack etc) and such things when a user comes across them are almost
impossible to debug.
The pointer issue is there largely because of the fact that F95 omitted the
ability to have allocatable arrays inside structures which means you have to
use pointers to work around this issue. This is of course a real pain.
Ideally the pointers should also be initialized to NULL when created and
then you can check if they are NULL in a way that is analogous to the is
allocated call for allocatable arrays. In the example given here I think the
variable should indeed just be an allocatable array. Note we should probably
try compiling sander with -assume-no-aliasing and see what happens.
All the best
Ross
/\
\/
|\oss Walker
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.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-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 18 2009 - 01:10:09 PDT
