Fortuna 2.5 Single Column Model: Difference between revisions

(20 intermediate revisions by the same user not shown)

Line 1:

This page describes the steps and modifications necessary to build and run the Single Column Model (SCM) under Fortuna 2.4 on discover. It assumes that you have successfully run the model as described in [[Fortuna 2.4 Quick Start]].

This page describes the steps and modifications necessary to build and run the Single Column Model (SCM) under Fortuna 2.5 on discover. It assumes that you have successfully run the model as described in [[Fortuna 2.5 Quick Start]].

'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''

'''Back to [[GEOS-5 Documentation for Fortuna 2.5]]'''

== Checking Out and Updating GEOS-5 for SCM ==

The Fortuna model tag <code>Fortuna-~~2_4~~</code> has all code necessary to run the single column model with any of the cases below.

The Fortuna model tag <code>Fortuna-2_5</code> has all code necessary to run the single column model with any of the cases below. '''The executable of the Single Column Model is identical to the global model'''; the only differences are the environment and settings with which it runs.

== Setting Up and Running Existing SCM Experiments ==

~~The~~ setup script for the SCM experiments is <code>/~~discover~~/~~nobackup~~/~~aeichman/scm/setup/getSCMdataf2.4.sh~~</code> . You do ''not'' have to run the <code>gcm_setup</code> script as you do to set up a global run. '''The ~~SCM environment and~~ setup ~~scripts have been changed~~ for Fortuna 2.4 and ~~older versions will~~ not ~~work for the current model tag~~.'''

Starting with the tag Fortuna-2_5_p1 the setup script for the SCM experiments is <code>src/Applications/GEOSgcm_App/scm_setup</code> . You do ''not'' have to run the <code>gcm_setup</code> script as you do to set up a global run. '''The current setup script will be updated with the tags, so use only that script for Fortuna 2.5 and later -- do not use any other.'''

At the time of this writing there are twenty experiments to choose from:

Line 27:

Create your own directory and ~~copy to it~~ the ~~script~~ <code>~~getSCMdataf2.4.sh~~</code>~~, then modify and uncomment the first executable line~~, which assigns <code>ESMADIR</code> to your local Fortuna 2.2 build that you are using for the SCM (you may already have this set as an environment variable). Uncomment one of the lines that assign the variable <code>CASEDIR</code> to choose the experiment to run. Then run the script. It will copy all of the necessary resource, forcing and data files to the working directory. Each experiment requires its own directory. If you modify the resource files (e.g., HISTORY.rc) you may want to copy the setup directory to your own area and modify it and the setup script accordingly so that you don't clobber your modifications.

Create your own run directory, then modify and uncomment the first executable line of <code>scm_setup</code>, which assigns <code>ESMADIR</code> to your local Fortuna 2.5 build that you are using for the SCM (you may already have this set as an environment variable). Uncomment one of the lines that assign the variable <code>CASEDIR</code> to choose the experiment to run. Then run the script from the run directory you have created. It will copy all of the necessary resource, forcing and data files to the working directory. Each experiment requires its own directory. If you modify the resource files (e.g., HISTORY.rc) you may want to copy the setup directory to your own area and modify it and the setup script accordingly so that you don't clobber your modifications.

Then you can just run the model executable from the command line in the directory you created. You will have to load the proper modules by sourcing <code>src/g5_modules</code>. Although it runs with a single processor, on discover you should run it from an interactive job on a compute node (as opposed to the '''discover''' front end). This can be done by running <code>qsub -I ijob</code>, where <code>ijob</code> is the job script that sets up the environment (examples are in <code>~aeichman</code> or <code>~amolod</code>). Once the job starts it starts an interactive shell on the job node, from which you can run the GEOS-5 executable. Since all of the necessary configuration files are copied to the experiment directory, it requires none of the extra environmental infrastructure needed for a global experiment that the run script <code>gcm_run.j</code> creates.

Then you can just run the model executable from the command line in the directory you created. You will have to load the proper modules by sourcing <code>src/g5_modules</code>. Although it runs with a single processor, on '''discover''' you should run it from an interactive job on a compute node (as opposed to the '''discover''' front end). This can be done by running <code>qsub -I ijob</code>, where <code>ijob</code> is the job script that sets up the environment (examples are in <code>~aeichman</code> or <code>~amolod</code>). Once the job starts it starts an interactive shell on the job node, from which you can run the GEOS-5 executable. Since all of the necessary configuration files are copied to the experiment directory, it requires none of the extra environmental infrastructure needed for a global experiment that the run script <code>gcm_run.j</code> creates.

== Creating Driving Datasets from MERRA ==

Given the resource and other files that come with a complete SCM configuration (either from an existing case or ~~created~~ with the procedure below), a driving data file for the same location and time span can be generated using MERRA output. ~~The~~ current scheme for MERRA data ~~includes the~~ analysis increments in the advection terms ~~that were left out in previous versions~~.

Given the resource and other files that come with a complete SCM configuration (either from an existing case or create with the procedure below), a driving data file for the same location and time span can be generated using MERRA output. Users should note that this current scheme for MERRA data does not include analysis increments in the advection terms, and probably should.

=== Obtaining MERRA Data ===

Line 46:

To use the scripts, modify the line in <code>getter.j</code> starting <code>setenv PATH ${PATH}:</code> ... to point to the directory

<code>src/~~Linux~~/~~bin~~</code> in your local Fortuna 2.2 build, which

<code>src/GMAO_Shared/GMAO_etc/</code> in your local Fortuna 2.0 build, which

contains the necessary utilities. These use perl

libraries, which might require additions to your environment. (Assume at first that they don't.) To specify the range of MERRA data to obtain, modify the variables

Line 60:

For more details, see <code>README</code>.

=== Generating the Driving Data ===

Now the ASCII .dat file used for the driving data can be created.

Under the directory <code>src/GMAO_Shared/GEOS_Util/post</code> in your Fortuna build, apply the following CVS command:

cvs upd -r b_afe_Fortuna_merra2scm merra2scm.F GNUmakefile

This will check out the source file <code>merra2scm.F</code>; it must be modified to the time and location of the data set to be created. Change the parameters <code>begdate</code> and <code>enddate</code> to the dates you want to cover, but leave <code>begtime</code> and <code>endtime</code> alone. If you are replicating an existing experiment, <code>begdate</code> and <code>enddate</code> can be obtained from that experiment's <code>cap_restart</code> and <code>CAP.rc</code>, respectively. The parameters <code>lonbegin</code>, <code>lonend</code>, <code>latbegin</code>, and <code>latend</code> specify the location and appropriate values can be gleaned from the filenames in the appropriate experiment under <code>/discover/nobackup/aeichman/scm/scminfiles/</code> -- for example, the filename

<code>tile.data_simple1_XY1x1-C_34N_100W_38N_95W</code>. (Note that these file names are truncated when copied by the SCM setup script.) Finally, change the variable <code>dirname</code> to the directory where you copied the MERRA data.

Then <code>cd</code> up to the <code>src</code> directory, run <code>make install</code>, and run the executable <code>merra2scm.x</code>. It will generate the driving data file <code>merra_scm.dat</code>, which can be used to replace the one with the expriment data.

=== Required Modifications to the Model ===

At the time of this writing, modifications need to be compiled in to load new cases. We are planning to amend this inconvenience. The source files to modify are in <code>src/GEOSgcs_GridComp/GEOSgcm_GridComp/GEOSagcm_GridComp/GEOSsuperdyn_GridComp/GEOSdatmodyn_GridComp</code>.

First, in <code>GEOS_DatmoDynGridComp.F90</code>, a case must be added in two <code>select</code> statements at (or near) line 1039 and line 1941:

select CASE(trim(DATA$))

A sample case is shown below:

<pre>

case("merra_arm97jul")

NT = 240

NLEVEL = 42

DATA_DRIVER=.true.

</pre>

For the case to be added, the <code>case</code> statement must have the name of the driver data file with the trailing <code>.dat</code> truncated (i.e. the file <code>merra_scm.dat</code> will require the <code>case</code> statement <code>case("merra_scm")</code> ). The variable <code>NT</code> must be assigned to the length of the time series of the driving data, and <code>NLEVEL</code> to the number of pressure levels. These values may be obtained from the header of the driver data file.

A similar, though more simple modification must be made in the other <code>case</code> statement that has MERRA SCM experiment names as cases, and the <code>if</code> statement at about line 1074.

Similarly, any experiment using MERRA data requires a modification to <code>reader.F90</code> at about lines 179, 302 and 325. The <code>if then</code> statement there:

<pre>

if(filename.eq."arm_97jul.dat".or. &

filename.eq."merra_arm97jul.dat".or. &

filename.eq."merra_arm_scmx.dat")then

</pre>

requires the addition of the full driver data file name.

With these modifications in place, the model may be recompiled.

Finally, the parameter <code>DRIVER_DATA</code> in <code>AGCM.rc</code> needs to be changed to the full filename of the driver data. Note that you will probably have to change the begin time in the <code>cap_restart</code> and the end time in <code>CAP.rc</code> to the appropriate times in <code>begtime</code> (probably <code>000000</code>) and <code>endtime</code>.

== Creating New SCM Case Boundary Conditions ==

To create the boundary condition files for a new SCM case with a location and time span different from the ones already made, there are a set of IDL scripts in

src/GEOSgcs_GridComp/GEOSgcm_GridComp/GEOSagcm_GridComp/GEOSsuperdyn_GridComp/GEOSdatmodyn_GridComp/idl

IDL can be run from the '''dali''' machine, which you should be able to <code>ssh</code> to from '''discover'''. See the NCCS documentation for IDL for help: http://www.nccs.nasa.gov/dali_qna.html#step5. Follow the steps and start IDL (<code>idl</code>). To run the script <code>make_bcs_ics.pro</code> enter:

IDL> .run make_bcs_ics

The procedure requires the restart files <code>fvcore_internal_rst</code>, <code>moist_internal_rst</code> and <code>catch_internal_rst</code> (with or without dates appended) seasonally appropriate for the experiment's start date, chosen in the priority month-day-year. Most restart files available have the time 2100z -- the affects of a disjoint between restart time-of-day and that of the beginning time of the model apparently diminish after a few days of spinup.

In the file <code>make_bcs_ics.pro</code> make the following changes:

*<code>odir</code> to an appropriate directory in your area for input files

*<code>gdirbase</code> to a directory in your area for output

*<code>cr</code> to the geographic range in coordinate degrees (<code>[''S W N E'']</code>)

*<code>casename</code> to a directory-appropriate name (this will be a subdirectory created for output in <code>gdirbase</code>)

*<code>sst_impose</code> to the desired SST boundary condition (if neccessary, in K)

*<code>ntype</code> (tile surface type) to 100 if over land, 0 if over sea

*<code>'moist_internal_rst.b19830214_21z'</code> to the name of your moist internal restart file

* the intances of <code>'fvcore_internal_rst.b19830214_21z'</code> to the name of your fvcore internal restart file

In <code>odir</code>, place the following files:

catch_internal_rst*

FV_144x91_DC_360x180_DE.til

fvcore_internal_rst*

lai_green_clim_144x91_DC.data

moist_internal_rst*

nirdf_144x91_DC.dat

topo_DYN_ave_144x91_DC.data

topo_GWD_var_144x91_DC.data

topo_TRB_var_144x91_DC.data

vegdyn_144x91_DC.dat

visdf_144x91_DC.dat

The files other than the restarts can currently be obtained from <code>/discover/nobackup/amolod/bcs/144x91/</code>.

Then run <code>make_bcs_ics.pro</code> from the IDL command line. This will create a set of files in <code>gdirbase/casename</code>.

Now you have to select a tile from the file <code>FV_144x91_DC_360x180_DE.til</code>. After the header, each line contains the specifications for one tile. Find a tile close to the location of your experiment -- the third column is longitude, the fourth latitude. The first column should be the same as the <code>ntype</code> in <code>make_bcs_ics.pro</code>. The last column is the tile number, which you should record.

Matlab (running on '''dali''') can make this task easier. First a edit a copy of <code>FV_144x91_DC_360x180_DE.til</code>, deleting the file header, the first eight lines. Then from Matlab you can <load> it. The following is an example of finding tiles near 39N 77W:

<pre>

>> format shortG

>> load FV_144x91_DC_360x180_DE.til

>> lat=40;lon=-77;

>> tilelines=find(int8(FV_144x91_DC_360x180_DE(:,4))==lat & int8(FV_144x91_DC_360x180_DE(:,3))==lon );FV_144x91_DC_360x180_DE(tilelines,[1 4 3 12])

ans =

100 39.963 -76.626 6894

100 39.96 -76.975 6895

100 40.182 -76.625 6896

100 40.187 -76.899 6899

100 40.134 -77.357 6900

100 40.353 -77.128 6901

100 39.595 -77.256 6935

19 39.566 -76.569 67187

>>

</pre>

The last command displays candidate tiles with their land/sea value, latitude, logitude, and tile number. It might make sense to examine adjacent whole lat/lon values.

Edit <code>make_land_files.pro</code> so that <code>bcsodir</code>, <code>xdir</code> and <code>casename</code> are the same as <code>odir</code>, <code>gdirbase</code> and <code>casename</code>, respectively, in <code>make_bcs_ics.pro</code>. Also change <code>itile</code> to the tile number you recorded from the tile file and <code>catchname</code> to the name of your catchment restart. The run the script. It will create a subdirectory <code>Landfiles</code> in the output directory and generate the land BC files there.

To make an appropriate <code>AGCM.rc</code>, copy one from an existing SCM case, and change the following:

* <code>AGCM_GRIDNAME</code> and <code>OGCM_GRIDNAME</code> to reflect the coordinates in the filenames of the files that you just generated

* <code>DRIVER_DATA</code> to the name of your driving data file name (for example, created from MERRA data in the section above)

Likewise, copy a <code>CAP.rc</code> and change the <code>END_DATE</code> as appropriate. Do the same for the start date in <code>cap_restart</code>. A <code>HISTORY.rc</code> can be copied without modification. Keep <code>AGCM.rc</code>, <code>CAP.rc</code>, <code>cap_restart</code>, and <code>HISTORY.rc</code> with the output from the IDL scripts. The latter will have to be either renamed or linked to names that the model will recognize -- see <code>/discover/nobackup/aeichman/scm/scminfiles/arm_97jul</code> for an example. You should have the following:

AGCM.rc

CAP.rc

cap_restart

catch_internal_rst

datmodyn_internal_rst

fraci.data

fvcore_internal_rst

HISTORY.rc

laigrn.data

moist_internal_rst

nirdf.dat

SEAWIFS_KPAR_mon_clim.data

sst.data

sstsi.data

tile.data

topo_dynave.data

topo_gwdvar.data

topo_trbvar.data

vegdyn.data

visdf.dat

These files, plus a driving data file, comprise the case-specific files for an SCM case, similar to those cases in <code>/discover/nobackup/aeichman/scm/scminfiles/</code>, and can use <code>getSCMdata.sh</code> to set up the model environment to run.

== Some Discussion About How to Use and Configure SCM ==

Line 196:

Line 343:

'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''

'''Back to [[GEOS-5 Documentation for Fortuna 2.5]]'''

@@ Line 1: / Line 1: @@
-This page describes the steps and modifications necessary to build and run the Single Column Model (SCM) under Fortuna 2.4 on discover.  It assumes that you have successfully run the model as described in [[Fortuna 2.4 Quick Start]].
+This page describes the steps and modifications necessary to build and run the Single Column Model (SCM) under Fortuna 2.5 on discover.  It assumes that you have successfully run the model as described in [[Fortuna 2.5 Quick Start]].
-'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''
+'''Back to [[GEOS-5 Documentation for Fortuna 2.5]]'''
 == Checking Out and Updating GEOS-5 for SCM ==
-The Fortuna model tag <code>Fortuna-2_4</code> has all code necessary to run the single column model with any of the cases below.
+The Fortuna model tag <code>Fortuna-2_5</code> has all code necessary to run the single column model with any of the cases below.  '''The executable of the Single Column Model is identical to the global model'''; the only differences are the environment and settings with which it runs.
 == Setting Up and Running Existing SCM Experiments ==
-The setup script for the SCM experiments is <code>/discover/nobackup/aeichman/scm/setup/getSCMdataf2.4.sh</code> .  You do ''not'' have to run the <code>gcm_setup</code> script as you do to set up a global run.   '''The SCM environment and setup scripts have been changed for Fortuna 2.4 and older versions will not work for the current model tag.'''
+Starting with the tag Fortuna-2_5_p1 the setup script for the SCM experiments is <code>src/Applications/GEOSgcm_App/scm_setup</code> .  You do ''not'' have to run the <code>gcm_setup</code> script as you do to set up a global run.   '''The current setup script will be updated with the tags, so use only that script for Fortuna 2.5 and later -- do not use any other.'''
 At the time of this writing there are twenty experiments to choose from:
@@ Line 27: / Line 27: @@
-Create your own directory and copy to it the script <code>getSCMdataf2.4.sh</code>, then modify and uncomment the first executable line, which assigns <code>ESMADIR</code> to your local Fortuna 2.2 build that you are using for the SCM (you may already have this set as an environment variable).  Uncomment one of the lines that assign the variable <code>CASEDIR</code> to choose the experiment to run.  Then run the script.  It will copy all of the necessary resource, forcing and data files to the working directory.  Each experiment requires its own directory.  If you modify the resource files (e.g., HISTORY.rc) you may want to copy the setup directory to your own area and modify it and the setup script accordingly so that you don't clobber your modifications.
+Create your own run directory, then modify and uncomment the first executable line of <code>scm_setup</code>, which assigns <code>ESMADIR</code> to your local Fortuna 2.5 build that you are using for the SCM (you may already have this set as an environment variable).  Uncomment one of the lines that assign the variable <code>CASEDIR</code> to choose the experiment to run.  Then run the script from the run directory you have created.  It will copy all of the necessary resource, forcing and data files to the working directory.  Each experiment requires its own directory.  If you modify the resource files (e.g., HISTORY.rc) you may want to copy the setup directory to your own area and modify it and the setup script accordingly so that you don't clobber your modifications.
-Then you can just run the model executable from the command line in the directory you created.  You will have to load the proper modules by sourcing <code>src/g5_modules</code>.  Although it runs with a single processor, on discover you should run it from an interactive job on a compute node (as opposed to the '''discover''' front end).  This can be done by running <code>qsub -I ijob</code>, where <code>ijob</code> is the job script that sets up the environment (examples are in <code>~aeichman</code> or <code>~amolod</code>).  Once the job starts it starts an interactive shell on the job node, from which you can run the GEOS-5 executable.  Since all of the necessary configuration files are copied to the experiment directory, it requires none of the extra environmental infrastructure needed for a global experiment that the run script <code>gcm_run.j</code> creates.
+Then you can just run the model executable from the command line in the directory you created.  You will have to load the proper modules by sourcing <code>src/g5_modules</code>.  Although it runs with a single processor, on '''discover''' you should run it from an interactive job on a compute node (as opposed to the '''discover''' front end).  This can be done by running <code>qsub -I ijob</code>, where <code>ijob</code> is the job script that sets up the environment (examples are in <code>~aeichman</code> or <code>~amolod</code>).  Once the job starts it starts an interactive shell on the job node, from which you can run the GEOS-5 executable.  Since all of the necessary configuration files are copied to the experiment directory, it requires none of the extra environmental infrastructure needed for a global experiment that the run script <code>gcm_run.j</code> creates.
 == Creating Driving Datasets from MERRA  ==
-Given the resource and other files that come with a complete SCM configuration (either from an existing case or created with the procedure below), a driving data file for the same location and time span can be generated using MERRA output.  The current scheme for MERRA data includes the analysis increments in the advection terms that were left out in previous versions.
+Given the resource and other files that come with a complete SCM configuration (either from an existing case or create with the procedure below), a driving data file for the same location and time span can be generated using MERRA output.  Users should note that this current scheme for MERRA data does not include analysis increments in the advection terms, and probably should.
 === Obtaining MERRA Data  ===
@@ Line 46: / Line 46: @@
 To use the scripts,  modify the line in <code>getter.j</code> starting <code>setenv PATH ${PATH}:</code> ... to point to the directory
-<code>src/Linux/bin</code> in your local Fortuna 2.2 build, which
+<code>src/GMAO_Shared/GMAO_etc/</code> in your local Fortuna 2.0 build, which
 contains the necessary utilities.  These use perl
 libraries, which might require additions to your environment. (Assume at first that they don't.) To specify the range of MERRA data to obtain, modify the variables
@@ Line 60: / Line 60: @@
 For more details, see <code>README</code>.
+=== Generating the Driving Data  ===
+Now the ASCII .dat file used for the driving data can be created.
+Under the directory <code>src/GMAO_Shared/GEOS_Util/post</code> in your Fortuna build, apply the following CVS command:
+ cvs upd -r b_afe_Fortuna_merra2scm merra2scm.F GNUmakefile
+This will check out the source file  <code>merra2scm.F</code>; it must be modified to the time and location of the data set to be created.  Change the parameters  <code>begdate</code> and <code>enddate</code> to the dates you want to cover, but leave <code>begtime</code> and <code>endtime</code> alone.  If you are replicating an existing experiment, <code>begdate</code> and <code>enddate</code> can be obtained from that experiment's <code>cap_restart</code> and <code>CAP.rc</code>, respectively. The parameters <code>lonbegin</code>, <code>lonend</code>, <code>latbegin</code>, and <code>latend</code> specify the location and appropriate values can be gleaned from the filenames in the appropriate experiment under <code>/discover/nobackup/aeichman/scm/scminfiles/</code> -- for example, the filename
+<code>tile.data_simple1_XY1x1-C_34N_100W_38N_95W</code>.  (Note that these file names are truncated when copied by the SCM setup script.)  Finally, change the variable <code>dirname</code> to the directory where you copied the MERRA data.
+Then <code>cd</code> up to the <code>src</code> directory, run <code>make install</code>, and run the executable <code>merra2scm.x</code>.  It will generate the driving data file <code>merra_scm.dat</code>, which can be used to replace the one with the expriment data.
+=== Required Modifications to the Model  ===
+At the time of this writing, modifications need to be compiled in to load new cases.  We are planning to amend this inconvenience.  The source files to modify are in <code>src/GEOSgcs_GridComp/GEOSgcm_GridComp/GEOSagcm_GridComp/GEOSsuperdyn_GridComp/GEOSdatmodyn_GridComp</code>.
+First, in <code>GEOS_DatmoDynGridComp.F90</code>, a case must be added in two <code>select</code> statements at (or near) line 1039 and line 1941:
+      select CASE(trim(DATA$))
+A sample case is shown below:
+<pre>
+   case("merra_arm97jul")
+      NT = 240
+      NLEVEL = 42
+      DATA_DRIVER=.true.
+</pre>
+For the case to be added, the <code>case</code> statement must have the name of the driver data file with the trailing <code>.dat</code> truncated (i.e. the file <code>merra_scm.dat</code> will require the <code>case</code> statement <code>case("merra_scm")</code> ).  The variable <code>NT</code> must be assigned to the length of the time series of the driving data, and <code>NLEVEL</code> to the number of pressure levels.  These values may be obtained from the header of the driver data file.
+A similar, though more simple modification must be made in the other <code>case</code> statement that has MERRA SCM experiment names as cases, and the <code>if</code> statement at about line 1074.
+Similarly, any experiment using MERRA data requires a modification to <code>reader.F90</code> at about lines 179, 302 and 325.  The <code>if then</code> statement there:
+<pre>
+        if(filename.eq."arm_97jul.dat".or. &
+           filename.eq."merra_arm97jul.dat".or. &
+           filename.eq."merra_arm_scmx.dat")then
+</pre>
+requires the addition of the full driver data file name.
+With these modifications in place, the model may be recompiled.
+Finally, the parameter <code>DRIVER_DATA</code> in <code>AGCM.rc</code> needs to be changed to the full filename of the driver data.  Note that you will probably have to change the begin time in the <code>cap_restart</code> and the end time in <code>CAP.rc</code> to the appropriate times in <code>begtime</code> (probably <code>000000</code>) and <code>endtime</code>.
+== Creating New SCM Case Boundary Conditions  ==
+To create the boundary condition files for a new SCM case with a location and time span different from the ones already made, there are a set of IDL scripts in
+ src/GEOSgcs_GridComp/GEOSgcm_GridComp/GEOSagcm_GridComp/GEOSsuperdyn_GridComp/GEOSdatmodyn_GridComp/idl
+IDL can be run from the '''dali''' machine, which you should be able to <code>ssh</code> to from '''discover'''.  See the NCCS documentation for IDL for help: http://www.nccs.nasa.gov/dali_qna.html#step5.  Follow the steps and start IDL (<code>idl</code>).  To run the script <code>make_bcs_ics.pro</code> enter:
+ IDL> .run make_bcs_ics
+The procedure requires the restart files <code>fvcore_internal_rst</code>, <code>moist_internal_rst</code> and <code>catch_internal_rst</code> (with or without dates appended) seasonally appropriate for the experiment's start date, chosen in the priority month-day-year.  Most restart files available have the time 2100z -- the affects of a disjoint between restart time-of-day and that of the beginning time of the model apparently diminish after a few days of spinup.
+In the file <code>make_bcs_ics.pro</code> make the following changes:
+*<code>odir</code> to an appropriate directory in your area for input files
+*<code>gdirbase</code> to a directory in your area for output
+*<code>cr</code> to the geographic range in coordinate degrees (<code>[''S W N E'']</code>)
+*<code>casename</code> to a directory-appropriate name (this will be a subdirectory created for output in <code>gdirbase</code>)
+*<code>sst_impose</code> to the desired SST boundary condition (if neccessary, in K)
+*<code>ntype</code> (tile surface type) to 100 if over land, 0 if over sea
+*<code>'moist_internal_rst.b19830214_21z'</code> to the name of your moist internal restart file
+* the intances of <code>'fvcore_internal_rst.b19830214_21z'</code> to the name of your fvcore internal restart file
+In <code>odir</code>, place the following files:
+ catch_internal_rst*
+ FV_144x91_DC_360x180_DE.til
+ fvcore_internal_rst*
+ lai_green_clim_144x91_DC.data
+ moist_internal_rst*
+ nirdf_144x91_DC.dat
+ topo_DYN_ave_144x91_DC.data
+ topo_GWD_var_144x91_DC.data
+ topo_TRB_var_144x91_DC.data
+ vegdyn_144x91_DC.dat
+ visdf_144x91_DC.dat
+The files other than the restarts can currently be obtained from <code>/discover/nobackup/amolod/bcs/144x91/</code>.
+Then run <code>make_bcs_ics.pro</code> from the IDL command line.  This will create a set of files in <code>gdirbase/casename</code>.
+Now you have to select a tile from the file <code>FV_144x91_DC_360x180_DE.til</code>.  After the header, each line contains the specifications for one tile.  Find a tile close to the location of your experiment -- the third column is longitude, the fourth latitude.  The first column should be the same as the <code>ntype</code> in <code>make_bcs_ics.pro</code>.  The last column is the tile number, which you should record.
+Matlab (running on '''dali''') can make this task easier.  First a edit a copy of  <code>FV_144x91_DC_360x180_DE.til</code>, deleting the file header, the first eight lines.  Then from Matlab you can <load> it.  The following is an example of finding tiles near 39N 77W:
+<pre>
+>> format shortG
+>> load FV_144x91_DC_360x180_DE.til
+>> lat=40;lon=-77;
+>> tilelines=find(int8(FV_144x91_DC_360x180_DE(:,4))==lat & int8(FV_144x91_DC_360x180_DE(:,3))==lon );FV_144x91_DC_360x180_DE(tilelines,[1 4 3 12])
+ans =
+       39.963      -76.626         6894
+        39.96      -76.975         6895
+       40.182      -76.625         6896
+       40.187      -76.899         6899
+       40.134      -77.357         6900
+       40.353      -77.128         6901
+       39.595      -77.256         6935
+       39.566      -76.569        67187
+>>
+</pre>
+The last command displays candidate tiles with their land/sea value, latitude, logitude, and tile number.  It might make sense to examine adjacent whole lat/lon values.
+Edit <code>make_land_files.pro</code> so that <code>bcsodir</code>, <code>xdir</code> and <code>casename</code> are the same as <code>odir</code>, <code>gdirbase</code> and <code>casename</code>, respectively, in <code>make_bcs_ics.pro</code>.  Also change <code>itile</code> to the tile number you recorded from the tile file and <code>catchname</code> to the name of your catchment restart.  The run the script.  It will create a subdirectory <code>Landfiles</code> in the output directory and generate the land BC files there.
+To make an appropriate <code>AGCM.rc</code>, copy one from an existing SCM case, and change the following:
+* <code>AGCM_GRIDNAME</code> and <code>OGCM_GRIDNAME</code> to reflect the coordinates in the filenames of the files that you just generated
+* <code>DRIVER_DATA</code> to the name of your driving data file name (for example, created from MERRA data in the section above)
+Likewise, copy a <code>CAP.rc</code> and change the <code>END_DATE</code> as appropriate.  Do the same for the start date in <code>cap_restart</code>.  A <code>HISTORY.rc</code> can be copied without modification.  Keep <code>AGCM.rc</code>, <code>CAP.rc</code>, <code>cap_restart</code>, and <code>HISTORY.rc</code> with the output from the IDL scripts.  The latter will have to be either renamed or linked to names that the model will recognize -- see <code>/discover/nobackup/aeichman/scm/scminfiles/arm_97jul</code> for an example.  You should have the following:
+ AGCM.rc
+ CAP.rc
+ cap_restart
+ catch_internal_rst
+ datmodyn_internal_rst
+ fraci.data
+ fvcore_internal_rst
+ HISTORY.rc
+ laigrn.data
+ moist_internal_rst
+ nirdf.dat
+ SEAWIFS_KPAR_mon_clim.data
+ sst.data
+ sstsi.data
+ tile.data
+ topo_dynave.data
+ topo_gwdvar.data
+ topo_trbvar.data
+ vegdyn.data
+ visdf.dat
+These files, plus a driving data file, comprise the case-specific files for an SCM case, similar to those cases in <code>/discover/nobackup/aeichman/scm/scminfiles/</code>, and can use <code>getSCMdata.sh</code> to set up the model environment to run.
 == Some Discussion About How to Use and Configure SCM  ==
@@ Line 196: / Line 343: @@
-'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''
+'''Back to [[GEOS-5 Documentation for Fortuna 2.5]]'''