Commit f8f0f2c4 authored by Peters, Wouter's avatar Peters, Wouter
Browse files

updated documentation

parent 0a167547
......@@ -4,7 +4,7 @@ time.restart : False
time.start : 2000-01-01 00:00:00
time.finish : 2000-01-15 00:00:00
time.cycle : 7
time.nlag : 2
time.nlag : 5
dir.da_run : ${HOME}/tmp/test_da
forecast.nmembers : 32
......@@ -2,12 +2,13 @@
# control.py
"""
Author : peters
.. module:: dasystem
.. moduleauthor:: Wouter Peters
Revision History:
File created on 26 Aug 2010.
The DaSystem class is found in the module :mod:`da.baseclasses.dasystem`, or in a specific implementation under the da/ source tree. It is derived from the standard python :class:`dictionary` object.
The DaSystem class is found in the module :mod:`dasystem`, or in a specific implementation under the da/ source tree. It is derived from the standard python :class:`dictionary` object.
It describes the details of the data assimilation system used (i.e., CarbonTracker, or CT Methane, or ....).
......
......@@ -2,7 +2,8 @@
# obs.py
"""
Author : peters
.. module:: obs
.. moduleauthor:: Wouter Peters
Revision History:
File created on 28 Jul 2010.
......
......@@ -2,7 +2,8 @@
# model.py
"""
Author : peters
.. module:: observationoperator
.. moduleauthor:: Wouter Peters
Revision History:
File created on 30 Aug 2010.
......
......@@ -2,7 +2,8 @@
# optimizer.py
"""
Author : peters
.. module:: optimizer
.. moduleauthor:: Wouter Peters
Revision History:
File created on 28 Jul 2010.
......
......@@ -2,12 +2,13 @@
# jobcontrol.py
"""
Author : peters
.. module:: platform
.. moduleauthor:: Wouter Peters
Revision History:
File created on 06 Sep 2010.
The PlatForm class is found in the module :mod:`da.baseclasses.platform`, or in a specific implementation under the da/source tree.
The PlatForm class is found in the module :mod:`platform`, or in a specific implementation under the da/source tree.
The platform object holds attributes and methods that allow job control on each specific platform. This includes methods to create and submit jobs, but also to obtain process and/or job ID's. These are needed to control the flow of
the system on each platform.
......
......@@ -2,12 +2,13 @@
# da_initexit.py
"""
Author : peters
.. module:: initexit
.. moduleauthor:: Wouter Peters
Revision History:
File created on 13 May 2009.
The CycleControl class is found in the module :mod:`da.tools.initexit`. It is derived from the standard python :class:`dictionary` object. It is the only core object of CTDAS that is automatically created in the pipeline, the user (normally) does not need to modify or extend it. The class is created based on options and arguments passes on the command line when submitting your main CTDAS job.
The CycleControl class is found in the module :mod:`initexit`. It is derived from the standard python :class:`dictionary` object. It is the only core object of CTDAS that is automatically created in the pipeline, the user (normally) does not need to modify or extend it. The class is created based on options and arguments passes on the command line when submitting your main CTDAS job.
Valid options are defined in
......@@ -247,34 +248,34 @@ class CycleControl(dict):
"""
This method determines how to proceed with the cycle. Three options are implemented:
1. Fresh start : set up the required file structure for this simulation and start
2. Restart : use latest da_runtime variables from the exec dir and restart
3. Recover : restart after crash by getting data from restart/one-ago folder
1. *Fresh start* : set up the required file structure for this simulation and start
2. *Restart* : use latest da_runtime variables from the exec dir and restart
3. *Recover* : restart after crash by getting data from restart/one-ago folder
The choice that gets executed depends on the presence of
1. the ``-r`` option on the command line, this triggers a recover
2. the ``time.restart : True`` option in the da.rc file
# the ``-r`` option on the command line, this triggers a recover
# the ``time.restart : True`` option in the da.rc file
The latter is automatically set if the filter submits the next cycle at the end of the current one,
through method :meth:`~da.tools.initexit.CycleControl.SubmitNextCycle`.
The specific call tree under each scenario is:
The specific call tree under each scenario is:
1.
1. *Fresh Start*
* dummy = :meth:`~da.tools.initexit.CycleControl.SetupFileStructure()` <- Create directory tree
2.
2. *Restart*
* dummy = :meth:`~da.tools.initexit.CycleControl.SetupFileStructure()`
* dummy = :meth:`~da.tools.initexit.CycleControl.RandomSeed` <- Read the random seed from file
3.
3. *Recover*
* dummy = :meth:`~da.tools.initexit.CycleControl.SetupFileStructure()`
* dummy = :meth:`~da.tools.initexit.CycleControl.RecoverRun()` <- Recover files from restart/one-ago dir, reset ``time.start``
* dummy = :meth:`~da.tools.initexit.CycleControl.RandomSeed`
And is always followed by a call to
* ParseTimes()
* WriteRc('jobfilename')
* ParseTimes()
* WriteRc('jobfilename')
"""
......@@ -446,7 +447,7 @@ class CycleControl(dict):
* The files in the ``ObservationOperator.RestartFileList``, i.e., restart data for the transport model
.. note:: We assume that the restart files for the :class:`~da.baseclasses.observationoperator.ObservationOperator`
.. note:: We assume that the restart files for the :ref:`ObservationOperator`
reside in a separate folder, i.e, the ObservationOperator does *not* write directly to the CTDAS restart dir!
"""
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment