Thanks to visit codestin.com
Credit goes to github.com

Skip to content

feat: Generic cos sin from rad filter #180

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 3 commits into from
Oct 30, 2025
Merged

feat: Generic cos sin from rad filter #180

merged 3 commits into from
Oct 30, 2025

Conversation

@MeraX
Copy link
Contributor

@MeraX MeraX commented Oct 23, 2025

Description

This filter converts a variable in radian to the cosine and sine of the variable.

What problem does this change solve?

The available cos_sin_mean_wave_direction filter expects values in degree.

What issue or task does this change relate to?

Additional notes

As a contributor to the Anemoi framework, please ensure that your changes include unit tests, updates to any affected dependencies and documentation, and have been tested in a parallel setting (i.e., with multiple GPUs). As a reviewer, you are also responsible for verifying these aspects and requesting changes if they are not adequately addressed. For guidelines about those please refer to https://anemoi.readthedocs.io/en/latest/

By opening this pull request, I affirm that all authors agree to the Contributor License Agreement.

@github-project-automation github-project-automation bot moved this to To be triaged in Anemoi-dev Oct 23, 2025
@github-actions github-actions bot added the tests label Oct 23, 2025
@MeraX MeraX requested a review from b8raoult October 23, 2025 16:38
@MeraX MeraX changed the title Generic cos sin from rad filter Feat: Generic cos sin from rad filter Oct 23, 2025
@MeraX MeraX changed the title Feat: Generic cos sin from rad filter feat: Generic cos sin from rad filter Oct 23, 2025
aaron-hopkinson
aaron-hopkinson reviewed Oct 28, 2025
View reviewed changes
Copy link
Contributor

@aaron-hopkinson aaron-hopkinson left a comment

Choose a reason for hiding this comment

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

Thanks for this @MeraX.

The code looks good to me, but I wonder if it might be better to add an optional argument to the existing cos_sin_mean_wave_direction filter (and potentially generalising this)? (We could also consider adding additional entries in the registry which handle the specialised cases).

What do you think?

@MeraX
Copy link
Contributor Author

MeraX commented Oct 28, 2025

Hi Aaron,

thanks for your comment. I was also thinking about a generalisation and discussing it a bit with @b8raoult. There are a couple of options:

  1. Have a general filter with a scaling parameter to convert from deg2rad and vice versa. Then derive a filter class with scaling=1 for cos_sin_from_rad and scaling=pi/180 for cos_sin_mean_wave_direction.
  2. Have said scaling as an argument to be defined by the user with a single filter class. The scaling argument could also be exposed in the form of some units parameter that can be radian or degree.
  3. Pipe the data through a rescale filter to convert from degree to radian and have just a single cos_sin filter with documented expected input units.
  4. Accept the fact that cos_sin_mean_wave_direction and cos_sin_from_rad differ significantly in terms of the few operations executed, but that their boiler plate is identical.

Baudoin and I chose 4th option to not overcomplicate this filter in terms of OOP. However I'm open, if you could imagine a simpler implementation.

It would nice to deduce the units from the metadata, however, I think this is impossible. The correct units might be available as part of the ekd.Field metadata in the forward_transform, but how should backward_transform guess the units?

Anyway, for generalisation, I would recommend giving the degree-variant of this filter a more general name, perhaps defining an alias for backward compatibility.

@aaron-hopkinson
Copy link
Contributor

aaron-hopkinson commented Oct 30, 2025

@MeraX

Given the simplicity of the filter, I'm not averse to option 4 for now. 🙂
Longer term, I'd like to try to reduce the amount of boilerplate associated with creating a filter and we should consider some of the options you proposed as part of some future work here – but it's not urgent, so let's not block adding this.

It would nice to deduce the units from the metadata, however, I think this is impossible. The correct units might be available as part of the ekd.Field metadata in the forward_transform, but how should backward_transform guess the units?

@b8raoult has been doing some work recently to track the processing of variables through anemoi (ecmwf/anemoi-datasets#437), I suspect that this might be a way of solving this problem.

Anyway, for generalisation, I would recommend giving the degree-variant of this filter a more general name, perhaps defining an alias for backward compatibility.

Sounds good to me. Would you like to make that change? (Happy to either add it to this PR, or you can create another – whatever you prefer).

@MeraX
Copy link
Contributor Author

MeraX commented Oct 30, 2025

@aaron-hopkinson, Thanks for your comment.

Would you like to make that change? (Happy to either add it to this PR, or you can create another – whatever you prefer).

I would leave that to a separate task and PR.

@aaron-hopkinson
Copy link
Contributor

aaron-hopkinson commented Oct 30, 2025

No worries, thanks @MeraX. I'll merge this. Feel free to ping/@ me on the other PR when it's ready.

@aaron-hopkinson aaron-hopkinson merged commit 7fabff9 into main Oct 30, 2025
71 checks passed
@aaron-hopkinson aaron-hopkinson deleted the generic_cos_sin_from_rad branch October 30, 2025 11:08
@github-project-automation github-project-automation bot moved this from To be triaged to Done in Anemoi-dev Oct 30, 2025
@DeployDuck DeployDuck mentioned this pull request Oct 30, 2025
Merged
aaron-hopkinson pushed a commit that referenced this pull request Oct 31, 2025
@DeployDuck
chore(main): Release 0.1.18 (#178)
bf3a828 
🤖 Automated Release PR

This PR was created by `release-please` to prepare the next release.
Once merged:

1. A new version tag will be created
2. A GitHub release will be published
3. The changelog will be updated

Changes to be included in the next release:
---


##
[0.1.18](0.1.17...0.1.18)
(2025-10-30)


### Features

* Add AccumToInterval filter transform
([#168](#168))
([0801a4b](0801a4b))
* Generic cos sin from rad filter
([#180](#180))
([7fabff9](7fabff9))


### Bug Fixes

* Clarify error message
([#181](#181))
([1cd0536](1cd0536))
* Remove variable from xarray metadata when grouping
([#182](#182))
([46465cd](46465cd))

---
> [!IMPORTANT]
> Please do not change the PR title, manifest file, or any other
automatically generated content in this PR unless you understand the
implications. Changes here can break the release process.
> ⚠️ Merging this PR will:
> - Create a new release
> - Trigger deployment pipelines
> - Update package versions

 **Before merging:**
 - Ensure all tests pass
 - Review the changelog carefully
 - Get required approvals

[Release-please
documentation](https://github.com/googleapis/release-please)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@aaron-hopkinson aaron-hopkinson aaron-hopkinson approved these changes

@b8raoult b8raoult Awaiting requested review from b8raoult

Assignees

No one assigned

Labels

ATS Approval not needed tests

Projects

Anemoi-dev
Status: Done

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@MeraX @aaron-hopkinson