Re-evaluating support for timevarying depth dimension
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 ?
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?
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?