This may not be the exact piece of mail to reply to on this thread. But on
the subject of allocatable storage, it is extraordinarily simple to just put
all the allocatables that will persist past some subroutine call at the
module level, and then for all such modules containing allocatable storage,
include the equivalent of a constructor, say init_foo() for module foo. You
can then also have the equivalent of a destructor if you need it, and
everything wrt data allocation is pretty simple and clean. You may find
that this sort of data has to be stuffed off in modules of relatively
limited scope due to circular dependency issues that arise in a module-based
language that generate and use module files at compile time (c headers are
much easier to structure a piece of s/w around). But I am sort of amazed at
all the discussion around this stuff. The approach I have used in pmemd is
pretty simple and straightforward, and available as at least one workable
example. Had I rather be working in another language? Probably, but this
stuff is not that hard to do. And on pointers, given that we generally have
a clue regarding how big things can get, you almost never need them (give me
an OS problem in c or c++ and I will pointerize the dickens out of it). And
they are inefficient if you have vectorizable ops. And for most of the
things we do, index offsets are a more efficient implementation. There are
undoubtedly problem domains within the code to which these comments don't
really neatly apply.
Regards - Bob
----- Original Message -----
From: "Joe Krahn" <krahn.niehs.nih.gov>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Monday, March 30, 2009 11:59 AM
Subject: Re: [AMBER-Developers] Amber coding standards
> Mark Williamson wrote:
>> Joe Krahn wrote:
>>> 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.
>>
>>
>> Hi Joe,
>>
>> Relating to this point and eventually linking to the current gfortran -g
>> bug discussion in another other thread. When I started working on the
>> chamber code I hit an issue with allocatable arrays and gfortran 4.1.2.
>>
>> Basically, gfortran 4.1.2 would fail compiling a piece of code like this:
>>
>> cat hello.f95
>> program main
>>
>> contains
>>
>> subroutine foo(x)
>> integer, allocatable :: x(:)
>> end subroutine foo
>>
>> end program main
>>
>> The error generated would be:
>>
>> integer, allocatable :: x(:)
>> 1
>> Error: In the selected standard, ALLOCATABLE attribute conflicts with
>> DUMMY attribute at (1)
>>
>>
>> These are the cvs logs that show where I "fixed" this issue in the
>> chamber code:
>>
>>
>> [mjw:chamber]$ cvs log psfprm.f
>> ---snip---
>> revision 10.16
>> date: 2009/01/23 20:05:44; author: mjw; state: Exp; lines: +35 -35
>> MJW: Attempt to translate a F2003-ism to F95 to avoid the following
>> error with gfortran < 4.2
>>
>> gfortran -c -O3 -fno-second-underscore -ffree-form -o psfprm.o
>> _psfprm.f
>> In file _psfprm.f:2025
>>
>> a0,a1,a2,a3,a4,a5,a6,a7,a8
>> 1
>> Error: ALLOCATABLE attribute conflicts with DUMMY attribute at (1)
>> --snip---
>>
>>
>> and the actual code change:
>>
>> [mjw:chamber]$ cvs diff -r 10.16 -r 10.15 psfprm.f
>> Index: psfprm.f
>> ===================================================================
>> RCS file: /home/amber_cvs/cvsroot/amber11/src/chamber/psfprm.f,v
>> retrieving revision 10.16
>> retrieving revision 10.15
>> diff -r10.16 -r10.15
>> 50c50
>> < integer, pointer, dimension(:) :: iresid,ipres,iac,imove, &
>> ---
>> > integer, allocatable, dimension(:) :: iresid,ipres,iac,imove, &
>> 59c59
>>
>> --etc---
>>
>> So, I changed the allocatable arrays to pointer arrays to avoid this
>> error. However, this is the converse to what is being said above.
>>
>
> These are different issues. Declaring dummy arguments as allocatables is
> not in Fortran90. You only need the argument to be allocatable if you want
> to allocate it inside the subroutine and return the allocated array. The
> original idea is that allocatable arrays are either globals, or only used
> as temporary arrays inside procedures. This is because a local allocatable
> array is automatically deallocated at the end of a procedure.
>
> So, allocatables are always better, but global allocatables need to be
> accessed as globals and not dummy arguments to allocate them.
>
> In general, pointers should only be used to point to memory, and not to
> allocate it. The exception is that derived types cannot hold allocatables
> until F2003, or with the TR-15581 extension, which should not be used yet
> due to portability.
>
> Maybe I should make a Wiki page explaining allocatable and pointer types?
>
> Joe
>
> _______________________________________________
> 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 Wed Apr 01 2009 - 01:09:47 PDT
