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

Question about runoff conversion #265

Open
JKALanger opened this issue Nov 30, 2022 · 3 comments
Open

Question about runoff conversion #265

JKALanger opened this issue Nov 30, 2022 · 3 comments

Comments

@JKALanger
Copy link

JKALanger commented Nov 30, 2022

Question

Description

In convert.py, one comment in the code says that the hydrological parameters are in "m of water per day" and that they need to be multiplied by 1,000 to get to m3/hour.

However, the ERA5 documentation for runoff says that the runoff is aggregated per hour (see attachment), so is the division by 24 really necessary? Also, why is it multiplied by 1,000? The conversion from "m per day" to m3/hour implies that the unit of the coefficient is m2, so do you assume an area of 1,000 m2 and if so, why?

Thanks for clarification and your continued work on atlite.

@coroa
Copy link
Member

coroa commented Dec 1, 2022

You are right in both points that the unit conversion is inconsistent.

There was quite some iteration in the used datasets and projections in the beginning. When this was conceived it used a different runoff dataset which reported runoff in kg / m^2 / day which is about equivalent to mm / day and had shapes with areas that were given in km^2 so that you had to do:

mm / day * km^2 = 1 / 1000 * m / 24 / h * 1000^2 m^2 = 1000 / 24 * m / h

But none of this is valid anymore with the current era5 dataset and the cea projection, which uses metres directly.

But it also does not matter too much, since this function is mostly intended to generate a profile rather than a full inflow estimation for each power plant. ie. the output of this function should be rescaled according to historical output at measurement points in the river or historical annual/monthly generation of plants; so that whatever global factor is put in, will normalize out anyway.

You're invited to submit a quick PR to fix it here now.

@JKALanger
Copy link
Author

Thanks for the fast and clear response.

Sorry, but I am rather new to GitHub, so I don't know how PR work. But if I understand correctly, you would just need to remove the (1000.0 / 24.0 ) term from the code.

@coroa
Copy link
Member

coroa commented Dec 1, 2022

Indeed

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

No branches or pull requests

3 participants