@valeriupredoi this originally stemmed from a desire to align as-close-as-possible to CF. But from discussion today we can't see a practical reason why cell measures shouldn't be masked.

So we'll leave this open as a future development task. If this is a priority for you please let us know.

we can't see a practical reason why cell measures shouldn't be masked.

Oh dear, I think it was me said that.
Now I looked at the code, where this is specifically dis-allowed for cell-measures only

This test was added as a specific exclusion in this PR
-- though the code has since been refactored somewhat, so it's not that obvious.

The argument given is "We can't save masked points properly, as we don't maintain a fill_value"
I guess the danger envisaged is that we might have masked data with a specific fill-value set on the array, and we don't support any way of making that the fill-value actually recorded in the netcdf file, so it could generate missing-point collisions.

Altogether It's a pretty theoretical idea of a potential problem : points masked in the array will be saved as default-missing-value, but there might also be unmasked points with that value : Highly improbable, except for integer data.
And this code is supposed to detect and (at least) warn about that occurrence.

So, I really don't agree with this argument -- and especially as it should apply equally to aux-coords, and ancillary variables (added much more recently), and those we don't disallow.
( N.B. the user can avoid the problem for cube data (only), by specifying fill_value(s) in the save operation )

So I think if all agree we could quickly make a change to just remove this check
Any contrary opinions ? speak now !

cheers gents! Not a priority nor anything stringent for us, just thought I'd raise a flag or two - if you guys decide to keep it we'd be finding a workaround, and in fact, one of @bouweandela 's current PRs (in ESMValCore) is inadvertently fixing this 👍

cheers gents! Not a priority nor anything stringent for us, just thought I'd raise a flag or two - if you guys decide to keep it we'd be finding a workaround, and in fact, one of @bouweandela 's current PRs (in ESMValCore) is inadvertently fixing this +1

Nevermind the second part of my statement - that was a bug, that is now fixed, so we're back at hitting this. It'd be cool if you guys removed the raise as @pp-mo mentions, or both the check and raise 😁

hey guys - we're still hitting this with iris=3.4.1 - not sure why you folks closed the issue 😕

hey guys - we're still hitting this with iris=3.4.1 - not sure why you folks closed the issue 😕

Hi @valeriupredoi, this feature was first available in v3.5.0rc0. See 897a7cb:

ahaa cheers @trexfeathers - let me update then, thanks for the heads up, I jumped the (version) gun

with iris=3.5 all goes smoother than a Ferrari's paint work, many thanks @trexfeathers and the iris gang 🍺