You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/tutorials/case_e.rst
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@
3
3
E - A Time-Independent Experiment
4
4
=================================
5
5
6
-
This example shows how to run a realistic testing experiment (based on https://doi.org/10.4401/ag-4844) while summarizing the concepts from the previous tutorials.
6
+
This example shows how to run a realistic testing experiment (based on :ref:`Schorlemmer et al. 2010<References>`) while summarizing the concepts from the previous tutorials.
7
7
8
8
.. currentmodule:: floatcsep
9
9
@@ -25,7 +25,7 @@ This example shows how to run a realistic testing experiment (based on https://d
25
25
Experiment Components
26
26
---------------------
27
27
28
-
The source code can be found in the ``tutorials/case_e`` folder or in `GitHub <https://github.com/cseptesting/floatcsep/blob/main/tutorials/case_e>`_. The input structure of the experiment is:
28
+
The source code can be found in the ``tutorials/case_e`` folder or in `the GitHub repository<https://github.com/cseptesting/floatcsep/blob/main/tutorials/case_e>`_. The input structure of the experiment is:
29
29
30
30
::
31
31
@@ -137,3 +137,9 @@ Plot command
137
137
colormap: magma
138
138
139
139
and re-run with the ``plot`` command. A forecast figure will re-appear in ``results/{window}/forecasts`` with a different colormap. Additional forecast and catalog plotting options can be found in the :func:`csep.utils.plots.plot_spatial_dataset` and :func:`csep.utils.plots.plot_catalog` ``pycsep`` functions.
140
+
141
+
142
+
References
143
+
----------
144
+
145
+
* Schorlemmer, D., Christophersen, A., Rovida, A., Mele, F., Stucchi, M. and Marzocchi, W. (2010). Setting up an earthquake forecast experiment in Italy. Annals of Geophysics, 53(3), 1–9. doi: `10.4401/ag-4844 <https://doi.org/10.4401/ag-4844>`_
Copy file name to clipboardExpand all lines: docs/tutorials/case_f.rst
+12-7Lines changed: 12 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,7 +25,7 @@ Experiment Components
25
25
---------------------
26
26
27
27
28
-
The source files can be found in the ``tutorials/case_e`` folder or in `GitHub <https://github.com/cseptesting/floatcsep/blob/main/tutorials/case_e>`_. The experiment structure is as follows:
28
+
The source files can be found in the ``tutorials/case_e`` folder or in `the GitHub repository<https://github.com/cseptesting/floatcsep/blob/main/tutorials/case_e>`_. The experiment structure is as follows:
29
29
30
30
::
31
31
@@ -49,7 +49,7 @@ The source files can be found in the ``tutorials/case_e`` folder or in `GitHub
49
49
Model
50
50
-----
51
51
52
-
The time-dependency of a model is manifested here by the provision of different forecasts, i.e., statistical descriptions of seismicity, for different time-windows. In this example, the forecasts were created from an external model https://github.com/lmizrahi/etas (`doi:10.1785/0220200231 <https://doi.org/10.1785/0220200231>`_), with which the experiment has no interface. This means that we use **only the forecast files** and no source code. We leave the handling of a model source code for subsequent tutorials.
52
+
The time-dependency of a model is manifested here by the provision of different forecasts, i.e., statistical descriptions of seismicity, for different time-windows. In this example, the forecasts were created from an external model https://github.com/lmizrahi/etas (`Mizrahi et al. 2021<References>`_), with which the experiment has no interface. This means that we use **only the forecast files** and no source code. We leave the handling of a model source code for subsequent tutorials.
53
53
54
54
55
55
@@ -73,7 +73,7 @@ Time
73
73
Catalog
74
74
~~~~~~~
75
75
76
-
The catalog ``catalog.json`` was obtained *previously* by using ``query_geonet`` and it was filtered to the testing period. However, it can be re-queried by changing its definition to:
76
+
The catalog ``catalog.json`` was obtained *prior* to the experiment by using ``query_geonet`` and it was filtered to the testing period. However, it can be re-queried by changing its definition to:
77
77
78
78
.. code-block:: yaml
79
79
@@ -93,29 +93,34 @@ Models
93
93
For consistency with time-dependent models that will create forecasts from a source code, the ``path`` should point to the folder of the model, which itself should contain a sub-folder named ``{path}/forecasts`` where the files are located.
94
94
95
95
.. important::
96
-
Note that for catalog-based forecasts, the model should explicit the number of simulations. This is meant for forecast files that contain synthetic catalogs with zero-event simulations, and therefore do not contain the total number of synthetic catalogs used.
96
+
Note that for catalog-based forecast models, the number of catalog simulations (``n_sims``) must be specified – because a forecast may contain synthetic catalogs with zero-event simulations and therefore does not imply the total number of simulated synthetic catalogs.
97
97
98
98
Tests
99
99
~~~~~
100
100
101
-
With time-dependent models, now catalog evaluations found in :obj:`csep.core.catalog_evaluations` can be used.
101
+
Having a time-dependent and catalog-based forecast model, catalog-based evaluations found in :obj:`csep.core.catalog_evaluations` can now be used.
It is possible to assign two plotting functions to a test, whose ``plot_args`` and ``plot_kwargs`` can be placed indented beneath
108
+
It is possible to assign two plotting functions to a test, whose ``plot_args`` and ``plot_kwargs`` can be placed indented beneath.
109
109
110
110
111
111
Running the experiment
112
112
----------------------
113
113
114
-
The experiment can be run by simply navigating to the ``tutorials/case_h`` folder in the terminal and typing.
114
+
The experiment can be run by simply navigating to the ``tutorials/case_h`` folder in the terminal and typing:
115
115
116
116
.. code-block:: console
117
117
118
118
$ floatcsep run config.yml
119
119
120
120
This will automatically set all the calculation paths (testing catalogs, evaluation results, figures) and will create a summarized report in ``results/report.md``.
121
121
122
+
123
+
References
124
+
----------
125
+
126
+
* Mizrahi, L., Nandan, S., & Wiemer, S. (2021). The effect of declustering on the size distribution of mainshocks. _Seismological Research Letters, 92_(4), 2333–2342. doi: `10.1785/0220200231 <https://doi.org/10.1785/0220200231>`_
Copy file name to clipboardExpand all lines: docs/tutorials/case_g.rst
+18-20Lines changed: 18 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ Here, we set up a time-dependent model from its **source code** for an experimen
26
26
Experiment Components
27
27
---------------------
28
28
29
-
The example folder contains also, along with the already known components (configurations, catalog), a sub-folder for the **source code** of the model ``pymock``. The components of the experiment (and model) are:
29
+
The example folder contains also, along with the already known components (configurations, catalog), a sub-folder for the **source code** of the model `pymock<https://git.gfz-potsdam.de/csep/it_experiment/models/pymock>`_. The components of the experiment (and model) are:
30
30
31
31
::
32
32
@@ -63,7 +63,7 @@ The example folder contains also, along with the already known components (confi
63
63
Model
64
64
-----
65
65
66
-
The experiment's complexity increases from time-independent to dependent mostly because we now need a **Model** (source code) to generate forecasts that changes for every time-window. The model main components are:
66
+
Transitioning from time-independent to dependent models increases an experiment's complexity because we now need a **Model** (source code) to generate forecasts that change for every time-window. A **Model**'s main components are:
67
67
68
68
69
69
* **Input**: The input consists in input **data** and **arguments**.
@@ -76,35 +76,33 @@ The experiment's complexity increases from time-independent to dependent mostly
76
76
77
77
2. The **input arguments** controls how the model's source code works. The minimum arguments to run a model are the forecast ``start_date`` and ``end_date``, which will be modified dynamically during an experiment with multiple time-windows. The experiment system will access `{model}/input/args.txt` and change the values of ``start_date = {datetime}`` and ``end_date = {datetime}`` before the model is run. Additional arguments can be set by convenience, such as (not limited to) ``catalog`` (the input catalog name), ``n_sims`` (number of synthetic catalogs) and random ``seed`` for reproducibility.
78
78
79
-
* **Output**: The model's output are the synthetic catalogs, which should be allocated in `{model}/forecasts/{filename}.csv` by the source code after each rone. The format is identically to ``csep_ascii``, but unlike in an input catalog, the ``catalog_id`` column should be modified for each synthetic catalog starting from 0. The file name follows the convention `{model_name}_{start}_{end}.csv`, where ``start`` and ``end`` folows the `%Y-%m-%dT%H:%M:%S.%f` - ISO861 FORMAT
79
+
* **Output**: The model's output are synthetic catalogs, which should be allocated in `{model}/forecasts/{filename}.csv` by the source code after each run. The format is identically to ``csep_ascii``, but unlike in an input catalog, the ``catalog_id`` column should be modified for each synthetic catalog starting from 0. The file name follows the convention `{model_name}_{start}_{end}.csv`, where ``start`` and ``end`` follows the `%Y-%m-%dT%H:%M:%S.%f` - ISO861 FORMAT.
80
80
81
-
* **Model build**: Inside the model source code, there are multiple options to build it. A standard python ``setup.cfg`` is given, which can be built inside a python ``venv`` or ``conda`` managers. This is created and built automatically by ``floatCSEP``, as long as the the model build instructions are correctly set up.
81
+
* **Model build**: Inside the model source code, there are multiple options to build it. A standard Python ``setup.cfg`` is given, which can be built inside a Python ``venv`` or ``conda`` managers. This is created and built automatically by ``floatCSEP``, as long as the the model build instructions are correctly set up.
82
82
83
83
* **Model run**: The model should be run with a simple command, e.g. **entrypoint**, to which only ``arguments`` could be passed if desired. The ``pymock`` model contains multiple example of entrypoints, but the modeler should use only one for clarity.
84
84
85
-
1. A `python` call with arguments
85
+
1. A ``python`` call with arguments:
86
86
87
87
.. code-block:: console
88
88
89
89
$ python run.py input/args.txt
90
90
91
-
2. Using a binary entrypoint with arguments (for instance, defined in the python build instructions: ``pymock/setup.cfg:entry_point``)
91
+
2. Using a binary entrypoint with arguments (for instance, defined in the Python build instructions: ``pymock/setup.cfg:entry_point``):
92
92
93
93
.. code-block:: console
94
94
95
95
$ pymock input/args.txt
96
96
97
-
3. A single binary entrypoint without arguments .
97
+
3. A single binary entrypoint without arguments, which means that the source code should internally read the input data and arguments (``input/catalog.csv`` and ``input/args.txt`` files, respectively):
98
98
99
99
.. code-block:: console
100
100
101
101
$ pymock
102
102
103
-
This means that the source code should internally read the input data and arguments, ``input/catalog.csv`` and ``input/args.txt`` files respectively.
104
-
105
103
.. important::
106
104
107
-
The model should be conceptualized as a **black-box**, whose only interface/interaction with the ``floatcsep`` system is to receive an input (i.e., input catalog and arguments) and generates an output (the forecasts).
105
+
A **Model** can be conceptualized as a **black-box**, whose only interface/interaction with the ``floatcsep`` system is to receive an input (i.e., input catalog and arguments) and subsequently generate an output (the forecasts).
108
106
109
107
110
108
Configuration
@@ -124,7 +122,7 @@ Time
124
122
Catalog
125
123
~~~~~~~
126
124
127
-
The catalog was obtained `previous to the experiment` using ``query_bsi``, but it was filtered from 2006 onwards, so it has enough data for the model calibration.
125
+
The catalog was obtained *prior* to the experiment using ``query_bsi``, but it was filtered from 2006 onwards, so it has enough data for the model calibration.
128
126
129
127
Models
130
128
~~~~~~
@@ -137,13 +135,13 @@ Models
137
135
:lines: 1-7
138
136
139
137
1. Now ``path`` points to the folder where the source is installed. Therefore, the input and the forecasts should be allocated ``{path}/input`` and ``{path}/forecasts``, respectively.
140
-
2. The ``func`` option is the shell command with which the model is run. As seen in the `Model`_ section, this could be either ``pymock``, ``pymock input/args.txt`` or ``python run.py input/args``. We use the simplest option ``pymock``, but you are welcome to try different entrypoints.
138
+
2. The ``func`` option is the shell command with which the model is run. As seen in the `Model` section, this could be either ``pymock``, ``pymock input/args.txt`` or ``python run.py input/args``. We use the simplest option ``pymock``, but you are welcome to try different entrypoints.
141
139
142
140
.. note::
143
141
The ``func`` command will be run from the model's directory and a model containerization (e.g., ``Dockerfile``, ``conda``).
144
142
145
-
3. The ``func_kwargs`` are extra arguments that will annotated to the ``input/args.txt`` file every time the model is run, or will be passed as extra arguments to the ``func`` call (Note that the two options are identical). This is useful to define sub-classes of models (or flavours) that uses the same source code, but a different instantiation.
146
-
4. The ``build`` option defines the style of container within which the model will be placed. Currently in **floatCSEP**, only the python module ``venv``, the package manager ``conda`` and the containerization manager ``Docker`` are currently supported.
143
+
3. The ``func_kwargs`` are extra arguments that will be added to the ``input/args.txt`` file every time the model is run, or will be passed as extra arguments to the ``func`` call (Note that the two options are identical). This is useful to define sub-classes of models (or flavours) that uses the same source code, but a different instantiation.
144
+
4. The ``build`` option defines the style of container within which the model will be placed. Currently in **floatCSEP**, only the Python module ``venv``, the package manager ``conda`` and the containerization manager ``Docker`` are currently supported.
147
145
148
146
.. important::
149
147
For these tutorials, we use ``venv`` sub-environments, but we recommend ``Docker`` to set up real experiments.
@@ -152,15 +150,15 @@ Models
152
150
Tests
153
151
~~~~~
154
152
155
-
With time-dependent models, now catalog evaluations found in :obj:`csep.core.catalog_evaluations` can be used.
153
+
Catalog-based evaluations found in :obj:`csep.core.catalog_evaluations` can be used.
It is possible to assign two plotting functions to a test, whose ``plot_args`` and ``plot_kwargs`` can be placed indented beneath
161
+
It is possible to assign two plotting functions to a test, whose ``plot_args`` and ``plot_kwargs`` can be placed indented beneath.
164
162
165
163
166
164
Custom Post-Process
@@ -173,13 +171,13 @@ Custom Post-Process
173
171
:language: yaml
174
172
:lines: 22-23
175
173
176
-
This option provides `hook` for a python script and a function within as:
174
+
This option provides a `hook` for a Python script and a function within as:
177
175
178
176
.. code-block:: console
179
177
180
178
{python_sript}:{function_name}
181
179
182
-
The requirements are that the script to be located within the same directory as the configuration file, whereas the function must receive a :class:`floatcsep.experiment.Experiment` as argument
180
+
The script must be located within the same directory as the configuration file, whereas the function must receive a :class:`floatcsep.experiment.Experiment` as argument:
In this way, the plot function can use all the :class:`~floatcsep.experiment.Experiment` attributes/methods to access catalogs, forecasts and test results. The script ``tutorials/case_g/custom_plot_script.py`` can also be viewed directly on `GitHub <https://github.com/cseptesting/floatcsep/blob/main/tutorials/case_g/custom_plot_script.py>`_, where it is exemplified how to access the experiment data in runtime.
189
+
In this way, the plot function can use all the :class:`~floatcsep.experiment.Experiment` attributes/methods to access catalogs, forecasts and test results. The script ``tutorials/case_g/custom_plot_script.py`` can also be viewed directly in `the GitHub repository <https://github.com/cseptesting/floatcsep/blob/main/tutorials/case_g/custom_plot_script.py>`_, where it is exemplified how to access the experiment data at runtime.
192
190
193
191
194
192
Running the experiment
195
193
----------------------
196
194
197
-
The experiment can be run by simply navigating to the ``tutorials/case_g`` folder in the terminal and typing.
195
+
The experiment can be run by simply navigating to the ``tutorials/case_g`` folder in the terminal and typing:
0 commit comments