Re-evaluating support for timevarying depth dimension

[VeckoTheGecko]

To support timevarying depth we have Field.set_depth_from_field() and "not_yet_set" in the dimension dict (this is outlined in tutorial_timevaryingdepthdimensions.ipynb). This feature, however, is quite intertwined with the codebase (in FieldSet._check_complete as well as the filebuffer operations, among other places).

Is this a feature that we're looking to bring into v4? (iirc our discussion during the hackathon mentioned not having time-evolving grids). Perhaps drop but look to include in a later version of v4?

I take it that the Sgrid/Croco discussion we were having before is unrelated to this @erikvansebille ?

[VeckoTheGecko]

Just noticed your comment in #1844 @erikvansebille

• SGrids and time-varying depth dimensions (since they can be handled with the CROCO-type-advection kernel?)

Perhaps you could elaborate here on this idea?

[erikvansebille]

Yep, good point about SGrid support. I fully agree that it is highly intertwined code that massively complicates the transition to v4. So I was completely ready to axe it, also because I assumed it was not/rarely used. And then I spoke to @sruehs, who mentions she now uses Parcels on an SGrid model in production, and I started doubted again.

Perhaps the best strategy is, as you proposed above, to for now remove the SGrids as we work on v4-implementation, but then (between the release of v4-alpha and v4) try to put SGrid support back in. But then from the ground up, also taking into account how we treat SGrids in Croco.

Is that a plan?