Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Different results for `run_until` and `run_until_and_store` #710
Thanks for the nice post!
I think it's reasonable to make run_until (or, maybe even better: the flowline model) stop at each MB year. On top of the reason you mention, another argument is the mass-balance: indeed, if we significantly exceed the first MB month with the last time step of the preceding year we are making a big difference.
So actually I have the feeling that the flowline model should have an option to force some steps, and the default should be to follow the updates of the mass-balance model.
This is again a very quick though from Reading class-room, but it sounds sensible to me.
cc @juliaeis who might be affected by this change as well.
Yes, this is why I actually suggest to implement it in
No, it should be exact same. (and for the older default
I don't understand what you mean. But the CFL will only very rarely lead to steps larger than weeks or months, very often much shorter. We still need it for numerical stability, but the new check will just make sure that the step meets each new MB year's start.
if you used
The CFL condition is to determine the actual time step within the flowline model: Even if you run your model for 1 year (
As for the timing: Some very basic and non significant tests gave me around ~5% difference between
Edit: This was meant as an answer to @juliaeis . But I got distracted while writing it so Fabi's answer came first.
So I tried to tackle this issue and I came to a couple of conclusions. The first being: Gepatschferner, the glacier shown in the example above is just a really really weird glacier!
Second conclusion: The difference might not be as big as I initially thought. The main reason being that OGGM's flowline model default timestepping sets an upper limit of 10 days. And even the 'ambitious' timestepping only uses 15 days as upper limit. So yes this can and does cause a difference, but it should be small for not so weird glaciers...
I implemented a limiting scheme (PR #743 ) and here are the length and volume differences between the current and my implementation for Hintereisferner :
As HEF always works well, I randomly picked Oberer Grindelwald glacier and there the differences are basically none existing:
If we would proceed from here this for sure needs some more testing, but to be honest I am not even sure if it is necessary. Problems with glaciers like Gepatschferner will not be solved by this.