[MITgcm-support] MITgcm floats.................

Ryan Abernathey rpa at MIT.EDU
Mon Apr 16 09:35:36 EDT 2012


 From the perspective of another user, option 3 makes the most sense  
to me. It seems like floats should function in a way that is  
completely analogous to ptracers.

For ptracers there is a parameter PTRACERS_Iter0. If  
nIter0.EQ.PTRACERS_Iter0, then the initial conditions are read (see  
ptracers_init_varia.F).

So the logical step would be to introduce FLT_Iter0. This would allow  
what Andreas wants to do and still preserve backwards compatibility.

-Ryan


On Apr 16, 2012, at 1:14 AM, Andreas Klocker wrote:

> J-M,
>
> Thanks for that. What do you think would be the best way to solve  
> this issue more permanently though? I think spinning up a model  
> without floats and then doing a float experiment might be a very  
> common thing..
>
> I'll definitely try solution 3 and 4 though and let you know what  
> happens.
>
> cheers,
> Andreas
>
> On 14/04/12 03:13, Jean-Michel Campin wrote:
>> Hi Andreas,
>>
>> There are several options:
>> 1) not changing the code, starting with nIter0=0 and to replace
>>  the main pickup files with a set of initial conditons files
>>   (pSurfInitFile= ..., hydrogThetaFile= ..., hydrogSaltFile= ...,
>>   uVelInitFile= ..., vVelInitFile= ...) corresponding to what is  
>> stored
>>  in the pickup file.
>> 2) generate a "pickup_flt" file yourself. It's very similar to float
>>  initial condition file (if mapIniPos2Index is set to False);
>>  But since you were probably prepared to use the default (which is
>>   mapIniPos2Index=T), you will have do the conversion yourself when
>>  generating this pickup_flt file, that is to give float position in  
>> index
>>  space instead of distances (and 1 file per tile, since this does  
>> not work
>>  with global files).
>> 3) modify flt_init_varia.F to read float initial conditions
>>   even when nIter0<>  0  and generate a modified "mitgcmuv"  
>> executable.
>>   You will used this modified executable to start the float  
>> simulation
>>   but will have to return to the un-modified one to continue after  
>> a restart.
>> 4) try this trick: since flt_init_varia.F does not recognize  
>> pickupSuff,
>>   you could try the following:
>>   a) set nIter0=0 and pickupSuff= {the name of your pickup file} in
>>      main parameter file "data", 3rd namelist.
>>   b) use normal float initial conditions file.
>>  let me know if this 4th solution does not work.
>>
>> Cheers,
>> Jean-Michel
>>
>> PS: I cc to support, might be useful for other pkg/flt users.
>>
>> On Fri, Apr 13, 2012 at 02:32:27PM +1000, Andreas Klocker wrote:
>>> Dear Masters of the MITgcm,
>>>
>>> I just started to experiment with floats in Ryan's channel and
>>> noticed a little problem. I'm trying to initialize floats starting
>>> from a spun-up state which David produced, but after looking at
>>> flt_init_varia.F it seems like I can only either start with a file
>>> with initial float positions if nIter0=0 (which means I would have
>>> to spinup the model again) or start from a pickup file (which I
>>> obviously don't have because there were no floats in the channel so
>>> far):
>>>
>>> C read floats initial condition from file
>>>       _BEGIN_MASTER(myThid)
>>>       IF ( nIter0.EQ.0 ) THEN
>>>         fn = flt_file
>>>       ELSE
>>>         WRITE(fn,'(A,I10.10)') 'pickup_flt.', nIter0
>>>       ENDIF
>>>       iL = ILNBLNK(fn)
>>>       WRITE(msgBuf,'(2A)')
>>> &    'FLT_INIT_VARIA: reading Floats from: ', fn(1:iL)
>>>       CALL PRINT_MESSAGE( msgBuf, standardMessageUnit,
>>> &                     SQUEEZE_RIGHT, myThid )
>>>
>>>
>>> What do you think is the easiest way to get around that? In the file
>>> with the initial float positions I can set a time (in s) when the
>>> floats are meant to start, but that file is only read if
>>> nIter0=0.... Is there an easy way to modify the Fortran code to fix
>>> that problem? Maybe some way to tell the model in the data.flt file
>>> if it is meant to look for an initial float file or a pickup?
>>>
>>> Any ideas?
>>>
>>> all the best from Oz,
>>> A.
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list