-
Notifications
You must be signed in to change notification settings - Fork 105
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
Time limit in process_custom_climate_data #157
Comments
Hi Anouk, This is getting quite interesting, I'd like to know more about your plans ;-) But first, to your question: I expect that solving this problem won't be trivial, as there is an underlying problem in pandas and xarray (see e.g. pydata/xarray#789 for xarray, which relies on pandas: pandas-dev/pandas#7307 ). OGGM does not rely heavily on pandas datetimes so I think we could solve this problem without getting burned in a hell of changes, but on the top of my head I can't really make a prognostic about how much change this would imply. In fact, the dynamical model of OGGM already relies on a very simple time system (https://github.com/OGGM/oggm/blob/master/oggm/utils.py#L675-L718), which could be meliorated and extended (based on other peoples systems, as I hope we don't have to reinvent the wheel here). I know this is not very helpful, but yes a change that would make OGGM work on longer timescales is necessary (I just didn't have that in mind when I started :-( ) |
Hello Fabien,
into
to avoid using pandas. I don't know yet what to do with these lines: So far these are the only lines that has give me problems with the starting date. So hopefully this requires just a small change. I will let you know once I know more about what I what to do with those lines. Shortly summarised I would like to run OGGM with over the last ~1000 years with different climate simulations of the Community Earth System Model Last Millennium Ensemble (CESM-LME), to look at the influence of natural climate variability on glacier in the Canadian Arctic. Later on in my PhD I would like to use OGGM to make runs over the second half of the Holocene. |
Doesn't give a problem with the proper input file. I thought you could set the date of 'days since' yourself, but if you use just 'days since 1801-01-01' than it all works fine. |
Right, I see. So there are good news and bad news about that ;-)
|
Here follows an update on the conversation we had on Slack: I made a 'process_gcm_data' task in climate.py, which is based on a copy of the 'process_cru_data' task. ` @entity_task(log, writes=['gcm_data'])
It is still really unflexible, but I thought it is a good moment to share it anyway. To test if it was working I let is overwrite the monthly_climate.nc file, instead of creating a gcm_data.nc file. With the function:
Which is almost a complete copy of 'write_monthly_climate_file', and there for I put it just below that function in utils.py. In order to be able to save the file as gcm_data.nc, I added 2 line in the cfg.py:
And for convenience I added the following line in the task.py:
So this is the status for now. For it to make sense to include it in the code base I should make it more flexible I think. Next to that there might be some other things that need to be changed. I don't know if it would be better to discuss this further here or leave it for the oggm workshop, both is fine for me. |
Thanks for your work! Here an answer to your question:
Not necessarily. Currently this function would be used by you and only you, and there is a rule in programing: don't try to solve problem you don't know about (yet). (this goes together with "if it's not broken, don't fix it") ;-) So I would welcome a PR where we can discuss your code in more detail. Whether or not we will manage to merge this before the workshop I don't know, but at least we can get started. |
That is a funny rule, but it indeed makes sense. I will make a PR on Monday :) Have a nice weekend! |
When my climate file starts in 1600 (or earlier) the years are not recognized as years any more.
yrs = nc_ts.time.year
AttributeError: 'Index' object has no attribute 'year'
I'm planning to make some changes in my fork, to solve this problem.
Would it make sense to make a pull request of these chances later on?
The text was updated successfully, but these errors were encountered: