[MITgcm-support] Changing mds file suffix

Jody Klymak jklymak at uvic.ca
Tue Feb 28 01:45:35 EST 2017



Sent from my iPad

> On Feb 27, 2017, at 22:29, Christoph Voelker <christoph.voelker at awi.de> wrote:
> 
> Hi Jody,
> also, even though it may not break the code, it will also force people
> to change their job scripts, analysis tools etc. It is of course not a
> terribly difficult thing to do, but unlike for the code, where everyone
> can change doing an update, everyone has to change their scripts on
> their own.


The default will be the same as it is now.  No one would *have* to use this new naming scheme, it would just be an option.  

Cheers,   Jody. 

> Cheers, Christoph
> 
>> Am 27/02/2017 um 21:25 schrieb Jean-Michel Campin:
>> Hi Jody,
>> 
>> It should not be too difficult to support a different convention for 
>> output file suffix, but probably easier if we keep the 10 digits/character.
>> 
>> One issue with "time in second" suffix is that it does not support time-step
>> that are not integer number of seconds, and after 320 something years
>> it exceeds the 10 digit number limit.
>> 
>> And regarding meta files, time is included in the list of arguments of the routine
>> that write meta files (S/R MDS_WRITE_META in file mdsio_write_meta.F),
>> and some *.meta files contain time information ( timeInterval = ...),
>> such as pickup files and output files from pkg/diagnostics.
>> But most of the I/O routines in pkg/rw and/or in pkg/mdsio don't have
>> myTime as argument and consequently output meta files that are written from
>> there don't have any time information.
>> 
>> Cheers,
>> Jean-Michel
>> 
>>> On Sun, Feb 26, 2017 at 08:35:35PM -0800, Jody Klymak wrote:
>>> Hi all, maintainers in particular,
>>> 
>>> There are a number of places in the code where file i/o creates a suffix based on myIter:
>>> ```
>>> WRITE(suff,'(I10.10)') myIter
>>> ```
>>> 
>>> I???ve found this restrictive for runs where I need to change deltaT (i.e. slow spinup past a startup transient).  I need to rename pickup files, and, worse, previous output can have the same iteration number as new output and get overwritten.  I???d *prefer* to save my files as 
>>> ```
>>> WRITE(suff,'(I10.10)') myTime
>>> ```
>>> i.e. `T.0000036000.data` refers to 10 hours, rather than iteration 36000.
>>> 
>>> Would it be possible for me to change the code above to:
>>> 
>>> ```
>>> CALL RW_GET_SUFF( myTime, myIter, myThid, suff )
>>> ```
>>> 
>>> and write that code with the default set to the above, but new parameters that allow other formats?  (i.e. I could imagine some would like simulation hours or days).  
>>> 
>>> Is this a terrible idea for some reason?  If I went through the exercise, would it have a hope of being merged?  I???d just do it for myself, but its actually deep enough in the code that it would be a personal nuisance to repatch every new version that I download.
>>> 
>>> I guess while I???m at it, I???ll ask again why the meta files don???t have the time written in them.  Is there anything that would break by adding:
>>> 
>>> ```
>>> timeStepNumber = [       8640 ];
>>> myTime = [     43200 ];
>>> ```
>>> 
>>> Thanks a lot,  Jody
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> -- 
> Christoph Voelker
> Alfred Wegener Institute for Polar and Marine Research
> Am Handelshafen 12
> 27570 Bremerhaven, Germany
> e: Christoph.Voelker at awi.de
> t: +49 471 4831 1848
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20170227/7c92a113/attachment-0001.htm>


More information about the MITgcm-support mailing list