[MITgcm-support] ctrl_set_globfld_xz/yz
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Sep 3 11:02:47 EDT 2009
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
More information about the MITgcm-support
mailing list