[MITgcm-support] OBCS settings
Martin Losch
mlosch at awi-bremerhaven.de
Wed Sep 13 03:57:06 EDT 2006
Hi Jill,
I think Matt put you on the right track already, but there one little
thing to add: The exf package is very convenient, especially, if you
have external forcing data (this includes open boundary values) that
have different "record periods", eg. daily wind fields, monthly
precipitation fields, etc.). But if, and only if, your forcing fields
all contain the same number of time records (that is, all are monthly
fields (exclusive-)or daily fields), then you can do without the exf
package (if for some reason, you don't want to use it). The forcing
period (and also that of obcs-fields) is controlled by
peridicExternalForcing, externalForcingPeriod, externalForcingCycle
in PARM03 of "data".
the 1e32 values suggest to me that you are trying to read double
precision files as single precision or vice versa, or you have little
endian file, or something like that.
On thing to try before you go through more trouble: use the "default
values" (OBCSprescribe = .false.) but specify "reasonable" defaults,
the are OBE/Wu/v = 0, and OBE/Wt = tRef(z), OBE/Ws = sRef(z). Make
sure that tRef and sRef are set in data in such a way that they do
not differ too much from you intial fields, or even better, don't
specify any initial T and S, so that you initial fields are also tRef
and sRef and there are no discontinuities at the begining. If that
works you can start putting back in the initial fields and/or obcs-
fields.
Martin
On Sep 13, 2006, at 4:51 AM, jschwarz at awi-bremerhaven.de wrote:
> Matt, you're a star! that will keep me busy for a while..
> Thanks,
> jill.
>
>
>
> ----- Original Message -----
> From: Matthew Robert Mazloff <mmazloff at mit.edu>
> Date: Wednesday, September 13, 2006 2:35 pm
> Subject: Re: [MITgcm-support] OBCS settings
>
>> Hi Jill,
>>
>> I tried to answer all your questions, and I found your problem (see
>> below). Sorry if I am wrong about anything.
>>
>> Good luck!
>> Matt
>>
>>
>> Quoting jschwarz at awi-bremerhaven.de:
>>
>>> Hi Matt,
>>>
>>> Thanks for that. I had made sure that all unfilled 'water' cells
>> in
>>> my initialisation theta and salinity fields were replaced with a
>>> local nonzero mean, but to double check, i've replaced these with
>>> dummy fields of theta=1, salinity=33 for the entire model
>> domain.
>>> And then:
>>>
>>> With closed boundaries, this runs fine (my first 'STOP NORMAL
>> END', yay!).
>>>
>>> With open boundaries, the wierd edge effects kick in again; this
>> is
>>> for sure a problem with my boundaries, not with T,S.
>>>
>>> One crucial piece of information could be that i don't initialise
>> the
>>> velocities at the open boundaries,
>>
>> this is the crucial piece...see below
>>
>>> so perhaps the more pertinent question is: if
>> OB[E/w][u/v/t/s]files
>>> are required, then
>>> a) do i understand correctly from the package code that this
>> means
>>> allowing OBCSprescribe,
>>
>> OBCSprescribe = TRUE then looks for U,V,T,S prescribed boundary
>> condition files
>>
>>> b) do the u/v/t/s files contain simple 2-d binary fields of
>> u/v/t/s
>>> )dims [1 x ny]?
>>
>> they should contain fields [ny x nz x nperiods]...you need to set
>> the
>> period in
>> data.exf unless the obcs are time constant...e.g. in data.exf put
>> obcsEstartdate1 = 20000101,
>> obcsEstartdate2 = 00000,
>> obcsEperiod = 2635200.0,
>>
>>> c) does exf need to be switched on for this, and if so
>>
>> as stated above, only if the obcs are time varying...if your fields
>> are
>> just [ny
>> x nz], then no need for exf package
>>
>>> d) is it possible to prescribe cyclic (e.g. 1 year's worth only)
>>> fields for OBCS but a longer time series for other
>>> packages (KPP & seaice)?
>>
>> yes...the packages are independent. the exf package also allows
>> independentforcing periods to be prescribed...e.g.
>> runoffperiod = 0.0,
>> lwfluxperiod = 21600.0,
>>
>> and finally
>>> e) is it possible to use daily u/v/t/s files run from MITs
>> ongoing
>>> global model runs (or is there some other source i've not found
>> that
>>> gives global, depth-distributed u/v/w fields) ?
>>
>> For your 1 degree setup I recommend using ECCO model output for
>> open boundary
>> conditions. This data can be obtained from the website
>> http://ecco.mit.edu/. Go to the data server page for output...let
>> me
>> know if you have trouble or
>> questions.
>>
>>>
>>> sorry for the deluge of questions- i've only found 1
>> /verification
>>> example that uses obcs and didn't manage to glean much from it.
>>>
>>
>> I'm not really sure what examples are out there...a somewhat older
>> setup I have
>> can be found at
>> http://mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/heimbach/SO4x2/
>> and this may be of some help.
>>
>>> If anyone can point out an example that would help, i'd be grateful.
>>>
>>> To your original question, some of my wierd edge effects (
>> with
>>> dummy initialisation fields of theta=1, S=33, a model domain from
>> -50
>>> to -80 (south), 140 to 260 E, 1 degree isotropic resolution, nx =
>>> 120, ny = 81, nz = 21) :
>>>
>>> T, S at timestep 0 feature a band 1 cell wide at the eastern
>> boundary
>>> which is set to 24 at iz=0 and changes with depth; i think it's
>> being
>>> set to the tref for each depth --- maybe the default behaviour
>> with
>>> non-prescribed boundaries?
>> yes, setting to tref is the default for non-prescribed initial
>> condition fields.
>>
>>> According to the T/S fields shown in state.0000...nc this makes a
>> big
>>> discrepancy at the eastern edge, as the neighbouring cells
>> contain
>>> theta values closer to +-1.
>>>
>> Well that will definately cause "wierd values". Only 1 value is
>> consistent with
>> the interior ocean dynamics. When the prescribed obc is (very)
>> inconsistentwith that values a boundary layer forms where large
>> ageostrophic
>> velocities are
>> common.
>>
>>> min/max OBNu,v,t,s OBEu,v and OBWu,v are +- 1 E+32 at all
>> timesteps,> min/max OBEt,s and OBWt,s are 4 to 24 and 34.58 to
>> 34.9 respectively
>>>
>>> U,V and W go crazy at the EW edges, with strong negative
>> velocities
>>> in the northern corners and positive ones in the southern
>> corners.
>>> At the next 2 timesteps, these get crazier, with interleaved NS
>>> strips of strong + and - velocities, but the velocities at the
>>> boundaries themselves are zero. This is also true if i switch
>>> nonslipsides to true.
>>>
>> Values of +- 1 E+32 mean garbage is being read in. This is your
>> problem! That
>> is funny the model doesnt blow up right away...anyway...you need to
>> give the
>> model a OBNu,v,t,s OBEu,v and OBWu,v field
>>
>> so you have defined ALLOW_OBCS_PRESCRIBE so you need a data.obcs
>> file like:
>>
>> #
>> # ***************
>> # Open boundaries
>> # ***************
>> &OBCS_PARM01
>> OB_Ieast = 81*-1,
>> OB_Iwest=81*1,
>> OB_Jnorth= 120*1,
>> #
>> useOrlanskiNorth=.FALSE.,
>> useOBCSsponge=.FALSE.,
>> useOBCSbalance=.FALSE.,
>> useOBCSprescribe=.TRUE.,
>> #
>> OBNuFile='UNBC.bin',
>> OBNvFile='VNBC.bin',
>> OBNtFile='TNBC.bin',
>> OBNsFile='SNBC.bin',
>> OBEuFile='UEBC.bin',
>> OBEvFile='VEBC.bin',
>> OBEtFile='TEBC.bin',
>> OBEsFile='SEBC.bin',
>> OBWuFile='UWBC.bin',
>> OBWvFile='VWBC.bin',
>> OBWtFile='TWBC.bin',
>> OBWsFile='SWBC.bin',
>> #
>> &
>>
>> All these files must be given....otherwise values of +-1E32 are
>> read in.
>>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
More information about the MITgcm-support
mailing list