When does filter commute with derivatives?

[NoraLoose]

What settings do I have to choose in constants.hpp to guarantee that the filter commutes with derivatives? I suspect

• DEFORM_AROUND_LAND = false (does this mean: don't change the kernel shape close to land?)
• FILTER_OVER_LAND = true (or is this option merely about whether the output is masked or not, and does not impact the actual filter algo?)

These questions are not part of the JOSS review process, just for my own curiosity.

[NoraLoose]

Is EXTEND_DOMAIN_TO_POLES important for this question too?

[bastorer]

Yep, you're correct!

DEFORM_AROUND_LAND sets whether or not the kernel shape changes to account for land masking. Setting to false keeps the shape consistent. A zero value is used where the kernel would overlap land.

FILTER_OVER_LAND is necessary if you have DEFORM_AROUND_LAND=false and you want to conserve energy. Coarse-graining over land will smear some of the energy a distance of ell/2 inland from the coast. For example, if ell = 500km, then a point 100km inland from the coast would 'see' some water cells in its filtering kernel, and so could have a non-zero coarse-grained velocity. As you filter over progressively larger and larger scales, you'll see the continents be slowly eroded with FILTER_OVER_LAND = true, but the domain integral of energy will be conserved.

Because of this, the post process files include region areas that include land as well as region areas that only account for water. That way, if you want an energy density, you can renormalize by just the water area and not the land area.

EXTEND_DOMAIN_TO_POLES is also relevant for this question. The NEMO dataset that we work with, for example, has a constant Antarctica land mask, and to save on unnecessary storage, doesn't have latitudes south of 80S in the dataset (I don't remember the exact number, but it's around there). If you then tried to filter at a point centred on 78S, if the kernel was large enough to extend past 80S, it would the implicitly deformed by the lack of datapoints. Setting EXTEND_DOMAIN_TO_POLES = true pads the grid to put in any missing polar cells so that the outputs have the full latitude range.

To summarize:

• If the dataset that you're using has a full sphere (i.e. all latitudes), then setting DEFORM_AROUND_LAND = false will be enough for commutativity.
• If the dataset truncates off one or both of the poles, you'll also need EXTEND_DOMAIN_TO_POLES = true to put them back in and have commutativity. [ Note: points at the actual poles aren't needed, but a missing latitude range is bad ]
• FILTER_OVER_LAND shouldn't impact commutativity, but it will impact conservation properties if DEFORM_AROUND_LAND = false since some energy will be lost to land and not included [ although, fun fact, deforming the kernel around also does not guarantee conservation laws, and can lead to either gaining or losing energy! ]

[bastorer]

A short follow-up on this:

A zero value is used where the kernel would overlap land.

This is only applicable for things like velocity, where it should be going to zero along the coastline, and so extending with zeros into land is valid / reasonable.

For other fields, such as density, pressure, and SSH, a zero extension isn't valid. For those, more complicated methods are required. In particular, FlowSieve includes a multi-scale interpolator using radial basis functions via the ALGLIB library. This would be done in pre-processing to create a new density field that extends over land, with the interpolated density then being passed in to coarse-graining.

This feature isn't highlighted in the documentation and tutorials yet. It's a fairly computationally expensive routine, and hasn't been the focus of our usage so far. Cleaning up that workflow and formalizing a tutorial for it is on the to-do list, but since its not necessary to filter velocity fields, hasn't been a focus.

[NoraLoose]

Thanks so much for these detailed explanations @bastorer. They are super clear! I suspect that other users will be interested in these answers too, since commutativity is a big pro of the FlowSieve filter operator.

We could leave this issue open for future reference? Alternatively, these points could be included in the documentation in the long run (if you agree this would be useful), whenever someone has time to do it.

[bastorer]

I'll plan to wrap this into the documentation, but in the mean time leaving the issue open for reference sounds good :-)