From 535f77a2bb18bc54d6f80c33483ae1f67d070961 Mon Sep 17 00:00:00 2001
From: bartgol <lbertag@sandia.gov>
Date: Tue, 19 Nov 2024 00:31:08 +0000
Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20E3SM-Pro?=
 =?UTF-8?q?ject/scream@0af3b66689541361cad997433847a08dd4bd9a3a=20?=
 =?UTF-8?q?=F0=9F=9A=80?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 common/eamxx_params/index.html |  15 +++++++++++++++
 search/search_index.json       |   2 +-
 sitemap.xml.gz                 | Bin 127 -> 127 bytes
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/common/eamxx_params/index.html b/common/eamxx_params/index.html
index 763b11212a6..a605296edb4 100644
--- a/common/eamxx_params/index.html
+++ b/common/eamxx_params/index.html
@@ -1915,6 +1915,16 @@ <h2 id="mam4_srf_online_emiss">mam4_srf_online_emiss</h2>
 <li>type: file  </li>
 </ul>
 </li>
+<li>mam4_srf_online_emiss::soil_erodibility_file:  <ul>
+<li>description: File containing soil erodibility  </li>
+<li>type: file  </li>
+</ul>
+</li>
+<li>mam4_srf_online_emiss::marine_organics_file:  <ul>
+<li>description: File containing marine organics emissions  </li>
+<li>type: file  </li>
+</ul>
+</li>
 <li>mam4_srf_online_emiss::srf_remap_file:  <ul>
 <li>description: File containing mapping data from the grid of emission files to the model grid. Unused if the grid is the same.  </li>
 <li>type: file  </li>
@@ -2698,6 +2708,11 @@ <h1 id="initial-conditions-parameters">Initial Conditions Parameters</h1>
 <li>type: array(real)  </li>
 </ul>
 </li>
+<li>initial_conditions::constituent_fluxes:  <ul>
+<li>description: <strong>MISSING</strong>  </li>
+<li>type: real  </li>
+</ul>
+</li>
 <li>initial_conditions::bc_c1:  <ul>
 <li>description: <strong>MISSING</strong>  </li>
 <li>type: real  </li>
diff --git a/search/search_index.json b/search/search_index.json
index d55f4daa08b..1b9ea13409b 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"The E3SM Atmosphere Model in C++ (EAMxx)","text":"<p>EAMxx  EAMxx is almost completely different in all ways from the atmosphere model used for E3SM versions 1-3. </p> <p>EAMxx was built from the ground up using C++ in order to embrace modern software practices and to allow \"performance portability\" across various supercomputers. The latter goal is achieved by using the Kokkos library. EAMxx is a \"clean-start\" model with almost no similarity to the E3SM atmosphere model used in versions 1-3.  Currently only the km-scale explicit-convection version called SCREAM (the Simple Cloud-Resolving E3SM Atmosphere Model) is available, but a low-resolution version is in the works.</p> <p>Like the documentation for other component models, EAMxx documentation is divided into:</p> <ul> <li>The User Guide - info about running EAMxx and all options for modifying a simulation</li> <li>The Developer Guide - information needed to contribute to EAMxx development</li> <li>The Technical Guide - equations and numerical methods used in EAMxx</li> </ul> <p>Put another way, all information about how to customize runs without changing code is included in the User Guide, general information about software design which is needed for intelligently modifying code goes in the Developer Guide, and details about the specific process implementations in the current model version are included in the Technical Guide. </p>"},{"location":"common/eamxx_params/","title":"EAMxx runtime configurable parameters","text":""},{"location":"common/eamxx_params/#atmosphere-processes-parameters","title":"Atmosphere Processes Parameters","text":""},{"location":"common/eamxx_params/#sc_import","title":"sc_import","text":"<ul> <li>sc_import::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>sc_import::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_import::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_import::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>sc_import::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>sc_import::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#sc_export","title":"sc_export","text":"<ul> <li>sc_export::prescribed_constants::fields:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li> <p>sc_export::prescribed_constants::values:  </p> <ul> <li>description: MISSING </li> <li>type: array(real)  </li> </ul> </li> <li> <p>sc_export::prescribed_from_file::fields:  </p> <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>sc_export::prescribed_from_file::files:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li> <p>sc_export::prescribed_from_file::fields_alt_name:  </p> <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li> <p>sc_export::number_of_subcycles:  </p> <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>sc_export::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_export::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_export::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>sc_export::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>sc_export::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#homme","title":"homme","text":"<ul> <li>homme::Moisture:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>homme::BfbHash:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>homme::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>homme::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>homme::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>homme::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>homme::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>homme::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#p3","title":"p3","text":"<ul> <li>p3::do_prescribed_ccn:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>p3::do_predict_nc:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>p3::enable_column_conservation_checks:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>p3::max_total_ni:  <ul> <li>description: maximum total ice concentration (sum of all categories)  </li> <li>type: real  </li> <li>constraints: gt 0  </li> </ul> </li> <li>p3::tables:  <ul> <li>description: MISSING </li> <li>type: array(file)  </li> </ul> </li> <li>p3::autoconversion_prefactor:  <ul> <li>description: Autoconversion linear prefactor  </li> <li>type: real  </li> </ul> </li> <li>p3::autoconversion_qc_exponent:  <ul> <li>description: Autoconversion qc exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::autoconversion_nc_exponent:  <ul> <li>description: Autoconversion nc exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::autoconversion_radius:  <ul> <li>description: Autoconversion droplet radius in meter  </li> <li>type: real  </li> </ul> </li> <li>p3::accretion_prefactor:  <ul> <li>description: Accretion linear prefactor  </li> <li>type: real  </li> </ul> </li> <li>p3::accretion_qc_exponent:  <ul> <li>description: Accretion qc exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::accretion_qr_exponent:  <ul> <li>description: Accretion qr exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::rain_selfcollection_prefactor:  <ul> <li>description: Rain self-collection prefactor  </li> <li>type: real  </li> </ul> </li> <li>p3::rain_selfcollection_breakup_diameter:  <ul> <li>description: Rain self-collection breakup diameter in meter  </li> <li>type: real  </li> </ul> </li> <li>p3::constant_mu_rain:  <ul> <li>description: Constant shape parameter (mu) in the rain droplet distribution  </li> <li>type: real  </li> </ul> </li> <li>p3::spa_ccn_to_nc_factor:  <ul> <li>description: Scaling factor for turning SPA ccn into P3 nc  </li> <li>type: real  </li> </ul> </li> <li>p3::cldliq_to_ice_collection_factor:  <ul> <li>description: Cloud liquid to ice collection scaling factor  </li> <li>type: real  </li> </ul> </li> <li>p3::rain_to_ice_collection_factor:  <ul> <li>description: Rain to ice collection scaling factor  </li> <li>type: real  </li> </ul> </li> <li>p3::min_rime_rho:  <ul> <li>description: Minimum rime density in kg/m3  </li> <li>type: real  </li> </ul> </li> <li>p3::max_rime_rho:  <ul> <li>description: Maximum rime density in kg/m3  </li> <li>type: real  </li> </ul> </li> <li>p3::immersion_freezing_exponent:  <ul> <li>description: Immersion freezing exponent for both rain and cloud liquid  </li> <li>type: real  </li> </ul> </li> <li>p3::deposition_nucleation_exponent:  <ul> <li>description: Deposition nucleation exponent factor  </li> <li>type: real  </li> </ul> </li> <li>p3::ice_sedimentation_factor:  <ul> <li>description: Ice sedimentation fall speed factor  </li> <li>type: real  </li> </ul> </li> <li>p3::do_ice_production:  <ul> <li>description: Flag to turn on ice production processes (loss processes unaffected)  </li> <li>type: logical  </li> </ul> </li> <li>p3::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>p3::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>p3::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>p3::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>p3::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>p3::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#shoc","title":"shoc","text":"<ul> <li>shoc::enable_column_conservation_checks:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>shoc::check_flux_state_consistency:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>shoc::lambda_low:  <ul> <li>description: minimum value of stability correction.  </li> <li>type: real  </li> </ul> </li> <li>shoc::lambda_high:  <ul> <li>description: maximum value of stability correction.  </li> <li>type: real  </li> </ul> </li> <li>shoc::lambda_slope:  <ul> <li>description: slope of change from lambda_low to lambda_high.  </li> <li>type: real  </li> </ul> </li> <li>shoc::lambda_thresh:  <ul> <li>description: stability threshold for which to apply more stability correction.  </li> <li>type: real  </li> </ul> </li> <li>shoc::thl2tune:  <ul> <li>description: Temperature variance tuning factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::qw2tune:  <ul> <li>description: Moisture variance tuning factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::qwthl2tune:  <ul> <li>description: Temperature moisture covariance  </li> <li>type: real  </li> </ul> </li> <li>shoc::w2tune:  <ul> <li>description: Vertical velocity variance  </li> <li>type: real  </li> </ul> </li> <li>shoc::length_fac:  <ul> <li>description: Length scale factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::c_diag_3rd_mom:  <ul> <li>description: Third moment vertical velocity damping factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::Ckh:  <ul> <li>description: Eddy diffusivity coefficient for heat  </li> <li>type: real  </li> </ul> </li> <li>shoc::Ckm:  <ul> <li>description: Eddy diffusivity coefficient for momentum  </li> <li>type: real  </li> </ul> </li> <li>shoc::extra_shoc_diags:  <ul> <li>description: Extra SHOC diagnostics  </li> <li>type: logical  </li> </ul> </li> <li>shoc::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>shoc::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>shoc::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>shoc::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>shoc::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>shoc::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_aci","title":"mam4_aci","text":"<ul> <li>mam4_aci::wsubmin:  <ul> <li>description: Minimum diagnostic sub-grid vertical velocity  </li> <li>type: real  </li> </ul> </li> <li>mam4_aci::top_level_mam4xx:  <ul> <li>description: Level corresponding to the top of troposphere clouds  </li> <li>type: integer  </li> </ul> </li> <li>mam4_aci::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_aci::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aci::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aci::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_aci::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aci::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_drydep","title":"mam4_drydep","text":"<ul> <li>mam4_drydep::fractional_land_use_file:  <ul> <li>description: File containing Fractional land use data for drydep  </li> <li>type: file  </li> </ul> </li> <li>mam4_drydep::drydep_remap_file:  <ul> <li>description: File containing mapping data from the grid of frac land use files to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>mam4_drydep::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_drydep::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_drydep::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_drydep::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_drydep::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_drydep::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#cldfraction","title":"cldFraction","text":"<ul> <li>cldFraction::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>cldFraction::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cldFraction::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cldFraction::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>cldFraction::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>cldFraction::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_aero_microphys","title":"mam4_aero_microphys","text":"<ul> <li>mam4_aero_microphys::mam4_do_cond:  <ul> <li>description: Switch to enable aerosol microphysics condensation process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_do_newnuc:  <ul> <li>description: Switch to enable aerosol microphysics nucleation process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_do_coag:  <ul> <li>description: Switch to enable aerosol microphysics coagulation process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_do_rename:  <ul> <li>description: Switch to enable aerosol microphysics rename process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_o3_tau:  <ul> <li>description: Linoz tau parameter  </li> <li>type: real  </li> </ul> </li> <li>mam4_aero_microphys::mam4_o3_sfc:  <ul> <li>description: Linoz surface parameter  </li> <li>type: real  </li> </ul> </li> <li>mam4_aero_microphys::mam4_o3_lbl:  <ul> <li>description: Linoz lbl parameter  </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_psc_T:  <ul> <li>description: Linoz psc ozone loss temperature (K) threshold  </li> <li>type: real  </li> </ul> </li> <li>mam4_aero_microphys::mam4_linoz_ymd:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_linoz_file_name:  <ul> <li>description: LINOZ chemistry file  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_oxid_ymd:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_oxid_file_name:  <ul> <li>description: File containing oxidants data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_chlorine_loading_ymd:  <ul> <li>description: Cycle year for chlorine  </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_linoz_chlorine_file:  <ul> <li>description: File containing chlorine data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_rsf_file:  <ul> <li>description: File containing photolysis data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_xs_long_file:  <ul> <li>description: File containing photolysis data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::elevated_emiss_ymd:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_season_wes_file:  <ul> <li>description: File containing season_wes data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_so2_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for so2  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_so4_a1_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for so4_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_so4_a2_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for ao4_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_pom_a4_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for pom_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_bc_a4_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for bc_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_num_a1_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for num_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_num_a2_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for num_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_num_a4_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for num_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_soag_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for soag  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::aero_microphys_remap_file:  <ul> <li>description: File containing mapping data from the grid of frac land use files to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_aero_microphys::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_aero_microphys::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_optics","title":"mam4_optics","text":"<ul> <li>mam4_optics::mam4_mode1_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 1, accumulation mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mode2_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 2, Aitken mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mode3_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 3, coarse mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mode4_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 4, p-carbon mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_water_refindex_file:  <ul> <li>description: File containing optical properties for aerosol water  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_soa_physical_properties_file:  <ul> <li>description: File containing optical properties for secondary organic aerosol  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_dust_physical_properties_file:  <ul> <li>description: File containing optical properties for dust  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_nacl_physical_properties_file:  <ul> <li>description: File containing optical properties for sea salt  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_so4_physical_properties_file:  <ul> <li>description: File containing optical properties for sulfate  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_pom_physical_properties_file:  <ul> <li>description: File containing optical properties for primary organic aerosol  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_bc_physical_properties_file:  <ul> <li>description: File containing optical properties for black carbon  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mom_physical_properties_file:  <ul> <li>description: File containing optical properties for marine organic aerosol  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_optics::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_optics::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_optics::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_optics::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_optics::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_wetscav","title":"mam4_wetscav","text":"<ul> <li>mam4_wetscav::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_wetscav::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_wetscav::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_wetscav::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_wetscav::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_wetscav::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_srf_online_emiss","title":"mam4_srf_online_emiss","text":"<ul> <li>mam4_srf_online_emiss::srf_emis_specifier_for_DMS:  <ul> <li>description: File containing surface emissions data for DMS  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_SO2:  <ul> <li>description: File containing surface emissions data for SO2  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_bc_a4:  <ul> <li>description: File containing surface emissions data for bc_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_num_a1:  <ul> <li>description: File containing surface emissions data for num_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_num_a2:  <ul> <li>description: File containing surface emissions data for num_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_num_a4:  <ul> <li>description: File containing surface emissions data for num_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_pom_a4:  <ul> <li>description: File containing surface emissions data for pom_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_so4_a1:  <ul> <li>description: File containing surface emissions data for so4_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_so4_a2:  <ul> <li>description: File containing surface emissions data for so4_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_remap_file:  <ul> <li>description: File containing mapping data from the grid of emission files to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_srf_online_emiss::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_srf_online_emiss::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_srf_online_emiss::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_srf_online_emiss::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_srf_online_emiss::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_constituent_fluxes","title":"mam4_constituent_fluxes","text":"<ul> <li>mam4_constituent_fluxes::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_constituent_fluxes::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_constituent_fluxes::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_constituent_fluxes::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_constituent_fluxes::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_constituent_fluxes::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#nudging","title":"nudging","text":"<ul> <li>nudging::nudging_filenames_patterns:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>nudging::nudging_fields:  <ul> <li>description: List of fields to be nudged.  Note, syntax of 'A:B' represents nudging field A with data from field B in files, syntax of 'A' assumes that nudging file has the same variables name as EAMxx  </li> <li>type: array(string)  </li> </ul> </li> <li>nudging::nudging_timescale:  <ul> <li>description: Timescale to apply nudging tendencies, 0: full replacement, &gt;0: actual timescale  </li> <li>type: integer  </li> </ul> </li> <li>nudging::use_nudging_weights:  <ul> <li>description: Flag for nudging weights option  </li> <li>type: logical  </li> </ul> </li> <li>nudging::nudging_weights_file:  <ul> <li>description: weights that relax the nudging fields update  </li> <li>type: string  </li> </ul> </li> <li>nudging::skip_vert_interpolation:  <ul> <li>description: Flag for skipping vertical interpolation  </li> <li>type: logical  </li> </ul> </li> <li>nudging::source_pressure_type:  <ul> <li>description: Flag for how source pressure levels are handled in the nudging dataset.     TIME_DEPENDENT_3D_PROFILE: The dataset contains a time-varying pressure profile, variable name 'p_mid' with dimensions (time,ncol,nlev).     STATIC_1D_VERTICAL_PROFILE: The dataset uses a fixed in time single pressure profile, variable name 'p_lev' with dimension (nlev).  </li> <li>type: string  </li> <li>valid values: TIME_DEPENDENT_3D_PROFILE,STATIC_1D_VERTICAL_PROFILE  </li> </ul> </li> <li>nudging::source_pressure_file:  <ul> <li>description: If STATIC_1D_VERTICAL_PROFILE, this is an optional arg to point to a file with the source pressure levels defined.     Default is to look for p_levs in the first nudging_filenames_patterns file  </li> <li>type: string  </li> </ul> </li> <li>nudging::nudging_refine_remap_mapfile:  <ul> <li>description: Refine-remapping mapfile from the source nudging dataset to the physics grid  </li> <li>type: string  </li> </ul> </li> <li>nudging::nudging_refine_remap_vert_cutoff:  <ul> <li>description: A vertical cutoff to go with refine-remap logic (in units of p_mid) where the nudging is turned off above it (closer to the surface)  </li> <li>type: real  </li> </ul> </li> <li>nudging::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>nudging::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>nudging::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>nudging::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>nudging::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>nudging::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mlcorrection","title":"mlcorrection","text":"<ul> <li>mlcorrection::ML_model_path_tq:  <ul> <li>description: Path to pre-trained ML model for temperature and specific humidity  </li> <li>type: string  </li> </ul> </li> <li>mlcorrection::ML_model_path_uv:  <ul> <li>description: Path to pre-trained ML model for wind fields  </li> <li>type: string  </li> </ul> </li> <li>mlcorrection::ML_model_path_sfc_fluxes:  <ul> <li>description: Path to pre-trained ML model for surface fluxes  </li> <li>type: string  </li> </ul> </li> <li>mlcorrection::ML_output_fields:  <ul> <li>description: ML correction output variables, the following variables are supported: T_mid,qv,u,v  </li> <li>type: array(string)  </li> </ul> </li> <li>mlcorrection::ML_correction_unit_test:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mlcorrection::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mlcorrection::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mlcorrection::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mlcorrection::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mlcorrection::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mlcorrection::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#testonly","title":"testOnly","text":"<ul> <li>testOnly::my_param:  <ul> <li>description: MISSING </li> <li>type: array(integer)  </li> </ul> </li> <li>testOnly::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>testOnly::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>testOnly::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>testOnly::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>testOnly::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>testOnly::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#spa","title":"spa","text":"<ul> <li>spa::spa_remap_file:  <ul> <li>description: File containing mapping data from the grid of spa_data_file to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>spa::spa_data_file:  <ul> <li>description: File containing aerosol data. Must be on same grid as the atm, or a coarser one  </li> <li>type: file  </li> </ul> </li> <li>spa::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>spa::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>spa::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>spa::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>spa::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>spa::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#rrtmgp","title":"rrtmgp","text":"<ul> <li>rrtmgp::rrtmgp_coefficients_file_sw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::rrtmgp_coefficients_file_lw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::rrtmgp_cloud_optics_file_sw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::rrtmgp_cloud_optics_file_lw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::column_chunk_size:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::active_gases:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>rrtmgp::ch4vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::co2vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::n2ovmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::f11vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::f12vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::n2vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::covmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::orbital_year:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::orbital_eccentricity:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>rrtmgp::orbital_obliquity:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>rrtmgp::orbital_mvelp:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>rrtmgp::rad_frequency:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::do_aerosol_rad:  <ul> <li>description: Flag to turn on/off considering aerosols in radiation calculations  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::enable_column_conservation_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::extra_clnclrsky_diag:  <ul> <li>description: Flag to turn on/off an extra clean-clear-sky (with neither clouds nor aerosols) radiation call  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::extra_clnsky_diag:  <ul> <li>description: Flag to turn on/off an extra clean-sky (with no aerosols) radiation call  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::do_subcol_sampling:  <ul> <li>description: Flag to turn on/off subcolumn sampling of optical properties; if false treat cells as either completely clear or cloudy  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>rrtmgp::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>rrtmgp::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>rrtmgp::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mac_aero_mic","title":"mac_aero_mic","text":"<ul> <li>mac_aero_mic::atm_procs_list:  <ul> <li>description: List of atm processes in this atm process group  </li> <li>type: array(string)  </li> </ul> </li> <li>mac_aero_mic::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> </ul> </li> <li>mac_aero_mic::Type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>mac_aero_mic::schedule_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: Sequential  </li> </ul> </li> <li>mac_aero_mic::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mac_aero_mic::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mac_aero_mic::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mac_aero_mic::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mac_aero_mic::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#cosp","title":"cosp","text":"<ul> <li>cosp::cosp_subcolumns:  <ul> <li>description: Number of subcolumns to use for COSP simulators; cosp_subcolumns=1 implies no subcolumn sampling  </li> <li>type: MISSING </li> </ul> </li> <li>cosp::cosp_frequency:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>cosp::cosp_frequency_units:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: steps,hours  </li> </ul> </li> <li>cosp::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>cosp::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cosp::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cosp::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>cosp::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>cosp::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#tms","title":"tms","text":"<ul> <li>tms::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>tms::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>tms::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>tms::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>tms::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>tms::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#physics","title":"physics","text":"<ul> <li>physics::atm_procs_list:  <ul> <li>description: List of atm processes in this atm process group  </li> <li>type: array(string)  </li> </ul> </li> <li>physics::Type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>physics::schedule_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: Sequential  </li> </ul> </li> <li>physics::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>physics::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>physics::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>physics::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>physics::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>physics::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#initial-conditions-parameters","title":"Initial Conditions Parameters","text":"<ul> <li>initial_conditions::Filename:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>initial_conditions::topography_filename:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>initial_conditions::phis:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_evap:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::precip_liq_surf_mass:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::precip_ice_surf_mass:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::cldfrac_liq:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sgs_buoy_flux:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::eddy_diff_mom:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::T_prev_micro_step:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qv_prev_micro_step:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::nr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qm:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::bm:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::ni_activated:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::nc_nuceat_tend:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::tke:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dir_vis:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dir_nir:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dif_vis:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dif_nir:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_sens_flux:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_lw_flux_up:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_mom_flux:  <ul> <li>description: MISSING </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::dgnum:  <ul> <li>description: Dry aerosol particles diameters (one per mode) [m]  </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::dgnumwet:  <ul> <li>description: Wet aerosol particles diameter [m]  </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::wetdens:  <ul> <li>description: Wet density of interstitial aerosol [kg/m3]  </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::bc_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::bc_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::bc_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::dst_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::dst_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::so4_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::so4_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::so4_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::pom_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::pom_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::pom_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::soa_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::soa_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::soa_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::nacl_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::nacl_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::nacl_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_hydrophilic_bc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::drydep_hydrophilic_bc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_hydrophilic_oc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::drydep_hydrophilic_oc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::qc:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qi:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::nc:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::ni:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::o3_volume_mix_ratio:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::perturbed_fields:  <ul> <li>description: IC fields (with level dimension) to apply a random perturbation to based on the parameters below.  </li> <li>type: array(string)  </li> </ul> </li> <li>initial_conditions::generate_perturbation_random_seed:  <ul> <li>description: Whether or not to generate a random seed for perturbation.  </li> <li>type: logical  </li> </ul> </li> <li>initial_conditions::perturbation_random_seed:  <ul> <li>description: Random seed used for perturbation. Will be overridded by generate_perturbation_random_seed=true.  </li> <li>type: integer  </li> </ul> </li> <li>initial_conditions::perturbation_limit:  <ul> <li>description: Defines a range [1-x, 1+x] which perturbation will be taken from.  </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::perturbation_minimum_pressure:  <ul> <li>description: Minimum pressure (relative to a reference level pressure profile) for which perturbation will be applied.  </li> <li>type: real  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#atmosphere-driver-parameters","title":"Atmosphere Driver Parameters","text":"<ul> <li>driver_options::atmosphere_dag_verbosity_level:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::atm_log_level:  <ul> <li>description: Verbosity level for the atm logger  </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn,error  </li> </ul> </li> <li>driver_options::atm_flush_level:  <ul> <li>description: Verbosity level that triggers automatic flush of the atm logger  </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn,error  </li> </ul> </li> <li>driver_options::output_to_screen:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>driver_options::mass_column_conservation_error_tolerance:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::energy_column_conservation_error_tolerance:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::column_conservation_checks_fail_handling_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::check_all_computed_fields_for_nans:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>driver_options::property_check_data_fields:  <ul> <li>description: list of additional data fields to output in property checks (only for physics grid)  </li> <li>type: array(string)  </li> </ul> </li> <li>driver_options::enable_iop:  <ul> <li>description: Enable intensive observation period. Currently the only use case is DP-EAMxx  </li> <li>type: logical  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#scorpio-parameters","title":"Scorpio Parameters","text":"<ul> <li>Scorpio::output_yaml_files:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>Scorpio::model_restart::iotype:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#homme-namelist","title":"Homme namelist","text":"<ul> <li>ctl_nl::cubed_sphere_map:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::disable_diagnostics:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::dt_remap_factor:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>constraints: ge 1  </li> </ul> </li> <li>ctl_nl::dt_tracer_factor:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>constraints: ge 1  </li> </ul> </li> <li>ctl_nl::hv_ref_profiles:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_order:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_scaling:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_subcycle:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_subcycle_tom:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_subcycle_q:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::nu:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::nu_top:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::pgrad_correction:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ftype:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: 0,2  </li> </ul> </li> <li>ctl_nl::se_geometry:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_limiter_option:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ne:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ne_x:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ne_y:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_lx:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ly:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_nsplit:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_partmethod:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_topology:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_tstep:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>ctl_nl::statefreq:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::theta_advect_form:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::theta_hydrostatic_mode:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::tstep_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::vert_remap_q_alg:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::transport_alg:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::vtheta_thresh:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>ctl_nl::mesh_file:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> </ul>"},{"location":"common/installation/","title":"Installation","text":"<p>Follow these simple instructions to build and test EAMxx's standalone configuration for yourself. This document makes use of the following paths:</p> <ul> <li><code>${RUN_ROOT_DIR}</code>: the root directory where EAMxx is built and run</li> <li><code>${EAMXX_SRC_DIR}</code>: the directory into which you've cloned the <code>scream</code> repo</li> </ul> <p>EAMxx's configuration and build system is based on CMake. CMake has been around a while and has gained a lot of traction in recent years, especially in the HPC community. It has good reference documentation, but it can be tricky to use if you've never encountered it. Ask a EAMxx team member for help if you're stuck on something CMake-related.</p> <p>If you see a <code>CMakeLists.txt</code> files or a file with a <code>.cmake</code> suffix, that's just part of the build system. You might also see files with <code>CTest</code> as part of their name. These files are related to CTest, CMake's testing tool.</p>"},{"location":"common/installation/#prerequisites","title":"Prerequisites","text":"<p>First, make sure you're on one of the machines supported by EAMxx, or that you have the following software installed:</p> <ul> <li>A working MPI installation (typically MPICH or Open-MPI)</li> <li>CMake and GNU Make</li> <li>A working set of C, C++, and Fortran compilers</li> <li>A recent version of Git</li> <li>A working installation of NetCDF,   including both C and   Fortran libraries.</li> </ul>"},{"location":"common/installation/#setting-up-your-environment","title":"Setting Up Your Environment","text":""},{"location":"common/installation/#configuring-and-building-scream","title":"Configuring and Building Scream","text":""},{"location":"common/installation/#1-start-from-a-trustworthy-commit","title":"1. Start From a Trustworthy Commit","text":"<p>First, make sure you've cloned the EAMxx repo (including all submodules) to <code>EAMXX_SRC_DIR</code> using the following command:</p> <pre><code>git clone --recurse-submodules https://github.com/E3SM-Project/scream\n</code></pre> <p>If you have already cloned the project and forgot to type <code>--recurse-submodules</code>, you can change to <code>$EAMXX_SRC_DIR</code> and using the following command to initialize, fetch and checkout all submodules:</p> <pre><code>git submodule update --init --recursive\n</code></pre> <p>If you're running a branch that's not <code>master</code>, check out this branch with</p> <pre><code>git checkout &lt;branch&gt;\n</code></pre>"},{"location":"common/installation/#2-configure-your-eamxx-build","title":"2. Configure Your EAMxx Build","text":"<p>Change to your <code>$RUN_ROOT_DIR</code> directory and use CMake to configure your build.</p> <p>If you're building SCREAM on one of our supported platforms, you can tell CMake to use the appropriate machine file using the <code>-C</code> flag. Machine files are located in <code>$EAMXX_SRC_DIR/components/eamxx/cmake/machine-files</code>. Take a look and see whether your favorite machine has one.</p> <p>For example, to configure SCREAM on the Quartz machine at LLNL:</p> <pre><code>cd $RUN_ROOT_DIR\ncmake \\\n    -DCMAKE_CXX_COMPILER=$(which mpicxx) \\\n    -DCMAKE_BUILD_TYPE=Debug \\\n    -C ${EAMXX_SRC_DIR}/components/eamxx/cmake/machine-files/quartz.cmake \\\n    ${EAMXX_SRC_DIR}/components/eamxx\n</code></pre> <p>If you're building on a machine that doesn't have a ready-made machine file, you can try configuring your build by manually passing options to CMake. This usually looks something like the following, which configures EAMxx to compile CPU code using Kokkos's OpenMP backend: <pre><code>cd $RUN_ROOT_DIR\ncmake \\\n    -D CMAKE_BUILD_TYPE=Debug \\\n    -D CMAKE_C_COMPILER=mpicc \\\n    -D CMAKE_CXX_COMPILER=mpicxx \\\n    -D CMAKE_Fortran_COMPILER=mpif90 \\\n    -D MPIEXEC_EXECUTABLE=`which mpiexec` \\\n    -D EKAT_MPI_NP_FLAG:STRING=-n \\\n    -D SCREAM_DYNAMICS_DYCORE=HOMME \\\n    -D SCREAM_DOUBLE_PRECISION:BOOL=ON \\\n    -D SCREAM_INPUT_ROOT:PATH=/path/to/scream-input \\\n    -D Kokkos_ENABLE_DEBUG=TRUE \\\n    -D Kokkos_ENABLE_AGGRESSIVE_VECTORIZATION=OFF \\\n    -D Kokkos_ENABLE_SERIAL=ON \\\n    -D Kokkos_ENABLE_OPENMP=ON \\\n    -D Kokkos_ENABLE_LIBDL=OFF \\\n    -D Kokkos_ENABLE_PROFILING=OFF \\\n    -D Kokkos_ENABLE_DEPRECATED_CODE=OFF \\\n    -D KOKKOS_ENABLE_ETI:BOOL=OFF \\\n    -D NetCDF_C_PATHS=/path/to/netcdf-c-dir \\\n    -D NetCDF_Fortran_PATHS=/path/to/netcdf-f90-dir \\\n    -D PnetCDF_C_PATHS=/path/to/pnetcdf-dir \\\n    -D PnetCDF_Fortran_PATHS=/path/to/pnetcdf-f90-dir \\\n    ${EAMXX_SRC_DIR}/components/eamxx\n</code></pre></p> <p>In either case, EAMxx requires MPI-aware compilers. Let's examine these options (only some of which are required on any given machine) to make sure we know what they do:</p> <ul> <li><code>CMAKE_BUILD_TYPE</code>: specifies whether you are building EAMxx in a   developer-friendly configuration (<code>Debug</code>), for a production run (<code>Release</code>)   or for performance profiling or some other specialized purpose. Typically,   you'll set this option to <code>Debug</code> or <code>Release</code>.</li> <li><code>CMAKE_{C,CXX,Fortran}_COMPILER</code>: the name of the command used to invoke an   MPI-enabled C, C++, or Fortran compiler to build EAMxx</li> <li><code>MPIEXEC_EXECUTABLE</code>: the name of the command used to run EAMxx using MPI,   typically <code>mpiexec</code> or <code>mpirun</code>, but possibly different depending on your   desired machine</li> <li><code>EKAT_MPI_NP_FLAG</code>: the flag passed to <code>MPIEXEC_EXECUTABLE</code> that you use to   specify the number of desired MPI processes. This is typically <code>-n</code> for   <code>mpiexec</code> and <code>-np</code> for <code>mpirun</code>.</li> <li><code>SCREAM_DYNAMICS_DYCORE</code>: specifies the dycore used for configuring EAMxx,   which is <code>NONE</code> if you are not configuring EAMxx to run its dycore-related   tests, or <code>HOMME</code> if you want to use HOMMExx</li> <li><code>SCREAM_DOUBLE_PRECISION</code>: indicates whether EAMxx's <code>Real</code> type is a   double-precision (<code>ON</code>) or single-precision (<code>OFF</code>) floating point type</li> <li><code>SCREAM_INPUT_ROOT</code>: specifies the location of the top-level folder that   stores input data files for EAMxx. This folder is populated with input files   which are downloaded automatically during EAMxx's build process.</li> <li>The Kokkos-related build options (most of which begin with <code>Kokkos_</code>) are   described in the Kokkos Wiki</li> <li><code>NetCDF_C_PATHS</code>: specifies one or more folders in which the NetCDF C library   and headers are installed. In the simplest configuration, the headers should   be located in <code>${NetCDF_C_PATHS}/include</code> and the library should live in   <code>${NetCDF_C_PATHS}/lib</code>.</li> <li><code>NetCDF_Fortran_PATHS</code>: specifies one or more folders in which the NetCDF   Fortran library and modules are installed. Analogous to <code>${NetCDF_C_PATHS}</code>,   <code>.mod</code> files should be in <code>${NetCDF_Fortran_PATHS}/include</code>, and the library   should be installed in <code>${NetCDF_Fortran_PATHS}/lib</code>.</li> <li><code>PnetCDF_C_PATHS</code>: specifies one or more folders in which the pNetCDF C   library and headers are installed, analogous to <code>NetCDF_C_PATHS</code>.</li> <li><code>PnetCDF_Fortran_PATHS</code>: specifies one or more folders in which the pNetCDF   Fortran library and modules are installed, analogous to   <code>NetCDF_Fortran_PATHS</code>.</li> </ul> <p>Above, we've configured <code>Debug</code> builds to make it easier to find and fix errors. For performance testing, you should configure a <code>Release</code> build and make use of other options, depending on your architecture.</p>"},{"location":"common/installation/#3-build-scream","title":"3. Build SCREAM","text":"<p>Now you can build SCREAM from that same directory:</p> <pre><code>make -j\n</code></pre> <p>The <code>-j</code> flag tells Make to use threads to compile in parallel. If you like, you can set the number of threads by passing it as an argument to <code>-j</code> (e.g. <code>make -j8</code>).</p>"},{"location":"common/installation/#running-tests","title":"Running Tests","text":"<p>You can run EAMxx's tests to make sure your build works by following the instructions here.</p>"},{"location":"developer/","title":"SCREAM Developer Guide","text":""},{"location":"developer/ci_nightly/","title":"Continuous Integration and Nightly Testing","text":""},{"location":"developer/ci_nightly/#autotester","title":"Autotester","text":"<p>EAMxx using github actions and a Sandia product called Autotester 2 to run CI testing on a CPU and GPU machine for every github pull request. By default, we run the e3sm_scream_v1_at suite and the standalone eamxx tests (test-all-scream).</p>"},{"location":"developer/ci_nightly/#nightly-overview-cdash","title":"Nightly overview, CDash","text":"<p>Our nightly testing is much more extensive than the CI testing. You can see our dashboard here under the section \"E3SM_SCREAM\": https://my.cdash.org/index.php?project=E3SM</p> <p>We run a variety of CIME test suites and standalone testing on a number of platforms. We even do some performance testing on frontier.</p>"},{"location":"developer/cime_testing/","title":"Full Model Testing","text":"<p>Full model system testing of eamxx is done through CIME test cases (much like the rest of E3SM).</p> <p>We offer a number of test suites, including:</p> <ul> <li>e3sm_scream_v0: Test the full set of V0 (pre-C++) tests</li> <li>e3sm_scream_v1: Test the full set of V1 (C++) tests</li> <li>e3sm_scream_v1_at: A smaller and quicker set of tests for autotesting</li> <li>e3sm_scream_hires: A small number of bigger, longer-running tests to measure performance</li> </ul> <p>Example for running a suite:</p> <pre><code>cd $repo/cime/scripts\n./create_test e3sm_scream_v1_at --wait\n</code></pre> <p>Example for running a single test case:</p> <pre><code>cd $repo/cime/scripts\n./create_test SMS.ne4_ne4.F2010-SCREAMv1 --wait\n</code></pre> <p>There are many behavioral tweaks you can make to a test case, like changing the run length, test type, etc. Most of this is not specific to eamxx and works for any CIME case. This generic stuff is well-documentated here: http://esmci.github.io/cime/versions/master/html/users_guide/testing.html</p> <p>When it comes to things specific to eamxx, you have grids, compsets, and testmods.</p> <p>Common EAMxx grids are:</p> <ul> <li>ne4_ne4 (low resolution)</li> <li>ne4pg2_ne4pg2 (low resolution with phys grid)</li> <li>ne30_ne30 (med resolution)</li> <li>ne30pg2_ne30pg2 (med resolution with phys grid)</li> <li>ne1024pg2_ne1024pg2 (ultra high with phys grid)</li> </ul> <p>More grid info can be found here: https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/933986549/ATM+Grid+Resolution+Summary</p> <p>Common EAMxx compsets are:</p> <ul> <li>F2010-SCREAM-LR: V0 low res compset with eamxx V0 atmosphere</li> <li>F2010-SCREAMv1: V1 standard compset with eamxx V1 atmosphere</li> <li>FIOP-SCREAMv1-DP: V1 with dpxx (doubly-periodic lateral boundary condition in C++)</li> <li>F2010-SCREAMv1-noAero: V1 without aerosol forcing</li> </ul> <p>Full info on supported compsets can be found by looking at this file: <code>$scream_repo/components/eamxx/cime_config/config_compsets.xml</code></p> <p>Common EAMxx testmods are:</p> <ul> <li>small_kernels: Enable smaller-granularity kernels,   can improve performance on some systems</li> <li>scream-output-preset-[1-6]: Our 6 output presets.   These turn some combination of our three output streams   (phys_dyn, phys, and diags),   various remaps, etc.</li> <li>bfbhash: Turns on bit-for-bit hash output: https://acme-climate.atlassian.net/wiki/spaces/NGDNA/pages/3831923056/EAMxx+BFB+hashing</li> </ul> <p>More info on running EAMxx can be found here: https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/3386015745/How+To+Run+EAMxx+SCREAMv1</p>"},{"location":"developer/field/","title":"Field","text":"<p>In EAMxx, a <code>Field</code> is a data structure holding two things: pointers to the data and pointers to metadata. Both the data and metadata are stored in <code>std::shared_ptr</code> instances, to ensure consistency across all copies of the field. This allows for fast shallow copy semantic for this class.</p> <p>The data is stored on both CPU and device memory (these may be the same, depending on the Kokkos backend). In EAMxx, we always assume and guarantee that the device data is up to date. That implies that the data must be explicitly synced to host before using it on host, and explicitly synced to device after host manipulation, in order to ensure correctness. In order to access the data, users must use the <code>get_view</code>/ <code>get_strided_view</code> methods, which takes two template arguments: the data type, and an enum specifying whether CPU or device data is needed. The data type is used to reinterpret the generic pointer stored inside to a view of the correct scalar type and layout. It is a possibly const-qualified type, and if the field was marked as \"read-only\", the method ensures that the provided data type is const. A read-only field can be created via the <code>getConst</code> method, which returns a shallow copy of the field, but marked as read-only. The enum specifying host or device data is optional, with device being the default.</p> <p>The metadata is a collection of information on the field, such as name, layout, units, allocation size, and more. Part of the metadata is immutable after creation (e.g., name, units, or layout), while some metadata can be partially or completely modified. The metadata is contained in the <code>FieldHeader</code> data structure, which contains four parts:</p> <ul> <li><code>FieldIdentifier</code>: stores the field's name, layout, units, data type,   and name of the grid where it's defined. These information are condensed   in a single string, that can be used to uniquely identify a field, allowing   to distinguish between different version of the same field.   The layout is stored in the <code>FieldLayout</code> data structure, which includes:</li> <li>the field tags: stored as a <code>std::vector&lt;FieldTag&gt;</code>, they give context to the     field's extents.</li> <li>the field dims: stored both as a <code>std::vector&lt;int&gt;</code>, as well as a 1d <code>Kokkos::View</code>.</li> <li><code>FieldTracking</code>: stores information on the usage of the field, as well as its   possible connections to other fields. In particular, the tracked items are:</li> <li>the field time stamp: the time stamp when the field was last updated.</li> <li>the field accumulation start time: used for fields that are accumulated over     several time steps (or time step subcycles). For instance, it allows to     reconstruct fluxes from raw accumulations.</li> <li>the providers/customers: lists of atmosphere processes (see below) that     respectively require/compute the field in their calculations.</li> <li>the field groups: a list of field groups that this field belongs too. Field groups     are used to access a group of fields without explicit prior knowledge about the     number and/or names of the fields.</li> <li><code>FieldAllocProp</code>: stores information about the allocation. While the field is not   yet allocated, users can request special allocations for the field, for instance   to accommodate packing (for SIMD), which may require padding. Upon allocation,   this information is then used by the Field structure to extract the actual data,   wrapped in a properly shaped <code>Kokkos::View</code>. The alloc props are also   responsible of tracking additional information in case the field is a \"slice\" of   a higher-dimensional one, a fact that can affect how the data is accessed.</li> <li>Extra data: stored as a <code>std::map&lt;std::string,ekat::any&gt;</code>, allows to catch any   metadata that does not fit in the above structures. This is a last resort structure,   intended to accommodate the most peculiar corner cases, and should be used sparingly.</li> </ul>"},{"location":"developer/grid/","title":"Grids and Remappers","text":"<p>In EAMxx, the <code>AbstractGrid</code> is an interface used to access information regarding the horizontal and vertical discretization. The most important information that the grid stores is:</p> <ul> <li>the number of local/global DOFs: these are the degrees of freedom of the   horizontal grid only. Here, local/global refers to the MPI partitioning.</li> <li>the DOFs global IDs (GIDs): a list of GIDs of the DOFs on the current MPI rank,   stored as a Field</li> <li>the local IDs (LIDs) to index list: this list maps the LID of a DOF (that is,   the position of the DOF in the GID list) to a \"native\" indexing system for that   DOF. For instance, a <code>PointGrid</code> (a class derived from <code>AbstractGrid</code>) is a   simple collection of points, so the \"native\" indexing system coincides with the   LIDs. However, for a <code>SEGrid</code> (a derived class, for spectral element grids),   the \"native\" indexing is a triplet <code>(ielem,igp,jgp)</code>, specifying the element   index, and the two indices of the Gauss point within the element.</li> <li>geometry data: stored as a <code>std::map&lt;std::string,Field&gt;</code>, this represent any   data that is intrinsically linked to the grid (either along the horizontal or   vertical direction), such as lat/lon coordinates, vertical coordinates, area   associated with the DOF.</li> </ul> <p>Grids can also be used to retrieve the layout of a 2d/3d scalar/vector field, which allows certain downstream classes to perform certain operations without assuming anything on the horizontal grid.</p> <p>In general, grid objects are passed around the different parts of EAMxx as const objects (read-only). The internal data can only be modified during construction, which usually is handled by a <code>GridsManager</code> object.</p>"},{"location":"developer/io/","title":"Input-Output","text":"<p>In EAMxx, I/O is handled through the SCORPIO library, currently a submodule of E3SM. The <code>scream_io</code> library within eamxx allows to interface the EAMxx infrastructure classes with the SCORPIO library.</p>"},{"location":"developer/kokkos_ekat/","title":"Kokkos and EKAT","text":""},{"location":"developer/kokkos_ekat/#kokkos","title":"Kokkos","text":"<p>EAMxx uses Kokkos for performance portable abstractions for parallel execution of code and data management to various HPC platforms, including OpenMP, Cuda, HIP, and SYCL. Here we give a brief overview of the important concepts for understanding Kokkos in EAMxx. For a more in depth description, see the Kokkos wiki.</p>"},{"location":"developer/kokkos_ekat/#kokkosdevice","title":"Kokkos::Device","text":"<p><code>Kokkos::Device</code> is a struct which contain the type definitions for two main Kokkos concepts: execution space (<code>Kokkos::Device::execution_space</code>), the place on-node where parallel operations (like for-loops, reductions, etc.) are executed, and the memory space (<code>Kokkos::Device::memory_space</code>), the memory location on-node where data is stored. Given your machine architecture, Kokkos defines a default \"device\" space, given by</p> <pre><code>Kokkos::Device&lt;Kokkos::DefaultExecutionSpace,\n         Kokkos::DefaultExecutionSpace::memory_space&gt;\n</code></pre> <p>where all performance critical code should be executed (e.g., on an NVIDIA machine, this device would be the GPU accelerators) and a default \"host\" space, given by</p> <pre><code>Kokkos::Device&lt;Kokkos::DefaultHostExecutionSpace,\n         Kokkos::DefaultHostExecutionSpace::memory_space&gt;\n</code></pre> <p>where data can be accessed by the CPU cores and is necessary for I/O interfacing, for example. Currently, these default spaces are the ones used by EAMxx. On CPU-only machines, host and device represent the same space.</p>"},{"location":"developer/kokkos_ekat/#kokkos-views","title":"Kokkos Views","text":"<p>The main data struct provided by Kokkos used in EAMxx in the <code>Kokkos::View</code>. This is a multi-dimensional data array that can live on either device or host memory space. These Views are necessary when running on GPU architectures as data structures like <code>std::vector</code> and <code>std::array</code> will be unavailable on device.</p> <p>Views are constructed in EAMxx most commonly with the following template and input arguments</p> <pre><code>Kokkos::View&lt;DataType, LayoutType, DeviceType&gt;(const std::string&amp; label,\n                         int dim0, int dim1, ...)\n</code></pre> <p>where</p> <ul> <li><code>DataType</code>: scalar type of the view, given as <code>ScalarType</code>+<code>*</code>(x's number of   run-time dimensions). E.g., a 2D view of doubles will have <code>DataType =   double**</code>. There is also an ability to define compile-time dimensions by   using <code>[]</code>, see    [Kokkos wiki section on views]    (https://kokkos.org/kokkos-core-wiki/API/core/view/view.html).</li> <li><code>LayoutType</code>: mapping of indices into the underlying 1D memory storage. Types   are:</li> <li><code>LayoutRight</code> (used in EAMxx): strides increase from the right most to the   left most dimension, right-most dimension is contiguous</li> <li><code>LayoutLeft</code>: strides increase from the left most to the right most   dimension, left-most dimension is contiguous</li> <li><code>LayoutStride</code>: strides can be arbitrary for each dimension</li> <li><code>DeviceType</code>: provides space where data live, defaults to the default device</li> </ul> <p>The following example defines a view \"temperature\" which has dimensions columns and levels:</p> <pre><code>Kokkos::View&lt;double**, Kokkos::LayoutRight, Kokkos::DefaultDevice&gt; temperature(\n  \"temperature\", ncols, nlevs);\n</code></pre>"},{"location":"developer/kokkos_ekat/#deep-copy","title":"Deep Copy","text":"<p>Kokkos provides <code>Kokkos::deep_copy(dst, src)</code> which copies data between views of the same dimensions, or a scalar values into a view. Common uses</p> <pre><code>Kokkos::deep_copy(view0, view1); // Copy all data from view1 into view0\nKokkos::deep_copy(view0, 5); // Set all values of view0 to 5\n</code></pre> <p>As seen in the next section, we can use <code>deep_copy()</code> to copy data between host and device.</p>"},{"location":"developer/kokkos_ekat/#mirror-views","title":"Mirror Views","text":"<p>We will often need to have memory allocation the resides on device (for computation), and then need that identical data on host (say, for output). Kokkos has a concept of mirror views, where data can be copied from host to device and vice versa.</p> <p>Here is an example using the device view <code>temperature</code> from above</p> <pre><code>// Allocate view on host that exactly mirrors the size of layout of the device\nview\nauto host_temperature = Kokkos::create_mirror_view(temperature);\n\n// Copy all data from device to host\nKokkos::deep_copy(host_temperature, temperature);\n</code></pre> <p>Kokkos also offers an all-in-one option</p> <pre><code>// Note: must hand the host device instance as first argument\nauto host_temperature = Kokkos::create_mirror_view_and_copy(\n  Kokkos::DefaultHostDevice(), temperature);\n</code></pre>"},{"location":"developer/kokkos_ekat/#parallel-execution","title":"Parallel Execution","text":"<p>The most basic parallel execution pattern used by EAMxx is the <code>Kokkos::parallel_for</code> which defines a for-loop with completely independent iterations. The <code>parallel_for</code> takes in an optional label for debugging, an execution policy, which defines a range and location (host or device) for the code to be run, and a lambda describing the body of code to be executed. The following are execution policies used in EAMxx</p> <ul> <li><code>int count</code>: 1D iteration range <code>[0, count)</code></li> <li><code>RangePolicy&lt;ExecSpace&gt;(int beg, int end)</code>: 1D iteration range for indices   <code>[beg, end)</code></li> <li><code>MDRangePolicy&lt;ExecSpace, Kokkos::Rank&lt;N&gt;&gt;(int[N] beg, int[N] end)</code>: multi-   dimensional iteration range <code>[beg, end)</code></li> <li><code>TeamPolicy&lt;ExecSpace&gt;(int league_size, int team_size, int vector_size)</code>: 1D   iteration over <code>league_size</code>, assigned to thread teams of size <code>team_size</code>,   each with <code>vector_size</code> vector lanes. Both <code>team_size</code> and <code>vector_size</code> can   be given <code>Kokkos::AUTO</code> as input for Kokkos to automatically compute.</li> </ul> <p>If no <code>ExecSpace</code> template is given, the default execution space is used.</p> <p>For lambda capture, use <code>KOKKOS_LAMBDA</code> macro which sets capture automatically based on architecture.</p> <p>Example using <code>RangePolicy</code> to initialize a view</p> <pre><code>Kokkos::View&lt;double**, Kokkos::LayoutRight&gt; temperature(\"temperature\", ncols,\n                            nlevs);\nKokkos::parallel_for(\"Init_temp\",\n           Kokkos::RangePolicy(0, ncols*nlevs),\n           KOKKOS_LAMBDA (const int idx) {\n  int icol = idx/nlevs;\n  int ilev = idx%nlevs;\n\n  temperature(icol, ilev) = 0;\n});\n</code></pre> <p>Same example with <code>TeamPolicy</code></p> <pre><code>Kokkos::parallel_for(\"Init_temp\",\n           Kokkos::TeamPolicy(ncols*nlevs, Kokkos::AUTO, Kokkos::AUTO),\n           KOKKOS_LAMBDA (const TeamPolicy::member_type&amp; team) {\n  // league_rank() gives the index for this team\n  int icol = team.league_rank()/nlevs;\n  int ilev = team.league_rank()%nlevs;\n\n  temperature(icol, ilev) = 0;\n});\n</code></pre>"},{"location":"developer/kokkos_ekat/#hierarchical-parallelism","title":"Hierarchical Parallelism","text":"<p>Using <code>TeamPolicy</code>, we can have up to three nested levels of parallelism: team parallelism, thread parallelism, vector parallelism. These nested policies can be called within the lambda body using the following execution policies</p> <ul> <li><code>TeamThreadRange(team, begin, end)</code>: execute over threads of a team</li> <li><code>TeamVectorRange(team, begin, end)</code>: execute over threads and vector lanes of   a team</li> <li><code>ThreadVectorRange(team, begin, end)</code>: execute over vector lanes of a thread</li> </ul> <p>An example of using these policies</p> <pre><code>Kokkos::View&lt;double***&gt; Q(\"tracers\", ncols, ntracers, nlevs);\nKokkos::parallel_for(Kokkos::TeamPolicy(ncols, Kokkos::AUTO),\n           KOKKOS_LAMBDA (TeamPolicy::member_type&amp; team) {\n  int icol = team.league_rank();\n  Kokkos::parallel_for(Kokkos::TeamVectorRange(team, nlevs), [&amp;](int ilev) {\n  temperature(icol, ilev) = 0;\n  });\n\n  Kokkos::parallel_for(Kokkos::TeamThreadRange(team, nlevs), [&amp;](int ilev) {\n  Kokkos::parallel_for(Kokkos::ThreadVectorRange(team, ntracers), [&amp;](int iq) {\n    Q(icol, iq, ilev) = 0;\n  });\n  });\n});\n</code></pre> <p>IMPORTANT! Nested policies cannot be used in arbitrary order. <code>ThreadVectorRange</code> must be used inside a <code>TeamThreadRange</code>, and <code>TeamVectorRange</code> must be the only level of nested parallelism.</p> <pre><code>Kokkos::parallel_for(TeamPolicy(...), ... {\n   // OK\n   Kokkos::parallel_for(TeamThreadRange, ... {\n\n   });\n\n   // OK\n   Kokkos::parallel_for(TeamThreadRange, ... {\n   Kokkos::parallel_for(ThreadVectorRange, ... {\n\n   });\n   });\n\n   // OK\n   Kokkos::parallel_for(TeamVectorRange, ...{\n\n   });\n\n   // WRONG,ThreadVectorRange must be nested in TeamThreadRange\n   Kokkos::parallel_for(ThreadVectorRange, ...{\n\n   });\n\n   // WRONG, a TeamVectorRange must be the only nested level\n   Kokkos::parallel_for(TeamVectorRange, ...{\n   Kokkos::parallel_for(ThreadVectorRange, ... {\n\n   });\n   });\n});\n</code></pre> <p>Using these incorrectly can be very tricky to debug as the code almost certainly will not error out, but race conditions will exist among threads.</p>"},{"location":"developer/kokkos_ekat/#ekat","title":"EKAT","text":""},{"location":"developer/kokkos_ekat/#kokkostypes","title":"KokkosTypes","text":""},{"location":"developer/kokkos_ekat/#exespaceutils","title":"ExeSpaceUtils","text":""},{"location":"developer/kokkos_ekat/#vectorization-packs","title":"Vectorization: Packs","text":""},{"location":"developer/kokkos_ekat/#scratch-memory-worspacemanager","title":"Scratch Memory: WorspaceManager","text":""},{"location":"developer/kokkos_ekat/#algorithms","title":"Algorithms","text":""},{"location":"developer/managers/","title":"FieldManager and GridsManager","text":""},{"location":"developer/processes/","title":"Atmospheric Processes","text":"<p>In EAMxx, <code>AtmosphereProcess</code> (AP) is an abstract class representing a portion of the atmosphere timestep algorithm. In simple terms, an AP is an object that given certain input fields performs some calculations to compute some output fields. The concrete AP classes allow to create a buffer layer between particular packages (e.g., dynamics dycore, physics parametrizations) and the atmosphere driver (AD), allowing separation of concerns, so that the AD does not need to know details about the package, and the package does not need to know about the EAMxx infrastructure.</p> <p>To enhance this separation of concerns, EAMxx implements two more classes for handling APs:</p> <ul> <li>the concrete class <code>AtmosphereProcessGroup</code> (APG), which allows to group   together a set of AP's, which can be seen from outside as a single process;</li> <li>the <code>AtmosphereProcessFactory</code> class, which allows an APG to create its   internal processes without any knowledge of what they are.</li> </ul> <p>This infrastructure allows the AD to view the whole atmosphere as a single APG, and to be completely agnostic to what processes are run, and in which order. This design allows to have a code base that is cleaner, self-container, and easy to test via a battery of targeted unit tests.</p> <p>In EAMxx, we already have a few concrete AP's, interfacing the AD to the Hommexx non-hydrostatic dycore as well as some physics parametrizations (P3, SHOC, RRMTPG, etc). In the next section we describe the interfaces of an AP class, and we show an example of how to write a new concrete AP class.</p>"},{"location":"developer/processes/#atmosphere-process-interfaces","title":"Atmosphere process interfaces","text":"<p>An AP has several interfaces, which can be grouped into three categories:</p> <ul> <li>initialization: these interfaces are used to create the AP, as well as to   initialize internal data structures;</li> <li>run: these interfaces are used to make the AP compute its output fields from   its input fields;</li> <li>finalization: these interfaces are used to perform any clean up operation   (e.g., release files) before the AP is destroyed.</li> </ul> <p>Among the above, the initialization sequence is the most complex, and consists of several steps:</p> <ul> <li>The AD creates the APG corresponding to the whole atmosphere. As mentioned   above, this phase will make use of a factory, which allows the AD to be   agnostic to what is actually in the group. All AP's can start performing any   initialization work that they can, but at this point they are limited to use   only an MPI communicator as well as a list of runtime parameters (which were   previously read from an input file).</li> <li>The AD passes a <code>GridsManager</code> to the AP's, so that they can get information   about the grids they need. At this point, all AP's have all the information   they need to establish the layout of the input and output fields they need,   and can store a list of these \"requests\"</li> <li>After creating all fields (based on AP's requests), the AD passes a copy of   each input and output field to the AP's. These fields will be divided in   \"required\" and \"computed\", which differ in that the former are only passed   to the AP's as 'read-only' fields (see the field   documentation for more details)</li> <li>The AP's are queried for how much scratch memory they may need at run time.   After all AP's communicate their needs, the AD will provide a pointer to   scratch memory to the AP's. This is memory that can be used to initialize   temporary views/fields or other internal data structures. All AP's are given   the same pointer, which means no data persistence should be expected at run   time between one timestep and the next.</li> <li>The AD calls the 'initialize' method on each AP. At this point, all fields   are set, and AP's can complete any remaining initialization task</li> </ul> <p>While the base AP class provides an (empty) implementation for some methods, in case derived classes do not need a feature, some methods are purely virtual, and concrete classes will have to override them. Looking at existing concrete AP implementations is a good way to have a first idea of what a new AP class needs to implement. Here, we show go over the possible implementation of these methods in a hypothetical AP class. The header file may look something like this</p> <pre><code>#include &lt;share/atm_process/atmosphere_process.hpp&gt;\n\nclass MyProcess : public AtmosphereProcess\n{\npublic:\n  using gm_ptr = std::shared_ptr&lt;const GridsManager&gt;;\n\n  MyProcess(const ekat::Comm&amp; comm, const ekat::ParameterList&amp; pl);\n\n  std::string name () const override { return \"my_fancy_process\"; }\n  void set_grids (const gm_ptr&amp; grids_manager) override;\n  size_t requested_buffer_size_in_bytes () const override;\n  void init_buffers (const ATMBufferManager&amp; buffer_manager) override;\nprotected:\n\n  void initialize_impl (const RunType run_type) override;\n  void run_impl        (const double dt) override;\n  void finalize_impl   () override;\n\n  using view_1d = typename KokkosTypes&lt;DefaultDevice&gt;::view_1d&lt;Real&gt;;\n  using view_2d = typename KokkosTypes&lt;DefaultDevice&gt;::view_2d&lt;Real&gt;;\n\n  view_1d m_temp1;\n  view_2d m_temp2;\n\n  int m_ncols;\n  int m_nlevs;\n  bool m_has_blah;\n};\n</code></pre> <p>A few comments:</p> <ul> <li>we added two views to the class, which are meant to be used to store   intermediate results during calculations at runtime;</li> <li>there are other methods that the class can override (such as additional   operations when the AD sets a field in the AP), but most AP's only need to   override only these;</li> <li>we strongly encourage to add the keyword <code>override</code> when overriding a method;   in case of small typos (e.g., missing a <code>&amp;</code> or a <code>const</code>, the compiler will   be erroring out, since the signature will not match any virtual method in the   base class;</li> <li><code>finalize_impl</code> is often empty; unless the AP is managing external resources,   everything should be correctly released during destruction;</li> <li>the two methods for buffers can be omitted if the AP does not need any   scratch memory (and the default implementation from the base class will be   used).</li> </ul> <p>Here is a possible implementation of the methods, with some inline comments to explain</p> <pre><code>MyProcess::MyProcess (const ekat::Comm&amp; comm, const ekat::ParameterList&amp; pl)\n : AtmosphereProcess(comm,pl)\n{\n  // The base class copies pl into protected member m_params\n  m_has_blah = m_params.get&lt;bool&gt;(\"enable_blah\");\n}\n\nvoid MyProcess::set_grids (const std::shared_ptr&lt;GridsManager&gt;&amp; gm)\n{\n  using namespace ekat::units;\n  const auto nondim = Units::nondimensional();\n\n  auto grid = gm-&gt;get_grid(\"Physics\");\n  m_ncols = grid-&gt;get_num_local_dofs();\n  m_nlevs = grid-&gt;get_num_vertical_levels();\n\n  // In these names, 2d refers to \"horizontal only\", while 3d to \"horiz+vert\".\n  // But the grid stores dofs linearly, so there is only one array dimension\n  FieldLayout scalar2d = grid-&gt;get_2d_scalar_layout();\n  FieldLayout vector3d = grid-&gt;get_3d_vector_layout(true,2);\n\n  // Declare fields needed:\n  //  - Required: 'input' (read-only)\n  //  - Computed: 'output'\n  //  - Updated: 'input'+'output'\n  // Tell the AD we need 'velocity' to accommodate a Pack scalar type\n  add_field&lt;Required&gt;(\"coeff_2d\",scalar2d,nondim,grid-&gt;name);\n  add_field&lt;Updated&gt;(\"velocity\",vector3d,m/s,grid-&gt;name,SCREAM_PACK_SIZE);\n}\n\nsize_t MyProcess::requested_buffer_size_in_bytes ()\n{\n  // We use temp2 only if the blah feature is on\n  return m_ncols + (m_has_blah ? m_ncols*m_nlev : 0);\n}\n\nvoid MyProcess::init_buffers (const ATMBufferManager&amp; buffer_manager)\n{\n  auto mem = reinterpret_cast&lt;Real*&gt;(buffer_manager.get_memory());\n\n  m_temp1 = view_1d&lt;Real&gt;(mem,m_ncols);\n  mem += m_ncols;\n\n  if (m_has_blah) {\n    m_temp2 = view_2d&lt;Real&gt;(mem,m_ncols,m_nlevs);\n    mem += m_ncols*m_nlevs;\n  }\n\n  // Make sure we use exactly the mem we said we would\n  size_t used_mem = (mem - buffer_manager.get_memory())*sizeof(Real);\n  EKAT_REQUIRE_MSG(used_mem==requested_buffer_size_in_bytes(),\n    \"Error! Used memory != requested memory for MyProcess.\"\n    \"  used memory: \" + std::to_string(used_mem) + \"\\n\"\n    \"  requested: \" + std::to_string(requested_buffer_size_in_bytes()) + \"\\n\");\n}\n\nvoid MyProcess::initialize_impl(const RunType run_type)\n{\n  // Can complete any initialization of the background pkg\n  my_process_pkg_init(m_has_blah);\n}\n\nvoid MyProcess:run_impl (const double dt)\n{\n  using Policy = typename KokkosTypes&lt;DefaultDevice&gt;::TeamPolicy\n  using Member = typename KokkosTypes&lt;DefaultDevice&gt;::MemberType\n  using PackT  = ekat::Pack&lt;Real,SCREAM_PACK_SIZE&gt;;\n\n  // Create team policy\n  Policy policy(m_ncols,m_nlevs,1);\n\n  // Create local copies of class members (or else use KOKKOS_CLASS_LAMBDA)\n  auto temp1 = m_temp1;\n  auto temp2 = m_temp2;\n  auto do_blah = m_has_blah;\n\n  // Get views from fields. We \n  auto coeff2d  = get_field_in(\"coeff_2d\").get_view&lt;const Real*&gt;();\n  auto velocity = get_field_out(\"velocity\").get_view&lt;PackT**&gt;();\n\n  // Since we process velocity with a Pack scalar type, find out how many packs\n  // we have in each column\n  auto nlevs_packs = ekat::PackInfo&lt;SCREAM_PACK_SIZE&gt;::num_packs(m_nlevs);\n\n  // Call some function in the background pkg\n  do_some_work (coeff_2d,velocity,temp1,temp2,do_blah);\n\n  // Do some more work here\n  auto work = KOKKOS_LAMBDA (const Member&amp; team) {\n    int icol = team.league_rank();\n    auto col_work = [&amp;](const int ilev) {\n      velocity(icol,ilev) *= coeff_2d;\n    };\n    Kokkos::parallel_for(Kokkos::TeamVectorRange(team,nlevs_packs),col_work);\n  };\n  Kokkos::parallel_for(policy,work);\n  Kokkos::fence();\n}\n\nvoid MyProcess::finalize_impl ()\n{\n  // If the background package needs to cleanup something, do it now\n  my_process_pkg_cleanup();\n}\n</code></pre>"},{"location":"developer/source_tree/","title":"EAMxx's Source Tree","text":"<p>All EAMxx-specific code can be found in <code>components/eamxx</code> within the EAMxx repo. Here's how things are organized:</p> <ul> <li><code>cime_config</code>: Tools and XML files for integrating EAMxx with E3SM via the   CIME framework.</li> <li><code>cmake</code>: CMake functions and macros used by the configuration/build system.</li> <li><code>data</code>: Data files used by our tests.</li> <li><code>docs</code>: Documentation for the EAMxx project, including design documents,   instructions for building and testing EAMxx, and this document.</li> <li><code>scripts</code>: Miscellaneous scripts that implement workflows for running tests   and analyzing performance.</li> <li><code>src</code>: All C++ source code (and any bridges to Fortran) for EAMxx are stored   here. We describe the contents of this directory in greater detail below.</li> <li><code>tests</code>: Implements standalone, end-to-end tests for various EAMxx   components (RRTMG, HOMME, P3, SHOC, etc).</li> </ul> <p>In addition, you'll notice the following files in <code>components/eamxx</code>:</p> <ul> <li><code>CMakeLists.txt</code>: The CMake file that defines EAMxx's configuration/build   system.</li> <li><code>CTestConfig.cmake</code>: This CTest file contains parameters that determine how   our test results are reported to the E3SM CDash Site.</li> <li><code>README.md</code>: EAMxx's top-level README file, which describes the project and   its purpose.</li> <li><code>mkdocs.yml</code>: The configuration file for mkdocs,   the tool we currently use to build and publish our documentation.</li> </ul>"},{"location":"developer/source_tree/#the-src-directory","title":"The <code>src</code> Directory","text":"<p>Herein l\u0456es the source code for EAMxx. Broadly, here's where things are:</p> <ul> <li><code>control</code>: Contains the atmosphere driver and basic tests for it.</li> <li><code>dynamics</code>: Here's where HOMME lives within EAMxx, along with code for   interfacing with it using EAMxx's data structures.</li> <li><code>mct_coupling</code>: Glue code for embedding EAMxx within E3SM as an atmosphere   component using the MCT coupler.</li> <li><code>physics</code>: Source code for physics-related atmospheric processes, including</li> <li><code>p3</code>: The C++/Kokkos implementation of P3 microphysics within EAMxx.</li> <li><code>shoc</code>: The C++/Kokkos implementation of SHOC macrophysics within EAMxx.</li> <li><code>rrtmgp</code>: A stub for the radiation processes as represented in EAMxx.</li> <li><code>share</code>: Utilities and data structures common to these processes.</li> <li><code>share</code>: Utilities used by various components within EAMxx. Of note:</li> <li><code>io</code>: EAMxx's interface to the SCORPIO     library.</li> <li><code>diagnostics</code>: A collection of simple classes used to compute diagnostic   quantities.</li> </ul> <p>Each of these directories contains a <code>CMakeLists.txt</code> file for defining how things are build, and a <code>tests/</code> subdirectory that houses relevant unit and verification tests.</p> <p>You'll also see some other files in the <code>src/</code> directory itself, such as</p> <ul> <li><code>scream_config.h.in</code>: A template for generating a C++ header file with   EAMxx configuration information.</li> </ul>"},{"location":"developer/standalone_testing/","title":"Standalone EAMxx Testing","text":"<p>In this section we describe our testing methodology for standalone EAMxx configurations. We use several types of tests</p> <ul> <li>Unit tests are individual test programs that demonstrate that a small set   of code performs a single function or a set of related functions. We use   a C++ unit testing framework called Catch2   to implement unit tests.</li> <li>Property (verification) tests are test programs that configure code that   demonstrates that a part of EAMxx (for example, an atmospheric physics   parameterization or the dynamical core) is able to produce an answer that   satisfies some physical constraint or matches a known solution under specific   circumstances.</li> <li>Fortran-C++ \"bit-for-bit\" (BFB) tests are test programs, often implemented   as unit tests, that demonstrate that a set of C++ code ported from Fortran   produces bit-for-bit identical results to its Fortran counterpart, provided   certain compiler options are enabled (such as \"strict\" floating-point   arithmetic).</li> <li>Test Suites are named collections of tests that can be run on demand using   the ctest command.</li> </ul> <p>We also support a <code>test-all-scream</code> configuration that runs all of the standalone tests for an EAMxx configuration. Note, your current machine must be known to EAMxx before <code>test-all-scream</code> will work. A machine can be made known to EAMxx by editing the eamxx/scripts/machines_specs.py files. There are some instructions on what to do at the top of this file.</p> <p><code>test-all-scream</code> has a good help dump</p> <pre><code>cd $scream_repo/components/eamxx\n./scripts/test-all-scream -h\n</code></pre> <p>If you are unsure of the cmake configuration for you development cycle, one trick you can use is to run <code>test-all-scream</code> for the <code>dbg</code> test and just copy the cmake command it prints (then ctrl-C the process).</p> <pre><code>cd $scream_repo/components/eamxx\n./scripts/test-all-scream -t dbg -m $machine\n# wait for a few seconds*\n# Ctrl-C *\n# Copy the contents of DCMAKE_COMMAND that was passed to ctest *\n# Add \"cmake\" to beginning of contents and path to eamxx at the end. *\n</code></pre> <p>Considerations for using <code>test-all-scream</code>:</p> <ul> <li>Your machine must be known to our scripts, see above.</li> <li>If you try to run commands by-hand (outside of test-all-scream;   cmake, make, ctest, etc), you'll need to remember to   load the scream-env into your shell, which can be done like this:   <code>cd eamxx/scripts; eval $(./scripts/scream-env-cmd $machine)</code></li> <li>test-all-scream expects to be run from a compute node if you   are on a batch machine.</li> <li>You'll need to think about your baseline situation, as many of our   tests rely on pre-existing baselines. The -b option controls the baseline   location and can have the following values:</li> <li>AUTO: A common public baseline area shared by all developers</li> <li>LOCAL: A private baseline area for the current developer in the current repo</li> <li>$path: A specific arbitrary path</li> <li>None: If there is no -b at all, no baseline testing will be done</li> </ul>"},{"location":"developer/standalone_testing/#running-eamxxs-tests-with-ctest","title":"Running EAMxx's Tests with CTest","text":"<p>Before running the tests, generate a baseline file:</p> <pre><code>cd $RUN_ROOT_DIR\nmake baseline\n</code></pre> <p>The tests will run, automatically using the baseline file, which is located in the CMake-configurable path <code>${SCREAM_BASELINES_DIR}</code>. By default, this path is set to an invalid string. If baselines tests are enabled, we check that a valid path has been provided.</p> <p>To run all of SCREAM's tests, make sure you're in <code>$RUN_ROOT_DIR</code> and type</p> <pre><code>ctest -VV\n</code></pre> <p>This runs everything and reports results in an extra-verbose (<code>-VV</code>) manner.</p> <p>You can also run subsets of the SCREAM tests. For example, to run only the P3 regression tests (again, from the <code>$RUN_ROOT_DIR</code> directory), use</p> <pre><code>ctest -R p3_regression\n</code></pre>"},{"location":"developer/standalone_testing/#grouping-tests-with-labels","title":"Grouping Tests with Labels","text":"<p>We can create groupings of tests by using labels. For example, we have a <code>driver</code> label that runs tests for SCREAM's standalone driver. You can see a list of available labels by typing</p> <pre><code>ctest --print-labels\n</code></pre> <p>To see which tests are associated with a given label (e.g. <code>driver</code>), use</p> <pre><code>ctest -L driver -N\n</code></pre>"},{"location":"developer/standalone_testing/#eamxx-test-suites","title":"EAMxx Test Suites","text":""},{"location":"developer/standalone_testing/#the-p3_regression-suite","title":"The <code>p3_regression</code> Suite","text":"<p><code>p3_regression</code> uses a baseline file to compare any new or altered implementations with our P3 Fortran reference implementation. If you're working on the C++/Kokkos implementation, you can invoke any new tests to the function <code>Baseline::run_and_cmp</code> in <code>${SCREAM_SRC_DIR}/components/eamxx/p3/tests/p3_run_and_cmp.cpp</code>.</p> <p>If the reference Fortran implementation changes enough that a new baseline file is required, make sure to let other SCREAM team members know, in order to minimize disruptions.</p>"},{"location":"developer/style_guide/","title":"SCREAM C++ Style Guide","text":"<p>Here's our style guide. Let the holy wars begin!</p>"},{"location":"developer/style_guide/#types","title":"Types","text":""},{"location":"developer/style_guide/#functions-and-methods","title":"Functions and Methods","text":""},{"location":"developer/style_guide/#variables","title":"Variables","text":""},{"location":"technical/","title":"EAMxx Technical Guide","text":"<p>The goal of this document is to describe the specific equations, parameterizations, and numerical methods used in the current version of EAMxx. Because our master-branch implementation changes every time we make a new commit, this documentation will also evolve continuously. As such, documentation for master should always be considered to be preliminary and under construction. If you want trustworthy documentation, pull it from an official model release.</p>"},{"location":"technical/#overview","title":"Overview","text":"<p>Currently, EAMxx is only configured for km-scale convection-permitting runs. In order to provide scientifically-credible simulations at lower resolution, parameterizations for the following processes would be needed:</p> <ol> <li>deep convection</li> <li>gravity-wave drag</li> <li>energy fixer</li> </ol> <p>The only configuration of EAMxx that is currently implemented is the convection-permitting version, commonly known as the Simple Cloud-Resolving E3SM Atmosphere Model (SCREAM). Processes in EAMxx-SCREAM are:</p> <ol> <li>a non-hydrostatic version of the spectral-element dynamical core used by other E3SM Atmosphere Model versions<sup>1</sup> with semi-Lagrangian tracer advection as described by Bradley et al. (2022)<sup>2</sup></li> <li>turbulent mountain stress is crudely parameterized following Fiedler and Panofsky (1072)<sup>3</sup> to reduce excessive winds around topography</li> <li>the Simple Higher-Order Closure (SHOC) parameterization from Bogenschutz and Krueger (2013)[@Bogenschutz_Krueger13], which handles turbulent diffusion, condensation/evaporation, and liquid cloud fraction</li> <li>an all-or-nothing ice cloud fraction parameterization that sets ice cloud fraction to 100% whenever cloud ice mass q<sub>i</sub> is less than a user-specified threshold set by default to 1e-5 kg/kg. This scheme also sets the total cloud fraction (used by microphysics) to the maximum of the liquid and ice cloud fraction.</li> <li>the effects of aerosol are prescribed via the Simple Prescribed Aerosol (SPA) scheme, which is very similar to MACv2-SP<sup>4</sup></li> <li>the P3 microphysics scheme from Morrison and Milbrandt (2015)<sup>5</sup> modified as described by Caldwell et al. (2021)<sup>6</sup> to assume instantaneous liquid saturation adjustment for consistency with SHOC</li> <li>RTE/RRTMGP radiation from Pincus et al. (2019)<sup>7</sup> rewritten in C++ for consistency and performance</li> <li>the CFMIP Observation Simulator Package (COSP) is also integrated into EAMxx, but currently only the ISCCP output is enabled</li> </ol> <p>By default processes are called in this order, but which processes to include and in what order is modifiable at run time. After all atmospheric processes are called, output is written.  Surface components are then called before the next atmosphere step starts. These processes are described in more detail in Caldwell et al. (2021)<sup>6</sup>.  As in EAM, dynamics operates on a spectral element grid and all other processes use a finite-volume grid that divides each spectral element into 4 quadrilaterals. This physics grid is described in Hannah et al. (2021)<sup>8</sup>.</p> <ol> <li> <p>Mark A. Taylor, Oksana Guba, Andrew Steyer, Paul A. Ullrich, David M. Hall, and Christopher Eldred. An energy consistent discretization of the nonhydrostatic equations in primitive variables. Journal of Advances in Modeling Earth Systems, 12(1):e2019MS001783, 2020. e2019MS001783 10.1029/2019MS001783. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2019MS001783, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2019MS001783, doi:https://doi.org/10.1029/2019MS001783.\u00a0\u21a9</p> </li> <li> <p>A. M. Bradley, P. A. Bosler, and O. Guba. Islet: interpolation semi-lagrangian element-based transport. Geoscientific Model Development, 15(16):6285\u20136310, 2022. URL: https://gmd.copernicus.org/articles/15/6285/2022/, doi:10.5194/gmd-15-6285-2022.\u00a0\u21a9</p> </li> <li> <p>F. Fiedler and H. A. Panofsky. The geostrophic drag coefficient and the \u2018effective\u2019 roughness length. Quarterly Journal of the Royal Meteorological Society, 98(415):213\u2013220, 1972. URL: https://rmets.onlinelibrary.wiley.com/doi/abs/10.1002/qj.49709841519, arXiv:https://rmets.onlinelibrary.wiley.com/doi/pdf/10.1002/qj.49709841519, doi:https://doi.org/10.1002/qj.49709841519.\u00a0\u21a9</p> </li> <li> <p>B. Stevens, S. Fiedler, S. Kinne, K. Peters, S. Rast, J. M\u00fcsse, S. J. Smith, and T. Mauritsen. Macv2-sp: a parameterization of anthropogenic aerosol optical properties and an associated twomey effect for use in cmip6. Geoscientific Model Development, 10(1):433\u2013452, 2017. URL: https://gmd.copernicus.org/articles/10/433/2017/, doi:10.5194/gmd-10-433-2017.\u00a0\u21a9</p> </li> <li> <p>Hugh Morrison and Jason A. Milbrandt. Parameterization of cloud microphysics based on the prediction of bulk ice particle properties. part i: scheme description and idealized tests. Journal of the Atmospheric Sciences, 72(1):287 \u2013 311, 2015. URL: https://journals.ametsoc.org/view/journals/atsc/72/1/jas-d-14-0065.1.xml, doi:10.1175/JAS-D-14-0065.1.\u00a0\u21a9</p> </li> <li> <p>P. M. Caldwell, C. R. Terai, B. Hillman, N. D. Keen, P. Bogenschutz, W. Lin, H. Beydoun, M. Taylor, L. Bertagna, A. M. Bradley, T. C. Clevenger, A. S. Donahue, C. Eldred, J. Foucar, J.-C. Golaz, O. Guba, R. Jacob, J. Johnson, J. Krishna, W. Liu, K. Pressel, A. G. Salinger, B. Singh, A. Steyer, P. Ullrich, D. Wu, X. Yuan, J. Shpund, H.-Y. Ma, and C. S. Zender. Convection-permitting simulations with the e3sm global atmosphere model. Journal of Advances in Modeling Earth Systems, 13(11):e2021MS002544, 2021. e2021MS002544 2021MS002544. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2021MS002544, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2021MS002544, doi:https://doi.org/10.1029/2021MS002544.\u00a0\u21a9\u21a9</p> </li> <li> <p>Robert Pincus, Eli J. Mlawer, and Jennifer S. Delamere. Balancing accuracy, efficiency, and flexibility in radiation calculations for dynamical models. Journal of Advances in Modeling Earth Systems, 11(10):3074\u20133089, 2019. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2019MS001621, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2019MS001621, doi:https://doi.org/10.1029/2019MS001621.\u00a0\u21a9</p> </li> <li> <p>Walter M. Hannah, Andrew M. Bradley, Oksana Guba, Qi Tang, Jean-Christophe Golaz, and Jon Wolfe. Separating physics and dynamics grids for improved computational efficiency in spectral element earth system models. Journal of Advances in Modeling Earth Systems, 13(7):e2020MS002419, 2021. e2020MS002419 2020MS002419. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2020MS002419, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2020MS002419, doi:https://doi.org/10.1029/2020MS002419.\u00a0\u21a9</p> </li> </ol>"},{"location":"technical/aerocom_cldtop/","title":"The AeroCom algorithm","text":"<p>The goal of the AeroCom algorithm is to calculate properties at cloud top based on the AeroCom recommendation. There are two main parts of the algorithm: probabilistically determining \"cloud top\" and then \"calculating properties\" at said cloud top.</p> <p>We treat model columns independently, so we loop over all columns in parallel. We then loop over all layers in serial (due to needing an accumulative product), starting at 2 (second highest) layer because the highest is assumed to have no clouds. Let's take a photonic approach from above the model top. Let's say that \\(p_{k}\\) is the probability of a photon passing through the layer \\(k\\). We follow the maximum-random overlap assumption. In all cases, we assume the cloudiness (or cloudy fraction) is completely opaque.</p> <p>We assume the highest layer has no clouds, thus the \\(p_{k} = 1\\) for the highest layer. Note that \\(p_{k}\\) is initialized as 1 for all layers. We also clip the cloudy fraction \\(C_{i,k}\\) to ensure that \\(C_{i,k} \\in [0+\\epsilon, 1-\\epsilon]\\), where \\(\\epsilon = 0.001\\). Starting at the second highest layer, \\(k+1\\), we check if some \"cloudy\" conditions are met. These conditions are now arbitrarily defined by a cloudiness threshold of \\(\\epsilon\\) (i.e., \\(C_{i,k}&gt;\\epsilon\\)) and a non-zero threshold on the total (both liquid and ice) droplet number concentration (i.e., \\(cQ_{i,k} + iQ_{i,k} &gt; 0\\)). If the conditions are met, we estimate the cloud-top cloud fraction using an accumulative product following the maximum-random overlap assumption.</p> \\[c_{i} = 1 - \\prod_{k=2}^{K} p_{k} = 1 - \\prod_{k=2}^{K} \\frac{1 - \\max(C_{i,k}, C_{i,k-1})}{1-C_{i,k-1}}\\] <p>In order to estimate cloud-top properties, we weight by the probability of \"remaining cloudiness\" or \\(p_{k-1} - p_{k}\\).</p> Type Equation cloud property \\(x_{i} = \\sum_{k=2}^{K} X_{i,k} \\Phi_{i,k} (p_{k-1} - p_{k})\\) cloud content \\(x_{i} = \\sum_{k=2}^{K} \\Phi_{i,k} (p_{k-1} - p_{k})\\) other property \\(x_{i} = \\sum_{k=2}^{K} X_{i,k} (p_{k-1} - p_{k})\\) <p>In the above, \\(\\Phi_{i,k}\\) is the thermodynamic phase defined by the cloud droplet number concentration ratios.</p> \\[i\\Phi_{i,k} = \\frac{iQ_{i,k}}{iQ_{i,k} + cQ_{i,k}}\\] \\[c\\Phi_{i,k} = \\frac{cQ_{i,k}}{iQ_{i,k} + cQ_{i,k}}\\] <p>The thermodynamic phase is used only for cloud properties (e.g., cloud-top cloud droplet number concentration) or cloud content (e.g., cloud liquid content). Further, \\(X_{i,k}\\) is the three-dimensional cloud property of interest which is needed if we are converting a property from three-dimensional (\\(X\\)) to its two-dimensional counterpart (\\(x\\)). \"Other\" properties here include temperature and pressure which are not dependent on the thermodynamic phase.</p> <p>Most studies in this topic refer a technical report by Tiedtke et al. (1979)<sup>1</sup>. Another more recent general reference that may be of interest is that of R\u00e4is\u00e4nen et al. (2004)<sup>2</sup>.</p> <ol> <li> <p>M. Tiedtke, J.-F. Geleyn, A. Hollingsworth, and J.-F. Louis. ECMWF model parameterisation of sub-grid scale processes. Technical Report, ECMWF, Shinfield Park, Reading, January 1979. 10.\u00a0\u21a9</p> </li> <li> <p>Petri R\u00e4is\u00e4nen, Howard W Barker, Marat F Khairoutdinov, Jiangnan Li, and David A Randall. Stochastic generation of subgrid-scale cloudy columns for large-scale models. Quarterly Journal of the Royal Meteorological Society: A journal of the atmospheric sciences, applied meteorology and physical oceanography, 130(601):2047\u20132067, 2004.\u00a0\u21a9</p> </li> </ol>"},{"location":"user/","title":"SCREAM User Guide","text":"<p>This section contains documentation on how to create, setup, and run CIME cases with EAMxx as the atmosphere component. It is assumed that the reader has a familiarity with CIME case control system. In particular, we assume that the user knows how to create a case, and what the <code>case.setup</code>, <code>case.build</code>, and <code>case.submit</code> commands do.</p> <p>This user guide is still under construction. In the meantime, in case you can't find the information you need, you may visit our public confluence EAMxx user guide.</p>"},{"location":"user/clean_clear_sky/","title":"Clean- and clean-clear-sky diagnostics","text":"<p>In order to decompose the aerosol effective radiative forcing, additional diagnostic radiation calls are needed. These extra diagnostics are optionally added to the main radiation call. The extra diagnostics are:</p> <ul> <li>Clean-clear-sky fluxes: the fluxes that would be present if there were neither aerosols nor clouds, and are calculated by adding an additional radiation call at the very beginning of the logic before the optics class is endowed with aerosol and cloud properties.</li> <li>Clean-sky fluxes: the fluxes that would be present if there were no aerosols, and are calculated by adding an additional radiation call after substantiating an additional optics class, but not endowing it with aerosol properties.</li> </ul>"},{"location":"user/clean_clear_sky/#example-setup-current-as-of-april-2024","title":"Example setup (current as of April 2024)","text":"<p>The extra calls are controlled by runtime flags <code>extra_clnclrsky_diag</code> and <code>extra_clnsky_diag</code> (they take either <code>true</code> or <code>false</code> as their values).</p> <pre><code>    ./atmchange extra_clnclrsky_diag=true\n    ./atmchange extra_clnsky_diag=true\n</code></pre> <p>Below is an example output file to output the extra (clean and clean-clear-sky) radiation diagnostics atop the atmosphere.</p> <pre><code>%YAML 1.1\n---\nfilename_prefix: monthly.outputs\nAveraging Type: Average\nMax Snapshots Per File: 1\nFields:\n  Physics PG2:\n    Field Names:\n    - SW_clnclrsky_flux_up_at_model_top\n    - LW_clnclrsky_flux_up_at_model_top\n    - SW_clnsky_flux_up_at_model_top\n    - LW_clnsky_flux_up_at_model_top\noutput_control:\n  Frequency: 1\n  frequency_units: nmonths\n  MPI Ranks in Filename: false\n</code></pre>"},{"location":"user/cosp/","title":"CFMIP Observation Simulator Package (COSP) in EAMxx","text":"<p>COSP is partially implemented and supported in EAMxx. Currently, minimal outputs from the ISCCP, MODIS, and MISR simulators have been enabled.</p>"},{"location":"user/cosp/#running-with-cosp","title":"Running with COSP","text":"<p>Turning COSP on simply requires adding the <code>cosp</code> process to <code>atm_procs_list</code> via <code>atmchange</code> in a case directory: <pre><code>./atmchange physics::atm_procs_list=\"mac_aero_mic,rrtmgp,cosp\"\n</code></pre> Additionally, the frequency at which COSP is run can be configured via <code>atmchange</code>: <pre><code>./atmchange physics::cosp::cosp_frequency_units=\"steps\"\n./atmchange physics::cosp::cosp_frequency=1\n</code></pre></p> <p>COSP can be run with or without subcolumn sampling. This is configured by changing the <code>cosp_subcolumns</code> namelist variable via <code>atmchange</code>. A value of 1 implies no subcolumn sampling, while values greater than 1 specify the number of subcolumns to use for subcolumn sampling (assuming maximum-random overlap). E.g., <pre><code>./atmchange physics::cosp:cosp_subcolumns=1\n</code></pre> would disable subcolumn sampling, while <pre><code>./atmchange physics::cosp::cosp_subcolumns=10\n</code></pre> would use 10 subcolumns for the COSP internal subcolumn sampling using <code>SCOPS</code>/<code>PREC_SCOPS</code>. The default for high resolution cases (e.g., ne1024) should be to not use subcolumns, while lower resolutions (e.g., ne30) should enable subcolumn sampling.</p> <p>Output streams need to be added manually. A minimal example: <pre><code>./atmchange output_yaml_files=scream_daily_output.yaml\ncat &lt;&lt; EOF &gt; scream_cosp_daily_output.yaml\nAveraging Type: Average\nFields:\n  Physics PG2:\n    Field Names:\n    - isccp_cldtot\n    - isccp_ctptau\n    - modis_ctptau\n    - misr_cthtau\n    - cosp_sunlit\nMax Snapshots Per File: 1\nfilename_prefix: eamxx\noutput_control:\n  Frequency: 1\n  frequency_units: ndays\nEOF\n</code></pre></p>"},{"location":"user/cosp/#available-output-fields","title":"Available output fields","text":"<p>The following output fields are available:</p> <ul> <li>isccp_cldtot (total cloud area from ISCCP simulator)</li> <li>isccp_ctptau (ISCCP-simulated cloud top pressure/optical depth joint histogram)</li> <li>modis_ctptau (MODIS-simulated cloud top pressure/optical depth joint histogram)</li> <li>misr_cthtau  (MISR-simulated cloud top height/optical depth joint histogram)</li> <li>cosp_sunlit  (sunlit flag aggregated at COSP frequency for renormalizing daytime averages)</li> </ul> <p>ISCCP, MODIS, and MISR outputs are valid only for daytime/sunlit columns (to be consistent with available satellite retrievals). In order to aggregate only daytime columns in time averages, these outputs are multiplied by the sunlit flag (0 or 1) at each COSP calculation time. Time averages of these quantities are then aggregated, along with the cosp sunlit flag each time COSP is called. In order to back out the daytime-only time averages from the outputs, one needs to divide the output fields by <code>cosp_sunlit</code>. E.g., <pre><code>isccp_ctptau = mean(isccp_ctptau) / mean(cosp_sunlit)\n</code></pre></p>"},{"location":"user/dp_eamxx/","title":"Doubly Periodic (DP) EAMxx","text":"<p>To run the DP configuration of EAMxx (DP-EAMxx) please refer to the official DP resource page.  At this location you will find full documentation of case descriptions and access to run scripts.  Using these scripts, you should be able to get DP-EAMxx up and running in a matter of minutes on any machine that EAMxx currently runs on (CPU or GPU).</p>"},{"location":"user/eamxx_cases/","title":"Basics of EAMxx cases","text":"<p>This section explains how to create a case which uses EAMxx as the atmosphere model, as well as what are the currently supported compsets and grids for EAMxx.</p>"},{"location":"user/model_input/","title":"Model inputs","text":"<p>This section explains how input parameters are passed to EAMxx, and how the user can change their value. The full list of the currently configuraable runtime parameters for EAMxx can be found here.</p> <p>The infrastructure for reading inputs into EAMxx involves a few scripts/files:</p> <ol> <li><code>atmchange</code> and <code>atmquery</code>: these scripts are located in <code>SRCDIR/components/eamxx/scripts</code>,     and are soft-linked in the case folder. As their names suggest, they can be used to query     and change the runtime configuration parameter of EAMxx. Since these two scripts are the     only scripts that the average user needs to know and interact with, in the next sections     we give a brief overview of how they can be used and how their output can be interpreted.     Additionally, for both of the scripts a short help can also be obtained using the <code>-h</code> flag.</li> <li> <p><code>buildnml</code>: this script, located in <code>SRCDIR/components/eamxx/cime_config</code>, is called by CIME's     case management scripts (<code>case.setup</code>, <code>case.build</code>, and <code>case.submit</code>), and is responsible for creating     the input files that EAMxx will read to load its runtime parameters. Users should not have to modify this script,     nor should they have to manually call it, but it is useful to know what it does.     When <code>buildnml</code> runs, it creates a few files, containing EAMxx input parameters:</p> <ul> <li><code>scream_input.yaml</code>: this YAML file is located in the <code>RUNDIR/data</code> folder,     and will be read by EAMxx at runtime to load all of its configuration parameters. More precisely,     this file contains parameters that need to be used inside the EAMxx interfaces.</li> <li><code>namelist.nl</code>: this namelist file is     located in the <code>RUNDIR/data</code> folder, and will be parsed at runtime to get all the parameters for the     HOMME dycore (ADD REF). This file only contains dycore-specific parameters that are only recognized     inside HOMME, and does not contain any parameter pertaining EAMxx infrastructure.</li> <li><code>namelist_scream.xml</code>: this XML file is located in the case directory, and contains all the runtime parameters that EAMxx     will read in at runtime. <code>buildnml</code> uses this XML file as an intermediate file during the generation of     <code>scream_input.yaml</code> and <code>namelist.nl</code>. More specifically, <code>buildnml</code> generates this file using case information to select the     proper configurations from the file <code>namelist_defaults_scream.xml</code>, located in <code>SRCDIR/components/eamxx/cime_config</code>.     Despite the fact that the only files that are needed at runtime are <code>scream_input.yaml</code> and <code>namelist.nl</code>,     we generate and keep this XML file around to make the implementation of <code>atmquery</code> easier.</li> </ul> <p>Since these files are automatically generated when <code>buildnml</code> runs, users should not manually modify them. Any manual modification will be lost the next time <code>buildnml</code> runs (e.g., at <code>case.submit</code> time).</p> </li> </ol>"},{"location":"user/model_input/#querying-model-inputs-atmquery","title":"Querying model inputs: atmquery","text":"<p>This script is the simplest way for the user to check the value and properties of EAMxx input parameters. A basic usage of the script is</p> <pre><code>$ ./atmquery my_param\n</code></pre> <p>which will retrieve the value of the parameter called <code>my_param</code>, by locating the XML node \"my_param\" in the file <code>namelist_scream.xml</code> in the RUNDIR folder. Obviously, an XML file can have multiple nodes with the same tag, and the script is implemented to error out if multiple matches are found. In such a scenario, the user needs to provide also the parents nodes names, using enough parents to uniquely identify the node (in most cases, one parent is enough). To specify a parent, the user can prepend the parent name and <code>::</code> to the node name:</p> <pre><code>$ ./atmquery foo::my_param\n</code></pre> <p>The output will contain the fully scoped parameter name, along with the value. E.g.,</p> <pre><code>$ ./atmquery foo::my_param\n    namelist_defaults::node1::node2::foo::my_param:   10\n</code></pre> <p>It is sometimes desirable to query all the nodes that have a particular name, or that contain a particular string. We can do that by using the <code>--grep</code> flag:</p> <pre><code>$ ./atmquery --grep sub\n    iop_options::iop_dosubsidence: false\n    ctl_nl::hypervis_subcycle: 1\n    ctl_nl::hypervis_subcycle_tom: 1\n    ctl_nl::hypervis_subcycle_q: 6\n    atmosphere_processes::number_of_subcycles: 1\n    sc_import::number_of_subcycles: 1\n    homme::number_of_subcycles: 1\n    physics::number_of_subcycles: 1\n</code></pre> <p>TODO: This difference between basic and <code>--grep</code> is not really intuitive: as pointed out in this issue, we should change this. If we do, don't forget to update this following part of the docs. Using the <code>--grep</code> option has another effect: if the match is not a leaf of the XML tree, all its subelements are printed:</p> <pre><code>$ ./atmquery --grep homme\n  homme\n      Moisture: moist\n      BfbHash: 18\n      number_of_subcycles: 1\n      enable_precondition_checks: true\n      enable_postcondition_checks: true\n      repair_log_level: trace\n      internal_diagnostics_level: 0\n      compute_tendencies: None\n</code></pre> <p>Similarly to the CIME utility <code>xmlchange</code>, the options <code>--value</code>, <code>--type</code>, <code>--valid-values</code>, and <code>--full</code> can be used to respectively retrieve just the parameter value (useful for shell scripting), the parameter's type, a list of valid values for parameter (when applicable), or all of the above:</p> <pre><code>$ ./atmquery atm_log_level --value\n    info\n$ ./atmquery atm_log_level --type\n    namelist_defaults::driver_options::atm_log_level: string\n$ ./atmquery atm_log_level --valid-values\n    namelist_defaults::driver_options::atm_log_level: ['trace', 'debug', 'info', 'warn', 'error']\n$ ./atmquery atm_log_level --full\n      namelist_defaults::driver_options::atm_log_level\n        value: info\n        type: string\n        valid values: ['trace', 'debug', 'info', 'warn', 'error']\n</code></pre> <p>Finally, the option <code>--listall</code> can be used to list the whole content of the XML file, which will be displayed with each node indented in its parent scope:</p> <pre><code>$ ./atmquery --listall\n    namelist_defaults\n        grids_manager\n            Type: Homme\n            physics_grid_type: PG2\n            physics_grid_rebalance: None\n            dynamics_namelist_file_name: ./data/namelist.nl\n            vertical_coordinate_filename: /some/path/to/coords/file.nc\n        initial_conditions\n            Filename: /some/path/to/ic/file.nc\n            topography_filename: /some/path/to/topo/file.nc\n    ...\n</code></pre>"},{"location":"user/model_input/#changing-model-inputs-atmchange","title":"Changing model inputs: atmchange","text":"<p>When <code>buildnml</code> runs, the model inputs are deduced from the case configuration settings (e.g., the grid, the compset, etc.) and the <code>namelist_scream_defaults.xml</code> file, located in the eamxx source tree. The user can change any of these parameters using the <code>atmchange</code> script. A basic usage of the script is</p> <pre><code>$ ./atmchange my_param=10\n</code></pre> <p>As for <code>atmquery</code>, if there are multiple matches for a given parameter name, the user must specify a unique scoped name, which allows <code>atmchange</code> to uniquely identify the XML node to modify:</p> <pre><code>$ ./atmquery homme::number_of_subcycles\n    namelist_defaults::atmosphere_processes::homme::number_of_subcycles: 1\n$ ./atmchange number_of_subcycles=10\nERROR: internal_diagnostics_level is ambiguous. Use ANY in the node path to allow multiple matches. Matches:\n  namelist_defaults::atmosphere_processes::number_of_subcycles\n  namelist_defaults::atmosphere_processes::sc_import::number_of_subcycles\n  namelist_defaults::atmosphere_processes::homme::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::tms::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::shoc::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::cldFraction::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::spa::internal_diagnostics_level\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::p3::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::rrtmgp::number_of_subcycles\n  namelist_defaults::atmosphere_processes::sc_export::number_of_subcycles\n$ ./atmchange homme::number_of_subcycles=10\nRegenerating /path/to/namelist_scream.xml. Manual edits will be lost.\n$ ./atmquery homme::number_of_subcycles\n    namelist_defaults::atmosphere_processes::homme::number_of_subcycles: 10\n</code></pre> <p>In some cases, the user may be interested in changing all nodes with a given name. In that case, you can use 'ANY' as a node name:</p> <p><pre><code>$ ./atmquery --grep number_of_subcycles\n    atmosphere_processes::number_of_subcycles: 1\n    sc_import::number_of_subcycles: 1\n    homme::number_of_subcycles: 1\n    physics::number_of_subcycles: 1\n    mac_aero_mic::number_of_subcycles: 24\n    tms::number_of_subcycles: 1\n    shoc::number_of_subcycles: 1\n    cldFraction::number_of_subcycles: 1\n    spa::number_of_subcycles: 1\n    p3::number_of_subcycles: 1\n    rrtmgp::number_of_subcycles: 1\n    sc_export::number_of_subcycles: 1\n$ ./atmchange ANY::number_of_subcycles=3\nRegenerating /path/to/namelist_scream.xml. Manual edits will be lost.\n$ ./atmquery --grep number_of_subcycles\n    atmosphere_processes::number_of_subcycles: 3\n    sc_import::number_of_subcycles: 3\n    homme::number_of_subcycles: 3\n    physics::number_of_subcycles: 3\n    mac_aero_mic::number_of_subcycles: 3\n    tms::number_of_subcycles: 3\n    shoc::number_of_subcycles: 3\n    cldFraction::number_of_subcycles: 3\n    spa::number_of_subcycles: 3\n    p3::number_of_subcycles: 3\n    rrtmgp::number_of_subcycles: 3\n    sc_export::number_of_subcycles: 3\n</code></pre> In addition, \"ANY\" can be used in a \"scoped\" string, to limit the set of matches: <pre><code>$ ./atmchange mac_aero_mic::ANY::number_of_subcycles=1\nRegenerating /path/to/namelist_scream.xml. Manual edits will be lost.\n$ ./atmquery --grep number_of_subcycles\n    atmosphere_processes::number_of_subcycles: 3\n    sc_import::number_of_subcycles: 3\n    homme::number_of_subcycles: 3\n    physics::number_of_subcycles: 3\n    mac_aero_mic::number_of_subcycles: 1\n    tms::number_of_subcycles: 1\n    shoc::number_of_subcycles: 1\n    cldFraction::number_of_subcycles: 1\n    spa::number_of_subcycles: 1\n    p3::number_of_subcycles: 1\n    rrtmgp::number_of_subcycles: 3\n    sc_export::number_of_subcycles: 3\n</code></pre></p> <p>Since the XML file stores constraints on the parameter value (like its type or valid values), attempting to use the wrong type will cause an error:</p> <pre><code>$ ./atmquery --type se_ne\n    namelist_defaults::ctl_nl::se_ne: integer\n$ ./atmchange se_ne=hello\nERROR: Could not refine 'hello' as type 'integer':\n</code></pre> <p>There are three main types supported: integer, float, string, logical. When passing a string to <code>atmchange</code>, the script will try to interpret it acoording to the parameter type, and throw an error if that's not possible: for \"string\", anything works; for \"integer\", only digits are allowed, possibly with a negative sign in front; for \"float\", only digits are allowed, possibly with a negative sign in front and a decimal point; for \"logical\", only the strings \"true\" and \"false\" are allowed (case insensitive). There are two additional types supported: \"file\" and \"array(T)\", where \"T\" is any of the other supported types (but not another array):  - \"file\" is used to inform CIME of the input files that have to be download from E3SM data servers, like initial conditions files, or certain lookup tables.  - \"array(T)\" allows to specify a list of items (of the same type), which will be parsed inside EAMxx as    a <code>std::vector&lt;T&gt;</code>.</p> <p>For type \"string\" and \"array(T)\", it is also possible to append to the currently stored value</p> <pre><code>$ ./atmquery homme::compute_tendencies\n    namelist_defaults::atmosphere_processes::homme::compute_tendencies:\n        value: a, b\n        type: array(string)\n        valid values: []\n$ ./atmchange homme::compute_tendencies+=c\n$ ./atmquery homme::compute_tendencies --full\n    namelist_defaults::atmosphere_processes::homme::compute_tendencies\n        value: a, b, c\n        type: array(string)\n        valid values: []\n</code></pre>"},{"location":"user/model_input/#modifying-the-list-of-atmosphere-processes","title":"Modifying the list of atmosphere processes","text":"<p>The <code>atmchange</code> script can be used to change any of the runtime parameters of EAMxx. In particular, it can be used to add, remove, or reorder atmosphere processes. When adding an atmosphere process, we must first make sure that the defaults for that process are present in <code>namelist_defaults_scream.xml</code>. For instance, the default settings for the \"physics\" atmosphere process group include the following:</p> <pre><code>$ ./atmquery physics::atm_procs_list\n    namelist_defaults::atmosphere_processes::physics::atm_procs_list: mac_aero_mic,rrtmgp\n</code></pre> <p>where \"mac_aero_mic\" is itself an atmosphere process group, consisting of macrophysics, aerosols, and microphysics processes. If one wanted to add the \"cosp\" atmosphere process to this list, and change the number of its subcycles, it could do so via</p> <pre><code>$ ./atmchange physics::atm_procs_list+=cosp\n$ ./atmchange cosp::number_of_subcycles=3\n</code></pre> <p>Notice that if we swapped the two commands, we would get an error, since the node \"cosp\" is not present in the XML generated from the defaults until we decide to add it.</p> <p>It is also possible to declare a new (empty) atmosphere process group, which can then be filled with valid atmosphere processes via subsequent calls to <code>atmchange</code>. The syntax to trigger this behavior consists in specifying a process name that begins and ends with an underscore:</p> <pre><code>$ ./atmchange physics::atm_procs_list+=_my_group_\n</code></pre> <p>This adds a new process to the list of processes in \"physics\", called \"_my_group_\", and which is itself an atmosphere process group. Hence, we can then do</p> <pre><code>$ ./atmchange _my_group_::atm_procs_list+=A,B\n</code></pre> <p>where A and B must be valid atmosphere process names (i.e., present in <code>namelist_defaults_scream.xml</code>) or be themselves new atmosphere process groups (i.e., beginning/ending with an underscore)</p> <p><code>atmchange</code> can also be used to completely change a list of atmosphere processes:</p> <pre><code>$ ./atmchange physics::atm_procs_list=A,B,C\n</code></pre> <p>Notice that we used \"=\" instead of \"+=\", which means we will be overwriting the value, rather than appending. Any atmosphere process that was previously in the list but is no longer in it will be removed from the generated <code>namelist_defaults.xml</code> (and <code>scream_input.yaml</code>) files, along with all their nested parameters.</p>"},{"location":"user/model_output/","title":"Model output","text":"<p>EAMxx allows the user to configure the desired model output via YAML files, with each YAML file associated to a different output file. In order to add an output stream, one needs to run <code>atmchange output_yaml_files+=/path/to/my/output/yaml</code> (more information on how to use <code>atmchange</code> can be found here). During the <code>buildnml</code> phase of the case management system, a copy of these YAML files will be copied into the RUNDIR/data folder. During this process, the files will be parsed, and any CIME-related variable will be resolved accordingly. Therefore, it is not advised to put the original YAML files in RUNDIR/data, since upon <code>buildnml</code> execution, all the CIME vars will no longer be available in the YAML file, making it harder to tweak it, and even harder to share with other users/cases. Another consequence of this is that the user should not modify the YAML files in RUNDIR/data, since any modification will be lost on the next run of <code>buildnml</code>.</p>"},{"location":"user/model_output/#basic-output","title":"Basic output","text":"<p>The following is a basic example of an output request.</p> <pre><code>%YAML 1.1\n---\nfilename_prefix: my_output\nAveraging Type: Average\nMax Snapshots Per File: 10\nFields:\n  Physics:\n    Field Names:\n      - T_mid\n      - qv\n  Dynamics:\n    Field Names:\n      - dp3d_dyn\n      - omega_dyn\noutput_control:\n  Frequency: 6\n  frequency_units: nhours\n</code></pre> <p>Notice that lists can be equivalently specified in YAML as <code>Field Names: [f1, f2, f3]</code>. The user can specify fields to be outputted from any of the grids used in the simulation. In the example above, we requested fields from both the Physics and Dynamics grid. The meaning of the other parameters is as follows:</p> <ul> <li> <p><code>Averaging Type</code>: how the fields are integrated in time before being saved. Valid   options are</p> <ul> <li>Instant: no integration, each time frame saved corresponds to instantaneous values   of the fields</li> <li>Average/Max/Min: the fields undergo the corresponding operation over the time   interval specified in the <code>output_control</code> section. In the case above, each snapshot   saved to file corresponds to an average of the output fields over 6h windows.</li> </ul> </li> <li> <p><code>filename_prefix</code>: the prefix of the output file, which will be created in the run   directory. The full filename will be <code>$prefix.$avgtype.$frequnits_x$freq.$timestamp.nc</code>,   where $timestamp corresponds to the first snapshot saved in the file for Instant output,   or the beginning of the first averaging window for the other averaging types</p> </li> <li><code>Max Snapshots Per File</code>: specifies how many time snapshots can be put in a file. Once   this number is reached, EAMxx will close the file and open a new one.</li> <li><code>Frequency</code>: how many units of time are between two consecutive writes to file. For   Instant output the fields are \"sampled\" at this frequency, while for other averaging   types the fields are \"integrated\" in time over this window</li> <li><code>frequency_units</code>: units of the output frequency. Valid options are <code>nsteps</code> (the   number of atmosphere time steps), <code>nsecs</code>, <code>nmins</code>, <code>nhours</code>, <code>ndays</code>, <code>nmonths</code>,   <code>nyears</code>.</li> </ul>"},{"location":"user/model_output/#diagnostic-output","title":"Diagnostic output","text":"<p>In addition to the fields computed by EAMxx as part of the timestep, the user can request to output derived quantities, which will be computed on the fly by the I/O interface of EAMxx. There are two types of diagnostic outputs:</p> <ul> <li> <p>quantities computed as a function of EAMxx fields. These are simply physical quantities   that EAMxx does not keep in persistent storage. As of May 2024, the available   derived quantities are (case sensitive):</p> <ul> <li><code>PotentialTemperature</code></li> <li><code>AtmosphereDensity</code></li> <li><code>Exner</code></li> <li><code>VirtualTemperature</code></li> <li><code>z_int</code></li> <li><code>z_mid</code></li> <li><code>geopotential_int</code></li> <li><code>geopotential_mid</code></li> <li><code>dz</code></li> <li><code>DryStaticEnergy</code></li> <li><code>SeaLevelPressure</code></li> <li><code>LiqWaterPath</code></li> <li><code>IceWaterPath</code></li> <li><code>VapWaterPath</code></li> <li><code>RainWaterPath</code></li> <li><code>RimeWaterPath</code></li> <li><code>ShortwaveCloudForcing</code></li> <li><code>LongwaveCloudForcing</code></li> <li><code>RelativeHumidity</code></li> <li><code>ZonalVapFlux</code></li> <li><code>MeridionalVapFlux</code></li> <li><code>precip_liq_surf_mass_flux</code></li> <li><code>precip_ice_surf_mass_flux</code></li> <li><code>precip_total_surf_mass_flux</code></li> <li><code>surface_upward_latent_heat_flux</code></li> <li><code>wind_speed</code></li> <li><code>AerosolOpticalDepth550nm</code></li> <li><code>NumberPath</code></li> <li><code>AeroComCld</code></li> </ul> </li> </ul> <p>TODO: add some information about what each diagnostic is, perhaps a formula</p> <ul> <li> <p>lower-dimensional slices of a field. These are hyperslices of an existing field or of   another diagnostic output. As of August 2023, given a field X, the available options   are:</p> <ul> <li><code>X_at_lev_N</code>: slice the field <code>X</code> at the N-th vertical level index. Recall that   in EAMxx N=0 corresponds to the model top.</li> <li><code>X_at_model_bot</code>, <code>X_at_model_top</code>: special case for top and bottom of the model.</li> <li><code>X_at_Ymb</code>, <code>X_at_YPa</code>, <code>X_at_YhPa</code>: interpolates the field <code>X</code> at a vertical position   specified by the give pressure <code>Y</code>. Available units are <code>mb</code> (millibar), <code>Pa</code>, and <code>hPa</code>.</li> <li><code>X_at_Ym_above_Z</code>: interpolates the field <code>X</code> at a vertical height of <code>Y</code> meters above   <code>Z</code>, with <code>Z=surface</code> or <code>Z=sealevel</code>.</li> </ul> </li> </ul>"},{"location":"user/model_output/#remapped-output","title":"Remapped output","text":"<p>The following options can be used to to save fields on a different grid from the one they are computed on.</p> <ul> <li><code>horiz_remap_file</code>: a path to a map file (as produced by <code>ncremap</code>) between the grid   where the fields are defined and a coarser grid. EAMxx will use this to remap fields   on the fly, allowing to reduce the size of the output file. Note: with this feature,   the user can only specify fields from a single grid.</li> <li><code>vertical_remap_file</code>: similar to the previous option, this map file is used to   refine/coarsen fields in the vertical direction.</li> <li><code>IOGrid</code>: this parameter can be specified inside one of the grids sections, and will   denote the grid (which must exist in the simulation) where the fields must be remapped   before being saved to file. This feature is really only used to save fields on the   dynamics grid without saving twice the DOFs at the interface of two spectral elements.   E.g., for a scalar quantity defined only in the horizontal direction, native output   from the Dynamics grid would produce arrays of length <code>nelems*ngp*ngp</code>, where <code>ngp</code>    is the number of Gauss points along each axis in the 2d spectral element, and <code>nelems</code>   is the number of horizontal elements. However, due to continuity, the values on the   Gauss points on the element boundary must match the values on the neighboring element,   resulting in duplicated data. By remapping to a \"unique\" version of the dynamics grid   (which in EAMxx is referred to as \"Physics GLL\"), we can save roughly 45% of storage.   Note: this feature cannot be used along with the horizontal/vertical remap.</li> </ul>"},{"location":"user/model_output/#tendencies-output","title":"Tendencies output","text":"<p>It is also possible to request tendencies of fields that are updated by atmosphere processes, on a per-process basis (here, \"updated\" means that the field is both an input as well as an output of the atmosphere process). Since the term \"tendency\" can be used with slightly different connotations, we clarify what we mean by that when it comes to model output: if process P updates field A, by the tendency of A from process P we mean <code>(A_after_P - A_before_P) / dt</code>, where <code>dt</code> is the atmosphere timestep.</p> <p>As of May 2024, the user needs two things in order to get tendencies from a process. E.g., to get the tendencies of <code>T_mid</code> and <code>horiz_winds</code> from the process <code>shoc</code>, one needs:</p> <ul> <li><code>atmchange shoc::compute_tendencies=T_mid,horiz_winds</code>;</li> <li>add <code>shoc_T_mid_tend</code> and <code>shoc_horiz_winds_tend</code> to the list of fields in the desired output YAML file.</li> </ul>"},{"location":"user/model_output/#additional-options","title":"Additional options","text":"<p>The YAML file shown at the top of this section, together with the remap options in the following section, covers most of the options used in a typical run. There are however particular use cases that require some less common options, which we list here (in parentheses, the location in the YAML file and the type of the parameter value).</p> <ul> <li><code>flush_frequency</code> (toplevel list, integer): this parameter  can be used to specify how often the IO   library should sync the in-memory data to file. If not specified, the IO library is free to decide   when it should flush the data. This option can be helpful for debugging, in case a crash is occurring   after a certain number of steps, but before the IO library would automatically flush to file.</li> <li><code>Floating Point Precision</code> (toplevel list, string): this parameter specifies the precision to be used for floating   point variables in the output file. By default, EAMxx uses single precision. Valid values are   <code>single</code>, <code>float</code>, <code>double</code>, and <code>real</code>. The first two are synonyms, while the latter resolves   to <code>single</code> or <code>double</code> depending on EAMxx cmake configuration parameter <code>SCREAM_DOUBLE_PRECISION</code>.</li> <li><code>file_max_storage_type</code> (toplevel list, string): this parameter determines how the capacity of the file is specified.   By default, it is set to <code>num_snapshots</code>, which makes EAMxx read <code>Max Snapshots Per File</code> (explained   in the first section). However, the user can specify <code>one_year</code> or <code>one_month</code>, which will make   EAMxx create one output file per year/month of simulation, fitting however many snapshots are needed   in each file (depending on the output frequency). If <code>one_year</code> or <code>one_month</code> are used, the option   <code>Max Snapshots Per File</code> is ignored.</li> <li><code>MPI Ranks in Filename</code> (toplevel list, boolean): this option specifies whether the number of MPI ranks in the atm   communicator should be put inside the output file name. By default, this is <code>false</code>, since it is   usually not important. This option is mostly important for standalone unit testing, where several   versions of the same test (corresponding to different numbers of MPI ranks) are running concurrently,   so that different file names are needed to avoid resource contention.</li> <li><code>save_grid_data</code> (<code>output_control</code> sublist, boolean): this option allows to specify whether grid data   (such as <code>lat</code>/<code>lon</code>) should be added to the output stream. By default, it is <code>true</code>.</li> <li><code>iotype</code> (toplevel list, string): this option allows the user to request a particular format for the output   file. The possible values are <code>default</code>, <code>netcdf</code>, <code>pnetcdf,</code>adios<code>,</code>hdf5<code>, where</code>default` means   \"whatever is the PIO type from the case settings\".</li> <li><code>skip_t0_output</code> (<code>output_control</code> sublist, boolean): this option is relevant only for <code>Instant</code> output,   where fields are also outputed at the case start time (i.e., after initialization but before the beginning   of the first timestep). By default it is set to <code>false</code>.</li> <li>restart options: when performing a restart, EAMxx attempts to restart every output stream listed in   the <code>output_yaml_files</code> atm option (which can be queried via <code>atmquery output_yaml_files</code>). The user   can specify a few options, in order to tweak the restart behavior:</li> <li><code>Perform Restart</code> (<code>Restart</code> sublist, boolean): this parameter is <code>true</code> by default, but can be set     to <code>false</code> to force the model to ignore any history restart files, and start the output stream from     scratch, as if this was an initial run.</li> <li><code>filename_prefix</code> (<code>Restart</code> sublist, string): by default, this parameter is set to match the value     of <code>filename_prefix</code> from the toplevel list. It can be set to something else in case we want to     restart a previous simulation that was using a different filename prefix.</li> <li><code>force_new_file</code> (<code>Restart</code> sublist, boolean): this parameter allows to start a fresh new output file     upon restarts. By default, is is set to <code>false</code>, so that EAMxx will attempt to resume filling the     last produced output file (if any, and if it can accommodate more snapshots).</li> </ul>"},{"location":"user/nudging/","title":"Nudging in EAMxx","text":"<p>Nudging is supported in EAMxx. Currently, it is possible to nudge EAMxx to the output from a different EAMxx run or to reanalysis. Nudging data can be on your model grid or an arbitrary coarser grid. Inline interpolating of finer-grid nudging data to a coarser model resolution isn't implemented yet but may be in the future.</p>"},{"location":"user/nudging/#data-to-nudge-towards","title":"Data to nudge towards","text":"<p>The user is expected to prepapre (and then use <code>atmchange</code> to point to) nudging data files that are compliant with EAMxx specification. In practice, this means that the data files must contain variable names known to EAMxx (only U, V, T_mid, and qv are supported now). The files can be specified with an explicit list or via pattern matching. The files must contain an arbitary global attribute <code>case_t0</code>, and it is recommended to be the same as the time dimension unit (the files must be time-dimensioned). Finally, the dimension order must be such that <code>lev</code> is the last dimension, so most likely, the user must transpose the dimensions.</p>"},{"location":"user/nudging/#pressure-in-the-nudging-data","title":"Pressure in the nudging data","text":"<p>Pressure can be explicitly provided in the nudging data as time-varying <code>p_mid</code> corresponding to the option <code>TIME_DEPENDENT_3D_PROFILE</code> for <code>source_pressure_type</code>. Alternatively, the data can contain a time-invariant pressure variable <code>p_lev</code> corresponding to the option <code>TIME_DEPENDENT_3D_PROFILE</code> for <code>source_pressure_type</code>.</p>"},{"location":"user/nudging/#weighted-nudging-for-rrm-applications","title":"Weighted nudging for RRM applications","text":"<p>In regionally refined model applications, it is possible to use weighted nudging, for example, to avoid nudging the refined region. To achieve that, the user can use <code>atmchange</code> to set <code>use_nudging_weights</code> (boolean) and provide <code>nudging_weights_file</code> that has the weight to apply for nudging (for example, zeros in the refined region). Currently, weighted nudging is only supported if the user provides the nudging data at the target grid.</p>"},{"location":"user/nudging/#example-setup-current-as-of-april-2024","title":"Example setup (current as of April 2024)","text":"<p>To enable nudging as a process, one must declare it in the <code>atm_procs_list</code> runtime parameter.</p> <pre><code>./atmchange physics::atm_procs_list=\"mac_aero_mic,rrtmgp,cosp,nudging\"\n</code></pre> <p>The following options are needed to specify the nudging.</p> <pre><code>./atmchange nudging::nudging_filenames_patterns=\"/pathto/nudging_files/*.nc\" # can provide file name explicitly here instead (or multiple patterns)\n./atmchange nudging::source_pressure_type=TIME_DEPENDENT_3D_PROFILE # see section on pressure\n./atmchange nudging::nudging_fields=U,V # can include qv, T_mid as well\n./atmchange nudging::nudging_timescale=21600 # in seconds\n</code></pre> <p>To gain a deeper understanding of these parameters and options, please refer to code implementation of the nudging process.</p>"},{"location":"user/rrm_eamxx/","title":"Running EAMxx with a Regionally Refined Mesh (RRM)","text":"<p>Running EAMxx with a RRM allows you run a select region of the globe at high resolution (i.e. 3 km) with the remainder of the globe at a lower resolution (i.e. 25 or 100 km).  This document will point you to the steps required and resources available to assist in developing and running a new RRM.</p>"},{"location":"user/rrm_eamxx/#choose-your-rrm","title":"Choose Your RRM","text":"<p>What region of the globe do you want to refine?  Your first step should be to check library of RRM grids/cases that have already been developed to potentially avoid duplicate work.  If you found a RRM that suits your needs, you can skip the next step (\"Generate Your RRM\").</p>"},{"location":"user/rrm_eamxx/#generate-your-rrm","title":"Generate Your RRM","text":"<p>Please refer to the offical E3SM guide for developing new atmosphere grids, which provides detailed guidance for developing your RRM.</p> <p>After you have made all the necessary files for your RRM, you will need to configure your code branch so that it knows about your new grid.  The steps required to do this are documented at the top of the library of RRM grids/cases page.</p>"},{"location":"user/rrm_eamxx/#make-your-initial-condition-file","title":"Make Your Initial Condition File","text":"<p>The easiest way to generate an initial condition is to use the HICCUP tool, which is a set of flexible and robust python routines to streamline the task of generating a new atmospheric initial condition for E3SM.  Otherwise, please see the step-by-step instuctions if you prefer to manually generate your initial condition.</p>"},{"location":"user/rrm_eamxx/#assemble-nudging-data-optional","title":"Assemble Nudging Data (Optional)","text":"<p>If you wish to nudge your simulation, assemble your nudging data in the format required by EAMxx.  Please refer to the nudging documentation.</p> <p>In the event that you only want to nudge a portion of your domain, then you will need to generate a nudging weights file.  A common use case for this is when you want the high-resolution region to remain free-running (unnudged) while nudging the coarse domain towards reanalysis or model data.  Please use this script as an example of how to generate your nudging weights file.</p>"},{"location":"user/rrm_eamxx/#run-your-rrm","title":"Run your RRM","text":"<p>Congratulations, you are now ready to run your EAMxx RRM.  If you are running your RRM in free running mode (not using any nudging) then you simply need to modify an existing EAMxx script and change the resolution to match the one you created for your RRM.</p> <p>If you are using nudging, then please see this example script of how to run a nudged EAMxx RRM run.  This example script uses the California 3-km RRM, which is on the master branch.</p>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"The E3SM Atmosphere Model in C++ (EAMxx)","text":"<p>EAMxx  EAMxx is almost completely different in all ways from the atmosphere model used for E3SM versions 1-3. </p> <p>EAMxx was built from the ground up using C++ in order to embrace modern software practices and to allow \"performance portability\" across various supercomputers. The latter goal is achieved by using the Kokkos library. EAMxx is a \"clean-start\" model with almost no similarity to the E3SM atmosphere model used in versions 1-3.  Currently only the km-scale explicit-convection version called SCREAM (the Simple Cloud-Resolving E3SM Atmosphere Model) is available, but a low-resolution version is in the works.</p> <p>Like the documentation for other component models, EAMxx documentation is divided into:</p> <ul> <li>The User Guide - info about running EAMxx and all options for modifying a simulation</li> <li>The Developer Guide - information needed to contribute to EAMxx development</li> <li>The Technical Guide - equations and numerical methods used in EAMxx</li> </ul> <p>Put another way, all information about how to customize runs without changing code is included in the User Guide, general information about software design which is needed for intelligently modifying code goes in the Developer Guide, and details about the specific process implementations in the current model version are included in the Technical Guide. </p>"},{"location":"common/eamxx_params/","title":"EAMxx runtime configurable parameters","text":""},{"location":"common/eamxx_params/#atmosphere-processes-parameters","title":"Atmosphere Processes Parameters","text":""},{"location":"common/eamxx_params/#sc_import","title":"sc_import","text":"<ul> <li>sc_import::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>sc_import::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_import::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_import::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>sc_import::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>sc_import::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#sc_export","title":"sc_export","text":"<ul> <li>sc_export::prescribed_constants::fields:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li> <p>sc_export::prescribed_constants::values:  </p> <ul> <li>description: MISSING </li> <li>type: array(real)  </li> </ul> </li> <li> <p>sc_export::prescribed_from_file::fields:  </p> <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>sc_export::prescribed_from_file::files:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li> <p>sc_export::prescribed_from_file::fields_alt_name:  </p> <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li> <p>sc_export::number_of_subcycles:  </p> <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>sc_export::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_export::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>sc_export::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>sc_export::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>sc_export::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#homme","title":"homme","text":"<ul> <li>homme::Moisture:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>homme::BfbHash:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>homme::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>homme::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>homme::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>homme::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>homme::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>homme::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#p3","title":"p3","text":"<ul> <li>p3::do_prescribed_ccn:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>p3::do_predict_nc:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>p3::enable_column_conservation_checks:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>p3::max_total_ni:  <ul> <li>description: maximum total ice concentration (sum of all categories)  </li> <li>type: real  </li> <li>constraints: gt 0  </li> </ul> </li> <li>p3::tables:  <ul> <li>description: MISSING </li> <li>type: array(file)  </li> </ul> </li> <li>p3::autoconversion_prefactor:  <ul> <li>description: Autoconversion linear prefactor  </li> <li>type: real  </li> </ul> </li> <li>p3::autoconversion_qc_exponent:  <ul> <li>description: Autoconversion qc exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::autoconversion_nc_exponent:  <ul> <li>description: Autoconversion nc exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::autoconversion_radius:  <ul> <li>description: Autoconversion droplet radius in meter  </li> <li>type: real  </li> </ul> </li> <li>p3::accretion_prefactor:  <ul> <li>description: Accretion linear prefactor  </li> <li>type: real  </li> </ul> </li> <li>p3::accretion_qc_exponent:  <ul> <li>description: Accretion qc exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::accretion_qr_exponent:  <ul> <li>description: Accretion qr exponent  </li> <li>type: real  </li> </ul> </li> <li>p3::rain_selfcollection_prefactor:  <ul> <li>description: Rain self-collection prefactor  </li> <li>type: real  </li> </ul> </li> <li>p3::rain_selfcollection_breakup_diameter:  <ul> <li>description: Rain self-collection breakup diameter in meter  </li> <li>type: real  </li> </ul> </li> <li>p3::constant_mu_rain:  <ul> <li>description: Constant shape parameter (mu) in the rain droplet distribution  </li> <li>type: real  </li> </ul> </li> <li>p3::spa_ccn_to_nc_factor:  <ul> <li>description: Scaling factor for turning SPA ccn into P3 nc  </li> <li>type: real  </li> </ul> </li> <li>p3::cldliq_to_ice_collection_factor:  <ul> <li>description: Cloud liquid to ice collection scaling factor  </li> <li>type: real  </li> </ul> </li> <li>p3::rain_to_ice_collection_factor:  <ul> <li>description: Rain to ice collection scaling factor  </li> <li>type: real  </li> </ul> </li> <li>p3::min_rime_rho:  <ul> <li>description: Minimum rime density in kg/m3  </li> <li>type: real  </li> </ul> </li> <li>p3::max_rime_rho:  <ul> <li>description: Maximum rime density in kg/m3  </li> <li>type: real  </li> </ul> </li> <li>p3::immersion_freezing_exponent:  <ul> <li>description: Immersion freezing exponent for both rain and cloud liquid  </li> <li>type: real  </li> </ul> </li> <li>p3::deposition_nucleation_exponent:  <ul> <li>description: Deposition nucleation exponent factor  </li> <li>type: real  </li> </ul> </li> <li>p3::ice_sedimentation_factor:  <ul> <li>description: Ice sedimentation fall speed factor  </li> <li>type: real  </li> </ul> </li> <li>p3::do_ice_production:  <ul> <li>description: Flag to turn on ice production processes (loss processes unaffected)  </li> <li>type: logical  </li> </ul> </li> <li>p3::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>p3::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>p3::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>p3::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>p3::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>p3::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#shoc","title":"shoc","text":"<ul> <li>shoc::enable_column_conservation_checks:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>shoc::check_flux_state_consistency:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>shoc::lambda_low:  <ul> <li>description: minimum value of stability correction.  </li> <li>type: real  </li> </ul> </li> <li>shoc::lambda_high:  <ul> <li>description: maximum value of stability correction.  </li> <li>type: real  </li> </ul> </li> <li>shoc::lambda_slope:  <ul> <li>description: slope of change from lambda_low to lambda_high.  </li> <li>type: real  </li> </ul> </li> <li>shoc::lambda_thresh:  <ul> <li>description: stability threshold for which to apply more stability correction.  </li> <li>type: real  </li> </ul> </li> <li>shoc::thl2tune:  <ul> <li>description: Temperature variance tuning factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::qw2tune:  <ul> <li>description: Moisture variance tuning factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::qwthl2tune:  <ul> <li>description: Temperature moisture covariance  </li> <li>type: real  </li> </ul> </li> <li>shoc::w2tune:  <ul> <li>description: Vertical velocity variance  </li> <li>type: real  </li> </ul> </li> <li>shoc::length_fac:  <ul> <li>description: Length scale factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::c_diag_3rd_mom:  <ul> <li>description: Third moment vertical velocity damping factor  </li> <li>type: real  </li> </ul> </li> <li>shoc::Ckh:  <ul> <li>description: Eddy diffusivity coefficient for heat  </li> <li>type: real  </li> </ul> </li> <li>shoc::Ckm:  <ul> <li>description: Eddy diffusivity coefficient for momentum  </li> <li>type: real  </li> </ul> </li> <li>shoc::extra_shoc_diags:  <ul> <li>description: Extra SHOC diagnostics  </li> <li>type: logical  </li> </ul> </li> <li>shoc::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>shoc::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>shoc::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>shoc::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>shoc::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>shoc::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_aci","title":"mam4_aci","text":"<ul> <li>mam4_aci::wsubmin:  <ul> <li>description: Minimum diagnostic sub-grid vertical velocity  </li> <li>type: real  </li> </ul> </li> <li>mam4_aci::top_level_mam4xx:  <ul> <li>description: Level corresponding to the top of troposphere clouds  </li> <li>type: integer  </li> </ul> </li> <li>mam4_aci::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_aci::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aci::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aci::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_aci::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aci::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_drydep","title":"mam4_drydep","text":"<ul> <li>mam4_drydep::fractional_land_use_file:  <ul> <li>description: File containing Fractional land use data for drydep  </li> <li>type: file  </li> </ul> </li> <li>mam4_drydep::drydep_remap_file:  <ul> <li>description: File containing mapping data from the grid of frac land use files to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>mam4_drydep::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_drydep::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_drydep::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_drydep::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_drydep::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_drydep::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#cldfraction","title":"cldFraction","text":"<ul> <li>cldFraction::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>cldFraction::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cldFraction::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cldFraction::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>cldFraction::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>cldFraction::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_aero_microphys","title":"mam4_aero_microphys","text":"<ul> <li>mam4_aero_microphys::mam4_do_cond:  <ul> <li>description: Switch to enable aerosol microphysics condensation process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_do_newnuc:  <ul> <li>description: Switch to enable aerosol microphysics nucleation process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_do_coag:  <ul> <li>description: Switch to enable aerosol microphysics coagulation process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_do_rename:  <ul> <li>description: Switch to enable aerosol microphysics rename process  </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::mam4_o3_tau:  <ul> <li>description: Linoz tau parameter  </li> <li>type: real  </li> </ul> </li> <li>mam4_aero_microphys::mam4_o3_sfc:  <ul> <li>description: Linoz surface parameter  </li> <li>type: real  </li> </ul> </li> <li>mam4_aero_microphys::mam4_o3_lbl:  <ul> <li>description: Linoz lbl parameter  </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_psc_T:  <ul> <li>description: Linoz psc ozone loss temperature (K) threshold  </li> <li>type: real  </li> </ul> </li> <li>mam4_aero_microphys::mam4_linoz_ymd:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_linoz_file_name:  <ul> <li>description: LINOZ chemistry file  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_oxid_ymd:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_oxid_file_name:  <ul> <li>description: File containing oxidants data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_chlorine_loading_ymd:  <ul> <li>description: Cycle year for chlorine  </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_linoz_chlorine_file:  <ul> <li>description: File containing chlorine data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_rsf_file:  <ul> <li>description: File containing photolysis data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_xs_long_file:  <ul> <li>description: File containing photolysis data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::elevated_emiss_ymd:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::mam4_season_wes_file:  <ul> <li>description: File containing season_wes data  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_so2_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for so2  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_so4_a1_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for so4_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_so4_a2_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for ao4_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_pom_a4_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for pom_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_bc_a4_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for bc_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_num_a1_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for num_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_num_a2_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for num_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_num_a4_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for num_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::mam4_soag_elevated_emiss_file_name:  <ul> <li>description: elevated emissions for soag  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::aero_microphys_remap_file:  <ul> <li>description: File containing mapping data from the grid of frac land use files to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>mam4_aero_microphys::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_aero_microphys::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_aero_microphys::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_aero_microphys::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_aero_microphys::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_optics","title":"mam4_optics","text":"<ul> <li>mam4_optics::mam4_mode1_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 1, accumulation mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mode2_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 2, Aitken mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mode3_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 3, coarse mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mode4_physical_properties_file:  <ul> <li>description: File containing optical properties for MAM4 mode 4, p-carbon mode  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_water_refindex_file:  <ul> <li>description: File containing optical properties for aerosol water  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_soa_physical_properties_file:  <ul> <li>description: File containing optical properties for secondary organic aerosol  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_dust_physical_properties_file:  <ul> <li>description: File containing optical properties for dust  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_nacl_physical_properties_file:  <ul> <li>description: File containing optical properties for sea salt  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_so4_physical_properties_file:  <ul> <li>description: File containing optical properties for sulfate  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_pom_physical_properties_file:  <ul> <li>description: File containing optical properties for primary organic aerosol  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_bc_physical_properties_file:  <ul> <li>description: File containing optical properties for black carbon  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::mam4_mom_physical_properties_file:  <ul> <li>description: File containing optical properties for marine organic aerosol  </li> <li>type: file  </li> </ul> </li> <li>mam4_optics::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_optics::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_optics::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_optics::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_optics::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_optics::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_wetscav","title":"mam4_wetscav","text":"<ul> <li>mam4_wetscav::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_wetscav::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_wetscav::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_wetscav::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_wetscav::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_wetscav::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_srf_online_emiss","title":"mam4_srf_online_emiss","text":"<ul> <li>mam4_srf_online_emiss::srf_emis_specifier_for_DMS:  <ul> <li>description: File containing surface emissions data for DMS  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_SO2:  <ul> <li>description: File containing surface emissions data for SO2  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_bc_a4:  <ul> <li>description: File containing surface emissions data for bc_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_num_a1:  <ul> <li>description: File containing surface emissions data for num_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_num_a2:  <ul> <li>description: File containing surface emissions data for num_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_num_a4:  <ul> <li>description: File containing surface emissions data for num_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_pom_a4:  <ul> <li>description: File containing surface emissions data for pom_a4  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_so4_a1:  <ul> <li>description: File containing surface emissions data for so4_a1  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_emis_specifier_for_so4_a2:  <ul> <li>description: File containing surface emissions data for so4_a2  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::soil_erodibility_file:  <ul> <li>description: File containing soil erodibility  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::marine_organics_file:  <ul> <li>description: File containing marine organics emissions  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::srf_remap_file:  <ul> <li>description: File containing mapping data from the grid of emission files to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>mam4_srf_online_emiss::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_srf_online_emiss::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_srf_online_emiss::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_srf_online_emiss::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_srf_online_emiss::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_srf_online_emiss::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mam4_constituent_fluxes","title":"mam4_constituent_fluxes","text":"<ul> <li>mam4_constituent_fluxes::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mam4_constituent_fluxes::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_constituent_fluxes::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mam4_constituent_fluxes::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mam4_constituent_fluxes::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mam4_constituent_fluxes::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#nudging","title":"nudging","text":"<ul> <li>nudging::nudging_filenames_patterns:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>nudging::nudging_fields:  <ul> <li>description: List of fields to be nudged.  Note, syntax of 'A:B' represents nudging field A with data from field B in files, syntax of 'A' assumes that nudging file has the same variables name as EAMxx  </li> <li>type: array(string)  </li> </ul> </li> <li>nudging::nudging_timescale:  <ul> <li>description: Timescale to apply nudging tendencies, 0: full replacement, &gt;0: actual timescale  </li> <li>type: integer  </li> </ul> </li> <li>nudging::use_nudging_weights:  <ul> <li>description: Flag for nudging weights option  </li> <li>type: logical  </li> </ul> </li> <li>nudging::nudging_weights_file:  <ul> <li>description: weights that relax the nudging fields update  </li> <li>type: string  </li> </ul> </li> <li>nudging::skip_vert_interpolation:  <ul> <li>description: Flag for skipping vertical interpolation  </li> <li>type: logical  </li> </ul> </li> <li>nudging::source_pressure_type:  <ul> <li>description: Flag for how source pressure levels are handled in the nudging dataset.     TIME_DEPENDENT_3D_PROFILE: The dataset contains a time-varying pressure profile, variable name 'p_mid' with dimensions (time,ncol,nlev).     STATIC_1D_VERTICAL_PROFILE: The dataset uses a fixed in time single pressure profile, variable name 'p_lev' with dimension (nlev).  </li> <li>type: string  </li> <li>valid values: TIME_DEPENDENT_3D_PROFILE,STATIC_1D_VERTICAL_PROFILE  </li> </ul> </li> <li>nudging::source_pressure_file:  <ul> <li>description: If STATIC_1D_VERTICAL_PROFILE, this is an optional arg to point to a file with the source pressure levels defined.     Default is to look for p_levs in the first nudging_filenames_patterns file  </li> <li>type: string  </li> </ul> </li> <li>nudging::nudging_refine_remap_mapfile:  <ul> <li>description: Refine-remapping mapfile from the source nudging dataset to the physics grid  </li> <li>type: string  </li> </ul> </li> <li>nudging::nudging_refine_remap_vert_cutoff:  <ul> <li>description: A vertical cutoff to go with refine-remap logic (in units of p_mid) where the nudging is turned off above it (closer to the surface)  </li> <li>type: real  </li> </ul> </li> <li>nudging::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>nudging::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>nudging::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>nudging::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>nudging::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>nudging::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mlcorrection","title":"mlcorrection","text":"<ul> <li>mlcorrection::ML_model_path_tq:  <ul> <li>description: Path to pre-trained ML model for temperature and specific humidity  </li> <li>type: string  </li> </ul> </li> <li>mlcorrection::ML_model_path_uv:  <ul> <li>description: Path to pre-trained ML model for wind fields  </li> <li>type: string  </li> </ul> </li> <li>mlcorrection::ML_model_path_sfc_fluxes:  <ul> <li>description: Path to pre-trained ML model for surface fluxes  </li> <li>type: string  </li> </ul> </li> <li>mlcorrection::ML_output_fields:  <ul> <li>description: ML correction output variables, the following variables are supported: T_mid,qv,u,v  </li> <li>type: array(string)  </li> </ul> </li> <li>mlcorrection::ML_correction_unit_test:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mlcorrection::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>mlcorrection::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mlcorrection::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mlcorrection::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mlcorrection::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mlcorrection::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#testonly","title":"testOnly","text":"<ul> <li>testOnly::my_param:  <ul> <li>description: MISSING </li> <li>type: array(integer)  </li> </ul> </li> <li>testOnly::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>testOnly::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>testOnly::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>testOnly::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>testOnly::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>testOnly::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#spa","title":"spa","text":"<ul> <li>spa::spa_remap_file:  <ul> <li>description: File containing mapping data from the grid of spa_data_file to the model grid. Unused if the grid is the same.  </li> <li>type: file  </li> </ul> </li> <li>spa::spa_data_file:  <ul> <li>description: File containing aerosol data. Must be on same grid as the atm, or a coarser one  </li> <li>type: file  </li> </ul> </li> <li>spa::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>spa::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>spa::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>spa::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>spa::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>spa::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#rrtmgp","title":"rrtmgp","text":"<ul> <li>rrtmgp::rrtmgp_coefficients_file_sw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::rrtmgp_coefficients_file_lw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::rrtmgp_cloud_optics_file_sw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::rrtmgp_cloud_optics_file_lw:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>rrtmgp::column_chunk_size:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::active_gases:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>rrtmgp::ch4vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::co2vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::n2ovmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::f11vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::f12vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::n2vmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::covmr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::orbital_year:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::orbital_eccentricity:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>rrtmgp::orbital_obliquity:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>rrtmgp::orbital_mvelp:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>rrtmgp::rad_frequency:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>rrtmgp::do_aerosol_rad:  <ul> <li>description: Flag to turn on/off considering aerosols in radiation calculations  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::enable_column_conservation_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::extra_clnclrsky_diag:  <ul> <li>description: Flag to turn on/off an extra clean-clear-sky (with neither clouds nor aerosols) radiation call  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::extra_clnsky_diag:  <ul> <li>description: Flag to turn on/off an extra clean-sky (with no aerosols) radiation call  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::do_subcol_sampling:  <ul> <li>description: Flag to turn on/off subcolumn sampling of optical properties; if false treat cells as either completely clear or cloudy  </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>rrtmgp::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>rrtmgp::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>rrtmgp::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>rrtmgp::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#mac_aero_mic","title":"mac_aero_mic","text":"<ul> <li>mac_aero_mic::atm_procs_list:  <ul> <li>description: List of atm processes in this atm process group  </li> <li>type: array(string)  </li> </ul> </li> <li>mac_aero_mic::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> </ul> </li> <li>mac_aero_mic::Type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>mac_aero_mic::schedule_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: Sequential  </li> </ul> </li> <li>mac_aero_mic::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mac_aero_mic::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>mac_aero_mic::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>mac_aero_mic::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>mac_aero_mic::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#cosp","title":"cosp","text":"<ul> <li>cosp::cosp_subcolumns:  <ul> <li>description: Number of subcolumns to use for COSP simulators; cosp_subcolumns=1 implies no subcolumn sampling  </li> <li>type: MISSING </li> </ul> </li> <li>cosp::cosp_frequency:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>cosp::cosp_frequency_units:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: steps,hours  </li> </ul> </li> <li>cosp::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>cosp::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cosp::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>cosp::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>cosp::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>cosp::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#tms","title":"tms","text":"<ul> <li>tms::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>tms::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>tms::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>tms::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>tms::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>tms::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#physics","title":"physics","text":"<ul> <li>physics::atm_procs_list:  <ul> <li>description: List of atm processes in this atm process group  </li> <li>type: array(string)  </li> </ul> </li> <li>physics::Type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>physics::schedule_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: Sequential  </li> </ul> </li> <li>physics::number_of_subcycles:  <ul> <li>description: how many times to subcycle this atm process  </li> <li>type: MISSING </li> <li>constraints: gt 0  </li> </ul> </li> <li>physics::enable_precondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>physics::enable_postcondition_checks:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>physics::repair_log_level:  <ul> <li>description: MISSING </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn  </li> </ul> </li> <li>physics::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>physics::compute_tendencies:  <ul> <li>description: list of computed fields for which this process will back out tendencies  </li> <li>type: array(string)  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#initial-conditions-parameters","title":"Initial Conditions Parameters","text":"<ul> <li>initial_conditions::Filename:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>initial_conditions::topography_filename:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> <li>initial_conditions::phis:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_evap:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::precip_liq_surf_mass:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::precip_ice_surf_mass:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::cldfrac_liq:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sgs_buoy_flux:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::eddy_diff_mom:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::T_prev_micro_step:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qv_prev_micro_step:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::nr:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qm:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::bm:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::ni_activated:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::nc_nuceat_tend:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::tke:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dir_vis:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dir_nir:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dif_vis:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::sfc_alb_dif_nir:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_sens_flux:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_lw_flux_up:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::surf_mom_flux:  <ul> <li>description: MISSING </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::dgnum:  <ul> <li>description: Dry aerosol particles diameters (one per mode) [m]  </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::dgnumwet:  <ul> <li>description: Wet aerosol particles diameter [m]  </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::wetdens:  <ul> <li>description: Wet density of interstitial aerosol [kg/m3]  </li> <li>type: array(real)  </li> </ul> </li> <li>initial_conditions::constituent_fluxes:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::bc_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::bc_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::bc_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::dst_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::dst_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::so4_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::so4_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::so4_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::pom_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::pom_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::pom_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::soa_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::soa_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::soa_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::nacl_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::nacl_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::nacl_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::mom_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::num_c4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_hydrophilic_bc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::drydep_hydrophilic_bc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_hydrophilic_oc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::drydep_hydrophilic_oc:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin1:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin2:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin3:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::wetdep_dust_bin4:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::qc:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::qi:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::nc:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::ni:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::o3_volume_mix_ratio:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>initial_conditions::perturbed_fields:  <ul> <li>description: IC fields (with level dimension) to apply a random perturbation to based on the parameters below.  </li> <li>type: array(string)  </li> </ul> </li> <li>initial_conditions::generate_perturbation_random_seed:  <ul> <li>description: Whether or not to generate a random seed for perturbation.  </li> <li>type: logical  </li> </ul> </li> <li>initial_conditions::perturbation_random_seed:  <ul> <li>description: Random seed used for perturbation. Will be overridded by generate_perturbation_random_seed=true.  </li> <li>type: integer  </li> </ul> </li> <li>initial_conditions::perturbation_limit:  <ul> <li>description: Defines a range [1-x, 1+x] which perturbation will be taken from.  </li> <li>type: real  </li> </ul> </li> <li>initial_conditions::perturbation_minimum_pressure:  <ul> <li>description: Minimum pressure (relative to a reference level pressure profile) for which perturbation will be applied.  </li> <li>type: real  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#atmosphere-driver-parameters","title":"Atmosphere Driver Parameters","text":"<ul> <li>driver_options::atmosphere_dag_verbosity_level:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::atm_log_level:  <ul> <li>description: Verbosity level for the atm logger  </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn,error  </li> </ul> </li> <li>driver_options::atm_flush_level:  <ul> <li>description: Verbosity level that triggers automatic flush of the atm logger  </li> <li>type: string  </li> <li>valid values: trace,debug,info,warn,error  </li> </ul> </li> <li>driver_options::output_to_screen:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>driver_options::mass_column_conservation_error_tolerance:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::energy_column_conservation_error_tolerance:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::column_conservation_checks_fail_handling_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>driver_options::check_all_computed_fields_for_nans:  <ul> <li>description: MISSING </li> <li>type: logical  </li> </ul> </li> <li>driver_options::property_check_data_fields:  <ul> <li>description: list of additional data fields to output in property checks (only for physics grid)  </li> <li>type: array(string)  </li> </ul> </li> <li>driver_options::enable_iop:  <ul> <li>description: Enable intensive observation period. Currently the only use case is DP-EAMxx  </li> <li>type: logical  </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#scorpio-parameters","title":"Scorpio Parameters","text":"<ul> <li>Scorpio::output_yaml_files:  <ul> <li>description: MISSING </li> <li>type: array(string)  </li> </ul> </li> <li>Scorpio::model_restart::iotype:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> </ul>"},{"location":"common/eamxx_params/#homme-namelist","title":"Homme namelist","text":"<ul> <li>ctl_nl::cubed_sphere_map:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::disable_diagnostics:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::dt_remap_factor:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>constraints: ge 1  </li> </ul> </li> <li>ctl_nl::dt_tracer_factor:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>constraints: ge 1  </li> </ul> </li> <li>ctl_nl::hv_ref_profiles:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_order:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_scaling:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_subcycle:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_subcycle_tom:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::hypervis_subcycle_q:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::nu:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::nu_top:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::pgrad_correction:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ftype:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> <li>valid values: 0,2  </li> </ul> </li> <li>ctl_nl::se_geometry:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_limiter_option:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ne:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ne_x:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ne_y:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_lx:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_ly:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_nsplit:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_partmethod:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_topology:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::se_tstep:  <ul> <li>description: MISSING </li> <li>type: real  </li> </ul> </li> <li>ctl_nl::statefreq:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::theta_advect_form:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::theta_hydrostatic_mode:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::tstep_type:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::vert_remap_q_alg:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::transport_alg:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::vtheta_thresh:  <ul> <li>description: MISSING </li> <li>type: MISSING </li> </ul> </li> <li>ctl_nl::internal_diagnostics_level:  <ul> <li>description: MISSING </li> <li>type: integer  </li> </ul> </li> <li>ctl_nl::mesh_file:  <ul> <li>description: MISSING </li> <li>type: file  </li> </ul> </li> </ul>"},{"location":"common/installation/","title":"Installation","text":"<p>Follow these simple instructions to build and test EAMxx's standalone configuration for yourself. This document makes use of the following paths:</p> <ul> <li><code>${RUN_ROOT_DIR}</code>: the root directory where EAMxx is built and run</li> <li><code>${EAMXX_SRC_DIR}</code>: the directory into which you've cloned the <code>scream</code> repo</li> </ul> <p>EAMxx's configuration and build system is based on CMake. CMake has been around a while and has gained a lot of traction in recent years, especially in the HPC community. It has good reference documentation, but it can be tricky to use if you've never encountered it. Ask a EAMxx team member for help if you're stuck on something CMake-related.</p> <p>If you see a <code>CMakeLists.txt</code> files or a file with a <code>.cmake</code> suffix, that's just part of the build system. You might also see files with <code>CTest</code> as part of their name. These files are related to CTest, CMake's testing tool.</p>"},{"location":"common/installation/#prerequisites","title":"Prerequisites","text":"<p>First, make sure you're on one of the machines supported by EAMxx, or that you have the following software installed:</p> <ul> <li>A working MPI installation (typically MPICH or Open-MPI)</li> <li>CMake and GNU Make</li> <li>A working set of C, C++, and Fortran compilers</li> <li>A recent version of Git</li> <li>A working installation of NetCDF,   including both C and   Fortran libraries.</li> </ul>"},{"location":"common/installation/#setting-up-your-environment","title":"Setting Up Your Environment","text":""},{"location":"common/installation/#configuring-and-building-scream","title":"Configuring and Building Scream","text":""},{"location":"common/installation/#1-start-from-a-trustworthy-commit","title":"1. Start From a Trustworthy Commit","text":"<p>First, make sure you've cloned the EAMxx repo (including all submodules) to <code>EAMXX_SRC_DIR</code> using the following command:</p> <pre><code>git clone --recurse-submodules https://github.com/E3SM-Project/scream\n</code></pre> <p>If you have already cloned the project and forgot to type <code>--recurse-submodules</code>, you can change to <code>$EAMXX_SRC_DIR</code> and using the following command to initialize, fetch and checkout all submodules:</p> <pre><code>git submodule update --init --recursive\n</code></pre> <p>If you're running a branch that's not <code>master</code>, check out this branch with</p> <pre><code>git checkout &lt;branch&gt;\n</code></pre>"},{"location":"common/installation/#2-configure-your-eamxx-build","title":"2. Configure Your EAMxx Build","text":"<p>Change to your <code>$RUN_ROOT_DIR</code> directory and use CMake to configure your build.</p> <p>If you're building SCREAM on one of our supported platforms, you can tell CMake to use the appropriate machine file using the <code>-C</code> flag. Machine files are located in <code>$EAMXX_SRC_DIR/components/eamxx/cmake/machine-files</code>. Take a look and see whether your favorite machine has one.</p> <p>For example, to configure SCREAM on the Quartz machine at LLNL:</p> <pre><code>cd $RUN_ROOT_DIR\ncmake \\\n    -DCMAKE_CXX_COMPILER=$(which mpicxx) \\\n    -DCMAKE_BUILD_TYPE=Debug \\\n    -C ${EAMXX_SRC_DIR}/components/eamxx/cmake/machine-files/quartz.cmake \\\n    ${EAMXX_SRC_DIR}/components/eamxx\n</code></pre> <p>If you're building on a machine that doesn't have a ready-made machine file, you can try configuring your build by manually passing options to CMake. This usually looks something like the following, which configures EAMxx to compile CPU code using Kokkos's OpenMP backend: <pre><code>cd $RUN_ROOT_DIR\ncmake \\\n    -D CMAKE_BUILD_TYPE=Debug \\\n    -D CMAKE_C_COMPILER=mpicc \\\n    -D CMAKE_CXX_COMPILER=mpicxx \\\n    -D CMAKE_Fortran_COMPILER=mpif90 \\\n    -D MPIEXEC_EXECUTABLE=`which mpiexec` \\\n    -D EKAT_MPI_NP_FLAG:STRING=-n \\\n    -D SCREAM_DYNAMICS_DYCORE=HOMME \\\n    -D SCREAM_DOUBLE_PRECISION:BOOL=ON \\\n    -D SCREAM_INPUT_ROOT:PATH=/path/to/scream-input \\\n    -D Kokkos_ENABLE_DEBUG=TRUE \\\n    -D Kokkos_ENABLE_AGGRESSIVE_VECTORIZATION=OFF \\\n    -D Kokkos_ENABLE_SERIAL=ON \\\n    -D Kokkos_ENABLE_OPENMP=ON \\\n    -D Kokkos_ENABLE_LIBDL=OFF \\\n    -D Kokkos_ENABLE_PROFILING=OFF \\\n    -D Kokkos_ENABLE_DEPRECATED_CODE=OFF \\\n    -D KOKKOS_ENABLE_ETI:BOOL=OFF \\\n    -D NetCDF_C_PATHS=/path/to/netcdf-c-dir \\\n    -D NetCDF_Fortran_PATHS=/path/to/netcdf-f90-dir \\\n    -D PnetCDF_C_PATHS=/path/to/pnetcdf-dir \\\n    -D PnetCDF_Fortran_PATHS=/path/to/pnetcdf-f90-dir \\\n    ${EAMXX_SRC_DIR}/components/eamxx\n</code></pre></p> <p>In either case, EAMxx requires MPI-aware compilers. Let's examine these options (only some of which are required on any given machine) to make sure we know what they do:</p> <ul> <li><code>CMAKE_BUILD_TYPE</code>: specifies whether you are building EAMxx in a   developer-friendly configuration (<code>Debug</code>), for a production run (<code>Release</code>)   or for performance profiling or some other specialized purpose. Typically,   you'll set this option to <code>Debug</code> or <code>Release</code>.</li> <li><code>CMAKE_{C,CXX,Fortran}_COMPILER</code>: the name of the command used to invoke an   MPI-enabled C, C++, or Fortran compiler to build EAMxx</li> <li><code>MPIEXEC_EXECUTABLE</code>: the name of the command used to run EAMxx using MPI,   typically <code>mpiexec</code> or <code>mpirun</code>, but possibly different depending on your   desired machine</li> <li><code>EKAT_MPI_NP_FLAG</code>: the flag passed to <code>MPIEXEC_EXECUTABLE</code> that you use to   specify the number of desired MPI processes. This is typically <code>-n</code> for   <code>mpiexec</code> and <code>-np</code> for <code>mpirun</code>.</li> <li><code>SCREAM_DYNAMICS_DYCORE</code>: specifies the dycore used for configuring EAMxx,   which is <code>NONE</code> if you are not configuring EAMxx to run its dycore-related   tests, or <code>HOMME</code> if you want to use HOMMExx</li> <li><code>SCREAM_DOUBLE_PRECISION</code>: indicates whether EAMxx's <code>Real</code> type is a   double-precision (<code>ON</code>) or single-precision (<code>OFF</code>) floating point type</li> <li><code>SCREAM_INPUT_ROOT</code>: specifies the location of the top-level folder that   stores input data files for EAMxx. This folder is populated with input files   which are downloaded automatically during EAMxx's build process.</li> <li>The Kokkos-related build options (most of which begin with <code>Kokkos_</code>) are   described in the Kokkos Wiki</li> <li><code>NetCDF_C_PATHS</code>: specifies one or more folders in which the NetCDF C library   and headers are installed. In the simplest configuration, the headers should   be located in <code>${NetCDF_C_PATHS}/include</code> and the library should live in   <code>${NetCDF_C_PATHS}/lib</code>.</li> <li><code>NetCDF_Fortran_PATHS</code>: specifies one or more folders in which the NetCDF   Fortran library and modules are installed. Analogous to <code>${NetCDF_C_PATHS}</code>,   <code>.mod</code> files should be in <code>${NetCDF_Fortran_PATHS}/include</code>, and the library   should be installed in <code>${NetCDF_Fortran_PATHS}/lib</code>.</li> <li><code>PnetCDF_C_PATHS</code>: specifies one or more folders in which the pNetCDF C   library and headers are installed, analogous to <code>NetCDF_C_PATHS</code>.</li> <li><code>PnetCDF_Fortran_PATHS</code>: specifies one or more folders in which the pNetCDF   Fortran library and modules are installed, analogous to   <code>NetCDF_Fortran_PATHS</code>.</li> </ul> <p>Above, we've configured <code>Debug</code> builds to make it easier to find and fix errors. For performance testing, you should configure a <code>Release</code> build and make use of other options, depending on your architecture.</p>"},{"location":"common/installation/#3-build-scream","title":"3. Build SCREAM","text":"<p>Now you can build SCREAM from that same directory:</p> <pre><code>make -j\n</code></pre> <p>The <code>-j</code> flag tells Make to use threads to compile in parallel. If you like, you can set the number of threads by passing it as an argument to <code>-j</code> (e.g. <code>make -j8</code>).</p>"},{"location":"common/installation/#running-tests","title":"Running Tests","text":"<p>You can run EAMxx's tests to make sure your build works by following the instructions here.</p>"},{"location":"developer/","title":"SCREAM Developer Guide","text":""},{"location":"developer/ci_nightly/","title":"Continuous Integration and Nightly Testing","text":""},{"location":"developer/ci_nightly/#autotester","title":"Autotester","text":"<p>EAMxx using github actions and a Sandia product called Autotester 2 to run CI testing on a CPU and GPU machine for every github pull request. By default, we run the e3sm_scream_v1_at suite and the standalone eamxx tests (test-all-scream).</p>"},{"location":"developer/ci_nightly/#nightly-overview-cdash","title":"Nightly overview, CDash","text":"<p>Our nightly testing is much more extensive than the CI testing. You can see our dashboard here under the section \"E3SM_SCREAM\": https://my.cdash.org/index.php?project=E3SM</p> <p>We run a variety of CIME test suites and standalone testing on a number of platforms. We even do some performance testing on frontier.</p>"},{"location":"developer/cime_testing/","title":"Full Model Testing","text":"<p>Full model system testing of eamxx is done through CIME test cases (much like the rest of E3SM).</p> <p>We offer a number of test suites, including:</p> <ul> <li>e3sm_scream_v0: Test the full set of V0 (pre-C++) tests</li> <li>e3sm_scream_v1: Test the full set of V1 (C++) tests</li> <li>e3sm_scream_v1_at: A smaller and quicker set of tests for autotesting</li> <li>e3sm_scream_hires: A small number of bigger, longer-running tests to measure performance</li> </ul> <p>Example for running a suite:</p> <pre><code>cd $repo/cime/scripts\n./create_test e3sm_scream_v1_at --wait\n</code></pre> <p>Example for running a single test case:</p> <pre><code>cd $repo/cime/scripts\n./create_test SMS.ne4_ne4.F2010-SCREAMv1 --wait\n</code></pre> <p>There are many behavioral tweaks you can make to a test case, like changing the run length, test type, etc. Most of this is not specific to eamxx and works for any CIME case. This generic stuff is well-documentated here: http://esmci.github.io/cime/versions/master/html/users_guide/testing.html</p> <p>When it comes to things specific to eamxx, you have grids, compsets, and testmods.</p> <p>Common EAMxx grids are:</p> <ul> <li>ne4_ne4 (low resolution)</li> <li>ne4pg2_ne4pg2 (low resolution with phys grid)</li> <li>ne30_ne30 (med resolution)</li> <li>ne30pg2_ne30pg2 (med resolution with phys grid)</li> <li>ne1024pg2_ne1024pg2 (ultra high with phys grid)</li> </ul> <p>More grid info can be found here: https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/933986549/ATM+Grid+Resolution+Summary</p> <p>Common EAMxx compsets are:</p> <ul> <li>F2010-SCREAM-LR: V0 low res compset with eamxx V0 atmosphere</li> <li>F2010-SCREAMv1: V1 standard compset with eamxx V1 atmosphere</li> <li>FIOP-SCREAMv1-DP: V1 with dpxx (doubly-periodic lateral boundary condition in C++)</li> <li>F2010-SCREAMv1-noAero: V1 without aerosol forcing</li> </ul> <p>Full info on supported compsets can be found by looking at this file: <code>$scream_repo/components/eamxx/cime_config/config_compsets.xml</code></p> <p>Common EAMxx testmods are:</p> <ul> <li>small_kernels: Enable smaller-granularity kernels,   can improve performance on some systems</li> <li>scream-output-preset-[1-6]: Our 6 output presets.   These turn some combination of our three output streams   (phys_dyn, phys, and diags),   various remaps, etc.</li> <li>bfbhash: Turns on bit-for-bit hash output: https://acme-climate.atlassian.net/wiki/spaces/NGDNA/pages/3831923056/EAMxx+BFB+hashing</li> </ul> <p>More info on running EAMxx can be found here: https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/3386015745/How+To+Run+EAMxx+SCREAMv1</p>"},{"location":"developer/field/","title":"Field","text":"<p>In EAMxx, a <code>Field</code> is a data structure holding two things: pointers to the data and pointers to metadata. Both the data and metadata are stored in <code>std::shared_ptr</code> instances, to ensure consistency across all copies of the field. This allows for fast shallow copy semantic for this class.</p> <p>The data is stored on both CPU and device memory (these may be the same, depending on the Kokkos backend). In EAMxx, we always assume and guarantee that the device data is up to date. That implies that the data must be explicitly synced to host before using it on host, and explicitly synced to device after host manipulation, in order to ensure correctness. In order to access the data, users must use the <code>get_view</code>/ <code>get_strided_view</code> methods, which takes two template arguments: the data type, and an enum specifying whether CPU or device data is needed. The data type is used to reinterpret the generic pointer stored inside to a view of the correct scalar type and layout. It is a possibly const-qualified type, and if the field was marked as \"read-only\", the method ensures that the provided data type is const. A read-only field can be created via the <code>getConst</code> method, which returns a shallow copy of the field, but marked as read-only. The enum specifying host or device data is optional, with device being the default.</p> <p>The metadata is a collection of information on the field, such as name, layout, units, allocation size, and more. Part of the metadata is immutable after creation (e.g., name, units, or layout), while some metadata can be partially or completely modified. The metadata is contained in the <code>FieldHeader</code> data structure, which contains four parts:</p> <ul> <li><code>FieldIdentifier</code>: stores the field's name, layout, units, data type,   and name of the grid where it's defined. These information are condensed   in a single string, that can be used to uniquely identify a field, allowing   to distinguish between different version of the same field.   The layout is stored in the <code>FieldLayout</code> data structure, which includes:</li> <li>the field tags: stored as a <code>std::vector&lt;FieldTag&gt;</code>, they give context to the     field's extents.</li> <li>the field dims: stored both as a <code>std::vector&lt;int&gt;</code>, as well as a 1d <code>Kokkos::View</code>.</li> <li><code>FieldTracking</code>: stores information on the usage of the field, as well as its   possible connections to other fields. In particular, the tracked items are:</li> <li>the field time stamp: the time stamp when the field was last updated.</li> <li>the field accumulation start time: used for fields that are accumulated over     several time steps (or time step subcycles). For instance, it allows to     reconstruct fluxes from raw accumulations.</li> <li>the providers/customers: lists of atmosphere processes (see below) that     respectively require/compute the field in their calculations.</li> <li>the field groups: a list of field groups that this field belongs too. Field groups     are used to access a group of fields without explicit prior knowledge about the     number and/or names of the fields.</li> <li><code>FieldAllocProp</code>: stores information about the allocation. While the field is not   yet allocated, users can request special allocations for the field, for instance   to accommodate packing (for SIMD), which may require padding. Upon allocation,   this information is then used by the Field structure to extract the actual data,   wrapped in a properly shaped <code>Kokkos::View</code>. The alloc props are also   responsible of tracking additional information in case the field is a \"slice\" of   a higher-dimensional one, a fact that can affect how the data is accessed.</li> <li>Extra data: stored as a <code>std::map&lt;std::string,ekat::any&gt;</code>, allows to catch any   metadata that does not fit in the above structures. This is a last resort structure,   intended to accommodate the most peculiar corner cases, and should be used sparingly.</li> </ul>"},{"location":"developer/grid/","title":"Grids and Remappers","text":"<p>In EAMxx, the <code>AbstractGrid</code> is an interface used to access information regarding the horizontal and vertical discretization. The most important information that the grid stores is:</p> <ul> <li>the number of local/global DOFs: these are the degrees of freedom of the   horizontal grid only. Here, local/global refers to the MPI partitioning.</li> <li>the DOFs global IDs (GIDs): a list of GIDs of the DOFs on the current MPI rank,   stored as a Field</li> <li>the local IDs (LIDs) to index list: this list maps the LID of a DOF (that is,   the position of the DOF in the GID list) to a \"native\" indexing system for that   DOF. For instance, a <code>PointGrid</code> (a class derived from <code>AbstractGrid</code>) is a   simple collection of points, so the \"native\" indexing system coincides with the   LIDs. However, for a <code>SEGrid</code> (a derived class, for spectral element grids),   the \"native\" indexing is a triplet <code>(ielem,igp,jgp)</code>, specifying the element   index, and the two indices of the Gauss point within the element.</li> <li>geometry data: stored as a <code>std::map&lt;std::string,Field&gt;</code>, this represent any   data that is intrinsically linked to the grid (either along the horizontal or   vertical direction), such as lat/lon coordinates, vertical coordinates, area   associated with the DOF.</li> </ul> <p>Grids can also be used to retrieve the layout of a 2d/3d scalar/vector field, which allows certain downstream classes to perform certain operations without assuming anything on the horizontal grid.</p> <p>In general, grid objects are passed around the different parts of EAMxx as const objects (read-only). The internal data can only be modified during construction, which usually is handled by a <code>GridsManager</code> object.</p>"},{"location":"developer/io/","title":"Input-Output","text":"<p>In EAMxx, I/O is handled through the SCORPIO library, currently a submodule of E3SM. The <code>scream_io</code> library within eamxx allows to interface the EAMxx infrastructure classes with the SCORPIO library.</p>"},{"location":"developer/kokkos_ekat/","title":"Kokkos and EKAT","text":""},{"location":"developer/kokkos_ekat/#kokkos","title":"Kokkos","text":"<p>EAMxx uses Kokkos for performance portable abstractions for parallel execution of code and data management to various HPC platforms, including OpenMP, Cuda, HIP, and SYCL. Here we give a brief overview of the important concepts for understanding Kokkos in EAMxx. For a more in depth description, see the Kokkos wiki.</p>"},{"location":"developer/kokkos_ekat/#kokkosdevice","title":"Kokkos::Device","text":"<p><code>Kokkos::Device</code> is a struct which contain the type definitions for two main Kokkos concepts: execution space (<code>Kokkos::Device::execution_space</code>), the place on-node where parallel operations (like for-loops, reductions, etc.) are executed, and the memory space (<code>Kokkos::Device::memory_space</code>), the memory location on-node where data is stored. Given your machine architecture, Kokkos defines a default \"device\" space, given by</p> <pre><code>Kokkos::Device&lt;Kokkos::DefaultExecutionSpace,\n         Kokkos::DefaultExecutionSpace::memory_space&gt;\n</code></pre> <p>where all performance critical code should be executed (e.g., on an NVIDIA machine, this device would be the GPU accelerators) and a default \"host\" space, given by</p> <pre><code>Kokkos::Device&lt;Kokkos::DefaultHostExecutionSpace,\n         Kokkos::DefaultHostExecutionSpace::memory_space&gt;\n</code></pre> <p>where data can be accessed by the CPU cores and is necessary for I/O interfacing, for example. Currently, these default spaces are the ones used by EAMxx. On CPU-only machines, host and device represent the same space.</p>"},{"location":"developer/kokkos_ekat/#kokkos-views","title":"Kokkos Views","text":"<p>The main data struct provided by Kokkos used in EAMxx in the <code>Kokkos::View</code>. This is a multi-dimensional data array that can live on either device or host memory space. These Views are necessary when running on GPU architectures as data structures like <code>std::vector</code> and <code>std::array</code> will be unavailable on device.</p> <p>Views are constructed in EAMxx most commonly with the following template and input arguments</p> <pre><code>Kokkos::View&lt;DataType, LayoutType, DeviceType&gt;(const std::string&amp; label,\n                         int dim0, int dim1, ...)\n</code></pre> <p>where</p> <ul> <li><code>DataType</code>: scalar type of the view, given as <code>ScalarType</code>+<code>*</code>(x's number of   run-time dimensions). E.g., a 2D view of doubles will have <code>DataType =   double**</code>. There is also an ability to define compile-time dimensions by   using <code>[]</code>, see    [Kokkos wiki section on views]    (https://kokkos.org/kokkos-core-wiki/API/core/view/view.html).</li> <li><code>LayoutType</code>: mapping of indices into the underlying 1D memory storage. Types   are:</li> <li><code>LayoutRight</code> (used in EAMxx): strides increase from the right most to the   left most dimension, right-most dimension is contiguous</li> <li><code>LayoutLeft</code>: strides increase from the left most to the right most   dimension, left-most dimension is contiguous</li> <li><code>LayoutStride</code>: strides can be arbitrary for each dimension</li> <li><code>DeviceType</code>: provides space where data live, defaults to the default device</li> </ul> <p>The following example defines a view \"temperature\" which has dimensions columns and levels:</p> <pre><code>Kokkos::View&lt;double**, Kokkos::LayoutRight, Kokkos::DefaultDevice&gt; temperature(\n  \"temperature\", ncols, nlevs);\n</code></pre>"},{"location":"developer/kokkos_ekat/#deep-copy","title":"Deep Copy","text":"<p>Kokkos provides <code>Kokkos::deep_copy(dst, src)</code> which copies data between views of the same dimensions, or a scalar values into a view. Common uses</p> <pre><code>Kokkos::deep_copy(view0, view1); // Copy all data from view1 into view0\nKokkos::deep_copy(view0, 5); // Set all values of view0 to 5\n</code></pre> <p>As seen in the next section, we can use <code>deep_copy()</code> to copy data between host and device.</p>"},{"location":"developer/kokkos_ekat/#mirror-views","title":"Mirror Views","text":"<p>We will often need to have memory allocation the resides on device (for computation), and then need that identical data on host (say, for output). Kokkos has a concept of mirror views, where data can be copied from host to device and vice versa.</p> <p>Here is an example using the device view <code>temperature</code> from above</p> <pre><code>// Allocate view on host that exactly mirrors the size of layout of the device\nview\nauto host_temperature = Kokkos::create_mirror_view(temperature);\n\n// Copy all data from device to host\nKokkos::deep_copy(host_temperature, temperature);\n</code></pre> <p>Kokkos also offers an all-in-one option</p> <pre><code>// Note: must hand the host device instance as first argument\nauto host_temperature = Kokkos::create_mirror_view_and_copy(\n  Kokkos::DefaultHostDevice(), temperature);\n</code></pre>"},{"location":"developer/kokkos_ekat/#parallel-execution","title":"Parallel Execution","text":"<p>The most basic parallel execution pattern used by EAMxx is the <code>Kokkos::parallel_for</code> which defines a for-loop with completely independent iterations. The <code>parallel_for</code> takes in an optional label for debugging, an execution policy, which defines a range and location (host or device) for the code to be run, and a lambda describing the body of code to be executed. The following are execution policies used in EAMxx</p> <ul> <li><code>int count</code>: 1D iteration range <code>[0, count)</code></li> <li><code>RangePolicy&lt;ExecSpace&gt;(int beg, int end)</code>: 1D iteration range for indices   <code>[beg, end)</code></li> <li><code>MDRangePolicy&lt;ExecSpace, Kokkos::Rank&lt;N&gt;&gt;(int[N] beg, int[N] end)</code>: multi-   dimensional iteration range <code>[beg, end)</code></li> <li><code>TeamPolicy&lt;ExecSpace&gt;(int league_size, int team_size, int vector_size)</code>: 1D   iteration over <code>league_size</code>, assigned to thread teams of size <code>team_size</code>,   each with <code>vector_size</code> vector lanes. Both <code>team_size</code> and <code>vector_size</code> can   be given <code>Kokkos::AUTO</code> as input for Kokkos to automatically compute.</li> </ul> <p>If no <code>ExecSpace</code> template is given, the default execution space is used.</p> <p>For lambda capture, use <code>KOKKOS_LAMBDA</code> macro which sets capture automatically based on architecture.</p> <p>Example using <code>RangePolicy</code> to initialize a view</p> <pre><code>Kokkos::View&lt;double**, Kokkos::LayoutRight&gt; temperature(\"temperature\", ncols,\n                            nlevs);\nKokkos::parallel_for(\"Init_temp\",\n           Kokkos::RangePolicy(0, ncols*nlevs),\n           KOKKOS_LAMBDA (const int idx) {\n  int icol = idx/nlevs;\n  int ilev = idx%nlevs;\n\n  temperature(icol, ilev) = 0;\n});\n</code></pre> <p>Same example with <code>TeamPolicy</code></p> <pre><code>Kokkos::parallel_for(\"Init_temp\",\n           Kokkos::TeamPolicy(ncols*nlevs, Kokkos::AUTO, Kokkos::AUTO),\n           KOKKOS_LAMBDA (const TeamPolicy::member_type&amp; team) {\n  // league_rank() gives the index for this team\n  int icol = team.league_rank()/nlevs;\n  int ilev = team.league_rank()%nlevs;\n\n  temperature(icol, ilev) = 0;\n});\n</code></pre>"},{"location":"developer/kokkos_ekat/#hierarchical-parallelism","title":"Hierarchical Parallelism","text":"<p>Using <code>TeamPolicy</code>, we can have up to three nested levels of parallelism: team parallelism, thread parallelism, vector parallelism. These nested policies can be called within the lambda body using the following execution policies</p> <ul> <li><code>TeamThreadRange(team, begin, end)</code>: execute over threads of a team</li> <li><code>TeamVectorRange(team, begin, end)</code>: execute over threads and vector lanes of   a team</li> <li><code>ThreadVectorRange(team, begin, end)</code>: execute over vector lanes of a thread</li> </ul> <p>An example of using these policies</p> <pre><code>Kokkos::View&lt;double***&gt; Q(\"tracers\", ncols, ntracers, nlevs);\nKokkos::parallel_for(Kokkos::TeamPolicy(ncols, Kokkos::AUTO),\n           KOKKOS_LAMBDA (TeamPolicy::member_type&amp; team) {\n  int icol = team.league_rank();\n  Kokkos::parallel_for(Kokkos::TeamVectorRange(team, nlevs), [&amp;](int ilev) {\n  temperature(icol, ilev) = 0;\n  });\n\n  Kokkos::parallel_for(Kokkos::TeamThreadRange(team, nlevs), [&amp;](int ilev) {\n  Kokkos::parallel_for(Kokkos::ThreadVectorRange(team, ntracers), [&amp;](int iq) {\n    Q(icol, iq, ilev) = 0;\n  });\n  });\n});\n</code></pre> <p>IMPORTANT! Nested policies cannot be used in arbitrary order. <code>ThreadVectorRange</code> must be used inside a <code>TeamThreadRange</code>, and <code>TeamVectorRange</code> must be the only level of nested parallelism.</p> <pre><code>Kokkos::parallel_for(TeamPolicy(...), ... {\n   // OK\n   Kokkos::parallel_for(TeamThreadRange, ... {\n\n   });\n\n   // OK\n   Kokkos::parallel_for(TeamThreadRange, ... {\n   Kokkos::parallel_for(ThreadVectorRange, ... {\n\n   });\n   });\n\n   // OK\n   Kokkos::parallel_for(TeamVectorRange, ...{\n\n   });\n\n   // WRONG,ThreadVectorRange must be nested in TeamThreadRange\n   Kokkos::parallel_for(ThreadVectorRange, ...{\n\n   });\n\n   // WRONG, a TeamVectorRange must be the only nested level\n   Kokkos::parallel_for(TeamVectorRange, ...{\n   Kokkos::parallel_for(ThreadVectorRange, ... {\n\n   });\n   });\n});\n</code></pre> <p>Using these incorrectly can be very tricky to debug as the code almost certainly will not error out, but race conditions will exist among threads.</p>"},{"location":"developer/kokkos_ekat/#ekat","title":"EKAT","text":""},{"location":"developer/kokkos_ekat/#kokkostypes","title":"KokkosTypes","text":""},{"location":"developer/kokkos_ekat/#exespaceutils","title":"ExeSpaceUtils","text":""},{"location":"developer/kokkos_ekat/#vectorization-packs","title":"Vectorization: Packs","text":""},{"location":"developer/kokkos_ekat/#scratch-memory-worspacemanager","title":"Scratch Memory: WorspaceManager","text":""},{"location":"developer/kokkos_ekat/#algorithms","title":"Algorithms","text":""},{"location":"developer/managers/","title":"FieldManager and GridsManager","text":""},{"location":"developer/processes/","title":"Atmospheric Processes","text":"<p>In EAMxx, <code>AtmosphereProcess</code> (AP) is an abstract class representing a portion of the atmosphere timestep algorithm. In simple terms, an AP is an object that given certain input fields performs some calculations to compute some output fields. The concrete AP classes allow to create a buffer layer between particular packages (e.g., dynamics dycore, physics parametrizations) and the atmosphere driver (AD), allowing separation of concerns, so that the AD does not need to know details about the package, and the package does not need to know about the EAMxx infrastructure.</p> <p>To enhance this separation of concerns, EAMxx implements two more classes for handling APs:</p> <ul> <li>the concrete class <code>AtmosphereProcessGroup</code> (APG), which allows to group   together a set of AP's, which can be seen from outside as a single process;</li> <li>the <code>AtmosphereProcessFactory</code> class, which allows an APG to create its   internal processes without any knowledge of what they are.</li> </ul> <p>This infrastructure allows the AD to view the whole atmosphere as a single APG, and to be completely agnostic to what processes are run, and in which order. This design allows to have a code base that is cleaner, self-container, and easy to test via a battery of targeted unit tests.</p> <p>In EAMxx, we already have a few concrete AP's, interfacing the AD to the Hommexx non-hydrostatic dycore as well as some physics parametrizations (P3, SHOC, RRMTPG, etc). In the next section we describe the interfaces of an AP class, and we show an example of how to write a new concrete AP class.</p>"},{"location":"developer/processes/#atmosphere-process-interfaces","title":"Atmosphere process interfaces","text":"<p>An AP has several interfaces, which can be grouped into three categories:</p> <ul> <li>initialization: these interfaces are used to create the AP, as well as to   initialize internal data structures;</li> <li>run: these interfaces are used to make the AP compute its output fields from   its input fields;</li> <li>finalization: these interfaces are used to perform any clean up operation   (e.g., release files) before the AP is destroyed.</li> </ul> <p>Among the above, the initialization sequence is the most complex, and consists of several steps:</p> <ul> <li>The AD creates the APG corresponding to the whole atmosphere. As mentioned   above, this phase will make use of a factory, which allows the AD to be   agnostic to what is actually in the group. All AP's can start performing any   initialization work that they can, but at this point they are limited to use   only an MPI communicator as well as a list of runtime parameters (which were   previously read from an input file).</li> <li>The AD passes a <code>GridsManager</code> to the AP's, so that they can get information   about the grids they need. At this point, all AP's have all the information   they need to establish the layout of the input and output fields they need,   and can store a list of these \"requests\"</li> <li>After creating all fields (based on AP's requests), the AD passes a copy of   each input and output field to the AP's. These fields will be divided in   \"required\" and \"computed\", which differ in that the former are only passed   to the AP's as 'read-only' fields (see the field   documentation for more details)</li> <li>The AP's are queried for how much scratch memory they may need at run time.   After all AP's communicate their needs, the AD will provide a pointer to   scratch memory to the AP's. This is memory that can be used to initialize   temporary views/fields or other internal data structures. All AP's are given   the same pointer, which means no data persistence should be expected at run   time between one timestep and the next.</li> <li>The AD calls the 'initialize' method on each AP. At this point, all fields   are set, and AP's can complete any remaining initialization task</li> </ul> <p>While the base AP class provides an (empty) implementation for some methods, in case derived classes do not need a feature, some methods are purely virtual, and concrete classes will have to override them. Looking at existing concrete AP implementations is a good way to have a first idea of what a new AP class needs to implement. Here, we show go over the possible implementation of these methods in a hypothetical AP class. The header file may look something like this</p> <pre><code>#include &lt;share/atm_process/atmosphere_process.hpp&gt;\n\nclass MyProcess : public AtmosphereProcess\n{\npublic:\n  using gm_ptr = std::shared_ptr&lt;const GridsManager&gt;;\n\n  MyProcess(const ekat::Comm&amp; comm, const ekat::ParameterList&amp; pl);\n\n  std::string name () const override { return \"my_fancy_process\"; }\n  void set_grids (const gm_ptr&amp; grids_manager) override;\n  size_t requested_buffer_size_in_bytes () const override;\n  void init_buffers (const ATMBufferManager&amp; buffer_manager) override;\nprotected:\n\n  void initialize_impl (const RunType run_type) override;\n  void run_impl        (const double dt) override;\n  void finalize_impl   () override;\n\n  using view_1d = typename KokkosTypes&lt;DefaultDevice&gt;::view_1d&lt;Real&gt;;\n  using view_2d = typename KokkosTypes&lt;DefaultDevice&gt;::view_2d&lt;Real&gt;;\n\n  view_1d m_temp1;\n  view_2d m_temp2;\n\n  int m_ncols;\n  int m_nlevs;\n  bool m_has_blah;\n};\n</code></pre> <p>A few comments:</p> <ul> <li>we added two views to the class, which are meant to be used to store   intermediate results during calculations at runtime;</li> <li>there are other methods that the class can override (such as additional   operations when the AD sets a field in the AP), but most AP's only need to   override only these;</li> <li>we strongly encourage to add the keyword <code>override</code> when overriding a method;   in case of small typos (e.g., missing a <code>&amp;</code> or a <code>const</code>, the compiler will   be erroring out, since the signature will not match any virtual method in the   base class;</li> <li><code>finalize_impl</code> is often empty; unless the AP is managing external resources,   everything should be correctly released during destruction;</li> <li>the two methods for buffers can be omitted if the AP does not need any   scratch memory (and the default implementation from the base class will be   used).</li> </ul> <p>Here is a possible implementation of the methods, with some inline comments to explain</p> <pre><code>MyProcess::MyProcess (const ekat::Comm&amp; comm, const ekat::ParameterList&amp; pl)\n : AtmosphereProcess(comm,pl)\n{\n  // The base class copies pl into protected member m_params\n  m_has_blah = m_params.get&lt;bool&gt;(\"enable_blah\");\n}\n\nvoid MyProcess::set_grids (const std::shared_ptr&lt;GridsManager&gt;&amp; gm)\n{\n  using namespace ekat::units;\n  const auto nondim = Units::nondimensional();\n\n  auto grid = gm-&gt;get_grid(\"Physics\");\n  m_ncols = grid-&gt;get_num_local_dofs();\n  m_nlevs = grid-&gt;get_num_vertical_levels();\n\n  // In these names, 2d refers to \"horizontal only\", while 3d to \"horiz+vert\".\n  // But the grid stores dofs linearly, so there is only one array dimension\n  FieldLayout scalar2d = grid-&gt;get_2d_scalar_layout();\n  FieldLayout vector3d = grid-&gt;get_3d_vector_layout(true,2);\n\n  // Declare fields needed:\n  //  - Required: 'input' (read-only)\n  //  - Computed: 'output'\n  //  - Updated: 'input'+'output'\n  // Tell the AD we need 'velocity' to accommodate a Pack scalar type\n  add_field&lt;Required&gt;(\"coeff_2d\",scalar2d,nondim,grid-&gt;name);\n  add_field&lt;Updated&gt;(\"velocity\",vector3d,m/s,grid-&gt;name,SCREAM_PACK_SIZE);\n}\n\nsize_t MyProcess::requested_buffer_size_in_bytes ()\n{\n  // We use temp2 only if the blah feature is on\n  return m_ncols + (m_has_blah ? m_ncols*m_nlev : 0);\n}\n\nvoid MyProcess::init_buffers (const ATMBufferManager&amp; buffer_manager)\n{\n  auto mem = reinterpret_cast&lt;Real*&gt;(buffer_manager.get_memory());\n\n  m_temp1 = view_1d&lt;Real&gt;(mem,m_ncols);\n  mem += m_ncols;\n\n  if (m_has_blah) {\n    m_temp2 = view_2d&lt;Real&gt;(mem,m_ncols,m_nlevs);\n    mem += m_ncols*m_nlevs;\n  }\n\n  // Make sure we use exactly the mem we said we would\n  size_t used_mem = (mem - buffer_manager.get_memory())*sizeof(Real);\n  EKAT_REQUIRE_MSG(used_mem==requested_buffer_size_in_bytes(),\n    \"Error! Used memory != requested memory for MyProcess.\"\n    \"  used memory: \" + std::to_string(used_mem) + \"\\n\"\n    \"  requested: \" + std::to_string(requested_buffer_size_in_bytes()) + \"\\n\");\n}\n\nvoid MyProcess::initialize_impl(const RunType run_type)\n{\n  // Can complete any initialization of the background pkg\n  my_process_pkg_init(m_has_blah);\n}\n\nvoid MyProcess:run_impl (const double dt)\n{\n  using Policy = typename KokkosTypes&lt;DefaultDevice&gt;::TeamPolicy\n  using Member = typename KokkosTypes&lt;DefaultDevice&gt;::MemberType\n  using PackT  = ekat::Pack&lt;Real,SCREAM_PACK_SIZE&gt;;\n\n  // Create team policy\n  Policy policy(m_ncols,m_nlevs,1);\n\n  // Create local copies of class members (or else use KOKKOS_CLASS_LAMBDA)\n  auto temp1 = m_temp1;\n  auto temp2 = m_temp2;\n  auto do_blah = m_has_blah;\n\n  // Get views from fields. We \n  auto coeff2d  = get_field_in(\"coeff_2d\").get_view&lt;const Real*&gt;();\n  auto velocity = get_field_out(\"velocity\").get_view&lt;PackT**&gt;();\n\n  // Since we process velocity with a Pack scalar type, find out how many packs\n  // we have in each column\n  auto nlevs_packs = ekat::PackInfo&lt;SCREAM_PACK_SIZE&gt;::num_packs(m_nlevs);\n\n  // Call some function in the background pkg\n  do_some_work (coeff_2d,velocity,temp1,temp2,do_blah);\n\n  // Do some more work here\n  auto work = KOKKOS_LAMBDA (const Member&amp; team) {\n    int icol = team.league_rank();\n    auto col_work = [&amp;](const int ilev) {\n      velocity(icol,ilev) *= coeff_2d;\n    };\n    Kokkos::parallel_for(Kokkos::TeamVectorRange(team,nlevs_packs),col_work);\n  };\n  Kokkos::parallel_for(policy,work);\n  Kokkos::fence();\n}\n\nvoid MyProcess::finalize_impl ()\n{\n  // If the background package needs to cleanup something, do it now\n  my_process_pkg_cleanup();\n}\n</code></pre>"},{"location":"developer/source_tree/","title":"EAMxx's Source Tree","text":"<p>All EAMxx-specific code can be found in <code>components/eamxx</code> within the EAMxx repo. Here's how things are organized:</p> <ul> <li><code>cime_config</code>: Tools and XML files for integrating EAMxx with E3SM via the   CIME framework.</li> <li><code>cmake</code>: CMake functions and macros used by the configuration/build system.</li> <li><code>data</code>: Data files used by our tests.</li> <li><code>docs</code>: Documentation for the EAMxx project, including design documents,   instructions for building and testing EAMxx, and this document.</li> <li><code>scripts</code>: Miscellaneous scripts that implement workflows for running tests   and analyzing performance.</li> <li><code>src</code>: All C++ source code (and any bridges to Fortran) for EAMxx are stored   here. We describe the contents of this directory in greater detail below.</li> <li><code>tests</code>: Implements standalone, end-to-end tests for various EAMxx   components (RRTMG, HOMME, P3, SHOC, etc).</li> </ul> <p>In addition, you'll notice the following files in <code>components/eamxx</code>:</p> <ul> <li><code>CMakeLists.txt</code>: The CMake file that defines EAMxx's configuration/build   system.</li> <li><code>CTestConfig.cmake</code>: This CTest file contains parameters that determine how   our test results are reported to the E3SM CDash Site.</li> <li><code>README.md</code>: EAMxx's top-level README file, which describes the project and   its purpose.</li> <li><code>mkdocs.yml</code>: The configuration file for mkdocs,   the tool we currently use to build and publish our documentation.</li> </ul>"},{"location":"developer/source_tree/#the-src-directory","title":"The <code>src</code> Directory","text":"<p>Herein l\u0456es the source code for EAMxx. Broadly, here's where things are:</p> <ul> <li><code>control</code>: Contains the atmosphere driver and basic tests for it.</li> <li><code>dynamics</code>: Here's where HOMME lives within EAMxx, along with code for   interfacing with it using EAMxx's data structures.</li> <li><code>mct_coupling</code>: Glue code for embedding EAMxx within E3SM as an atmosphere   component using the MCT coupler.</li> <li><code>physics</code>: Source code for physics-related atmospheric processes, including</li> <li><code>p3</code>: The C++/Kokkos implementation of P3 microphysics within EAMxx.</li> <li><code>shoc</code>: The C++/Kokkos implementation of SHOC macrophysics within EAMxx.</li> <li><code>rrtmgp</code>: A stub for the radiation processes as represented in EAMxx.</li> <li><code>share</code>: Utilities and data structures common to these processes.</li> <li><code>share</code>: Utilities used by various components within EAMxx. Of note:</li> <li><code>io</code>: EAMxx's interface to the SCORPIO     library.</li> <li><code>diagnostics</code>: A collection of simple classes used to compute diagnostic   quantities.</li> </ul> <p>Each of these directories contains a <code>CMakeLists.txt</code> file for defining how things are build, and a <code>tests/</code> subdirectory that houses relevant unit and verification tests.</p> <p>You'll also see some other files in the <code>src/</code> directory itself, such as</p> <ul> <li><code>scream_config.h.in</code>: A template for generating a C++ header file with   EAMxx configuration information.</li> </ul>"},{"location":"developer/standalone_testing/","title":"Standalone EAMxx Testing","text":"<p>In this section we describe our testing methodology for standalone EAMxx configurations. We use several types of tests</p> <ul> <li>Unit tests are individual test programs that demonstrate that a small set   of code performs a single function or a set of related functions. We use   a C++ unit testing framework called Catch2   to implement unit tests.</li> <li>Property (verification) tests are test programs that configure code that   demonstrates that a part of EAMxx (for example, an atmospheric physics   parameterization or the dynamical core) is able to produce an answer that   satisfies some physical constraint or matches a known solution under specific   circumstances.</li> <li>Fortran-C++ \"bit-for-bit\" (BFB) tests are test programs, often implemented   as unit tests, that demonstrate that a set of C++ code ported from Fortran   produces bit-for-bit identical results to its Fortran counterpart, provided   certain compiler options are enabled (such as \"strict\" floating-point   arithmetic).</li> <li>Test Suites are named collections of tests that can be run on demand using   the ctest command.</li> </ul> <p>We also support a <code>test-all-scream</code> configuration that runs all of the standalone tests for an EAMxx configuration. Note, your current machine must be known to EAMxx before <code>test-all-scream</code> will work. A machine can be made known to EAMxx by editing the eamxx/scripts/machines_specs.py files. There are some instructions on what to do at the top of this file.</p> <p><code>test-all-scream</code> has a good help dump</p> <pre><code>cd $scream_repo/components/eamxx\n./scripts/test-all-scream -h\n</code></pre> <p>If you are unsure of the cmake configuration for you development cycle, one trick you can use is to run <code>test-all-scream</code> for the <code>dbg</code> test and just copy the cmake command it prints (then ctrl-C the process).</p> <pre><code>cd $scream_repo/components/eamxx\n./scripts/test-all-scream -t dbg -m $machine\n# wait for a few seconds*\n# Ctrl-C *\n# Copy the contents of DCMAKE_COMMAND that was passed to ctest *\n# Add \"cmake\" to beginning of contents and path to eamxx at the end. *\n</code></pre> <p>Considerations for using <code>test-all-scream</code>:</p> <ul> <li>Your machine must be known to our scripts, see above.</li> <li>If you try to run commands by-hand (outside of test-all-scream;   cmake, make, ctest, etc), you'll need to remember to   load the scream-env into your shell, which can be done like this:   <code>cd eamxx/scripts; eval $(./scripts/scream-env-cmd $machine)</code></li> <li>test-all-scream expects to be run from a compute node if you   are on a batch machine.</li> <li>You'll need to think about your baseline situation, as many of our   tests rely on pre-existing baselines. The -b option controls the baseline   location and can have the following values:</li> <li>AUTO: A common public baseline area shared by all developers</li> <li>LOCAL: A private baseline area for the current developer in the current repo</li> <li>$path: A specific arbitrary path</li> <li>None: If there is no -b at all, no baseline testing will be done</li> </ul>"},{"location":"developer/standalone_testing/#running-eamxxs-tests-with-ctest","title":"Running EAMxx's Tests with CTest","text":"<p>Before running the tests, generate a baseline file:</p> <pre><code>cd $RUN_ROOT_DIR\nmake baseline\n</code></pre> <p>The tests will run, automatically using the baseline file, which is located in the CMake-configurable path <code>${SCREAM_BASELINES_DIR}</code>. By default, this path is set to an invalid string. If baselines tests are enabled, we check that a valid path has been provided.</p> <p>To run all of SCREAM's tests, make sure you're in <code>$RUN_ROOT_DIR</code> and type</p> <pre><code>ctest -VV\n</code></pre> <p>This runs everything and reports results in an extra-verbose (<code>-VV</code>) manner.</p> <p>You can also run subsets of the SCREAM tests. For example, to run only the P3 regression tests (again, from the <code>$RUN_ROOT_DIR</code> directory), use</p> <pre><code>ctest -R p3_regression\n</code></pre>"},{"location":"developer/standalone_testing/#grouping-tests-with-labels","title":"Grouping Tests with Labels","text":"<p>We can create groupings of tests by using labels. For example, we have a <code>driver</code> label that runs tests for SCREAM's standalone driver. You can see a list of available labels by typing</p> <pre><code>ctest --print-labels\n</code></pre> <p>To see which tests are associated with a given label (e.g. <code>driver</code>), use</p> <pre><code>ctest -L driver -N\n</code></pre>"},{"location":"developer/standalone_testing/#eamxx-test-suites","title":"EAMxx Test Suites","text":""},{"location":"developer/standalone_testing/#the-p3_regression-suite","title":"The <code>p3_regression</code> Suite","text":"<p><code>p3_regression</code> uses a baseline file to compare any new or altered implementations with our P3 Fortran reference implementation. If you're working on the C++/Kokkos implementation, you can invoke any new tests to the function <code>Baseline::run_and_cmp</code> in <code>${SCREAM_SRC_DIR}/components/eamxx/p3/tests/p3_run_and_cmp.cpp</code>.</p> <p>If the reference Fortran implementation changes enough that a new baseline file is required, make sure to let other SCREAM team members know, in order to minimize disruptions.</p>"},{"location":"developer/style_guide/","title":"SCREAM C++ Style Guide","text":"<p>Here's our style guide. Let the holy wars begin!</p>"},{"location":"developer/style_guide/#types","title":"Types","text":""},{"location":"developer/style_guide/#functions-and-methods","title":"Functions and Methods","text":""},{"location":"developer/style_guide/#variables","title":"Variables","text":""},{"location":"technical/","title":"EAMxx Technical Guide","text":"<p>The goal of this document is to describe the specific equations, parameterizations, and numerical methods used in the current version of EAMxx. Because our master-branch implementation changes every time we make a new commit, this documentation will also evolve continuously. As such, documentation for master should always be considered to be preliminary and under construction. If you want trustworthy documentation, pull it from an official model release.</p>"},{"location":"technical/#overview","title":"Overview","text":"<p>Currently, EAMxx is only configured for km-scale convection-permitting runs. In order to provide scientifically-credible simulations at lower resolution, parameterizations for the following processes would be needed:</p> <ol> <li>deep convection</li> <li>gravity-wave drag</li> <li>energy fixer</li> </ol> <p>The only configuration of EAMxx that is currently implemented is the convection-permitting version, commonly known as the Simple Cloud-Resolving E3SM Atmosphere Model (SCREAM). Processes in EAMxx-SCREAM are:</p> <ol> <li>a non-hydrostatic version of the spectral-element dynamical core used by other E3SM Atmosphere Model versions<sup>1</sup> with semi-Lagrangian tracer advection as described by Bradley et al. (2022)<sup>2</sup></li> <li>turbulent mountain stress is crudely parameterized following Fiedler and Panofsky (1072)<sup>3</sup> to reduce excessive winds around topography</li> <li>the Simple Higher-Order Closure (SHOC) parameterization from Bogenschutz and Krueger (2013)[@Bogenschutz_Krueger13], which handles turbulent diffusion, condensation/evaporation, and liquid cloud fraction</li> <li>an all-or-nothing ice cloud fraction parameterization that sets ice cloud fraction to 100% whenever cloud ice mass q<sub>i</sub> is less than a user-specified threshold set by default to 1e-5 kg/kg. This scheme also sets the total cloud fraction (used by microphysics) to the maximum of the liquid and ice cloud fraction.</li> <li>the effects of aerosol are prescribed via the Simple Prescribed Aerosol (SPA) scheme, which is very similar to MACv2-SP<sup>4</sup></li> <li>the P3 microphysics scheme from Morrison and Milbrandt (2015)<sup>5</sup> modified as described by Caldwell et al. (2021)<sup>6</sup> to assume instantaneous liquid saturation adjustment for consistency with SHOC</li> <li>RTE/RRTMGP radiation from Pincus et al. (2019)<sup>7</sup> rewritten in C++ for consistency and performance</li> <li>the CFMIP Observation Simulator Package (COSP) is also integrated into EAMxx, but currently only the ISCCP output is enabled</li> </ol> <p>By default processes are called in this order, but which processes to include and in what order is modifiable at run time. After all atmospheric processes are called, output is written.  Surface components are then called before the next atmosphere step starts. These processes are described in more detail in Caldwell et al. (2021)<sup>6</sup>.  As in EAM, dynamics operates on a spectral element grid and all other processes use a finite-volume grid that divides each spectral element into 4 quadrilaterals. This physics grid is described in Hannah et al. (2021)<sup>8</sup>.</p> <ol> <li> <p>Mark A. Taylor, Oksana Guba, Andrew Steyer, Paul A. Ullrich, David M. Hall, and Christopher Eldred. An energy consistent discretization of the nonhydrostatic equations in primitive variables. Journal of Advances in Modeling Earth Systems, 12(1):e2019MS001783, 2020. e2019MS001783 10.1029/2019MS001783. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2019MS001783, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2019MS001783, doi:https://doi.org/10.1029/2019MS001783.\u00a0\u21a9</p> </li> <li> <p>A. M. Bradley, P. A. Bosler, and O. Guba. Islet: interpolation semi-lagrangian element-based transport. Geoscientific Model Development, 15(16):6285\u20136310, 2022. URL: https://gmd.copernicus.org/articles/15/6285/2022/, doi:10.5194/gmd-15-6285-2022.\u00a0\u21a9</p> </li> <li> <p>F. Fiedler and H. A. Panofsky. The geostrophic drag coefficient and the \u2018effective\u2019 roughness length. Quarterly Journal of the Royal Meteorological Society, 98(415):213\u2013220, 1972. URL: https://rmets.onlinelibrary.wiley.com/doi/abs/10.1002/qj.49709841519, arXiv:https://rmets.onlinelibrary.wiley.com/doi/pdf/10.1002/qj.49709841519, doi:https://doi.org/10.1002/qj.49709841519.\u00a0\u21a9</p> </li> <li> <p>B. Stevens, S. Fiedler, S. Kinne, K. Peters, S. Rast, J. M\u00fcsse, S. J. Smith, and T. Mauritsen. Macv2-sp: a parameterization of anthropogenic aerosol optical properties and an associated twomey effect for use in cmip6. Geoscientific Model Development, 10(1):433\u2013452, 2017. URL: https://gmd.copernicus.org/articles/10/433/2017/, doi:10.5194/gmd-10-433-2017.\u00a0\u21a9</p> </li> <li> <p>Hugh Morrison and Jason A. Milbrandt. Parameterization of cloud microphysics based on the prediction of bulk ice particle properties. part i: scheme description and idealized tests. Journal of the Atmospheric Sciences, 72(1):287 \u2013 311, 2015. URL: https://journals.ametsoc.org/view/journals/atsc/72/1/jas-d-14-0065.1.xml, doi:10.1175/JAS-D-14-0065.1.\u00a0\u21a9</p> </li> <li> <p>P. M. Caldwell, C. R. Terai, B. Hillman, N. D. Keen, P. Bogenschutz, W. Lin, H. Beydoun, M. Taylor, L. Bertagna, A. M. Bradley, T. C. Clevenger, A. S. Donahue, C. Eldred, J. Foucar, J.-C. Golaz, O. Guba, R. Jacob, J. Johnson, J. Krishna, W. Liu, K. Pressel, A. G. Salinger, B. Singh, A. Steyer, P. Ullrich, D. Wu, X. Yuan, J. Shpund, H.-Y. Ma, and C. S. Zender. Convection-permitting simulations with the e3sm global atmosphere model. Journal of Advances in Modeling Earth Systems, 13(11):e2021MS002544, 2021. e2021MS002544 2021MS002544. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2021MS002544, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2021MS002544, doi:https://doi.org/10.1029/2021MS002544.\u00a0\u21a9\u21a9</p> </li> <li> <p>Robert Pincus, Eli J. Mlawer, and Jennifer S. Delamere. Balancing accuracy, efficiency, and flexibility in radiation calculations for dynamical models. Journal of Advances in Modeling Earth Systems, 11(10):3074\u20133089, 2019. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2019MS001621, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2019MS001621, doi:https://doi.org/10.1029/2019MS001621.\u00a0\u21a9</p> </li> <li> <p>Walter M. Hannah, Andrew M. Bradley, Oksana Guba, Qi Tang, Jean-Christophe Golaz, and Jon Wolfe. Separating physics and dynamics grids for improved computational efficiency in spectral element earth system models. Journal of Advances in Modeling Earth Systems, 13(7):e2020MS002419, 2021. e2020MS002419 2020MS002419. URL: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2020MS002419, arXiv:https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2020MS002419, doi:https://doi.org/10.1029/2020MS002419.\u00a0\u21a9</p> </li> </ol>"},{"location":"technical/aerocom_cldtop/","title":"The AeroCom algorithm","text":"<p>The goal of the AeroCom algorithm is to calculate properties at cloud top based on the AeroCom recommendation. There are two main parts of the algorithm: probabilistically determining \"cloud top\" and then \"calculating properties\" at said cloud top.</p> <p>We treat model columns independently, so we loop over all columns in parallel. We then loop over all layers in serial (due to needing an accumulative product), starting at 2 (second highest) layer because the highest is assumed to have no clouds. Let's take a photonic approach from above the model top. Let's say that \\(p_{k}\\) is the probability of a photon passing through the layer \\(k\\). We follow the maximum-random overlap assumption. In all cases, we assume the cloudiness (or cloudy fraction) is completely opaque.</p> <p>We assume the highest layer has no clouds, thus the \\(p_{k} = 1\\) for the highest layer. Note that \\(p_{k}\\) is initialized as 1 for all layers. We also clip the cloudy fraction \\(C_{i,k}\\) to ensure that \\(C_{i,k} \\in [0+\\epsilon, 1-\\epsilon]\\), where \\(\\epsilon = 0.001\\). Starting at the second highest layer, \\(k+1\\), we check if some \"cloudy\" conditions are met. These conditions are now arbitrarily defined by a cloudiness threshold of \\(\\epsilon\\) (i.e., \\(C_{i,k}&gt;\\epsilon\\)) and a non-zero threshold on the total (both liquid and ice) droplet number concentration (i.e., \\(cQ_{i,k} + iQ_{i,k} &gt; 0\\)). If the conditions are met, we estimate the cloud-top cloud fraction using an accumulative product following the maximum-random overlap assumption.</p> \\[c_{i} = 1 - \\prod_{k=2}^{K} p_{k} = 1 - \\prod_{k=2}^{K} \\frac{1 - \\max(C_{i,k}, C_{i,k-1})}{1-C_{i,k-1}}\\] <p>In order to estimate cloud-top properties, we weight by the probability of \"remaining cloudiness\" or \\(p_{k-1} - p_{k}\\).</p> Type Equation cloud property \\(x_{i} = \\sum_{k=2}^{K} X_{i,k} \\Phi_{i,k} (p_{k-1} - p_{k})\\) cloud content \\(x_{i} = \\sum_{k=2}^{K} \\Phi_{i,k} (p_{k-1} - p_{k})\\) other property \\(x_{i} = \\sum_{k=2}^{K} X_{i,k} (p_{k-1} - p_{k})\\) <p>In the above, \\(\\Phi_{i,k}\\) is the thermodynamic phase defined by the cloud droplet number concentration ratios.</p> \\[i\\Phi_{i,k} = \\frac{iQ_{i,k}}{iQ_{i,k} + cQ_{i,k}}\\] \\[c\\Phi_{i,k} = \\frac{cQ_{i,k}}{iQ_{i,k} + cQ_{i,k}}\\] <p>The thermodynamic phase is used only for cloud properties (e.g., cloud-top cloud droplet number concentration) or cloud content (e.g., cloud liquid content). Further, \\(X_{i,k}\\) is the three-dimensional cloud property of interest which is needed if we are converting a property from three-dimensional (\\(X\\)) to its two-dimensional counterpart (\\(x\\)). \"Other\" properties here include temperature and pressure which are not dependent on the thermodynamic phase.</p> <p>Most studies in this topic refer a technical report by Tiedtke et al. (1979)<sup>1</sup>. Another more recent general reference that may be of interest is that of R\u00e4is\u00e4nen et al. (2004)<sup>2</sup>.</p> <ol> <li> <p>M. Tiedtke, J.-F. Geleyn, A. Hollingsworth, and J.-F. Louis. ECMWF model parameterisation of sub-grid scale processes. Technical Report, ECMWF, Shinfield Park, Reading, January 1979. 10.\u00a0\u21a9</p> </li> <li> <p>Petri R\u00e4is\u00e4nen, Howard W Barker, Marat F Khairoutdinov, Jiangnan Li, and David A Randall. Stochastic generation of subgrid-scale cloudy columns for large-scale models. Quarterly Journal of the Royal Meteorological Society: A journal of the atmospheric sciences, applied meteorology and physical oceanography, 130(601):2047\u20132067, 2004.\u00a0\u21a9</p> </li> </ol>"},{"location":"user/","title":"SCREAM User Guide","text":"<p>This section contains documentation on how to create, setup, and run CIME cases with EAMxx as the atmosphere component. It is assumed that the reader has a familiarity with CIME case control system. In particular, we assume that the user knows how to create a case, and what the <code>case.setup</code>, <code>case.build</code>, and <code>case.submit</code> commands do.</p> <p>This user guide is still under construction. In the meantime, in case you can't find the information you need, you may visit our public confluence EAMxx user guide.</p>"},{"location":"user/clean_clear_sky/","title":"Clean- and clean-clear-sky diagnostics","text":"<p>In order to decompose the aerosol effective radiative forcing, additional diagnostic radiation calls are needed. These extra diagnostics are optionally added to the main radiation call. The extra diagnostics are:</p> <ul> <li>Clean-clear-sky fluxes: the fluxes that would be present if there were neither aerosols nor clouds, and are calculated by adding an additional radiation call at the very beginning of the logic before the optics class is endowed with aerosol and cloud properties.</li> <li>Clean-sky fluxes: the fluxes that would be present if there were no aerosols, and are calculated by adding an additional radiation call after substantiating an additional optics class, but not endowing it with aerosol properties.</li> </ul>"},{"location":"user/clean_clear_sky/#example-setup-current-as-of-april-2024","title":"Example setup (current as of April 2024)","text":"<p>The extra calls are controlled by runtime flags <code>extra_clnclrsky_diag</code> and <code>extra_clnsky_diag</code> (they take either <code>true</code> or <code>false</code> as their values).</p> <pre><code>    ./atmchange extra_clnclrsky_diag=true\n    ./atmchange extra_clnsky_diag=true\n</code></pre> <p>Below is an example output file to output the extra (clean and clean-clear-sky) radiation diagnostics atop the atmosphere.</p> <pre><code>%YAML 1.1\n---\nfilename_prefix: monthly.outputs\nAveraging Type: Average\nMax Snapshots Per File: 1\nFields:\n  Physics PG2:\n    Field Names:\n    - SW_clnclrsky_flux_up_at_model_top\n    - LW_clnclrsky_flux_up_at_model_top\n    - SW_clnsky_flux_up_at_model_top\n    - LW_clnsky_flux_up_at_model_top\noutput_control:\n  Frequency: 1\n  frequency_units: nmonths\n  MPI Ranks in Filename: false\n</code></pre>"},{"location":"user/cosp/","title":"CFMIP Observation Simulator Package (COSP) in EAMxx","text":"<p>COSP is partially implemented and supported in EAMxx. Currently, minimal outputs from the ISCCP, MODIS, and MISR simulators have been enabled.</p>"},{"location":"user/cosp/#running-with-cosp","title":"Running with COSP","text":"<p>Turning COSP on simply requires adding the <code>cosp</code> process to <code>atm_procs_list</code> via <code>atmchange</code> in a case directory: <pre><code>./atmchange physics::atm_procs_list=\"mac_aero_mic,rrtmgp,cosp\"\n</code></pre> Additionally, the frequency at which COSP is run can be configured via <code>atmchange</code>: <pre><code>./atmchange physics::cosp::cosp_frequency_units=\"steps\"\n./atmchange physics::cosp::cosp_frequency=1\n</code></pre></p> <p>COSP can be run with or without subcolumn sampling. This is configured by changing the <code>cosp_subcolumns</code> namelist variable via <code>atmchange</code>. A value of 1 implies no subcolumn sampling, while values greater than 1 specify the number of subcolumns to use for subcolumn sampling (assuming maximum-random overlap). E.g., <pre><code>./atmchange physics::cosp:cosp_subcolumns=1\n</code></pre> would disable subcolumn sampling, while <pre><code>./atmchange physics::cosp::cosp_subcolumns=10\n</code></pre> would use 10 subcolumns for the COSP internal subcolumn sampling using <code>SCOPS</code>/<code>PREC_SCOPS</code>. The default for high resolution cases (e.g., ne1024) should be to not use subcolumns, while lower resolutions (e.g., ne30) should enable subcolumn sampling.</p> <p>Output streams need to be added manually. A minimal example: <pre><code>./atmchange output_yaml_files=scream_daily_output.yaml\ncat &lt;&lt; EOF &gt; scream_cosp_daily_output.yaml\nAveraging Type: Average\nFields:\n  Physics PG2:\n    Field Names:\n    - isccp_cldtot\n    - isccp_ctptau\n    - modis_ctptau\n    - misr_cthtau\n    - cosp_sunlit\nMax Snapshots Per File: 1\nfilename_prefix: eamxx\noutput_control:\n  Frequency: 1\n  frequency_units: ndays\nEOF\n</code></pre></p>"},{"location":"user/cosp/#available-output-fields","title":"Available output fields","text":"<p>The following output fields are available:</p> <ul> <li>isccp_cldtot (total cloud area from ISCCP simulator)</li> <li>isccp_ctptau (ISCCP-simulated cloud top pressure/optical depth joint histogram)</li> <li>modis_ctptau (MODIS-simulated cloud top pressure/optical depth joint histogram)</li> <li>misr_cthtau  (MISR-simulated cloud top height/optical depth joint histogram)</li> <li>cosp_sunlit  (sunlit flag aggregated at COSP frequency for renormalizing daytime averages)</li> </ul> <p>ISCCP, MODIS, and MISR outputs are valid only for daytime/sunlit columns (to be consistent with available satellite retrievals). In order to aggregate only daytime columns in time averages, these outputs are multiplied by the sunlit flag (0 or 1) at each COSP calculation time. Time averages of these quantities are then aggregated, along with the cosp sunlit flag each time COSP is called. In order to back out the daytime-only time averages from the outputs, one needs to divide the output fields by <code>cosp_sunlit</code>. E.g., <pre><code>isccp_ctptau = mean(isccp_ctptau) / mean(cosp_sunlit)\n</code></pre></p>"},{"location":"user/dp_eamxx/","title":"Doubly Periodic (DP) EAMxx","text":"<p>To run the DP configuration of EAMxx (DP-EAMxx) please refer to the official DP resource page.  At this location you will find full documentation of case descriptions and access to run scripts.  Using these scripts, you should be able to get DP-EAMxx up and running in a matter of minutes on any machine that EAMxx currently runs on (CPU or GPU).</p>"},{"location":"user/eamxx_cases/","title":"Basics of EAMxx cases","text":"<p>This section explains how to create a case which uses EAMxx as the atmosphere model, as well as what are the currently supported compsets and grids for EAMxx.</p>"},{"location":"user/model_input/","title":"Model inputs","text":"<p>This section explains how input parameters are passed to EAMxx, and how the user can change their value. The full list of the currently configuraable runtime parameters for EAMxx can be found here.</p> <p>The infrastructure for reading inputs into EAMxx involves a few scripts/files:</p> <ol> <li><code>atmchange</code> and <code>atmquery</code>: these scripts are located in <code>SRCDIR/components/eamxx/scripts</code>,     and are soft-linked in the case folder. As their names suggest, they can be used to query     and change the runtime configuration parameter of EAMxx. Since these two scripts are the     only scripts that the average user needs to know and interact with, in the next sections     we give a brief overview of how they can be used and how their output can be interpreted.     Additionally, for both of the scripts a short help can also be obtained using the <code>-h</code> flag.</li> <li> <p><code>buildnml</code>: this script, located in <code>SRCDIR/components/eamxx/cime_config</code>, is called by CIME's     case management scripts (<code>case.setup</code>, <code>case.build</code>, and <code>case.submit</code>), and is responsible for creating     the input files that EAMxx will read to load its runtime parameters. Users should not have to modify this script,     nor should they have to manually call it, but it is useful to know what it does.     When <code>buildnml</code> runs, it creates a few files, containing EAMxx input parameters:</p> <ul> <li><code>scream_input.yaml</code>: this YAML file is located in the <code>RUNDIR/data</code> folder,     and will be read by EAMxx at runtime to load all of its configuration parameters. More precisely,     this file contains parameters that need to be used inside the EAMxx interfaces.</li> <li><code>namelist.nl</code>: this namelist file is     located in the <code>RUNDIR/data</code> folder, and will be parsed at runtime to get all the parameters for the     HOMME dycore (ADD REF). This file only contains dycore-specific parameters that are only recognized     inside HOMME, and does not contain any parameter pertaining EAMxx infrastructure.</li> <li><code>namelist_scream.xml</code>: this XML file is located in the case directory, and contains all the runtime parameters that EAMxx     will read in at runtime. <code>buildnml</code> uses this XML file as an intermediate file during the generation of     <code>scream_input.yaml</code> and <code>namelist.nl</code>. More specifically, <code>buildnml</code> generates this file using case information to select the     proper configurations from the file <code>namelist_defaults_scream.xml</code>, located in <code>SRCDIR/components/eamxx/cime_config</code>.     Despite the fact that the only files that are needed at runtime are <code>scream_input.yaml</code> and <code>namelist.nl</code>,     we generate and keep this XML file around to make the implementation of <code>atmquery</code> easier.</li> </ul> <p>Since these files are automatically generated when <code>buildnml</code> runs, users should not manually modify them. Any manual modification will be lost the next time <code>buildnml</code> runs (e.g., at <code>case.submit</code> time).</p> </li> </ol>"},{"location":"user/model_input/#querying-model-inputs-atmquery","title":"Querying model inputs: atmquery","text":"<p>This script is the simplest way for the user to check the value and properties of EAMxx input parameters. A basic usage of the script is</p> <pre><code>$ ./atmquery my_param\n</code></pre> <p>which will retrieve the value of the parameter called <code>my_param</code>, by locating the XML node \"my_param\" in the file <code>namelist_scream.xml</code> in the RUNDIR folder. Obviously, an XML file can have multiple nodes with the same tag, and the script is implemented to error out if multiple matches are found. In such a scenario, the user needs to provide also the parents nodes names, using enough parents to uniquely identify the node (in most cases, one parent is enough). To specify a parent, the user can prepend the parent name and <code>::</code> to the node name:</p> <pre><code>$ ./atmquery foo::my_param\n</code></pre> <p>The output will contain the fully scoped parameter name, along with the value. E.g.,</p> <pre><code>$ ./atmquery foo::my_param\n    namelist_defaults::node1::node2::foo::my_param:   10\n</code></pre> <p>It is sometimes desirable to query all the nodes that have a particular name, or that contain a particular string. We can do that by using the <code>--grep</code> flag:</p> <pre><code>$ ./atmquery --grep sub\n    iop_options::iop_dosubsidence: false\n    ctl_nl::hypervis_subcycle: 1\n    ctl_nl::hypervis_subcycle_tom: 1\n    ctl_nl::hypervis_subcycle_q: 6\n    atmosphere_processes::number_of_subcycles: 1\n    sc_import::number_of_subcycles: 1\n    homme::number_of_subcycles: 1\n    physics::number_of_subcycles: 1\n</code></pre> <p>TODO: This difference between basic and <code>--grep</code> is not really intuitive: as pointed out in this issue, we should change this. If we do, don't forget to update this following part of the docs. Using the <code>--grep</code> option has another effect: if the match is not a leaf of the XML tree, all its subelements are printed:</p> <pre><code>$ ./atmquery --grep homme\n  homme\n      Moisture: moist\n      BfbHash: 18\n      number_of_subcycles: 1\n      enable_precondition_checks: true\n      enable_postcondition_checks: true\n      repair_log_level: trace\n      internal_diagnostics_level: 0\n      compute_tendencies: None\n</code></pre> <p>Similarly to the CIME utility <code>xmlchange</code>, the options <code>--value</code>, <code>--type</code>, <code>--valid-values</code>, and <code>--full</code> can be used to respectively retrieve just the parameter value (useful for shell scripting), the parameter's type, a list of valid values for parameter (when applicable), or all of the above:</p> <pre><code>$ ./atmquery atm_log_level --value\n    info\n$ ./atmquery atm_log_level --type\n    namelist_defaults::driver_options::atm_log_level: string\n$ ./atmquery atm_log_level --valid-values\n    namelist_defaults::driver_options::atm_log_level: ['trace', 'debug', 'info', 'warn', 'error']\n$ ./atmquery atm_log_level --full\n      namelist_defaults::driver_options::atm_log_level\n        value: info\n        type: string\n        valid values: ['trace', 'debug', 'info', 'warn', 'error']\n</code></pre> <p>Finally, the option <code>--listall</code> can be used to list the whole content of the XML file, which will be displayed with each node indented in its parent scope:</p> <pre><code>$ ./atmquery --listall\n    namelist_defaults\n        grids_manager\n            Type: Homme\n            physics_grid_type: PG2\n            physics_grid_rebalance: None\n            dynamics_namelist_file_name: ./data/namelist.nl\n            vertical_coordinate_filename: /some/path/to/coords/file.nc\n        initial_conditions\n            Filename: /some/path/to/ic/file.nc\n            topography_filename: /some/path/to/topo/file.nc\n    ...\n</code></pre>"},{"location":"user/model_input/#changing-model-inputs-atmchange","title":"Changing model inputs: atmchange","text":"<p>When <code>buildnml</code> runs, the model inputs are deduced from the case configuration settings (e.g., the grid, the compset, etc.) and the <code>namelist_scream_defaults.xml</code> file, located in the eamxx source tree. The user can change any of these parameters using the <code>atmchange</code> script. A basic usage of the script is</p> <pre><code>$ ./atmchange my_param=10\n</code></pre> <p>As for <code>atmquery</code>, if there are multiple matches for a given parameter name, the user must specify a unique scoped name, which allows <code>atmchange</code> to uniquely identify the XML node to modify:</p> <pre><code>$ ./atmquery homme::number_of_subcycles\n    namelist_defaults::atmosphere_processes::homme::number_of_subcycles: 1\n$ ./atmchange number_of_subcycles=10\nERROR: internal_diagnostics_level is ambiguous. Use ANY in the node path to allow multiple matches. Matches:\n  namelist_defaults::atmosphere_processes::number_of_subcycles\n  namelist_defaults::atmosphere_processes::sc_import::number_of_subcycles\n  namelist_defaults::atmosphere_processes::homme::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::tms::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::shoc::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::cldFraction::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::spa::internal_diagnostics_level\n  namelist_defaults::atmosphere_processes::physics::mac_aero_mic::p3::number_of_subcycles\n  namelist_defaults::atmosphere_processes::physics::rrtmgp::number_of_subcycles\n  namelist_defaults::atmosphere_processes::sc_export::number_of_subcycles\n$ ./atmchange homme::number_of_subcycles=10\nRegenerating /path/to/namelist_scream.xml. Manual edits will be lost.\n$ ./atmquery homme::number_of_subcycles\n    namelist_defaults::atmosphere_processes::homme::number_of_subcycles: 10\n</code></pre> <p>In some cases, the user may be interested in changing all nodes with a given name. In that case, you can use 'ANY' as a node name:</p> <p><pre><code>$ ./atmquery --grep number_of_subcycles\n    atmosphere_processes::number_of_subcycles: 1\n    sc_import::number_of_subcycles: 1\n    homme::number_of_subcycles: 1\n    physics::number_of_subcycles: 1\n    mac_aero_mic::number_of_subcycles: 24\n    tms::number_of_subcycles: 1\n    shoc::number_of_subcycles: 1\n    cldFraction::number_of_subcycles: 1\n    spa::number_of_subcycles: 1\n    p3::number_of_subcycles: 1\n    rrtmgp::number_of_subcycles: 1\n    sc_export::number_of_subcycles: 1\n$ ./atmchange ANY::number_of_subcycles=3\nRegenerating /path/to/namelist_scream.xml. Manual edits will be lost.\n$ ./atmquery --grep number_of_subcycles\n    atmosphere_processes::number_of_subcycles: 3\n    sc_import::number_of_subcycles: 3\n    homme::number_of_subcycles: 3\n    physics::number_of_subcycles: 3\n    mac_aero_mic::number_of_subcycles: 3\n    tms::number_of_subcycles: 3\n    shoc::number_of_subcycles: 3\n    cldFraction::number_of_subcycles: 3\n    spa::number_of_subcycles: 3\n    p3::number_of_subcycles: 3\n    rrtmgp::number_of_subcycles: 3\n    sc_export::number_of_subcycles: 3\n</code></pre> In addition, \"ANY\" can be used in a \"scoped\" string, to limit the set of matches: <pre><code>$ ./atmchange mac_aero_mic::ANY::number_of_subcycles=1\nRegenerating /path/to/namelist_scream.xml. Manual edits will be lost.\n$ ./atmquery --grep number_of_subcycles\n    atmosphere_processes::number_of_subcycles: 3\n    sc_import::number_of_subcycles: 3\n    homme::number_of_subcycles: 3\n    physics::number_of_subcycles: 3\n    mac_aero_mic::number_of_subcycles: 1\n    tms::number_of_subcycles: 1\n    shoc::number_of_subcycles: 1\n    cldFraction::number_of_subcycles: 1\n    spa::number_of_subcycles: 1\n    p3::number_of_subcycles: 1\n    rrtmgp::number_of_subcycles: 3\n    sc_export::number_of_subcycles: 3\n</code></pre></p> <p>Since the XML file stores constraints on the parameter value (like its type or valid values), attempting to use the wrong type will cause an error:</p> <pre><code>$ ./atmquery --type se_ne\n    namelist_defaults::ctl_nl::se_ne: integer\n$ ./atmchange se_ne=hello\nERROR: Could not refine 'hello' as type 'integer':\n</code></pre> <p>There are three main types supported: integer, float, string, logical. When passing a string to <code>atmchange</code>, the script will try to interpret it acoording to the parameter type, and throw an error if that's not possible: for \"string\", anything works; for \"integer\", only digits are allowed, possibly with a negative sign in front; for \"float\", only digits are allowed, possibly with a negative sign in front and a decimal point; for \"logical\", only the strings \"true\" and \"false\" are allowed (case insensitive). There are two additional types supported: \"file\" and \"array(T)\", where \"T\" is any of the other supported types (but not another array):  - \"file\" is used to inform CIME of the input files that have to be download from E3SM data servers, like initial conditions files, or certain lookup tables.  - \"array(T)\" allows to specify a list of items (of the same type), which will be parsed inside EAMxx as    a <code>std::vector&lt;T&gt;</code>.</p> <p>For type \"string\" and \"array(T)\", it is also possible to append to the currently stored value</p> <pre><code>$ ./atmquery homme::compute_tendencies\n    namelist_defaults::atmosphere_processes::homme::compute_tendencies:\n        value: a, b\n        type: array(string)\n        valid values: []\n$ ./atmchange homme::compute_tendencies+=c\n$ ./atmquery homme::compute_tendencies --full\n    namelist_defaults::atmosphere_processes::homme::compute_tendencies\n        value: a, b, c\n        type: array(string)\n        valid values: []\n</code></pre>"},{"location":"user/model_input/#modifying-the-list-of-atmosphere-processes","title":"Modifying the list of atmosphere processes","text":"<p>The <code>atmchange</code> script can be used to change any of the runtime parameters of EAMxx. In particular, it can be used to add, remove, or reorder atmosphere processes. When adding an atmosphere process, we must first make sure that the defaults for that process are present in <code>namelist_defaults_scream.xml</code>. For instance, the default settings for the \"physics\" atmosphere process group include the following:</p> <pre><code>$ ./atmquery physics::atm_procs_list\n    namelist_defaults::atmosphere_processes::physics::atm_procs_list: mac_aero_mic,rrtmgp\n</code></pre> <p>where \"mac_aero_mic\" is itself an atmosphere process group, consisting of macrophysics, aerosols, and microphysics processes. If one wanted to add the \"cosp\" atmosphere process to this list, and change the number of its subcycles, it could do so via</p> <pre><code>$ ./atmchange physics::atm_procs_list+=cosp\n$ ./atmchange cosp::number_of_subcycles=3\n</code></pre> <p>Notice that if we swapped the two commands, we would get an error, since the node \"cosp\" is not present in the XML generated from the defaults until we decide to add it.</p> <p>It is also possible to declare a new (empty) atmosphere process group, which can then be filled with valid atmosphere processes via subsequent calls to <code>atmchange</code>. The syntax to trigger this behavior consists in specifying a process name that begins and ends with an underscore:</p> <pre><code>$ ./atmchange physics::atm_procs_list+=_my_group_\n</code></pre> <p>This adds a new process to the list of processes in \"physics\", called \"_my_group_\", and which is itself an atmosphere process group. Hence, we can then do</p> <pre><code>$ ./atmchange _my_group_::atm_procs_list+=A,B\n</code></pre> <p>where A and B must be valid atmosphere process names (i.e., present in <code>namelist_defaults_scream.xml</code>) or be themselves new atmosphere process groups (i.e., beginning/ending with an underscore)</p> <p><code>atmchange</code> can also be used to completely change a list of atmosphere processes:</p> <pre><code>$ ./atmchange physics::atm_procs_list=A,B,C\n</code></pre> <p>Notice that we used \"=\" instead of \"+=\", which means we will be overwriting the value, rather than appending. Any atmosphere process that was previously in the list but is no longer in it will be removed from the generated <code>namelist_defaults.xml</code> (and <code>scream_input.yaml</code>) files, along with all their nested parameters.</p>"},{"location":"user/model_output/","title":"Model output","text":"<p>EAMxx allows the user to configure the desired model output via YAML files, with each YAML file associated to a different output file. In order to add an output stream, one needs to run <code>atmchange output_yaml_files+=/path/to/my/output/yaml</code> (more information on how to use <code>atmchange</code> can be found here). During the <code>buildnml</code> phase of the case management system, a copy of these YAML files will be copied into the RUNDIR/data folder. During this process, the files will be parsed, and any CIME-related variable will be resolved accordingly. Therefore, it is not advised to put the original YAML files in RUNDIR/data, since upon <code>buildnml</code> execution, all the CIME vars will no longer be available in the YAML file, making it harder to tweak it, and even harder to share with other users/cases. Another consequence of this is that the user should not modify the YAML files in RUNDIR/data, since any modification will be lost on the next run of <code>buildnml</code>.</p>"},{"location":"user/model_output/#basic-output","title":"Basic output","text":"<p>The following is a basic example of an output request.</p> <pre><code>%YAML 1.1\n---\nfilename_prefix: my_output\nAveraging Type: Average\nMax Snapshots Per File: 10\nFields:\n  Physics:\n    Field Names:\n      - T_mid\n      - qv\n  Dynamics:\n    Field Names:\n      - dp3d_dyn\n      - omega_dyn\noutput_control:\n  Frequency: 6\n  frequency_units: nhours\n</code></pre> <p>Notice that lists can be equivalently specified in YAML as <code>Field Names: [f1, f2, f3]</code>. The user can specify fields to be outputted from any of the grids used in the simulation. In the example above, we requested fields from both the Physics and Dynamics grid. The meaning of the other parameters is as follows:</p> <ul> <li> <p><code>Averaging Type</code>: how the fields are integrated in time before being saved. Valid   options are</p> <ul> <li>Instant: no integration, each time frame saved corresponds to instantaneous values   of the fields</li> <li>Average/Max/Min: the fields undergo the corresponding operation over the time   interval specified in the <code>output_control</code> section. In the case above, each snapshot   saved to file corresponds to an average of the output fields over 6h windows.</li> </ul> </li> <li> <p><code>filename_prefix</code>: the prefix of the output file, which will be created in the run   directory. The full filename will be <code>$prefix.$avgtype.$frequnits_x$freq.$timestamp.nc</code>,   where $timestamp corresponds to the first snapshot saved in the file for Instant output,   or the beginning of the first averaging window for the other averaging types</p> </li> <li><code>Max Snapshots Per File</code>: specifies how many time snapshots can be put in a file. Once   this number is reached, EAMxx will close the file and open a new one.</li> <li><code>Frequency</code>: how many units of time are between two consecutive writes to file. For   Instant output the fields are \"sampled\" at this frequency, while for other averaging   types the fields are \"integrated\" in time over this window</li> <li><code>frequency_units</code>: units of the output frequency. Valid options are <code>nsteps</code> (the   number of atmosphere time steps), <code>nsecs</code>, <code>nmins</code>, <code>nhours</code>, <code>ndays</code>, <code>nmonths</code>,   <code>nyears</code>.</li> </ul>"},{"location":"user/model_output/#diagnostic-output","title":"Diagnostic output","text":"<p>In addition to the fields computed by EAMxx as part of the timestep, the user can request to output derived quantities, which will be computed on the fly by the I/O interface of EAMxx. There are two types of diagnostic outputs:</p> <ul> <li> <p>quantities computed as a function of EAMxx fields. These are simply physical quantities   that EAMxx does not keep in persistent storage. As of May 2024, the available   derived quantities are (case sensitive):</p> <ul> <li><code>PotentialTemperature</code></li> <li><code>AtmosphereDensity</code></li> <li><code>Exner</code></li> <li><code>VirtualTemperature</code></li> <li><code>z_int</code></li> <li><code>z_mid</code></li> <li><code>geopotential_int</code></li> <li><code>geopotential_mid</code></li> <li><code>dz</code></li> <li><code>DryStaticEnergy</code></li> <li><code>SeaLevelPressure</code></li> <li><code>LiqWaterPath</code></li> <li><code>IceWaterPath</code></li> <li><code>VapWaterPath</code></li> <li><code>RainWaterPath</code></li> <li><code>RimeWaterPath</code></li> <li><code>ShortwaveCloudForcing</code></li> <li><code>LongwaveCloudForcing</code></li> <li><code>RelativeHumidity</code></li> <li><code>ZonalVapFlux</code></li> <li><code>MeridionalVapFlux</code></li> <li><code>precip_liq_surf_mass_flux</code></li> <li><code>precip_ice_surf_mass_flux</code></li> <li><code>precip_total_surf_mass_flux</code></li> <li><code>surface_upward_latent_heat_flux</code></li> <li><code>wind_speed</code></li> <li><code>AerosolOpticalDepth550nm</code></li> <li><code>NumberPath</code></li> <li><code>AeroComCld</code></li> </ul> </li> </ul> <p>TODO: add some information about what each diagnostic is, perhaps a formula</p> <ul> <li> <p>lower-dimensional slices of a field. These are hyperslices of an existing field or of   another diagnostic output. As of August 2023, given a field X, the available options   are:</p> <ul> <li><code>X_at_lev_N</code>: slice the field <code>X</code> at the N-th vertical level index. Recall that   in EAMxx N=0 corresponds to the model top.</li> <li><code>X_at_model_bot</code>, <code>X_at_model_top</code>: special case for top and bottom of the model.</li> <li><code>X_at_Ymb</code>, <code>X_at_YPa</code>, <code>X_at_YhPa</code>: interpolates the field <code>X</code> at a vertical position   specified by the give pressure <code>Y</code>. Available units are <code>mb</code> (millibar), <code>Pa</code>, and <code>hPa</code>.</li> <li><code>X_at_Ym_above_Z</code>: interpolates the field <code>X</code> at a vertical height of <code>Y</code> meters above   <code>Z</code>, with <code>Z=surface</code> or <code>Z=sealevel</code>.</li> </ul> </li> </ul>"},{"location":"user/model_output/#remapped-output","title":"Remapped output","text":"<p>The following options can be used to to save fields on a different grid from the one they are computed on.</p> <ul> <li><code>horiz_remap_file</code>: a path to a map file (as produced by <code>ncremap</code>) between the grid   where the fields are defined and a coarser grid. EAMxx will use this to remap fields   on the fly, allowing to reduce the size of the output file. Note: with this feature,   the user can only specify fields from a single grid.</li> <li><code>vertical_remap_file</code>: similar to the previous option, this map file is used to   refine/coarsen fields in the vertical direction.</li> <li><code>IOGrid</code>: this parameter can be specified inside one of the grids sections, and will   denote the grid (which must exist in the simulation) where the fields must be remapped   before being saved to file. This feature is really only used to save fields on the   dynamics grid without saving twice the DOFs at the interface of two spectral elements.   E.g., for a scalar quantity defined only in the horizontal direction, native output   from the Dynamics grid would produce arrays of length <code>nelems*ngp*ngp</code>, where <code>ngp</code>    is the number of Gauss points along each axis in the 2d spectral element, and <code>nelems</code>   is the number of horizontal elements. However, due to continuity, the values on the   Gauss points on the element boundary must match the values on the neighboring element,   resulting in duplicated data. By remapping to a \"unique\" version of the dynamics grid   (which in EAMxx is referred to as \"Physics GLL\"), we can save roughly 45% of storage.   Note: this feature cannot be used along with the horizontal/vertical remap.</li> </ul>"},{"location":"user/model_output/#tendencies-output","title":"Tendencies output","text":"<p>It is also possible to request tendencies of fields that are updated by atmosphere processes, on a per-process basis (here, \"updated\" means that the field is both an input as well as an output of the atmosphere process). Since the term \"tendency\" can be used with slightly different connotations, we clarify what we mean by that when it comes to model output: if process P updates field A, by the tendency of A from process P we mean <code>(A_after_P - A_before_P) / dt</code>, where <code>dt</code> is the atmosphere timestep.</p> <p>As of May 2024, the user needs two things in order to get tendencies from a process. E.g., to get the tendencies of <code>T_mid</code> and <code>horiz_winds</code> from the process <code>shoc</code>, one needs:</p> <ul> <li><code>atmchange shoc::compute_tendencies=T_mid,horiz_winds</code>;</li> <li>add <code>shoc_T_mid_tend</code> and <code>shoc_horiz_winds_tend</code> to the list of fields in the desired output YAML file.</li> </ul>"},{"location":"user/model_output/#additional-options","title":"Additional options","text":"<p>The YAML file shown at the top of this section, together with the remap options in the following section, covers most of the options used in a typical run. There are however particular use cases that require some less common options, which we list here (in parentheses, the location in the YAML file and the type of the parameter value).</p> <ul> <li><code>flush_frequency</code> (toplevel list, integer): this parameter  can be used to specify how often the IO   library should sync the in-memory data to file. If not specified, the IO library is free to decide   when it should flush the data. This option can be helpful for debugging, in case a crash is occurring   after a certain number of steps, but before the IO library would automatically flush to file.</li> <li><code>Floating Point Precision</code> (toplevel list, string): this parameter specifies the precision to be used for floating   point variables in the output file. By default, EAMxx uses single precision. Valid values are   <code>single</code>, <code>float</code>, <code>double</code>, and <code>real</code>. The first two are synonyms, while the latter resolves   to <code>single</code> or <code>double</code> depending on EAMxx cmake configuration parameter <code>SCREAM_DOUBLE_PRECISION</code>.</li> <li><code>file_max_storage_type</code> (toplevel list, string): this parameter determines how the capacity of the file is specified.   By default, it is set to <code>num_snapshots</code>, which makes EAMxx read <code>Max Snapshots Per File</code> (explained   in the first section). However, the user can specify <code>one_year</code> or <code>one_month</code>, which will make   EAMxx create one output file per year/month of simulation, fitting however many snapshots are needed   in each file (depending on the output frequency). If <code>one_year</code> or <code>one_month</code> are used, the option   <code>Max Snapshots Per File</code> is ignored.</li> <li><code>MPI Ranks in Filename</code> (toplevel list, boolean): this option specifies whether the number of MPI ranks in the atm   communicator should be put inside the output file name. By default, this is <code>false</code>, since it is   usually not important. This option is mostly important for standalone unit testing, where several   versions of the same test (corresponding to different numbers of MPI ranks) are running concurrently,   so that different file names are needed to avoid resource contention.</li> <li><code>save_grid_data</code> (<code>output_control</code> sublist, boolean): this option allows to specify whether grid data   (such as <code>lat</code>/<code>lon</code>) should be added to the output stream. By default, it is <code>true</code>.</li> <li><code>iotype</code> (toplevel list, string): this option allows the user to request a particular format for the output   file. The possible values are <code>default</code>, <code>netcdf</code>, <code>pnetcdf,</code>adios<code>,</code>hdf5<code>, where</code>default` means   \"whatever is the PIO type from the case settings\".</li> <li><code>skip_t0_output</code> (<code>output_control</code> sublist, boolean): this option is relevant only for <code>Instant</code> output,   where fields are also outputed at the case start time (i.e., after initialization but before the beginning   of the first timestep). By default it is set to <code>false</code>.</li> <li>restart options: when performing a restart, EAMxx attempts to restart every output stream listed in   the <code>output_yaml_files</code> atm option (which can be queried via <code>atmquery output_yaml_files</code>). The user   can specify a few options, in order to tweak the restart behavior:</li> <li><code>Perform Restart</code> (<code>Restart</code> sublist, boolean): this parameter is <code>true</code> by default, but can be set     to <code>false</code> to force the model to ignore any history restart files, and start the output stream from     scratch, as if this was an initial run.</li> <li><code>filename_prefix</code> (<code>Restart</code> sublist, string): by default, this parameter is set to match the value     of <code>filename_prefix</code> from the toplevel list. It can be set to something else in case we want to     restart a previous simulation that was using a different filename prefix.</li> <li><code>force_new_file</code> (<code>Restart</code> sublist, boolean): this parameter allows to start a fresh new output file     upon restarts. By default, is is set to <code>false</code>, so that EAMxx will attempt to resume filling the     last produced output file (if any, and if it can accommodate more snapshots).</li> </ul>"},{"location":"user/nudging/","title":"Nudging in EAMxx","text":"<p>Nudging is supported in EAMxx. Currently, it is possible to nudge EAMxx to the output from a different EAMxx run or to reanalysis. Nudging data can be on your model grid or an arbitrary coarser grid. Inline interpolating of finer-grid nudging data to a coarser model resolution isn't implemented yet but may be in the future.</p>"},{"location":"user/nudging/#data-to-nudge-towards","title":"Data to nudge towards","text":"<p>The user is expected to prepapre (and then use <code>atmchange</code> to point to) nudging data files that are compliant with EAMxx specification. In practice, this means that the data files must contain variable names known to EAMxx (only U, V, T_mid, and qv are supported now). The files can be specified with an explicit list or via pattern matching. The files must contain an arbitary global attribute <code>case_t0</code>, and it is recommended to be the same as the time dimension unit (the files must be time-dimensioned). Finally, the dimension order must be such that <code>lev</code> is the last dimension, so most likely, the user must transpose the dimensions.</p>"},{"location":"user/nudging/#pressure-in-the-nudging-data","title":"Pressure in the nudging data","text":"<p>Pressure can be explicitly provided in the nudging data as time-varying <code>p_mid</code> corresponding to the option <code>TIME_DEPENDENT_3D_PROFILE</code> for <code>source_pressure_type</code>. Alternatively, the data can contain a time-invariant pressure variable <code>p_lev</code> corresponding to the option <code>TIME_DEPENDENT_3D_PROFILE</code> for <code>source_pressure_type</code>.</p>"},{"location":"user/nudging/#weighted-nudging-for-rrm-applications","title":"Weighted nudging for RRM applications","text":"<p>In regionally refined model applications, it is possible to use weighted nudging, for example, to avoid nudging the refined region. To achieve that, the user can use <code>atmchange</code> to set <code>use_nudging_weights</code> (boolean) and provide <code>nudging_weights_file</code> that has the weight to apply for nudging (for example, zeros in the refined region). Currently, weighted nudging is only supported if the user provides the nudging data at the target grid.</p>"},{"location":"user/nudging/#example-setup-current-as-of-april-2024","title":"Example setup (current as of April 2024)","text":"<p>To enable nudging as a process, one must declare it in the <code>atm_procs_list</code> runtime parameter.</p> <pre><code>./atmchange physics::atm_procs_list=\"mac_aero_mic,rrtmgp,cosp,nudging\"\n</code></pre> <p>The following options are needed to specify the nudging.</p> <pre><code>./atmchange nudging::nudging_filenames_patterns=\"/pathto/nudging_files/*.nc\" # can provide file name explicitly here instead (or multiple patterns)\n./atmchange nudging::source_pressure_type=TIME_DEPENDENT_3D_PROFILE # see section on pressure\n./atmchange nudging::nudging_fields=U,V # can include qv, T_mid as well\n./atmchange nudging::nudging_timescale=21600 # in seconds\n</code></pre> <p>To gain a deeper understanding of these parameters and options, please refer to code implementation of the nudging process.</p>"},{"location":"user/rrm_eamxx/","title":"Running EAMxx with a Regionally Refined Mesh (RRM)","text":"<p>Running EAMxx with a RRM allows you run a select region of the globe at high resolution (i.e. 3 km) with the remainder of the globe at a lower resolution (i.e. 25 or 100 km).  This document will point you to the steps required and resources available to assist in developing and running a new RRM.</p>"},{"location":"user/rrm_eamxx/#choose-your-rrm","title":"Choose Your RRM","text":"<p>What region of the globe do you want to refine?  Your first step should be to check library of RRM grids/cases that have already been developed to potentially avoid duplicate work.  If you found a RRM that suits your needs, you can skip the next step (\"Generate Your RRM\").</p>"},{"location":"user/rrm_eamxx/#generate-your-rrm","title":"Generate Your RRM","text":"<p>Please refer to the offical E3SM guide for developing new atmosphere grids, which provides detailed guidance for developing your RRM.</p> <p>After you have made all the necessary files for your RRM, you will need to configure your code branch so that it knows about your new grid.  The steps required to do this are documented at the top of the library of RRM grids/cases page.</p>"},{"location":"user/rrm_eamxx/#make-your-initial-condition-file","title":"Make Your Initial Condition File","text":"<p>The easiest way to generate an initial condition is to use the HICCUP tool, which is a set of flexible and robust python routines to streamline the task of generating a new atmospheric initial condition for E3SM.  Otherwise, please see the step-by-step instuctions if you prefer to manually generate your initial condition.</p>"},{"location":"user/rrm_eamxx/#assemble-nudging-data-optional","title":"Assemble Nudging Data (Optional)","text":"<p>If you wish to nudge your simulation, assemble your nudging data in the format required by EAMxx.  Please refer to the nudging documentation.</p> <p>In the event that you only want to nudge a portion of your domain, then you will need to generate a nudging weights file.  A common use case for this is when you want the high-resolution region to remain free-running (unnudged) while nudging the coarse domain towards reanalysis or model data.  Please use this script as an example of how to generate your nudging weights file.</p>"},{"location":"user/rrm_eamxx/#run-your-rrm","title":"Run your RRM","text":"<p>Congratulations, you are now ready to run your EAMxx RRM.  If you are running your RRM in free running mode (not using any nudging) then you simply need to modify an existing EAMxx script and change the resolution to match the one you created for your RRM.</p> <p>If you are using nudging, then please see this example script of how to run a nudged EAMxx RRM run.  This example script uses the California 3-km RRM, which is on the master branch.</p>"}]}
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 8109a5d0cfdf3baae431ad5d1c208b5dd2f2be24..bd75785e9f55eebcb834795801164a4fb2c317ee 100644
GIT binary patch
delta 13
Ucmb=gXP58h;9$6FJ(0Zv02-hJ-~a#s

delta 13
Ucmb=gXP58h;9%%Co5)@P02wX=l>h($