cryogrid / cryogridcommunity_source

This is the community version of CryoGrid, a numerical model to investigate land surface processes in permafrost environments.

CryoGrid community model

This is the community version of CryoGrid, a numerical model to investigate land surface processes in the terrestrial cryosphere. This version of CryoGrid is implemented in MATLAB.

Note: This is the latest development of the CryoGrid model family. It comprises the functionalities of previous versions including CryoGrid3, which is no longer encouraged to be used.

Documentation

The paper "The CryoGrid community model - a multi-physics toolbox for climate-driven simulations in the terrestrial cryosphere" in published in Geoscientific Model Development and contains a description of the model and instructions to run it (Supplements 1, 3).

Getting started

Both CryoGridCommunity_source and CryoGridCommunity_run are required. See CryoGridCommunity_run for details. An instruction video on downloading the CryoGrid community model and running simple simulations is available here: https://www.youtube.com/watch?v=L1GIurc5_J4&t=372s The parameter files and model forcing data for the simple simulations from the video can be downloaded here: http://files.artek.byg.dtu.dk/files/cryogrid/CryoGridExamples/CryoGrid_simpleExamples.zip

Get involved

There is an email group for news, (high-level) discussions and invitation to the annual hackathon, as well as a slack for debugging, (low-level) discussions, community building and other things CryoGrid-related!

cryogridcommunity_source's Issues

PPROVIDER_EXCEL requires initialize_excel in all classes

The new PPROVIDER_EXCEL requires an initialize_excel method to be present in all classes in order to be compatible.

What is the intention behind requiring this dependency?

It breaks the design philosophy that the core model classes should be unaware how parameters are obtained.
When a new PROVIDER class is implemented, all other classes in the model will have to be modified with a new initialize_newprovider method, if we are to follow the PPROVIDER_EXCEL implementation.

What is the use case scenario, where a particular class needs to know if the data came from an Excel or a Yaml file or something else?

Could we change it to just a generic initialize method, without loss of functionality, and thus avoid touching all classes when a new provider class is implemented?

Setup a dynamic documentation like ReadTheDoc for all members to openly contribute

ReadTheDoc hosts freely documentation for open-source project. The documentation could be hosted on readthedoc, and then the content be on a Github repository under the project/user Cryogrid called cryogrid-doc for instance.

Here is a simple tutorial to set it up: https://tutos.readthedocs.io/en/latest/source/git_rtd.html

To start, the admin of the project can set it up and material can then be added by community members. The PDF content can be brought to the doc as a starter.

FORCING classes have hardcoded path to forcing data

With the recent code restructuring, FORCING classes no longer receive the forcing data path specified in the run file.
Instead, FORCING classes have hardcoded forcing paths.

In the new PPROVIDER class, all classes are instantiated the same, and therefore we cannot pass specific parameters to some instantiated classes.

Possible solutions:

• Pass all paths (result_path and forcing_path) to all instantiated classes, even those who don't need them
• Pass the PPROVIDER instance to new_class during initialization, and let the class itself grab additional parameters it might need from the PPROVIDER instance
• Require user to manually set the forcing_path after instantiation. In practice this would be handled by the TILE class right after retreiving the FORCING instance from the PPROVIDER

Which would be the better way?
Other suggestions?