wave energy converters and new wind and wave data modules - #475
wave energy converters and new wind and wave data modules#475lmezilis wants to merge 53 commits into
Conversation
for more information, see https://pre-commit.ci
|
Thanks a lot for this nice feature! Can you let us know when you are ready for us to review it? @brynpickering Can I ask you to review it if you have capacity? Thanks! |
|
Thank you! I think we can review it right away, and I can prepare some files for documentation. Apologies for being very new to github procedures. I am slowly starting to get the hang of it. |
No worries, good that you mention it! We'll help you get settled in and don't hesitate to ask questions if something is unclear or to ping us (e.g. using |
brynpickering
left a comment
There was a problem hiding this comment.
Thanks for opening this PR @lmezilis ! As @euronion has mentioned, some documentation is needed. My comments are about implementation. I have no comments on the method, I'm sure you've got that right! There's lots of scope to clean things up, though, which will help us maintain the feature in future.
If you want any clarification on comments/suggestions I've made, just reply directly on the comment. If you are happy with a suggestion, you can just accept it and it will automatically update the code for you. You can always accept a suggestion but then make edits to it later.
One thing missing from the new files is a REUSE header. You can find equivalents in other files. The easiest is to just copy the one across from era5.py. Then, make sure your name is in AUTHORS.rst so you count as one of the "Contributors to atlite".
| features = { | ||
| "height": ["height"], | ||
| "wind": ["wnd100m", "wnd_shear_exp", "wnd_azimuth", "roughness"], | ||
| "wind": ["wnd100m", "wnd_azimuth", "roughness"], |
There was a problem hiding this comment.
you probably didn't mean to delete "wnd_shear_exp". I assume this is needed by other atlite methods.
There was a problem hiding this comment.
Yes I was working with an older version of atlite, this was accidental.
| "wave_height": ["wave_height"], | ||
| "wave_period": ["wave_period"], |
There was a problem hiding this comment.
Collapse this into a wave: ["wave_height", "wave_period"] option. Then users can request the wave feature and get both of these variables. It's unlikely they'd ever want one but not the other.
| Optionally (add_lon_lat, default:True) preserves latitude and | ||
| longitude columns as 'lat' and 'lon'. |
There was a problem hiding this comment.
you mention this option in the docstring but it isn't in the method signature. Do you want to include this option or not?
There was a problem hiding this comment.
this option was not necessary for the mrel wave files. I eventually renamed the dimentions in the last part of the script. I would say that the function "_rename_and_clean_coords" can be deleted here. do you think we should include this option?
EDIT: I saw the rest of the comments now, I will include the function and try to make it as similar to era5 as possible.
| def get_data_wave_height(ds): | ||
| ds = ds.rename({"hs": "wave_height"}) | ||
| ds["wave_height"] = ds["wave_height"].clip(min=0.0) | ||
|
|
||
| return ds | ||
|
|
||
|
|
||
| def get_data_wave_period(ds): | ||
| ds = ds.rename({"tp": "wave_period"}) | ||
| # ds["wave_period"] = (1 / ds["wave_period"]) | ||
| ds["wave_period"] = ds["wave_period"].clip(min=0.0) | ||
|
|
||
| return ds |
There was a problem hiding this comment.
Keep the process the same as in era5.py - split this into data retrieval and then sanitisation and call the sanitisation function only if requested in get_data (you can copy most of the functionality directly over from era5.py)
There was a problem hiding this comment.
EDIT: you don't actually need these get_data_... methods in this module, but having sanitize_... methods would be good. They can then be called iteratively in get_data as is done in era5.py
There was a problem hiding this comment.
you are correct, I was working with these files a long time ago, figuring out how which functions I need, will correct this!
|
|
||
| def get_data_wave_period(ds): | ||
| ds = ds.rename({"tp": "wave_period"}) | ||
| # ds["wave_period"] = (1 / ds["wave_period"]) |
There was a problem hiding this comment.
It's always better to rely on version history to recover lines of code you no longer need, rather than commenting them out. So, feel free to delete all your commented out lines!
There was a problem hiding this comment.
Yes, sorry for this, I thought I did that for every file but forgot this one.
| def convert_wave(ds, wec_type): | ||
| power_matrix = pd.DataFrame.from_dict(wec_type["Power_Matrix"]) |
There was a problem hiding this comment.
You should have a docstring here
| """ | ||
| Generate wave generation time series | ||
|
|
||
| evaluates the significant wave height (Hs) and wave peak period (Tp) |
There was a problem hiding this comment.
Since Hs and Tp are MREL-specific and wouldn't make sense if using ERA5 data, it might make more sense to not reference them by these acronyms in this file.
| # Ignore IDE project files | ||
| .idea/ | ||
| .vscode | ||
| .vs |
There was a problem hiding this comment.
It's generally best to add these pointers to your own "global" gitignore, rather than to every project you work on. That way, it never accidentally slips in without you realising it!
There was a problem hiding this comment.
Since CERRA is available via the Climate Data Store, we should follow the same approach to data retrieval as with ERA5. You could probably just copy era5.py directly and delete all but the wind getter method, then adapt the wind getter method to match the data available from CERRA.
It might be best to drop this from this PR, though, and bring it in separately later. I can see a benefit to changing the features we bring in for wind since we can retrieve wind speed at various height/pressure levels from CDS, which would allow us to create a wind vertical profile (as we do with ERA5 data).
There was a problem hiding this comment.
The problem with CERRA here is that there is a lot of preprocessing of data in order for atlite to be able to read it. I agree that it is best to review this later. Should I take an action on this or can you simply reject this file?
There was a problem hiding this comment.
The easiest is for you to simply delete this file (and reference to cerra elsewhere). If we want to revisit it, this file will still be in the commit history so we can bring it back if we want anything from it!
|
Hello @brynpickering, I have made all of the changes locally, should I commit changes in the forked branch or is there another way to continue? |
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
Yes, in the forked branch. You should be able to just always work in the forked branch and push to your own repository ("origin") whenever you make changes. Those changes will then be made visible in this PR |
brynpickering
left a comment
There was a problem hiding this comment.
Thanks for the changes @lmezilis. Just a couple of extra comments.
I still need to check the processing method, which I'll do now. In the meantime, it would be great to add some documentation. The easiest would be to add a jupyter notebook to examples and then link that into the docs by adding an entry into doc/examples (following the example of the other entries). The example notebook could load from era5 and mrel separately and maybe compare the results for a specific gridcell?
There was a problem hiding this comment.
The easiest is for you to simply delete this file (and reference to cerra elsewhere). If we want to revisit it, this file will still be in the commit history so we can bring it back if we want anything from it!
| """ | ||
| Rename and sanitize retrieved wave height data. | ||
| """ | ||
| ds = ds.rename({"hs": "wave_height"}) |
There was a problem hiding this comment.
No need, this renaming is happening in the main function now (rename(features)).
| """ | ||
| Rename and sanitize retrieved wave height data. | ||
| """ | ||
| ds = ds.rename({"tp": "wave_period"}) |
There was a problem hiding this comment.
No need, this renaming is happening in the main function now (rename(features)).
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
|
I made all of these similar commits because there are some things that I need to change in the syntax, but the pre-commit auto fix changes them back. I don't know why. |
|
@lmezilis no worries. We'll probably squash all these commits when we merge it in, so it'll all be cleaned up. You could install pre-commit locally so the fixes are managed locally. In your RE allowing data downloads, I've found that the OpenDAP fails when trying to download more than a few MB of data at once ( |
|
Yes I had the same problem the last few days even though last week I could complete it. I say for now lets keep it manual, and I will contact the server to see what we can do. |
|
@lmezilis we have some merge conflicts now. Do you want to resolve them by yourself or should I take over? I would review afterwards |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…/atlite into wecmatrices-datamodules
for more information, see https://pre-commit.ci
…/atlite into wecmatrices-datamodules
…atrices-datamodules
for more information, see https://pre-commit.ci
…atrices-datamodules
|
@FabianHofmann I made some adjustments and finally the pre-commit check is completed. I think we are ready to finalize this PR. |
Closes # (if applicable).
Changes proposed in this Pull Request
Checklist
doc.environment.yaml,environment_docs.yamlandsetup.py(if applicable).doc/release_notes.rstof the upcoming release is included.