Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strategy for daily model and sfc type model implementation in OGGM #1703

Open
fmaussion opened this issue Apr 4, 2024 · 2 comments
Open

Comments

@fmaussion
Copy link
Member

@bearecinos after our meeting and some thinking with @lilianschuster, I'd suggest the following:

If you can solve most of the failing tests on mb-sandbox in a reasonable time, it's worth spending the effort to have a benchmark we can work with. However, @lilianschuster said that there is also quite some boiler-plate code that might hinder development itself, so if this gets too complicated maybe drop this step altogether.

Regardless of the outcome of the above, perhaps the easiest would still be to start from scratch on OGGM core itself, by:

  • starting a new module called massbalance_sandbox.py in oggm/core
  • creating a first class called DailyTIModel which mirrors MonthlyTIModel but uses @lilianschuster's code to deal with daily inputs
  • DailyTIModel can be tested the same way as MonthlyTIModel and it can be quite shallow, for example by copiing some of the tests in
    def test_mb_calibration_from_scalar_mb(self):
  • Surface type distinction will come after that.

Thoughts?

@bearecinos
Copy link
Member

bearecinos commented Apr 4, 2024

Yep sounds good ... happy to start the script and the class and ask input when needed. The aim first would be to re-create that test_prepro.py::test_mb_calibration_from_scalar_mb with @lilianschuster's classes/code and go from there... to put together the new massbalance_sandbox.py script.

@bearecinos
Copy link
Member

bearecinos commented Jun 3, 2024

@fmaussion @lilianschuster
I've started working on this and the first thing that I notice is that before the DailyTIModel class we might need another Superclass e.g. class MassBalanceModel(object, metaclass=SuperclassMeta): at the top?

Lili's code has a different way of defining that though.. She has a TIModel_Parent class which does not look quite the same? The parent class deals with chosen different MB types within Lili's code (e.g. smb with surface type distinction etc)
The question is perhaps more for @lilianschuster:
The code that we want to keep and integrate is it both? the: TIModel_Parent(MassBalanceModel) and TIModel(TIModel_Parent): or just the TIModel(TIModel_Parent):?? I guess the main feature is everything related in both classes to the mb_type = mb_real_daily

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants