[MITgcm-support] upgrade to latest checkpoint

[Matthew Mazloff]

Hi Jody,

But if mdsioLocalDir is not defined in your data file then I believe  
it will not make directories....and everything will be in your output  
directory.

A quick fix though is just to type

mv 0???/* .

and all directory info will be dumped back into output....

-Matt




On Aug 16, 2009, at 1:19 PM, Jean-Michel Campin wrote:

> Hi Jody,
>
> Few remarks:
> 1) the main reason why we changed the "mdsioLocalDir" behavior
> is that on some platform (more precisely, with some file system),
> it's much slower when all processors write to the same dir;
> adding the proc number to the mdsioLocalDir name was a way to go
> arround this. Did not think that this mdsioLocalDir was already
> used for some other purpose. We might add an other flag to
> restaure previous behavior.
> But I don't know if we will modify rdmds.m to deal with multiple dir
> (might slow down this script on some system).
>
> 2) Regarding 1.D vector:
>> DRF.*, DRC.*, PHrefC.*, PHrefF.*, RC.* and RF.*
> they are not related to 1 particular tile (no 00x.00y ) and
> they follow "global file" convention i.e., ignoring mdsioLocalDir
> instruction. I agree that it might appear a little bit obscure, but
> it's not strictly speaking a bug.
>
> Cheers,
> Jean-Michel
>
> On Sat, Aug 15, 2009 at 06:54:22PM -0700, Klymak Jody wrote:
>> Hmmm, the code now writes as the MDS files as:
>>
>> outputdir/0000/V.00000001200.001.001.meta
>> outputdir/0000/V.00000001200.001.001.data
>>
>> outputdir/0001/V.00000001200.001.002.meta
>> outputdir/0001/V.00000001200.001.002.data
>>
>> i.e where 0000, 0001, etc are directories containing the output from
>> each processor used to make the run (which also is the output of each
>> tile in my setup).  It used to put these all in one directory, and  
>> rdmds
>> seems to handle that fine.  Probably the easiest thing would be if  
>> there
>> is a way to stop the new behaviour.
>>
>> If that is the file structure you have then I'm a little confused  
>> how to
>> call the function.  Normally I'd just do
>>
>>  V = rdmds('outputdir/V',1200);
>>
>> and that would return all tiles.  I can do
>>
>>  V=rdmds('outputdir/0001/V',1200);
>>
>> but that just returns the second tile.
>>
>> Thanks,  Jody
>>
>>
>> On 15-Aug-09, at 6:12 PM, Holly Dail wrote:
>>
>>> Hi Jody -
>>>
>>> Unless I misunderstand the file structure you're describing, the
>>> attached rdmds.m works fine for me with a call like:
>>>
>>> 	xx_hfluxm_iter2 = rdmds([run2,'/xx_hfluxm.0000000002']);
>>>
>>> <rdmds.m>
>>>
>>>
>>> I would guess the version in the CVS under MITgcm/utils/matlab/ 
>>> rdmds.m
>>> probably works too, but I haven't updated that code recently.
>>>
>>> Holly
>>>
>>>
>>> On Aug 15, 2009, at Aug 15 , 6:27 PM, Klymak Jody wrote:
>>>
>>>> 	
>>>> Hi all,
>>>>
>>>> I just upgraded from a 2006 version of the gcm to c61T.  It looks
>>>> like its working, but a few of the utility routines have changed so
>>>> I have some debugging before I'm sure my code mods are correct.  A
>>>> couple of questions in the meantime:
>>>>
>>>> Does anyone have an rdmds.m that works with the new file structure
>>>> (i.e. 0000/*.001.data, 0001/*.002.data, etc) or is there an easy  
>>>> way
>>>> to turn that file structure off?
>>>>
>>>> DRF.*, DRC.*, PHrefC.*, PHrefF.*, RC.* and RF.* all are written to
>>>> the directory the gcm is run from, not from the directory indicated
>>>> by mdsioLocalDir, where everything else goes.  This was a problem  
>>>> in
>>>> the 2006 version as well, and I think qualifies as a bug.  Looks
>>>> like write_glvec_rs.F,  doesn't respect mdsionLocalDir.
>>>>
>>>> Thanks,  Jody
>>>>
>>>> --
>>>> Jody Klymak
>>>> http://web.uvic.ca/~jklymak
>>>>
>>>> _______________________________________________
>>>> 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