[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