Read some interpolation tables into the Model struct #674
Conversation
Huite
force-pushed
the
interpolate-level
branch
from
49c4185 to
5096122
Compare
visr
changed the title
Place logic similarly to other structures, not a separate file.
There was a problem hiding this comment.
One small comment. I don't think I am familiar enough with the rest of the code to review it. I leave that to @visr 🙃
|
I've done some fixes here so we can use "Basin / subgrid_level" as you originally intended. I seem to have broken the test along the way though. I could use more description of the design though. Main questions are:
|
|
Good question about the name. I did some thinking: this stems from my idea that Ribasim would present 1:1 levels to MODFLOW, but it turns out this is impractical for multiple reasons, because we do not necessarily want the subgrid elements to align 1:1 (e.g. because the Ribasim domain is larger spatially than the MODFLOW domain, or vice versa). The name would still be a useful entry to have when setting up the coupling schemes, but in that sense it's no different from the x and y columns that we discussed yesterday. In that case, all the grouping is a coupler problem only, and in Ribasim everything can be flattened (which also cleans up the BMI). I guess the idea with exporter and level is that the exporter "does the exporting"; the level is just a level. I'll omit the name column, and see whether the exporter / level thing can be cleared up somewhat. |
Name struct Subgrid Becomes Basin / subgrid in Geopackage Remove name column from subgrid table Remove nested subgrids (unique subgrid_ids are sufficient)
Also use `nextfloat(-Inf)`, we already use that elsewhere, and perhaps `prevfloat`'s small dx can cause floating point issues.
More consistently with the other validation code.
No description provided.