or better: delete

Some time arrays in the SnowFirnCover class mix dt.datetime and np.nan.
I think using np.datetime64 and np.naT might be a cleaner solution, although np.datetim64 seems to be a slower => this needs testing!

Not many people care about Python 2.7 anymore

We haven't yet determined a license for the project!

Unlike the temperature gradient, which is straightforward to calculate from the meto grids input, the precipitation gradient needs a more careful treatment.
At the moment we use the grid as well to determine the gradient, however especially with the problem of spatial variability in precipitation messing up the gradient calculation.
We should think of a better solution, for example including only cells that intersect with the glacier outlines or that fall into the glacier basin.

For the glaciers where we have MB measurements, the preciptation gradient could be calibrated on extrapolated snow pit measurements.

The image size in the README is horrible.
However, changing the parameters in the RST file doesn't seem to help, because (by a bug), GitHub doesn't evaluate the parameters properly ( see github/markup#295).
Sooner or later this should be fixed by introducing smaller images.

Instead of saving snow/firn in layers as they precipitate, they should be restructured e.g. one per year by merging the lowermost layers. This would allow e.g. an exponential decrease in minimum layer SWE with depth.
This would save a lot of storage.

To scale shortwave radiation in terrain with the helpt of potential radiation, we currently use Meteosat total shortwave incoming radiation, assuming a fixed proportion of 20% diffuse radiation. This ensure that radiation does not become zero, but is a very poor solution. We should go ehead and try to use the Meteosat diffuse radiation for the downscaling as well.

Poetry is much faster than conda....

To run CRAMPON operationally on the server, we currently need VPN access to fetch all the LFI DEMs from speedy-11-12-fs.wsl.ch (speeds seems to be closed within the WSL domain).
ISG doesn't allow our servers to be within a VPN, so we need to think of a different solution.

Trying to access speedy without being in VPN leads to an ugly console crash without proper error message that @lgeibel has experienced.

Up to now, the syncing function just compares to file lists. I could not use rsync itself, as it is not ensured that both machines are unix-like.
Definitely, this should be replaced sooner or later, at least by an algorithm that uses checksums.

Hints are here:
https://blog.liw.fi/posts/rsync-in-python/
https://stackoverflow.com/questions/21550106/paramiko-recursive-directory-copy-python

These two models are potential candidates for the ensemble as well:

1. Giesen and Oerlemans (2012): Giesen, R. H., & Oerlemans, J. (2012). Calibration of a surface mass balance model for global-scale applications. The Cryosphere, 6(6), 1463-1481.
2. The "Alternative Temperature Index Melt Model" from : Reveillet, M., Vincent, C., Six, D., & Rabatel, A. (2017). Which empirical model is best suited to simulate glacier mass balances?. Journal of Glaciology, 63(237), 39-54.

The WMO-SPICE project offers a lot of output to correct solid precipitation measurements. At least some of them should be implemented - maybe in a community effort together with MeteoSwiss and the SLF OSHD.

There is a nice curve describing the snow-rain phase transition as a function of temperature in the paper by Jan Magnusson:

https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/2016WR019092

Start off here:
pydata/xarray#501

We should start testing using an environment that is based on at least Python 3.8

Up to now, OGGM refers to the grid cell which is closest to the RGI Centroid and uses this as reference for meteo input calculation (see here).
As our data have a 0.02° resolution (~2km), it might be worth thinking about considering all cells that intersect/ the glacier geometry, but e.g. a minimum 5x5 window around the centroid.

The Cirrus connection needs a VPN connection into the WSL network which has to be activated externally.
There should be some piece of code which is able to check/open up a VPN connection with credentials.

Hints are here:
http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/anyconnectadmin30/ac15userguidelines.html (but restricted to Cisco :/)

Now, in the operational module, we just check if the date of yesterday is available in the climate file.
It would be way better to check if all variables, i.e. temperature, precipitation and soon radiation are there => if one is not present, the retry decorator should catch this case.
If radiation is not there, one could start the radiation-independent mass balance calculations. However, this might be a bit advanced for the moment....