[MITgcm-devel] exf_readparms: EXF_NML_04

[Martin Losch]

Hi Jean-Michel,

back from vacation. 

Does this mean, that my suggestion/change does not work and should be taken back?

Martin

On Jul 28, 2011, at 8:45 PM, Jean-Michel Campin wrote:

> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel