Running Doubly-Periodic Experiment: Difference between revisions

Bmauer (talk | contribs)
Bmauer (talk | contribs)
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 4: Line 4:
The doubly periodic capability in GEOS-5 allows one to run a simulation on an arbitrary Cartesian domain with periodicity in both dimensions.
The doubly periodic capability in GEOS-5 allows one to run a simulation on an arbitrary Cartesian domain with periodicity in both dimensions.
==Setup==
==Setup==
A doubly periodic code is run through GEOSgcm.x like full the model. in the fvcore_layout.rc file the size of the domain is specified in meters like so:
A doubly periodic code is run through GEOSgcm.x like full the model.  
Until code are incorporated you will need to make a few modifications and recompile to properly run a doubly periodic experiment. Please see a member of the software infrastructure team for details. Once you have recompiled you will need to setup an experiment. The easiest way is to do a normal setup with gcm_setup and modify the appropriate rc files.
 
First in the fvcore_layout.rc file the size of the domain is specified in meters like so:


dx_const: 13000
dx_const: 13000
Line 12: Line 15:


==Example AGCM.rc==
==Example AGCM.rc==
Below is snippets showing what needs to be changed in the AGCM.rc to perform a doubly periodic run. Note the change in the grid name that alerts the model this is a doubly periodic setup.
Most of the changes will be needed in the AGCM.rc file. Below is snippets showing what needs to be changed in the AGCM.rc to perform a doubly periodic run. Note the change in the grid name that alerts the model this is a doubly periodic setup.
The most critical are the FIXED_LATS and FIXED_LONS keywords which tell where the cell is located. The CASE_ID, T0, and CASE_TRACERS values should be the values in the example below unless new cases get added in the future.
The most critical are the FIXED_LATS and FIXED_LONS keywords which tell where the cell is located. The CASE_ID, T0, and CASE_TRACERS values should be the values in the example below unless new cases get added in the future. For now the DP is only setup to run over ocean with no land so the OGCM_IM and OGCM_JM are 1. All the restarts can be bootstrapped, hence the dashes in front of every one.
<pre>
<pre>
# Atmospheric Model Configuration Parameters
# Atmospheric Model Configuration Parameters
Line 159: Line 162:
</pre>
</pre>


==Example fvcore_layout.rc==
<pre>
      ntiles: 1
  grid_type: 4
    dx_const: 7000.
    dy_const: 7000.
  test_case: 14
  ADIABATIC: .false.
hydrostatic: .false.
        nord: 0
      d2_bg: 0.0075
      d4_bg: 0.0
      dddmp: 0.2
        kd3: 0.0
    fill_dp: .true.
    n_sponge: 0
    d2_bg_k1: 0.2
    d2_bg_k2: 0.2
      ksplit: 4
      nsplit: 15
      msplit: 3
    hord_mt: 10
    hord_vt: 10
    hord_tm: 10
    hord_dp: 13
    hord_tr: 13
    kord_tm: -9
    kord_mt:  9
    kord_wz:  9
    kord_tr:  9
    remap_t: .false
    consv_te: .true.
    fv_debug: .false.
      FV_OFF: .false.
    inline_q: .false.
    z_tracer: .true.
</pre>
==Other files==
==Other files==
In addition you will need an appropriate tile file name DPXXX.til where XXX is the resolution as well as appropriate fraci.data, kpar.data, and sst.data files
In addition to the changes to the AGCM.rc and fvcore_layout.rc files the doubly periodic case requires new boundary conditions.
The files that need to be replaced are as follows:
The normal tile file will need to be replaced and should have the name DPXXX.til.
 
The doubly periodic case has one ocean point so you will need a fraci.data, kpar.data, and sst.data files that have the appropriate point extracted.
 
Finally you will need dummy topography files for the topography and the gwd and turb variances since we are only simulating over ocean. A file that consists of one record of the appropriate IMxIM filled with zeros will suffice. The topography files can all be pointed to this file.