GEOS-5 Checkout and Build Instructions (Fortuna): Difference between revisions
Line 148: | Line 148: | ||
'''AGCM.rc''' | '''AGCM.rc''' | ||
This file controls the model run characteristics. For example, | This file controls the model run characteristics. For example, for our tag (and answering the setup questions as above) the '''AGCM.rc''' file has the following lines characteristic (to run '''GOCART''' with interactive aerosol forcing): | ||
GOCART_INTERNAL_RESTART_FILE: gocart_internal_rst | GOCART_INTERNAL_RESTART_FILE: gocart_internal_rst | ||
GOCART_INTERNAL_RESTART_TYPE: binary | GOCART_INTERNAL_RESTART_TYPE: binary | ||
GOCART_INTERNAL_CHECKPOINT_FILE: gocart_internal_checkpoint | GOCART_INTERNAL_CHECKPOINT_FILE: gocart_internal_checkpoint | ||
GOCART_INTERNAL_CHECKPOINT_TYPE: binary | GOCART_INTERNAL_CHECKPOINT_TYPE: binary | ||
#AEROCLIM: ExtData/CMIP/L72/aero_clm/gfedv2.aero.eta.%y4%m2clm.nc | |||
#AEROCLIMDEL: ExtData/CMIP/L72/aero_clm/gfedv2.del_aero.eta.%y4%m2clm.nc | |||
#AEROCLIMYEAR: 2002 | |||
DU_OPTICS: ExtData/CMIP/x/opticsBands_DU.v4.nc | |||
SS_OPTICS: ExtData/CMIP/x/opticsBands_SS.v3.nc | |||
SU_OPTICS: ExtData/CMIP/x/opticsBands_SU.v3.nc | |||
OC_OPTICS: ExtData/CMIP/x/opticsBands_OC.nc | |||
BC_OPTICS: ExtData/CMIP/x/opticsBands_BC.nc | |||
NUM_BANDS: 18 | |||
DIURNAL_BIOMASS_BURNING: yes | |||
RATS_PROVIDER: PCHEM # options: PCHEM, GMICHEM, STRATCHEM (Radiatively active tracers) | |||
AERO_PROVIDER: GOCART # options: PCHEM, GOCART (Radiatively active aerosols) | |||
ANALYSIS_OX_PROVIDER: PCHEM # options: PCHEM, GMICHEM, STRATCHEM, GOCART | |||
To run with climatological aerosol forcing, modify the appropriate lines above to look like: | |||
AEROCLIM: ExtData/AeroCom/L72/aero_clm/gfedv2.aero.eta.%y4%m2clm.nc | AEROCLIM: ExtData/AeroCom/L72/aero_clm/gfedv2.aero.eta.%y4%m2clm.nc | ||
AEROCLIMDEL: ExtData/AeroCom/L72/aero_clm/gfedv2.del_aero.eta.%y4%m2clm.nc | AEROCLIMDEL: ExtData/AeroCom/L72/aero_clm/gfedv2.del_aero.eta.%y4%m2clm.nc | ||
AEROCLIMYEAR: 2002 | AEROCLIMYEAR: 2002 | ||
AERO_PROVIDER: PCHEM # options: PCHEM, GOCART (Radiatively active aerosols) | AERO_PROVIDER: PCHEM # options: PCHEM, GOCART (Radiatively active aerosols) | ||
'''HISTORY.rc''' | '''HISTORY.rc''' | ||
Line 177: | Line 188: | ||
'tavg2d_aer_x' | 'tavg2d_aer_x' | ||
'inst3d_aer_v' | 'inst3d_aer_v' | ||
:: | 'tavg3d_aer_p' | ||
'tavg2d_chm_x' | |||
'tavg3d_chm_p' | |||
'inst2d_hwl_x' | |||
'inst2d_force_x' | |||
'inst3d_force_p' | |||
:: | |||
'''CAP.rc''' | '''CAP.rc''' | ||
Line 185: | Line 202: | ||
'''gcm_run.j''' | '''gcm_run.j''' | ||
This is the model run script. You might not need to edit anything, but check in here to see if we are pointing to the right emission files. | This is the model run script. You might not need to edit anything, but check in here to see if we are pointing to the right emission files. This is system dependent. For our tag, on discover, there is a line: | ||
setenv CHMDIR /share/ | setenv CHMDIR /discover/nobackup/projects/gmao/share/dao_ops/fvInput_nc3 | ||
which points to the | which points to the emission files presumed in this run. You might have to modify this line on a different system or to use different emission inventories. | ||
'''An Optional Modification''' | '''An Optional Modification''' | ||
Line 202: | Line 214: | ||
substituting the appropriate YYYYMM in END_DATE for the overall time you want your experiment to end. | substituting the appropriate YYYYMM in END_DATE for the overall time you want your experiment to end. | ||
By default the '''gcm_run.j''' on this tag has the following environment variables set like this: | |||
set STOP_MID_MONTH = 1 | set STOP_MID_MONTH = 1 | ||
set DFLT_JOB_SGMT = 16 | set DFLT_JOB_SGMT = 16 | ||
Here's what is happening: overall model control is handled by '''CAP.rc'''. We specify the model finish time with END_DATE in '''CAP.rc'''. As set up, JOB_SGMT is the number of days to run the model in a single segment, and NUM_SGMT is the number of segments to run in a single queue submission. With STOP_MID_MONTH set to '''1''' what happens is that the JOB_SGMT environment variable is tweaked for each half-month of the model run. That is, the first segment runs the initial number of days (in this case, 17) and the next segment runs for however many days are needed to reach the 1st of the next month. (In this example, I'm presuming we're starting from an initial date of 19991231, which requires us to run for 17 days to cause the model to stop on 20000117, which is the desired monthly mid-point.) What's really happening is that CAP.rc is being edited after each segment to specify the (hopefully) correct number of days to run the next segment. Here, NUM_SGMT is set to '''12''', which will run the model for 6 months in a single queue submission (1/2 month per segment). This seems to fit conservatively for our resolution in a single 8-hour wallclock time request. | Here's what is happening: overall model control is handled by '''CAP.rc'''. We specify the model finish time with END_DATE in '''CAP.rc'''. As set up, JOB_SGMT is the number of days to run the model in a single segment, and NUM_SGMT is the number of segments to run in a single queue submission. With STOP_MID_MONTH set to '''1''' what happens is that the JOB_SGMT environment variable is tweaked for each half-month of the model run. That is, the first segment runs the initial number of days (in this case, 17) and the next segment runs for however many days are needed to reach the 1st of the next month. (In this example, I'm presuming we're starting from an initial date of 19991231, which requires us to run for 17 days to cause the model to stop on 20000117, which is the desired monthly mid-point.) What's really happening is that CAP.rc is being edited after each segment to specify the (hopefully) correct number of days to run the next segment. Here, NUM_SGMT is set to '''12''', which will run the model for 6 months in a single queue submission (1/2 month per segment). This seems to fit conservatively for our resolution in a single 8-hour wallclock time request. | ||
If you don't care about any of this, you can set STOP_MID_MONTH = 0, which bypasses this logic and all segments are exactly as long as JOB_SGMT specifies. | |||
'''Running on Pleiades''' | '''Running on Pleiades''' | ||
This tag has successfully checked out, built, run, and archived results on NAS machine Pleiades. | This tag has successfully checked out, built, run, and archived results on NAS machine Pleiades. No modifications to scripts are needed, as the appropriate choices for that machine are handled in gcm_setup. | ||
=== Setup the Experiment EXPDIR === | === Setup the Experiment EXPDIR === |