[MITgcm-devel] putting mnc init in fizhi (and land)
Ed Hill
ed at eh3.com
Fri Jul 9 09:36:07 EDT 2004
On Fri, 2004-07-09 at 08:03, Andrea Molod wrote:
> hi ed,
> you asked to have this stuff sent to the devel list, you got it.
Hi Andrea,
Thank you for sending email to the devel list. I mean that sincerely.
> my understanding of the conversation with JM and you and myself
> about where to initialize some of the package dependant mnc
> stuff is that we ended up seeing that it SHOULD NOT be done inside
> the package, but needs to be in mnc and/or the diagnostics if
> the mnc stuff is only for diagnostics. (JM, do you recall???)
>
> and structurally, i frankly can't see any reason why fizhi for
> instance has to know whether the diagnostics in the end will be
> output with mnc or mdsio. the same may go for the land. can you
> imagine putting mnc init stuff inside of every package that has
> its own size (or other) parameters that mnc has to know about?
> that to me seems to be part of the functionality inside mnc....
The "fizhi_mnc_init" routine doesn't do anything useful for the
diagnostics package. Its just a subroutine that initializes a group of
MNC "Grid types" (strings) so that FIZHI variables (those with Z=Nrphys)
can then be easily written or read using MNC. Its true that the routine
was created while I was working on diagnostics, but now its just
infrastructure that I'd like to put in place so that we can read/write
the FIZHI fields with MNC.
Eventually, I'd like to be able to read/write every field in every
package with MNC so that it can be used for pickups.
> so - maybe fizhi_mnc_init should be in mnc, with fizhi ifdefs
> around it.
I tend to agree with Alistair -- that its supposed to be the other way
around. But I bow to the wishes of the overall group!
> as for the land part, if the mnc init stuff MUST go in the land package,
> at a minimum shouldn't it be ifdef'd with mnc package?
The corresponding "land_mnc_init()" routine has the necessary #ifdef-s.
I tested it last night before checking it in.
> oh yeah - WHAT is FIZHI_OPTIONS.h doing?
I'm just trying to follow the convention used in most of the other
packages. If it causes any problems (which it shouldn't), it is very
easy to remove.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3 at mit.edu ed at eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
More information about the MITgcm-devel
mailing list