[MITgcm-support] Open Boundaries

heimbach at mit.edu heimbach at mit.edu
Tue Feb 10 09:22:40 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