Fortran 90/95 is a big improvement over any fortran you would have used in
1987. Still a stone ax in a number of ways, but mostly in ways that someone
like myself would find annoying... Allocation is simple; you just use the
allocate() and deallocate() statements. Plenty of examples in pmemd. For
stuff that is invariant, I do it at setup. For stuff that changes with
time, I reevaluate as needed and deallocate/reallocate. You generally don't
want to be fragmenting the heap with a continuous stream of small
allocations/deallocations, so it is good to think about what you are doing a
bit. I also like to use dynamic arrays on the stack (all you do is declare
the array as a variable in a subroutine and dimension it by input parameters
to the subroutine), though this can cause grief on systems where the
stacksize has a low limit (fixable by sysadmin, but still a hassle). You
can actually improve cache utilization by extensive use of stack storage in
the right context, where you have different sets of temporary arrays in use
at different times. Anyway, the dynamic memory alloc I do in pmemd is
pretty simple and efficient, so it is a "not bad" example. Sander still has
it's own stack architecture for dynamic memory; while this was a great
bridge allowing us to size data structures as needed in the pre-f90 days, it
would be probably fair to say it is overly complex and error prone (no
offense intended; it was a good bridge).
Best Regards - Bob
----- Original Message -----
From: "Lachele Foley" <lfoley.ccrc.uga.edu>
To: <amber-developers.scripps.edu>
Sent: Tuesday, November 11, 2008 9:41 AM
Subject: Re: amber-developers: Extra Points Calculation
>> understand the exact storage requirement, and get data organized in such
>> a
>> manner as to increase cache utilization
>
> Yes. Good idea. Of course. I'm all for efficient resource use. I was
> wondering how hard it would be to implement a dynamic sort of allocation
> in this situation. Seems it ought to be possible, but my last significant
> fortran was back in... oh... 1987, and there wasn't much of it even then.
>
>> but if someone wants to shoot me a
>> copy of the runfiles, I will see what it does in pmemd.
>
> Will do, in just a moment.
>
> :-) Lachele
> --
> B. Lachele Foley, PhD '92,'02
> Assistant Research Scientist
> Complex Carbohydrate Research Center, UGA
> 706-542-0263
> lfoley.ccrc.uga.edu
>
>
> ----- Original Message -----
> From: Robert Duke
> [mailto:rduke.email.unc.edu]
> To: amber-developers.scripps.edu
> Sent: Tue, 11
> Nov 2008 08:50:49 -0500
> Subject: Re: amber-developers: Extra Points
> Calculation
>
>
> [snip]
>>
>> ----- Original Message -----
>> From: "David A. Case" <case.biomaps.rutgers.edu>
>> To: <amber-developers.scripps.edu>
>> Sent: Tuesday, November 11, 2008 7:08 AM
>> Subject: Re: amber-developers: Extra Points Calculation
>>
>>
>> > On Mon, Nov 10, 2008, Volodymyr Babin wrote:
>> >>
>> >> please see the patch for cvs sander attached. Does it
>> >> look harmless enough to be committed?
>> >
>> > Does it solve Lachele's problem (the sucrose_EP test case)? As far as
>> > I
>> > can
>> > see, that example does not include any "LP" atoms, and I don't think we
>> > should
>> > be expanding to that...my recollection was that "LP" atoms (still found
>> > in
>> > some old parameter/topology files) were *not* treated as extra points,
>> > but
>>
>> > as
>> > real atoms.
>> >
>> > I tried to expand the size of max14 (not as much as you did), and was
>> > still
>> > getting segfaults on Lachele's example. But it is great if your fix
>> > works.
>> >
>> > ...dac
>> >
>> >
>>
>>
>
Received on Fri Dec 05 2008 - 14:26:37 PST
