Ross Walker wrote:
> Hi Joe,
>
>> That is why we need a list of allowed extension routines. Sander appears
>> to only use IARGC, GETARG and EXIT. Maybe those 3 are the complete list.
>
> Yes although I think right now we are okay with all of those. The original
> idea though was that we have wrappers for all the extension routines that
> deal with exceptions. For example people should ONLY be using mexit (or
> through sander_bomb) and NOT calling exit directly. The routine mexit is
> defined in mexit.f (although there is one in both src/lib/ and src/sander/
> which is somewhat confusing) and deals with cases where exit is not
> supported. E.g.
>
> #ifdef XLF90
> if (status /= 0) then
> stop 1
> else
> stop 0
> end if
> #else
> call exit(status)
> #endif
>
> Note the one in src/sander/ does not seem to correctly deal with calling
> exit when MPI is defined. Here it always seems to call exit regardless of
> the definition.
>
> The same is true for getarg - you are supposed to call getarg_wrap (same for
> iargc). However, I think what is generally happening these days is that
> everything (as far as most users are concerned) is converging on a single
> operating system (Linux) or variations thereof and a single instruction set
> (x86_64) hence nothing else (bsd etc etc) is being properly tested. So
> people just add the extension calls to the code, find it compiles on their
> machine and then assume all is good.
>
> We should probably organise a retreat for a select group of coders to get
> together (no presentations allowed etc) and decide on a series of standards
> etc and then go through the code and clean it up / enforce those standards.
>
> All the best
> Ross
>
The way I would implement it is to create an EXIT() subroutine in
src/lib for compilers that don't have it, which can be called directly
by utility functions or by MEXIT from SANDER. That is sort of how the
src/lib MEXIT works, except that it is not called by Sander's MEXIT.
GETARG_WRAP is different, because it is implemented for SANDER, and not
a generic portable front-end to handle compiler differences. If Amber
does implement a portable front-end to getarg, it might be better to use
the F2003 syntax, which will eventually be the proper way to get command
args.
There probably needs to be a list of allowed extension routines for
utilities, and a separate set of restrictions for SANDER code.
It would help to use strict compiler flags to minimize non-standard
usage, but this will require some code clean-up, and will usually not
give warnings for external extension subroutines.
Joe
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 18 2009 - 01:17:45 PDT
