Combined vertical fluxes on Basin

[visr]

One limitation of the way we save flows in #644 is that we cannot separate the 4 basin fluxes (precipitation, evaporation, drainage, infiltration). We could make separate accommodations for those. Or perhaps these should really be separate node types with 1 flux each;

• Precipitation
• Evaporation (specify potential_evaporation and connect to Basin to get open water evaporation)
• Infiltration (combine with drainage? one node per modflow cell?)

This would also fix the timeseries duplication problem. Say you have 1000 Basins in a small area with a single precipitation timeseries. Now you have to copy this data 1000x, once per Basin. If you have a separate Precipitation node, you only have to define it once and connect it to all 1000 Basins, just like you can do already for e.g. a LevelBoundary. For visualization you'd probably want an easy way to hide these nodes and edges though.

Originally posted by @visr in #644 (comment)

[gijsber]

From a modeller's perspective I am not fond of this solution as it involves another connection to track that your timesries ends up in the correct basin. But if we can hide it from the modeller and julia or ribasim_python offers the methods to post/get these series using the basinId it probably is ok.

[visr]

Yes I think it should be straightforward to create tooling to follow the indirection.

[Huite]

I guess the benefit additional nodes is that you can always store a "flow" variable for a given node, so all the information is encoded in the network and the types. I'm not too fond it for the same reason @gijsber mentions, but also conceptually: I've always considered the nodes to be somewhat physically distinct entities, which is reflected by the network topology.

I would vote for what feels like the solution here: treat the edge flows separately in the output. I find it a bit clunky in how you need to select basin flows anyway. Why not store a separate table with a basin index and the various balance terms for that timestep?

MODFLOW 6 also has different format for internodal flows (flow-ja-face) and flows to the node itself.

In UGRID terms, similarly: the internodal flows would be stored on the edges. The node terms would be stored on the nodes.
Although in case of UGRID, you wouldn't be able to combine it nicely either, because the nodes of the topology are so dissimilar (a control node obviously has no precipitation term).
So in the case of writing to UGRID, you either need a lot of padding values (NaN for the precipitation variable of the control nodes e.g.), or you need to define separate dimensions per type of node. Incidentally, the padding approach is what we do for the MODFLOW 6 boundary budgets. In that case, it's well worth it IMO, because it makes it a lot easier for the user to interact with the data: they need only know about DataArrays which represent the entire topology. This ease of interaction easily wins out over the somewhat wasteful duplication caused by padding NaNs everywhere. It means you can directly make spatial selections and easily visualize the data. QGIS also directly understands the data in that form.

[visr]

We won't go with separate nodes to split combined flows, instead we remove the combined flows and make sure we add separate fluxes to the node specific output files.

• remove combined vertical flows from the flow.arrow and internals
• add columns for the vertical Basin flows to basin.arrow and store the mean flows there, similar to Change flow results from instantaneous to average over past timestep #935

[evetion]

Depending on functionality that gets removed (like flow edges without an id that can be recovered from the network), introduce an utility that recover them in this issue.