[MITgcm-support] Open Boundaries
heimbach at mit.edu
heimbach at mit.edu
Tue Feb 10 09:22:08 EST 2004
Hi there,
the ECCO-related obcs stuff is not yet merged into the main branch
(it's the only remaining non-merged piece).
It causes the problems Stefano is facing.
We may need to meet to agree on what should be merged
and whether the current ecco-branch implementation
is OK (I remember there were issues in the past
since the time-dependent obcs sponge layer interacts with cal,
and not everyone was happy with it).
-Patrick
Quoting Alistair Adcroft <adcroft at MIT.EDU>:
> Jake,
>
> Is there a problem here? Or is it a usage issue?
>
> A.
> --
> Dr Alistair Adcroft http://www.mit.edu/~adcroft
> MIT Climate Modeling Initiative tel: (617) 253-5938
> EAPS 54-1523, 77 Massachusetts Ave, Cambridge, MA, USA
>
> -----Original Message-----
> From: mitgcm-support-bounces at mitgcm.org
> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of quero_s at libero.it
> Sent: Tuesday, February 10, 2004 6:51 AM
> To: MITgcm support
> Subject: [MITgcm-support] Open Boundaries
>
>
> Hello,
> in these last days, I tried to make the model (version: 'checkpoint52e_pre')
> read external (time and space dependent) BC files. I added to the oceanic
> standard package group the exf and cal packages and built the code
> succesfully. I encountered several problems during runtime... I think there
> is a bug in the exf_getffields routine, that should call exf_getobcs
> (exf_obcs, as specified in the call tree in exf_getforcing.F (below)):
>
> C !CALLING SEQUENCE:
> c ...
> c exf_getforcing
> c |
> c |-- exf_getclim (get climatological fields used e.g. for relax.)
> c |
> c |-- exf_getffields <- this one does almost everything
> c | | 1. reads in fields, either flux or atmos. state,
> c | | depending on CPP options
> c | | 2. If forcing and control is flux, we're already done here
> c | | 3. If forcing is atmos. state, then
> c | | (a) if control is atmos. state, then the control variable
> c | | anomalies are read here
> c | | * ctrl_getatemp
> c | | * ctrl_getaqh
> c | | * ctrl_getuwind
> c | | * ctrl_getvwind
> c | | 4. flux fields are interpolated on current time
> c | | (b) next the flux fields are computed via bulk formulae
> c | |
> c | |-- exf_obcs
> c | If open boundaries are prescribed externally,
> c | OB values for current time step are read here
> c | 1. for each boundary (north, south, west, east)
> c | sliced fields are read for T,S,U,V
> c | 2. if OB's are part of control vector,
> c | control variable anomalies are added to OB values
> c | * ctrl_getobcsn
> c | * ctrl_getobcss
> c | * ctrl_getobcsw
> c | * ctrl_getobcse
> c |
> c |-- exf_bulkformulae
> c | If ALLOW_BULKFORMULAE, compute fluxes via bulkformulae
> c |
>
>
> In exf_getffields there is no call to exf_obcs or exf_getobcs. I added this
> call to the routine and the model seemed to read the files. Though, the
> values were overwritten by the values prescribed in obcs_calc.F (zero u and
> v velocity, initial temperature and salinity, by default). I decided to move
> the call in this latter routine but I think that the records are not read
> correctly (below there is the pattern of u comp of velocity: the iput file
> had constant values (-0.01 m/s)!): values went to NaNQ after few iterations.
>
> // =======================================================
> // Field OBNu at iteration 2
> // CMIN = 7.777777777777828E-02
> // CMAX = 3.500000000000000E+01
> // CINT = 1.293415637860082E+00
> // SYMBOLS (CMIN->CMAX): -abcdefghijklmnopqrstuvwxyz+
> // 0.0: .
> // RANGE I (Lo:Hi:Step):( 1: 64: 1)
> // RANGE J (Lo:Hi:Step):( 1: 1: -1)
> // RANGE K (Lo:Hi:Step):( 1: 20: 1)
> // =======================================================
> J = 1
> I=10 I=20 I=30 I=40 I=50 I=60
> |--K--|123456789|123456789|123456789|123456789|123456789|123456789|1234
> 1 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 ++++++++++++++++++++++++++++++++++++++++++......................
> 4 ....................................++++++.+++++++++++++++++++++
> 5 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 6 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 7 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 8 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 9 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 10 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 11 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 12 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 13 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 14 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 15 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 16 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 17 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 18 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 19 +++++++++++++++++++++++++++++++++++.++++++.+++++++++++++++++++++
> 20 +++++++++++++++++++++++++++++++++++.++++++-+++++++++++++++++++++
> // =======================================================
> // END OF FIELD =
> // =======================================================
>
>
> I think there is a problem with the overlap regions (the domain is 64 x 64 x
> 20 with overlap value of 3). Did I forget something? Has anybody dealt with
> this kind of problems before? I apologize for the long (rather boring?) mail
> and wait for opinions and/or suggestions. Thanks,
>
> Stefano
>
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>
More information about the MITgcm-support
mailing list