[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