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