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

Why can we define a HybridPressureFactory without surface air pressure #6072

Open
schlunma opened this issue Jul 22, 2024 · 3 comments
Open

Comments

@schlunma
Copy link
Contributor

📰 Custom Issue

Iris allows defining a HybridPressureFactory without specifying a surface air pressure coordinate. The coordinate will be treated as 0 in this case.

I encountered this problem in a file with an invalid formula_terms: ap: ap b: ap ps: ps where ps does not exist in the cube. This will lead to the warning IrisCfMissingVarWarning: Missing CF-netCDF formula term variable 'ps', referenced by netCDF variable 'lev', but apart from that the cube is loaded and a wrong air pressure coordinate is created.

What's the reasoning behind this to allow that? I would have expected an error similar to the one that is raised for the AtmosphereSigmaFactory.

A similar problem happens for the HybridHeightFactory, which can also be created without orography.

@stephenworsley
Copy link
Contributor

@SciTools/peloton I believe this is due to generic code which will replace missing dependencies with 0. It seems like this effectively leads to nonsense in the case of HyridPressureFactory, though for HybridHeightFactory makes more sense, since it effectively describes a default of a spherical earth. There may be a case for adding logic which declines to build a coordinate (and raises a warning) when doing so would be nonsensical. How important do you consider it to be to avoid creating such invalid pressure coordinates?

@schlunma
Copy link
Contributor Author

Thanks for the answer @stephenworsley!

It's not super critical to me, but I think it would be helpful if iris would not create the factory if one of the formula terms is invalid instead of building a (potentially) wrong coordinate. I know that there is a warning, but it's super easy to ignore that, especially if the derived coordinate is present in the cube.

@pp-mo
Copy link
Member

pp-mo commented Aug 28, 2024

From @SciTools/peloton we think this is a good idea, but we're currently very resource-limited, so it's hard to see when this can get done.
So we think we'll have to leave this unresolved for now. If you want to propose new code, that might be a way forward, but it still needs attention from the team, and it's unclear when we will get around to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

4 participants