[MITgcm-support] ctrl_set_globfld_xz/yz

[Martin Losch]

Hi Jean-Michel,

thanks,
I am so behind the recent code (maybe 5days, mea culpa (o:)

@Matt: we could keep the old code and add an appropriate CPP_FLAG  
around it, e.g. CTRL_INITOBCS_QUICK_AND_DIRTY, and then introduce new  
code that uses write_rec_xz/yz_rl to make Jean-Michel happy. That way  
you could keep that faster initialization. We can also put an IF  
(.not.useSingleCPUio) THEN/ENDIF around it. What do you think? None of  
this is shown to TAF, isn't it? (according to ctrl_ad_diff.list; I  
haven't used TAF on this, yet).

There is no way to increment nRecords in a meta file, yet, (at least I  
don't know of any), so writing a meta file for the adxx/xx_obcs-files  
is non-trivial (and I don't think I want to embark on this).

M.

On Sep 3, 2009, at 5:02 PM, Jean-Michel Campin wrote:

> Hi Martin,
>
> It was just a comment (and will not fix the issue you have with
> singleCpuIO/globalFile). But since I recently tried to clean-up
> those section/slice IO, I thought it would be usefull to mention it.
> It's in pkg/rw/write_rec.F (cvs version 1.4, from Sept 01, 2009).
> Cheers,
> Jean-Michel
>
> On Thu, Sep 03, 2009 at 04:46:56PM +0200, Martin Losch wrote:
>> Hi Jean-Michel,
>>
>> I cannot find WRITE_REC_XZ_RL anywhere (write_rec.F contains only  
>> the xy
>> combination). Where is it?
>>
>> Martin
>>
>> On Sep 3, 2009, at 4:08 PM, Jean-Michel Campin wrote:
>>
>>> Hi Martin,
>>> Just a comment:
>>> We should try not to use MDSWRITEFIELDXZ( ... ,'RL', ...)
>>> anymore, but instead WRITE_REC_XZ_RL
>>> Jean-Michel
>>>
>>> On Thu, Sep 03, 2009 at 03:26:10PM +0200, Martin Losch wrote:
>>>> Hi all (probably mostly Patrick and Matt)
>>>>
>>>> why do we need this complicated arrangement in ctrl_set_globfld_xz/
>>>> yz of
>>>> first writing a 3d field into, say, adxx_obcsn.*.data, and then
>>>> adding
>>>> the remaining number of vertical slabs? Wouldn't it be easier to
>>>> replace
>>>> the two loops by just one like this:
>>>>
>>>>>     do irec = 1, ncvarrecs(ivartype) +1
>>>>>        call MDSWRITEFIELDXZ( fname, ctrlprec,.FALSE., 'RL',
>>>>>    &        Nr, globfldxz,
>>>>>    &        irec,   optimcycle,  mythid)
>>>>>     enddo
>>>>
>>>> Is it just because the mdsiowritefieldxz/yz do not write meta- 
>>>> files?
>>>> But
>>>> what is the use of a meta file for a 3D field that is clearly wrong
>>>> (dimensions and nRecords will only be accidentally correct)?
>>>>
>>>> We are having an interesting problem with this: we have
>>>> useSingleCPUio=.true. and globalFiles=.false. so that
>>>> mdswritefld writes a file adxx_obcsn.0000000000.data (because of
>>>> useSingleCPUio=.true.). Then for irec > nrec_nl mdswritefieldxz
>>>> tries to
>>>> append a file adxx_obcsn.0000000000.001.001.data (because
>>>> globalFiles=.false.), which does not exist and the model stops with
>>>> "File does not exist". It took me a while to figure that out,  
>>>> because
>>>> for short integration times ncvarsrecs<Ny so that nrec_nl = 0 and
>>>> the 3d
>>>> field is never written. The problem appeared only for longer
>>>> integrations (so that ncvarsrecs>=Ny and nrec_nl>0). Bug or  
>>>> feature?
>>>> Is
>>>> there a problem with the above fix?
>>>>
>>>> Martin and Olaf
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support