View source for GCHP Run Configuration Files v12

'''''[[Developing_GCHP_v12|Previous]] | [[Getting Started with GCHP v12]] | [[GCHP Main Page]]'''''
#[[GCHP_Hardware_and_Software_Requirements_v12|Hardware and Software Requirements]]
#[[Downloading_GCHP_v12|Downloading Source Code and Data Directories]]
#[[Obtaining_a_GCHP_Run_Directory_v12|Obtaining a Run Directory]]
#[[Setting_Up_the_GCHP_Environment_v12|Setting Up the GCHP Environment]]
#[[Compiling_GCHP_v12|Compiling]]
#[[Running_GCHP:_Basics_v12|Running GCHP: Basics]]
#[[Running_GCHP:_Configuration_v12|Running GCHP: Configuration]]
#[[GCHP_Output_Data_v12|Output Data]]
#[[Developing_GCHP_v12|Developing GCHP]]
#<span style="color:blue">'''Run Configuration Files'''</span>
<br>

Please note that documentation on this page primarily reflects the latest GCHP public release which is currently the GCHP 12 series. The documentation will be updated for the GCHP 13.0.0 release over the coming months.

== Overview ==

GCHP is controlled using a set of resource configuration files that are included in the GCHP run directory and are denoted by suffix <tt>.rc</tt>. These files contain information required by GCHP including hardware allocation, initialization and runtime parameters, locations of necessary files, and where, what and how to read and write data to and from GCHP. Files include: 
#[[#CAP.rc|CAP.rc]]
#[[#ExtData.rc|ExtData.rc]]
#[[#GCHP.rc|GCHP.rc]]
#[[#HISTORY.rc|HISTORY.rc]]
#[[#fvcore_layout.rc|fvcore_layout.rc]]
#[[#input.nml|input.nml]]

Within GCHP, GEOS-Chem also still relies upon settings controlled by <tt>input.geos</tt> and <tt>HEMCO_Config.rc</tt>. However, several of the entries are superseded by settings in the config files or must be set consistently across multiple files. Inconsistencies may result in your program crashing or yielding unexpected results. 

To avoid mistakes and make run configuration easier, we include bash shell script <tt>runConfig.sh</tt> to update the most commonly used settings in the configuration files, with the exceptions of <tt>HEMCO_Config.rc</tt> and <tt>ExtData.rc</tt> which must be edited manually (e.g. if you turn on/off, edit, remove, or add emissions). Executing this script will over-write existing values in files and write the new settings to output file <tt>runConfig.log</tt>. The sample run scripts, e.g. <tt>gchp.run</tt>, that comes with the run directory includes executing <tt>runConfig.sh</tt> prior to submitting a GCHP run job.

Using <tt>runConfig.sh</tt> to configure common settings makes run configure much simpler, but also comes with peril. If you edit a different config file with a setting that is also configured in <tt>runConfig.sh</tt> then your update will be over-written. This is a common mistake that new users make, particularly when editing the diagnostics frequency in HISTORY.rc since they may be used to editing that for GEOS-Chem Classic. Please get very familiar with the options in <tt>runConfig.sh</tt> and be conscientious about not updating the same setting elsewhere.

While much of the labor of updating the various configuration files has been eliminated by <tt>runConfig.sh</tt>, it is still worth understanding what is happening under the hood with the other files. This page details the settings within those other configuration files and what they are used for, as well as how you should set them if you were running GCHP without <tt>runConfig.sh</tt>.

== Configuration File Descriptions ==

The following table lists the core functions of each of the configuration files in the GCHP run directory. See the individual subsections on each file for additional information.

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC" valign="top"
!width="280px"|File
!width="720px"|Primary function in GCHP
|-valign="top"
| <tt>input.geos</tt>
| Controls which aspects of the chemistry simulation are run. Note that input.geos does not currently control input and output information such as restart file, met-field paths, and diagnostics.

|-valign="top"
| <tt>CAP.rc</tt>
| Controls the simulation timing parameters such as start date and duration.

|-valign="top"
| <tt>ExtData.rc</tt>
| Specifies where all input files are located. All files requested by GCHP must be specified in this file. Using default values can be given by specifying the path as “/dev/null”.

|-valign="top"
| <tt>GCHP.rc</tt>
| Controls all major aspects of the simulation. Grid resolution, core distribution, timesteps, and restart files are be defined in this file.

|-valign="top"
| <tt>HISTORY.rc</tt>
| Controls and directs output from GCHP.

|-valign="top"
| <tt>fvcore_layout.rc</tt>
| Specifies the cubed-sphere layout for the FV3 dynamic core. Grid resolution and timestep are included in this file and must match values in other configuration files.

|-valign="top"
| <tt>input.nml</tt>
| Contains the configurable domain stack size.
|}

=== CAP.rc ===
<tt>CAP.rc</tt> is the configuration file for the top-level "Cap" (in ESMF/MAPL lingo) component. It handles general runtime settings for GCHP including time and data parameters, performance profiling routines, and system-wide timestep (hearbeat). Combined with file <tt>cap_restart</tt>, <tt>CAP.rc</tt> configures the exact dates for the next run of GCHP. 

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC"
!width="280px"|Parameter
!width="720px"|Description

|-valign="top"
|<tt>ROOT_NAME</tt>
|Sets the child name (<tt>GCHP</tt>) that MAPL will use to initialize the ROOT component within CAP. It uses this name in all operations when querying and interacting with ROOT. 

|-valign="top"
|<tt>ROOT_CF</tt>
|Resource configuration file for the ROOT component (<tt>GCHP.rc</tt>) which stores run information such as timesteps. 

|-valign="top"
|<tt>HIST_CF</tt>
|MAPL's HISTORY component resource configuration file (<tt>HISTORY.rc</tt>) which stores output configuration information such as variable names and grid. 

|-valign="top"
|<tt>BEG_DATE</tt>
|Begin date for the range of the experiment, in format <tt>YYYYMMDD hhmmss</tt>.<br>'''Set <tt>BEG_DATE</tt> to your simulation start date.'''

|-valign="top"
|<tt>END_DATE</tt>
|End date for the range of the experiment, in format <tt>YYYYMMDD hhmmss</tt>.<br>'''Ensure <tt>END_DATE</tt> is later than or equal to your simulation end date.'''

|-valign="top"
|<tt>JOB_SGMT</tt>
|Duration of each individual run, in format <tt>YYYYMMDD hhmmss</tt>. Should be shorter than or equal to the span of <tt>BEG_DATE</tt> and <tt>END_DATE</tt>. <br>'''Set <tt>JOB_SGMT</tt> to your simulation duration.'''

|-valign="top"
|<tt>DEBUG_LEVEL</tt>
|Similar to the [[The_HEMCO_User's_Guide#HEMCO_settings|HEMCO <tt>VERBOSE</tt> flag]], the debug flag enables debug output in GCHP. Values range from 0 (no debug output; default) to 20 (maximum amount of debug output). 
Setting this flag to 20 is especially helpful in identifying problems concerning reading input files in ExtData. <br>'''Set <tt>DEBUG_LEVEL</tt> to 20 if having problems reading input files with ExtData.'''

|-valign="top"
|<tt>TILEPATH</tt>
|Path to tile files used in ExtData. Default is symbolic link <tt>TileFiles</tt> set when setting up your GCHP run directory.

|-valign="top"
|<tt>HEARTBEAT_DT</tt>
|The 'ticking' rate of the ESMF/MAPL internal clock, in seconds. At every tick of the heartbeat, ESMF queries all components to see if anything needs to be calculated based upon the components' defined timesteps. Default is 1800.<br>'''Set <tt>HEARTBEAT_DT</tt> to the minimum timestep set in <tt>GCHP.rc</tt>.'''

|-valign="top"
|<tt>MAPL_ENABLE_TIMERS</tt>
|Enables output of MAPL's run-profile timers. Default is <tt>YES</tt>.

|-valign="top"
|<tt>MAPL_ENABLE_MEMUTILS</tt>
|Enables runtime output of the programs' memory usage. Default is <tt>YES</tt>.

|-valign="top"
|<tt>PRINTSPEC</tt>
|If enabled, runs the model until all components are initialized. Then, dumps all the names of the members of the internal import/export states and ends the model. Setting options include: 0 (default): Off, 1: Import & Export, 2: Import, and 3: Export.

|}

=== ExtData.rc ===

<tt>ExtData.rc</tt> contains emissions information for use with MAPL and ESMF. For more information see the [https://geos5.org/wiki/index.php?title=Using_the_ExtData_component ''ExtData component'' page on the GEOS-5 wiki].

The information that <tt>ExtData.rc</tt> contains overlaps with GEOS-Chem configuration file [[The_HEMCO_User's_Guide|<tt>HEMCO_Config.rc</tt>]]. However, during a GCHP run, emissions files are found using the paths in <tt>ExtData.rc</tt> rather than in <tt>HEMCO_Config.rc</tt>; the file paths in <tt>HEMCO_Config.rc</tt> are ignored. Unlike the <tt>HEMCO_Config.rc</tt> file, the <tt>ExtData.rc</tt> file also includes GMAO Meteorological data.

Note that meteorology data paths in <tt>input.geos</tt> are ignored by GCHP and are superceded by paths in <tt>ExtData.rc</tt>.  See the [http://geos5.org/wiki/index.php?title=Using_the_ExtData_component GEOS-5 wiki] for detailed information about <tt>ExtData</tt> component. If you run into a problem with met fields when you later run GCHP, first check <tt>ExtData.rc</tt> to ensure you have the correct data paths.

<tt>ExtData.rc</tt> includes the following information in a space-delimited single row for each primary export (e.g. met field), 2D variable at the edge (e.g. <tt>VEGFRAC_*</tt>), and emission field.

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC"
!width="280px"|Info Name
!width="720px"|Description

|-valign="top"
|<tt>Export Name</tt>
|Name of imported met field (e.g. <tt>ALBD</tt>) or HEMCO emissions container name (e.g. <tt>GEIA_NH3_ANTH</tt>).

|-valign="top"
|<tt>Units</tt>
|Unit string nested within single quotes. <tt>'1'</tt> indicates there is no unit conversion from the native units in the netCDF file.

|-valign="top"
|<tt>Dimension</tt>
|2D is <tt>xy</tt> and 3D is <tt>xyz</tt>.

|-valign="top"
|<tt>Vertical Location</tt>
|Possible values include <tt>C</tt> for center, <tt>E</tt> for edge. If 2D enter <tt>C</tt> or <tt>E</tt> but this will obviously not be used.

|-valign="top"
|<tt>Clim</tt>
|Enter <tt>Y</tt> if the file is a 12 month climatology, otherwise enter <tt>N</tt>. If you specify it is a climatology ExtData the data can be on either one file or 12 files if they are templated appropriately with one per month.

|-valign="top"
|<tt>Conservative</tt>
|Enter <tt>Y</tt> the data should be regridded in a mass conserving fashion through a tile file. <tt>F;{VALUE}</tt> can also be used for fractional regridding. Otherwise enter <tt>N</tt> to use the non-conervative bilinear regridding.

|-valign="top"
|<tt>Refresh Time Template</tt>
|Possible values include:
*<tt>-</tt>: The field will only be updated once the first time ExtData runs
*<tt>0</tt>: Update the variable at every step. ExtData will do a linear interpolation to the current time using the available data.
*<tt>%y4-%m2-%h2T%h2:%n2:00</tt>: Set the recurring time to update the file. The file will be updated when the evaluated template changes. For example, a template in the form %y4-%m2-%d2T12:00:00 will cause the variable to be updated at the start of a new day (i.e. when the clock hits 2007-08-02T00:00:00 it will update the variable but the time it will use for reading and interpolation is 2007-08-02T12:00:00).

|-valign="top"
|<tt>Offset Factor</tt>
|Factor the variable will be shifted by. Use <tt>none</tt> for no shifting.

|-valign="top"
|<tt>Scale Factor</tt>
|Factor the variable will be scaled by. Use <tt>none</tt> for no scaling. 

|-valign="top"
|<tt>External File Variable</tt>
|The name of the variable in the netCDF data file, e.g. <tt>ALBEDO</tt> in met fields.

|-valign="top"
|<tt>External File Template</tt>
|Path to the netCDF data file. If not using the data, specify <tt>/dev/null</tt> to reduce processing time. If there are no tokens in the template name ExtData will assume that all the data is on one file. Note that if the data on file is at a different resolution that the application grid, the underlying I/O library ExtData uses will regrid the data to the application grid.

|}

=== GCHP.rc ===

'''Important Note: This section is not yet updated for GCHP 12.5.0. Several changes to this file occur in that version for compatibility with a newer version of MAPL.'''

<tt>GCHP.rc</tt> is resource configuration file for the ROOT component within GCHP. It controls, at a minimum, global model resolution, grid type, parallel sub-domain size, component time steps, and job restart parameters.

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC"
!width="280px"|Parameter
!width="720px"|Description

|-valign="top"
|<tt>NX, NY</tt>
|Number of boxes in the two MPI sub-domain dimensions. <br>'''''<tt>NX * NY</tt> must equal your number of CPUs; <tt>NX</tt> or <tt>NY</tt> must be a multiple of 6 (the number of faces); typically <tt>NY</tt> is set as a multiple of 6.'''''

|-valign="top"
|<tt>IM</tt>
|Number of grid cells on the side of a single cubed sphere face. <br>'''''Get a rough idea of equivalent lat/lon resolution by dividing 90 by <tt>IM</tt>. Choose your timestep settings accordingly (see <tt>RUN_DT</tt> below).'''''

|-valign="top"
|<tt>JM</tt>
|Number of grid cells times 6, essentially defining the second dimension if all six faces are stacked in a 2-dimensional array. <br>'''''Must be to equal to <tt>IM*6</tt>.'''''

|-valign="top"
|<tt>LM</tt>
|Number of vertical grid cells. The default value is 72. <br>'''''Must be equal to the vertical resolution of the offline meteorological fields since MAPL cannot regrid vertically''''' 

|-valign="top"
|<tt>GRIDNAME</tt>
|The default grid name is <tt>PE24x144-CF</tt>. The grid name includes how the pole is treated, the face side length, the face side length times six, and whether it is a Cubed Sphere Grid or Lat/Lon. The name <tt>PE24x144-CF</tt> indicates polar edge (PE), 24 cells along one face side, 144 for 24*6, and a cubed-sphere grid (CF). Many options here are defined in MAPL_Generic. <br>'''''Must be consistent with <tt>IM</tt> and <tt>JM</tt>.'''''

|-valign="top"
|<tt>GEOChem_CTM</tt>
|A toggle that tells FVDycore that it is operating as a transport model rather than a prognostic model if set to 1.

|-valign="top"
|<tt>AdvCore_Advection</tt>
|Default is 1.

|-valign="top"
|<tt>DYCORE</tt>
|Should either be set to OFF (default) or ON. This value does nothing, but MAPL will crash if it is not declared.

|-valign="top"
|<tt>HEARTBEAT_DT</tt>
|The timestep in seconds that the DYCORE Component should be called. Default is 600.<br>'''Must be a multiple of <tt>HEARTBEAT_DT</tt> in <tt>CAP.rc</tt>.'''

|-valign="top"
|<tt>SOLAR_DT</tt>
|The timestep in seconds that the SOLAR Component should be called. Default is 600.<br>'''Must be a multiple of <tt>HEARTBEAT_DT</tt> in <tt>CAP.rc</tt>.'''

|-valign="top"
|<tt>IRRAD_DT</tt>
|The timestep in seconds that the IRRAD Component should be called.  ESMF checks this value during its timestep check. Default is 600.<br>'''Must be a multiple of <tt>HEARTBEAT_DT</tt> in <tt>CAP.rc</tt>.'''

|-valign="top"
|<tt>RUN_DT</tt>
|The timestep in seconds that the RUN Component should be called.  ESMF checks this value during its timestep check. The recommended timestep [s] per grid resolution (see <tt>IM</tt>) are: 1800 (4x5); 900 (2x2.5); 600 (1x1.25); 600 (1/2 degree); 300 (1/4 degree).<br>'''Must be a multiple of <tt>HEARTBEAT_DT</tt> in <tt>CAP.rc</tt>.'''

|-valign="top"
|<tt>GIGCchem_DT</tt>
|The timestep in seconds that the GIGCchem Component should be called. ESMF checks this value during its timestep check. Default is 1200.<br>'''Must be a multiple of <tt>HEARTBEAT_DT</tt> in <tt>CAP.rc</tt>.'''

|-valign="top"
|<tt>DYNAMICS_DT</tt>
|The timestep in seconds that the DYNAMICS Component should be called.  ESMF checks this value during its timestep check. Default is 600.<br>'''Must be a multiple of <tt>HEARTBEAT_DT</tt> in <tt>CAP.rc</tt>.'''

|-valign="top"
|<tt>SOLARAvrg, IRRADAvrg</tt>
|Default is 0.

|-valign="top"
|<tt>GIGCchem_REFERENCE_TIME</tt>
|

|-valign="top"
|<tt>PRINTRC</tt>
|Specifies which resource values to print. Options include 0: Non-Default Values, and 1: All Values. Default setting is 0.

|-valign="top"
|<tt>PARALLEL_READFORCING</tt>
|Enables or disables parallel I/O processes when writing the restart files. Default value is 0 (disabled).

|-valign="top"
|<tt>NUM_READERS, NUM_WRITERS</tt> 
|Number of simultaneous readers. Should divide evenly unto <tt>NY</tt>. Default value is 1.

|-valign="top"
|<tt>BKG_FREQUENCY</tt>
|Active observer when desired. Default value is 0.

|-valign="top"
|<tt>GIGCchem_INTERNAL_RESTART_FILE</tt>
|The filename of the internal restart file to be written.

|-valign="top"
|<tt>GIGCchem_INTERNAL_RESTART_TYPE</tt>
|The format of the internal restart file. Valid types include <tt>pbinary</tt> and <tt>pnc4</tt>.

|-valign="top"
|<tt>GIGCchem_INTERNAL_CHECKPOINT_FILE</tt>
|The filename of the internal checkpoint file to be written.

|-valign="top"
|<tt>GIGCchem_INTERNAL_CHECKPOINT_TYPE</tt>
|The format of the internal checkstart file. Valid types include <tt>pbinary</tt> and <tt>pnc4</tt>.

|-valign="top"
|<tt>GIGCchem_INTERNAL_HEADER</tt>
|Only needed when the file type is set to <tt>pbinary</tt>. Specifies if a binary file is self-describing.

|-valign="top"
|<tt>DYN_INTERNAL_RESTART_FILE</tt>
|The filename of the DYNAMICS internal restart file to be written.

|-valign="top"
|<tt>DYN_INTERNAL_RESTART_TYPE</tt>
|The format of the DYNAMICS internal restart file. Valid types include <tt>pbinary</tt> and <tt>pnc4</tt>.

|-valign="top"
|<tt>DYN_INTERNAL_CHECKPOINT_FILE</tt>
|The filename of the DYNAMICS internal checkpoint file to be written.

|-valign="top"
|<tt>DYN_INTERNAL_CHECKPOINT_TYPE</tt>
|The format of the DYNAMICS internal checkpoint file. Valid types include <tt>pbinary</tt> and <tt>pnc4</tt>.

|-valign="top"
|<tt>DYN_INTERNAL_HEADER</tt>
|Only needed when the file type is set to <tt>pbinary</tt>. Specifies if a binary file is self-describing.

|-valign="top"
|<tt>MAX_DIAG, MAX_TRCS, MAX_MEMB, MAX_FAMS, MAX_DEP, LINOZ_NFIELDS, LINOZ_NLAT, LINOZ_NLEVELS, LINOZ_NMONTHS, RUN_PHASES</tt>
|For reading the <tt>input.geos</tt> file. Default value is 80.

|-valign="top"
|<tt>HEMCO_CONFIG</tt>
|Name of the HEMCO configuration file. Default is <tt>HEMCO_Config.rc</tt>.

|-valign="top"
|<tt>STDOUT_LOGFILE</tt>
|Log filename template. Default is <tt>PET%%%%%.GEOSCHEMchem.log</tt>.

|-valign="top"
|<tt>STDOUT_LOGLUN</tt>
|Logical unit number for stdout. Default value is 6.

|-valign="top"
|<tt>INIT_ZERO</tt>
|Default is 0.

|-valign="top"
|<tt>INIT_GCC</tt>
|Default is 0.

|}

=== HISTORY.rc ===

All output from GCHP is in netCDF format, with the contents of each output file controlled by <tt>HISTORY.rc</tt>. Information in <tt>HISTORY.rc</tt> is organized as follows:

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC"
!width="280px"|Parameter
!width="720px"|Description

|-valign="top"
|<tt>EXPID</tt>
|The beginning of where output files can be stored. Includes directory structure (<tt>OutputDir</tt>) and beginning of filename (<tt>GCHP</tt>).

|-valign="top"
|<tt>EXPDSC</tt>
|The Export Description. If one does <tt>ncdump -h</tt>, the attribute "Title" will be the set value of <tt>EXPDSC</tt>.

|-valign="top"
|<tt>CoresPerNode</tt> 
|Number of CPUs per node for your simulation. Should match <tt>NX</tt> in [[#GCHP.rc|<tt>GCHP.rc</tt>]].

|-valign="top"
|<tt>COLLECTIONS</tt>
|String names of all collections you wish to output (e.g. <tt>'center'</tt>, <tt>'regrid'</tt>). GCHP outputs data as collections and each collection is output as a single file. You can create as many different collections as you want. For each collection, the following fields may be specified. Note that in some instances default values are used if a setting is not explicitly defined.

|-valign="top"
|<tt>{COLLECTION}.template</tt>
|The output filename suffix. Including a date string, such as <tt>'%y4%m2%d2</tt>, will insert the simulation start day (following GrADS conventions). This should also include the file extension (e.g. <tt>.nc4</tt>)

|-valign="top"
|<tt>{COLLECTION}.format</tt>
|Character string defining the file format. Options include <tt>CFIO</tt> (default) for netCDF-4 or <tt>flat</tt> for binary files.

|-valign="top"
|<tt>{COLLECTION}.resolution</tt>
|Defines the output resolution, <tt>IX</tt> <tt>IY</tt> (in lat-lon). Output can be at a different resolution than the model run. Defaults to the same as the model. This means if the model is running at cubed sphere, it will by default output a cubed-sphere grid unless specified otherwise.

|-valign="top"
|<tt>{COLLECTION}.frequency</tt>
|The frequency at which values are archived for output in <tt>hhmmss</tt> format. For example, the default <tt>010000</tt> will output data every hour.

|-valign="top"
|<tt>{COLLECTION}.mode</tt>
|String defining archived values. Options are either <tt>instantaneous</tt> or <tt>time-averaged</tt> data. Default is <tt>instantaneous</tt>.

|-valign="top"
|<tt>{COLLECTION}.acc_interval</tt>
|Needed when mode is set to <tt>time-averaged</tt>. Defines the accumulation interval of the time average. Must be less than or equal to frequency.<br>'''NOTE: Does not appear in downloaded run directory <tt>HISTORY.rc</tt>.'''

|-valign="top"
|<tt>{COLLECTION}.subset</tt>
|Used to declare only outputting a subset of data for output. Values include <tt>lonMin</tt>, <tt>lonMax</tt>, <tt>latMin</tt>, and <tt>latMax</tt>.<br>'''NOTE: Does not appear in downloaded run directory <tt>HISTORY.rc</tt>.'''

|-valign="top"
|<tt>{COLLECTION}.fields</tt>
|Paired character strings for diagnostic names and its associated gridded component to be written out.

|}

'''Important note about output resolution:''' The native resolution of GCHP output is on a cubed-sphere grid. Output in the native resolution will have dimensions [Nx6NxKxT] where N is a cubed sphere side length, K is the number of vertical layers, and T is the number of time samples in the file (i.e. duration divided by frequency).  Specifying a regular lat-lon resolution in <tt>HISTORY.rc</tt> (e.g. <tt>144 91</tt>) causes GCHP to attempt to regrid the output variables from cubed sphere resolution to lat-lon, assuming a uniform cell size throughout the domain. In this example, a regular 4x5 output will be created, although it will be different from the standard GEOS-Chem 4x5 output grid (e.g. no half-polar grid cells).

'''Important note about vertical dimensions:''' The vertical axis in the unprocessed GCHP output files are flipped relative to GEOS-Chem Classic output file. Level index 1 corresponds to the top of the atmospheric while the end corresponds to the surface. Please keep this in mind when you perform post-processing and data visualization using GCHP output.

=== fvcore_layout.rc ===

Setting options in fvcore_layout.rc are listed below. Note that additional file <tt>input.nml</tt> (see next section) controls specific aspects of the FV3 dycore. If this file is not present, you may have memory errors.

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC"
!width="280px"|Parameter
!width="720px"|Description

|-valign="top"
|<tt>npx</tt>
|Number of grid cells on cubed sphere face. The default setting is 24 (roughly 4x5 lat/lon equivalent).<br>'''''Must match <tt>IM</tt> in [[#GCHP.rc|<tt>GCHP.rc</tt>]].'''''

|-valign="top"
|<tt>npy</tt>
|Number of grid cells on cubed sphere face. The default setting is 24 (roughly 4x5 lat/lon equivalent).<br>'''''Must match <tt>IM</tt> in [[#GCHP.rc|<tt>GCHP.rc</tt>]].'''''

|-valign="top"
|<tt>npz</tt>
|Number of levels. The default setting is 72.<br>'''''Must match <tt>LM</tt> in [[#GCHP.rc|<tt>GCHP.rc</tt>]].'''''

|-valign="top"
|<tt>dt</tt>
|Transport timestep in seconds. The default setting is 600 (10 minutes).<br>'''''Must match <tt>HEARTBEAT_DT</tt> in [[#CAP.rc|<tt>CAP.rc</tt>]] and <tt>RUN_DT</tt> in [[#GCHP.rc|<tt>GCHP.rc</tt>]].'''''

|-valign="top"
|<tt>n_sponge<br>ADIABATIC<br>hydrostatic<br>nord<br>d2_bg<br>d4_bg<br>dddmp<br>ksplit<br>nsplit<br>msplit<br>hord_mt<br>hord_vt<br>hord_vt<br>hord_dp<br>hord_tr<br>kord_tm<br>kord_mt<br>kord_wz<br>kord_tr<br>FV_OFF<br>fv_debug<br>inline_q<br>z_tracer<br>chk_mass</tt>
|Additional settings. You will generally only use the default values provided.

|}

=== input.nml ===

Setting options in <tt>input.nml</tt> are listed below. <tt>input.nml</tt> controls specific aspects of the FV3 dycore. If this file is not present, you may have memory errors. 

{| border=1 cellspacing=0 cellpadding=5 
|-bgcolor="#CCCCCC"
!width="280px"|Parameter
!width="720px"|Description

|-valign="top"
|<tt>print_memory_usage</tt>
|Supposed to toggle memory usage prints to log. However, in practice turning it on or off does not seem to have any effect. Memory usage is always printed.

|-valign="top"
|<tt>domain_stack_size</tt>
|Domain stack size in bytes. We use a default of 7000000 but this may not be large enough if using very few cores with a high resolution run (e.g. 6 or 12 cores at c48). If the domain size is too small then you will get an mpp domain stack size overflow error in advection. If this happens, try increasing the domain stack size in <tt>input.nml</tt>.

|}

== Automatic Updating with RunConfig.sh ==

Sourcing <tt>runConfig.sh</tt> overwrites files in several files. But which exactly does it overwrite? This information is printed out by <tt>runConfig.sh</tt> when you source it. Here is sample output to illustrate what is happening. In each snapshot of output, the left-most variable defined in the far-right file will be updated with the value in the center. 

[[File:gchp RunConfig1.png]]

[[File:gchp RunConfig2.png]]

[[File:gchp RunConfig3.png]]

--------------------------------------

'''''[[Developing_GCHP_v12|Previous]] | [[Getting Started with GCHP v12]] | [[GCHP Main Page]]'''''