[MITgcm-devel] exf_readparms: EXF_NML_04

Jean-Michel Campin jmc at ocean.mit.edu
Thu Jul 28 14:45:52 EDT 2011


Hi Martin,

There is a problem on aces cluster with open64 compiler
with experiment seaice_obcs (data.exf has namelist EXF_NML_04
which needs to be skipped to read EXF_NML_OBCS, and it's not
doing it correctly), see last night test: 
http://mitgcm.org/testing/results/2011_07/tr_aces-tuv_20110728_0/seaice_obcs/run.tr_log

It's an old version/compiler (4.2.1), need to see if a newer version works better.
In the mean time, I am going to change seaice_obcs/input/data.exf
so that this test can pass.

Cheers,
Jean-Michel

On Wed, Jul 27, 2011 at 12:18:03PM -0400, Jean-Michel Campin wrote:
> Martin,
> 
> > I can try to change exf_readparms.F to be a little more consistent and we can see how it goes?
> I agree, and saw your changes, it makes sense.
> Cheers,
> Jean-Michel
> 
> On Wed, Jul 27, 2011 at 04:13:56PM +0200, Martin Losch wrote:
> > Hi Jean-Michel,
> > 
> > currently your expectation would not be met by the code for ICEFRONT nor OBCS.
> > 
> > USE_EXF_INTERPOLATION does not have run time parameter, so that's different anyway.
> > 
> > I did not mean to suggest to include all sorts of namelists into our verification/*/input*/data.exf 
> > I was thinking about my runs where I want to compare with and without USE_EXF_INTERPOLATION and still use similar data.exf (with EXF_NML_04). Currently, that's not possible (and maybe not so important, either).
> > 
> > I can try to change exf_readparms.F to be a little more consistent and we can see how it goes?
> > 
> > Martin
> > 
> > On Jul 27, 2011, at 3:53 PM, Jean-Michel Campin wrote:
> > 
> > > Hi Martin,
> > > 
> > > I think there is not yet a well defined rule regarding those optional
> > > namelists.
> > > But I would prefer (and would expect) to get the same behavior with
> > > 1) with #undef ALLOW_ICEFRONT
> > > and 
> > > 2) with useICEFRONT=.FALSE. and with #defined ALLOW_ICEFRONT
> > > same with OBCS (but does this apply to USE_EXF_INTERPOLATION too ?)
> > > 
> > > Otherwise, I don't know if it will be a good idea to add in our 
> > > verification/*/input*/data.exf
> > > all the potential namelist (even if they are not read, it will not cause
> > > problems) so that in case we add a pkg/option, will still be able to read
> > > data.exf
> > > This is what I would favor regarding data.gmredi, but don't know about 
> > > data.exf
> > > 
> > > Cheers,
> > > Jean-Michel
> > > 
> > > On Wed, Jul 27, 2011 at 12:12:04PM +0200, Martin Losch wrote:
> > >> Dear EXF'lers and other namelisters,
> > >> 
> > >> do we have a general policy for "optional" namelists? For example, the namelist EXF_NML_04 is pretty empty) when USE_EXF_INTERPOLATION is undefined (it contains only idummy, and that is probably the case only because you cannot have empty namelists?). Still it is read. The next namelist (EXF_NML_SGRUNOFF) is alway defined, but only read when ALLOW_ICEFRONT is defined, the same is true for EXF_NML_OBCS.
> > >> 
> > >> Wouldn't it make sense to define and read these namelists, only when the appropriate CPP flags are set? As far as I know it doesn't matter to have extra namelists in a file, that are not read, but it does matter when a namelist is read that contains entries that are not defined (as currently possible with EXF_NML_04).
> > >> 
> > >> What do you think about this?
> > >> 
> > >> Martin
> > >> 
> > >> 
> > >> _______________________________________________
> > >> MITgcm-devel mailing list
> > >> MITgcm-devel at mitgcm.org
> > >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> > > 
> > > _______________________________________________
> > > MITgcm-devel mailing list
> > > MITgcm-devel at mitgcm.org
> > > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel



More information about the MITgcm-devel mailing list