One way to make the transition a bit more gradual is to keep the common
block inside the MEMORY module, but also define pointer arrays with nice
names, for example:
integer, pointer :: residue_pointer(:)
...
subroutine memory_init()
residue_pointer => ix(i02:i02+nres)
...
Then people can access the residue_pointer array by name, and code can
be updated gradually, instead of breaking and then trying to debug a
single large overhaul.
Joe
Crowley, Michael wrote:
> Hi Guys,
> One of the reasons for keeping the locmem method around was for the ease of
> broadcasting the whole data structure as a unit in the beginning.
> There are ways of doing that now with mpi types which we should move to for
> this kind of broadcasting of multiple things without doing multiple
> broadcasts.
> So I agree that it should go in a module now, but that the broadcast should
> be figured out at the same time.
> Cheers,
> Mike
>
>
> On 3/18/09 1:35 PM, "Ross Walker" <ross.rosswalker.co.uk> wrote:
>
>> Hi Joe,
>>
>> I think this has been on the cards for a while, at least adding most things
>> to modules and getting rid of all the common blocks etc. The thing that has
>> slowed this down in some cases is there is a lot of subtle stuff implied by
>> all of this. I.e. the forcing of things to be linear in memory etc. Since a
>> lot of the MPI calls assume this to be the case. Hence I and others have
>> been burnt by removing a common block and placing it in a module for
>> example. The net result being that we have put it back the way it was and
>> made a mental note to go back and do it when we have more time which often
>> doesn't materialize.
>>
>> While adding the locmem stuff to a module is a good idea I think really what
>> that needs is a complete overhaul. I.e. we should do away with the get stack
>> approach etc. Mike Crowley was on his way to doing this before he got side
>> tracked by DOE stuff and so it never got finished.
>>
>> So yes while I would applaud you adding this to a module I think really it
>> would be better if we instead took the time to replace it rather than making
>> it easy to use in which case the impetus to replace will be reduced and it
>> will stay in therefore another decade.
>>
>> All the best
>> Ross
>>
>>>> -----Original Message-----
>>>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>>>> bounces.ambermd.org] On Behalf Of Joe Krahn
>>>> Sent: Wednesday, March 18, 2009 11:47 AM
>>>> To: AMBER Developers Mailing List
>>>> Subject: [AMBER-Developers] Fortran module for LOCMEM?
>>>>
>>>> It would be nice to be able to access LOCMEM globals without recursively
>>>> passing the stack arrays from the main SANDER routine, by putting them
>>>> into a module. PUPIL already does this, but it would be better to have a
>>>> standard module, where SANDER, PUPIL and others can USE the stack arrays.
>>>>
>>>> The LOCMEM module can also include memory.h, so you can access a stack
>>>> index without having to access the whole set of LOCMEM index variable
>>>> names.
>>>>
>>>> It is pretty simple:
>>>>
>>>> #include "dprec.h"
>>>> module memory
>>>> #include "memory.h"
>>>> _REAL_, dimension(:), allocatable :: x
>>>> integer, dimension(:), allocatable :: ix
>>>> character(len=4), dimension(:), allocatable :: ih
>>>> end module memory
>>>>
>>>>
>>>> then in sander.f
>>>> use memory, only: x, ix, ih
>>>>
>>>> and pupildata.f:
>>>> use memory, only: ixStack=>ix, realStack=>x, ihStack=>ih
>>>>
>>>> Or, skip the "only:" part, and don't #include "memory.h".
>>>>
>>>> It could also be used to hold general-purpose globals that are not part
>>>> of the LOCMEM arrays. In fact, the module could be called "globals"
>>>> instead of "memory".
>>>>
>>>> Joe
>>>>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 22 2009 - 01:08:50 PDT
