Okay, the thing about common blocks - while they are in some senses really
ugly in terms of allowing uncontrolled data sharing and other sins, what
they DO accomplish for us is to allow us to create a block of contiguous
variables that can be broadcast to slaves via mpi. I know of no cleaner way
to do this myself; if you put stuff is a sequenced record, then you can
screw up namelist-based access to a bunch of variables. I think that while
something cleaner would be nice, if we are consistent about how we use these
things, then it is not necessarily the end of the world. On other fronts,
locmem to be specific, I would drop it like a hot rock. It is basically a
software engineering nightmare, especially from the bug-o-rama perspective
(I will presume everyone has a clue why I would say this without me
elaborating further), and you can get much better engineering/reliability
from the use of allocated storage. Just my willing-to-be-a-crank 2 cents...
- Bob
----- Original Message -----
From: "Gustavo Seabra" <gustavo.seabra.gmail.com>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Thursday, March 26, 2009 2:19 PM
Subject: Re: [AMBER-Developers] Goals for AMBER code format/style?
On Thu, Mar 26, 2009 at 12:33 PM, Joe Krahn <krahn.niehs.nih.gov> wrote:
> It would be nice to have more stuff on the Wiki about code strictness and
> plans for the current code. Here are some of my suggestions.
Are we realy bringing the Wiki back? In this case, we would also need
to update a whole lot of stuff there... I'd volunteer to do it, but
I'm afraid I'm not familiar enough with what's already there, what's
still valid, what is not, etc...
> Is AMBER still working towards implicit-none in all source files? It would
> be nice to disable the default implicit-none with compiler flags.
I'm not sure I understand what you mean here. Do you really want to
*disable* implicit none? what is wrong with it?
> Is there any reason not to convert all of the common-block .h files into
> module files? It would be trivial to do a quick conversion by wrapping the
> existing header code, leaving the common blocks as they are, and working
> on
> removing them later.
I always thought the only reason they are still there is because no
one decided to tackle them directly... (until now? :-) )
> At least for Gnu make, it is useful to use $(MAKE) instead of 'make',
> partly
> because it allows a parallel-make, giving much faster build times on
> multi-processor machines. For example, replace:
> cd dir; make xyz
> with:
> $(MAKE) -C dir xyz
> However, I don't know if $(MAKE) and the '-C' flag are standard for BSD
> make
> as well.
I believe this is the same as the common-block --> module issue...
just a matter of people getting to it. Many makefiles are old and
haven't been touched for a long time. Furthermore, there's always the
idea of "if it ain't broke, don't fix it..." and we just learn to live
with it :-(
Gustavo.
_______________________________________________
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 Fri Mar 27 2009 - 01:17:02 PDT
