Home

Awesome

ciceroscm

Python version of the CICERO-SCM simple climate model/emulator

Running

To run the model, copy <code>run_full_forcing.py</code> or <code>run_scm.py</code> for a forcing, or full emissions run from the <code>scripts</code> directory. The forcing run currently supports only files with single total forcing series supplemented with solar and volcanic forcing time series. There is currently no support for pure concentration runs, only full emissions. The scripts show you how to specify input data and output data placement. The output data will be placed in a folder called output_test in the folder from which you run the script. More input data on the appropriate format (at least for emission runs) can be found in <code>/div/amoc/CSCM/SCM_Linux_v2019/RCMIP/input/</code> on amoc for internal use.

Instance configurations

When a new instance of the CICERO-SCM class is created the dictionary cfg needs to be sent as a parameter, detailing the configurations of the instance. All options that end in _file can be exchanged with the same parameter ending in _data to send in data directly. See details on the data format in the input_handler module. Configuration options are:

Options for run

With a CICEROSCM instance in place, you are ready to start runs with various parameter configurations, using the input files as set by the instance configuration

Run configurations

Parameter sets

Physical parameters to the model is divided in two parametersets each of which are sent as two seperate dictionaries to the run call.

pamset_udm

The upwelling diffusion model (which is needed for all runs) takes the following parameters.(Default value in paranthesis):

pamset_emiconc

The concentration and emission parameterset (which is needed for emission runs) takes the following parameters. (Default value in paranthesis):

Parallelisation tools

The module also has a submodule of parallelisation tools. This includes:

Example scripts

The scripts folder contains various example scripts that can be used to see how to set up various types of runs. The start of all of them adds the necessary parts for the file to run with the module. If you want to run from somewhere else you will need to edit the <code>sys.path.append</code> command so it points to where you've stored the src directory of this repository.

Jupyter Notebooks

The notebooks folder provides simple working examples to run the model within a Jupyter environment, and plot example output. Installation instructions for installing Jupyterlab can be found at https://jupyter.org/install <code>CSCM_example_textinput.ipynb</code> runs a simple emissions run with ssp245 data from 1900 to 2050, using input data text files stored in the <code>tests/test-data</code> folder <code>CSCM_example_directinput.ipynb</code> illustrates an interactive case, where ssp data is read into the environment and passed directly to the model

prescripts

Inside the scripts folder is a folder called prescripts. It contains scripts that show how to prepare perturbation files for a run and two example datafiles. And includes scripts to prepare natural emissions files.

Development

<code>git clone git@github.com:ciceroOslo/ciceroscm.git</code>

<code>git checkout -b your-cool-branch-name</code>

<code>git status</code>

It will tell you the branch you are on, changes since last etc

<code>git add path-of-file-that-changed</code>

Repeat this for all the files that you would want to commit the changes for

<code>git commit -m "A small message to describe the changes"</code>

<code>git push</code>

(The last one is to push the changes to the github version. The first time youi do this on a new branch you will need to set where to push to, but how to do that will be suggested when you just do git push)

<code>git checkout main</code>

<code>git pull</code>

<code>git checkout your-cool-branch-name</code>

<code>git merge main</code>

If all goes well this will fill your terminal with a merge message in your default editor, which is likely vim. The message there is likely ok as it is, so to just use that as a commit message for the merge type: <code>:wq</code> which will just save and quit vim and complete the merge with the original commit message.

Then finally just push your code to the web.

<code>git push</code>

The last part is just to pushed this new version of your branch again

Test suite and environment

The code comes with a suite of tests and tools. To use this you must do:

<code>make first-venv</code>

<code>make virtual-environment</code>

This should only be necessary the first time you setup the code You can load this environment with

<code>source venv/bin/activate</code>

Later to update you should do:

<code>make virtual-environment</code>

Or if you know you need updates, but aren't getting them:

<code>make clean</code>

<code>make virtual-environment</code>

After this you should be able to run the automatic tests

<code>make test</code>

Will only run the tests

<code>make checks</code>

Will run the tests and formatting tests

Before your code branch can be merged into the main code, it has to pass all the tests (The makefile also has an option to run only the formatting checks) Tests are located in tests in tests/test-data/ data for testing against fortran runs and test input data are stored. In tests/unit there are unit tests for certain methods. In test/integration there are integration tests of the code, comparing the results to fortran. When you develop new code, try to think about what can be done to test and validate that your code does what you expect it to do, and try to integrate such tests into the automatic testing scheme.

General code flow

The main code consists of four modules