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

Clarify time handling (+bugfix) #352

Merged
merged 4 commits into from
Nov 10, 2017
Merged

Clarify time handling (+bugfix) #352

merged 4 commits into from
Nov 10, 2017

Conversation

fmaussion
Copy link
Member

@fmaussion fmaussion commented Nov 10, 2017

closes #348

@fmaussion
Copy link
Member Author

This PR:

  • solves a very small bug where the floating months in output file where not of the exact correct length because I used calendar months instead of the hydrological ones
  • clarifies the model output time format by naming the coordinates the right way and by storing calendar as well as hydrological dates
  • the compile_input_climate time format is now in line with the model output

Working in hydrological years might be confusing at first but this is what we want for the model output. With this format it is now possible to compute annual averages based on both calendars. The recommended way is simply: ds.groupby('hydro_year').mean(dim='time') for example

@fmaussion fmaussion requested a review from anoukvlug November 10, 2017 16:26
@fmaussion
Copy link
Member Author

cc @jlandmann

@fmaussion fmaussion merged commit 358c525 into OGGM:master Nov 10, 2017
----------
hydro_year : bool
If the float year follows the "hydrological year" convention or
not (default:True)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to include in the description that y1 or yn need to be defined. On the other hand it is very clear when you read the function how it works, so it might not be really needed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are right the docstring is not complete here

@@ -238,6 +238,7 @@ def __init__(self, gdir, mu_star=None, bias=None, prcp_fac=None,
ny, r = divmod(len(time), 12)
if r != 0:
raise ValueError('Climate data should be N full years')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it is a good moment to also include checking if the climate data actually start in January.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we assume the that the data starts in October (because of the hydrological year)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow I mixed things up, but you are right.

diag_ds['ela_m'] = ('time', np.zeros(nm) * np.NaN)
diag_ds['ela_m'].attrs['description'] = ('Annual Equilibrium Line '
'Altitude')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the Equilibrium Line Altitude is by definition annual, therefore I believe that the word 'annual' is redundant in this case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. I'll keep it that way though: because of implementation details, it is still stored at a monthly time step, so to make it clear I added the "Annual"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't think of that, but in that case it makes indeed a lot off sense to leave it like it is :)

@fmaussion
Copy link
Member Author

Thanks for the review! Next time I'll try to wait a bit more before merging ;)

@anoukvlug
Copy link
Collaborator

Thanks @fmaussion for making the changes, it made things more clear to me :)

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

Successfully merging this pull request may close these issues.

The OGGM "time format" should be clearer
2 participants