Are there regression tests for ZStarCoordinate? I am worried this issue affects the fidelity of zstar.

Question relating to this PR as I am wondering if the misalignment happens elsewhere: Should there be a dispatch for operators such that if the argument is in the wrong location it throws?

Question relating to this PR as I am wondering if the misalignment happens elsewhere: Should there be a dispatch for operators such that if the argument is in the wrong location it throws?

Hmm. We could implement that. However, it would only throw an error on CPU beacuse on GPU, Field is adapted to Field.data. But as I write this, I think that your idea will still work because we would still get that error in tests, which is sufficient to prevent it. This would be a pretty simple PR (the code could be generated with metaprogramming). I think this is actually a great idea; we can't automatically infer which operator to use, but we can throw an error if the wrong operator is used on CPU and this effectively achieves the same thing!

Are there regression tests for ZStarCoordinate? I am worried this issue affects the fidelity of zstar.

There are tests for the conservation of tracers in z star and the fidelity of the implicit solve.

Are there regression tests for ZStarCoordinate? I am worried this issue affects the fidelity of zstar.

There are tests for the conservation of tracers in z star and the fidelity of the implicit solve.

Interesting. I think this change concerns whether the pressure gradient is correct. We may not be testing it.

I think we should merge this asap

I am a bit afraid of the possible loss of performance, but ok let's merge it and keep it in mind

maybe we can add a zstar option in the benchmarks PR, if we see there is a very large difference between zstar and static coordinate we can worry otherwise there is no issue.

We should also have immersed-boundary-aware interpolations for this derivative to be actually correct across immersed boundaries

We should also have immersed-boundary-aware interpolations for this derivative to be actually correct across immersed boundaries

should we do that in this PR?

I am a bit afraid of the possible loss of performance, but ok let's merge it and keep it in mind

we can add the pressure gradient calculation based on buoyancy back if needed. There is a trade-off; one is a derivative but the other requires evaluating TEOS10?

are the failing tests related? should we merge this?

They do not seem to be related. I think we can merge this. Distributed tests are acting up a bit