[MITgcm-support] ctrl_set_globfld_xz/yz

[Matthew Mazloff]

Hi Martin,

Hi Martin,

So this is kinda my fault :o)

To optimize things we wanted to do the writing in large chunks -- so  
yeah, to initialize the field we wrote using the 3D field )and yeah,  
the meta is all wrong).  But we also had singlecpuio enabled for  
MDSWRITEFIELDXZ so it wasnt an issue.  Now that singlecpuio doesnt  
exist for MDSWRITEFIELDXZ, or for the new version (WRITE_REC_XZ_RL),  
we have a problem.

I suggest we do exactly what you say -- though it may slow down  
initialization a bit it is much more consistent with run time behavior  
(i.e. safer).

And one other thing is that I am not sure how JMC's new structure  
works exactly, but if you are worried about the meta files, a write  
meta needed to be added to MDSWRITEFIELDXZ in mdsio_slice.F

Also, if you are going to monkey around with the slice routines, you  
may want to put an if statement in that prevents writing to a tile if  
not on an open boundary.  We are writing a lot of unnecessary files  
filled with zeros.

Thanks
-Matt






On Sep 3, 2009, at 7:08 AM, 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