Machine Port Validation for CCSM Development Code

!! Validating CLM-BGC code within CCSM

  • Validation will be done using the I component configuration [clm, datm7 (CLMHIST mode), dice, docn (SSTDATA mode) ] at T31_gx3v5.
  • Assume that a 15 year I case control has been done on a trusted machine. Refer to this control as blclm_t31x3 below.
  • Assume that clm in both the validation run and in bl_t31x3 will be run consistently in either CN or CASA mode.
  • Assume that all branch files will start from blclm_t31x3.
  • Do performance analysis of developmental code base on new machine (e.g. look at loopmark listings for vector platforms, etc.).
  • Test restart/branch of I component configuration (using the appropriate clm CN or CASA configuration) for developmental code base.
  • Run I case for 15 years starting from arbitrary initialization for clm and compare to blclm_t31x3.
  • Run I case for 2 days branching from year 15 of blclm_t31x3 and output clm history files every time step. Compare tendencies at first time step to blclm_t31x3.
    !! Validating POP-BGC code within CCSM
  • Validation will be done using the C component configuration [dlnd, datm7 (TN460 mode), dice, pop ] at T31_gx3v5. (Note that in the development code base, latm6/datm6 are no longer supported. latm6 has been replaced by datm7-TN460 mode. datm6 has been replaced by datm7-CAMHIST mode).
  • Assume that a 15 year C case control has been done on a trusted machine. Refer to this control as blpop_t31x3 below.
  • Assume that all branch files will start from blpop_t31x3.
  • Do performance analysis of developmental code base on new machine (e.g. look at loopmark listings for vector platforms, etc.).
  • Test restart/branch of C component configuration for developmental code base.
  • Run C case for 2 days branching from year 15 of blpop_t31x3 and output pop history files every time step. Compare tendencies at first time step to blpop_t31x3.
  • Run C case for 15 years and compare to blpop_t31x3.

!! Porting/System-Upgrade Validation for Ocean Models within CCSM
In addition to the validation measures used on CCSM as a whole, the
following procedure will aid in the validation of the ocean model
after porting to a new system or following a major system upgrade:

  • Set up a CCSM C_PRESENT_DAY case at the T31_gx3v5 resolution. For validating the ocean model after a system upgrade, do this before the upgrade on the targeted machine. For a porting validation, do this on a "trusted machine."
  • Modify the ocean model as follows:
    • set up the "partially_coupled" option and set lactive_ice = .false.
    • add iage and ecosys
    • improve task layout by modifying COMPORDER to put the ocean model first, the coupler second
    • increase ocean tasks, if needed
  • Set INFO_DBUG to 2
  • Run the case for one month, writing a restart file at the end of the run
  • Restart the case from the restart files created in the previous step. Set ocean tavg and diagnostics frequencies to nstep and run for two days.
  • Repeat the last step on the same machine after the system upgrade, or follow the first five steps on the target machine for a porting validation.
  • Compare the two-day output files from the two sets of runs. If there are concerns about diverging solutions, the user may need to instrument additional diagnostics and repeat the two-day runs. (If this is an upgrade validation, rerun the baseline case with new diagnostics on a "trusted machine."

!! Validating FV CAM development code code within CCSM

  • To be filled in
  • No labels