• For developers who work with CompartmentalSystems LAPM and testinfrastructure simultaneously:

  • Clone the repository and its submodules:

    • If you do not have a bgc_md2 repo yet:

      git clone --recurse-submodules https://github.com/MPIBGC-TEE/bgc_md2.git

    • If you already have a bgc_md2 repo (and want to keep it):

      • Pull the changes in bgc_md2 and the submodules simultaneuously:

        git pull --recurse-submodules
        

      • Make sure that the submodule folders in src are not empty.

        git submodule init
        git submodule update
        

  • Update conda

    conda update --all
    

  • Create a conda environment and run the install script:

    conda create -y --name bgc_md2
    conda activate bgc_md2
    ./install_developer_conda.sh 

    This will install the dependencies and run python setup.py develop for every subpackage so that your code changes in one of these packages take mmediate effect.

  • Run the tests.

    cd tests
    ./run_tests.py
    

    If you can run this script successfully, you have a working installation of bgc_md and can run all functions.

  • Troubleshooting:

    • We noticed that in MacOS, it is necessary to update packages in the conda environment before running the tests successfully. Try to update conda ( conda update --all) and run the tests again.

  • Working with the installation:

    • pulling: Since you will nearly always pull with the --recurse-submodules flag
      consider creating an alias

      git config alias.spull 'pull --recurse-submodules'
      

      which enables you to say git spull to achieve the same effect

    • Tips to work with git submodules:

• The latest build of the package documentation can be found here:.

The package is supposed to assist in the creation of 'reports' in the form of jupyter notebooks. The notebooks will be of the following types.

1. Investigations of a single model (or modelrun).
2. Comparisons between models (modelruns).

In the first case the role of the bgc_md package is to guide the user (=author of a particular notebook concerned with a particular model, and simultaniously author of the source.py of that model) by using the computability graph (as represented by bgc_md/resolve/MvarsAndComputers.py) to either

• show which addidional results can be computed, given the information already present in the models `source.py' or
• show which additional information has to be provided in the models source.py to be able to obtain a desired result.

In the second case the same assistance is required for queries, which are best described by examples.

• Create a table including all the models for which we can compute the compartmental matrix (from whatever Mvars are provided, in the different model files)
• Compute the maximum set of Mvars we can compute for a given set of models
• ...

• The 'Computers' and 'MVars' represent a set of types and strictly typed functions (including the return values). This has been implemented with the new python type annotations.
  An advantage is that we can express our idea in a well defined and well documented way and avoid extra effort for the user..
• The computibility graph is expensive to create and only changes if new Computers and MVars are created. It should be cached, which encurages the use of immutable data structures. (since we can use functools )