|
|
| Line 1: |
Line 1: |
|
| |
|
| = The CMT Command Line Tools =
| | [[Image:Alert-yellow.png | center | 50px | Out-of-date page ]] |
| | | This page is out of date. |
| {{Alert Box|message=Before beginning, you will need to have:
| | Please see the |
| * Set up an account on the [[HPCC_account_requirements | CSDMS cluster]], and be able to connect to it through an ssh client.
| | [[PyMT]] |
| }}
| | page for information on the Python Modeling Toolkit, |
| | | the successor to CMT. |
| == Load the CMT environment ==
| |
| Once logged into the CSDMS High Performance Computing Cluster, beach.colorado.edu, you will need to set up your environment to use the CMT command line tools. This is most easily done using modules.
| |
| | |
| <syntaxhighlight lang=bash>
| |
| $ module purge
| |
| $ module load cmtcl
| |
| </syntaxhighlight>
| |
| | |
| This clears any previously loaded modules and then adds the <tt>cmt</tt> command to your path. If you have done this successfully, the following should print out a brief help message that describes some of the options for the cmt command,
| |
| | |
| <syntaxhighlight lang=bash>
| |
| $ cmt --help
| |
| </syntaxhighlight>
| |
| | |
| == Running a CMT Configuration ==
| |
| | |
| To run an example we first must prepare a CMT resource file. The resource file will tell CMT what components to use and how to connect them. The most basic way to run CMT on the command line is,
| |
| | |
| <syntaxhighlight lang=bash>
| |
| $ cmt my_resource_file.rc
| |
| </syntaxhighlight>
| |
| | |
| where <tt>my_resource_file.rc</tt> is described in the next section. Usually this file is prepared by the CMT graphical user interface, however, it is a fairly simple format and can be created by-hand without too much effort. It is much easier to start with a template though so I will provide links to some sample resource files.
| |
| | |
| | |
| {{Alert Box|message=Please note that these files are provided for reference and at this time are not guaranteed to even work. The probability of working generally decreases as one moves down the list. I hope to have them all working as soon as possible but, until then, beware!
| |
| }}
| |
| | |
| Some sample resource files that run the Child model:
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/child_00.rc Child by itself]
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/child_01.rc Child connected to some input topography]
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/child_02.rc Child connected to some input topography and base level changes]
| |
| | |
| Some sample resource files that run the Sedflux3D model:
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/sedflux_00.rc Sedflux by itself]
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/sedflux_01.rc sedflux connected to some input topography]
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/sedflux_02.rc sedflux connected to some input topography and base level changes]
| |
| | |
| A connect Child-Sedflux simulation:
| |
| * [https://csdms.colorado.edu/~huttone/cmt_sample_rc_files/child_sedflux_00.rc Child coupled to Sedflux]
| |
| | |
| == Running an Example ==
| |
| | |
| On beach.colorado.edu, I put some example rc files in the directory,
| |
| | |
| /scratch/cmt/sample_rc_files
| |
| | |
| These are the same ones referenced above. In addition there are some sample input files in the directory,
| |
| | |
| /scratch/cmt/sample_input_files
| |
| | |
| There are some input files for both Sedflux and Child. Note that the sample RC files reference these input files. If you want to use your own input files you will have to create your own copy of them and change your RC file to point to your own copy.
| |
| | |
| To run an example simulation, first create a folder that will hold your input and output and copy the sample RC file into this folder.
| |
| | |
| <syntaxhighlight lang=bash>
| |
| $ mkdir cmt_examples
| |
| $ cd cmt_examples
| |
| $ cp /scratch/cmt/sample_rc_files/child_00.rc .
| |
| </syntaxhighlight>
| |
| | |
| Now (from your <tt>cmt_examples</tt> folder) you can run CMT,
| |
| <syntaxhighlight lang=bash>
| |
| $ cmt -C \$TMPDIR --launch-args="-q debug" child_00.rc
| |
| </syntaxhighlight>
| |
| Your CMT configuration described by the <tt>child_00.rc</tt> resource file is now running on one of the compute nodes of the cluster. When it competes the input and output will be placed in sub folder of your <tt>cmt_examples</tt> folder, whose name will be the job id that the <tt>cmt</tt> command returned.
| |
| | |
| A couple notes:
| |
| * The <tt>-C \$TMPDIR</tt> argument tells cmt to use a temporary folder on the compute node to hold all of your input and output data.
| |
| * The <tt>--launch-args="-q debug"</tt> argument puts your job into the debug queue so that it will start quickly.
| |
| | |
| | |
| {{Alert Box|message=If you think your simulation will take more than 2 hours to complete you must not submit it to the debug queue. For longer runs, leave out the <tt>--launch-args</tt> option completely.
| |
| }}
| |
| | |
| == The CMT Resource File ==
| |
| | |
| The CMT resource file tells the CMT what to do through three main commands:
| |
| # <tt>instantiate</tt>. Create an instance of a component.
| |
| # <tt>connect</tt>. Connect two components.
| |
| # <tt>parameters</tt>. Set a model parameter
| |
| There are other too, but these are the main ones.
| |
| | |
| === instantiate ===
| |
| | |
| Instantiate a component of type <tt>class_name</tt> and call it <tt>instance_name</tt>. Later on in the file we will use the instance name when referring to this component.
| |
| <syntaxhighlight lang=bash>
| |
| instantiate <class_name> <instance_name>
| |
| </syntaxhighlight>
| |
| Examples of instance names are <tt>edu.csdms.models.Child</tt> and <tt>edu.csdms.models.Sedflux3D</tt>. Instance names can be pretty much any old string. So, an example instantiate command would be,
| |
| <syntaxhighlight lang=bash>
| |
| instantiate edu.csdms.models.Child Child
| |
| </syntaxhighlight>
| |
| | |
| === connect ===
| |
| | |
| Connect the component instances <tt>user_name</tt> and <tt>provider_name</tt>. The two components will be connected through their named ports. All most always the user and provider port names will be the same but the need not be.
| |
| <syntaxhighlight lang=bash>
| |
| connect <user_name> <user_port> <provider_name> <provider_port>
| |
| </syntaxhighlight>
| |
| As an example, the Child component provides information about its subaerial delta through a provider port called SubaerialDelta. The Sedflux3D component is able to (optionally) use data provided by such a port. Thus, these two components can be connected through this port with the following command,
| |
| <syntaxhighlight lang=bash>
| |
| connect Sedflux3D SubaerialDelta Child SubaerialDelta
| |
| </syntaxhighlight>
| |
| In this case, the Child component provides the Sedflux3D component with information about sediment erosion and deposition rates on land.
| |
| | |
| === parameters ===
| |
| | |
| For the component <instance_name>, set the configuration parameter <param_key> to be <param_value>.
| |
| <syntaxhighlight lang=bash>
| |
| parameters <instance_name> Configure <param_key> <param_value>
| |
| </syntaxhighlight>
| |
