You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe this may be intended behavior, but it is not easy to identify from the current GRIDGEN example (https://flopy.readthedocs.io/en/latest/Notebooks/gridgen_example.html). A related coordinate-transformation issue was previously discussed in #1474.
When creating a MODFLOW 6 DISV grid from GRIDGEN, a typical workflow is:
Create a structured base grid with xorigin, yorigin, and optionally angrot.
I understand that the coordinates returned in vertices and cell2d therefore are already expressed in the transformed, real-world coordinate system. It does not return xorigin, yorigin, or angrot. Consequently, when the returned dictionary is passed directly to ModflowGwfdisv, those three DISV options retain their default values of zero.
The resulting DISV grid is spatially located correctly, but origin and rotation metadata are lost to the DISV package and are therefore written as zero values to the MODFLOW 6 binary grid file.
I also understand that passing the original transformation directly to the DISV constructor would result in an incorrect grid, because FloPy applies the transformation to coordinates that have already been transformed by GRIDGEN, so the in-memory VertexGrid is shifted and/or rotated a second time.
The apparent workaround is to inverse-transform the info in disv_gridprops back to local coordinates before constructing the DISV package plus passing xorigin, yorigin, and angrot when calling the constructor.
I have not been able to find a helper in flopy that does this straight away.
Proposals:
Could/Should get_gridprops_disv() optionally preserve the original coordinate transformation by returning local coordinates plus xorigin, yorigin, and angrot?
It seems ideal that the GRIDGEN example mentions this loss of info. The example demonstrates rotation in its initial GRIDGEN section, but the later MODFLOW 6 DISV section uses an unrotated grid.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I believe this may be intended behavior, but it is not easy to identify from the current GRIDGEN example (https://flopy.readthedocs.io/en/latest/Notebooks/gridgen_example.html). A related coordinate-transformation issue was previously discussed in #1474.
When creating a MODFLOW 6 DISV grid from GRIDGEN, a typical workflow is:
get_gridprops_disv() returns:
I understand that the coordinates returned in vertices and cell2d therefore are already expressed in the transformed, real-world coordinate system. It does not return xorigin, yorigin, or angrot. Consequently, when the returned dictionary is passed directly to ModflowGwfdisv, those three DISV options retain their default values of zero.
The resulting DISV grid is spatially located correctly, but origin and rotation metadata are lost to the DISV package and are therefore written as zero values to the MODFLOW 6 binary grid file.
I also understand that passing the original transformation directly to the DISV constructor would result in an incorrect grid, because FloPy applies the transformation to coordinates that have already been transformed by GRIDGEN, so the in-memory VertexGrid is shifted and/or rotated a second time.
The apparent workaround is to inverse-transform the info in disv_gridprops back to local coordinates before constructing the DISV package plus passing xorigin, yorigin, and angrot when calling the constructor.
I have not been able to find a helper in flopy that does this straight away.
Proposals:
All reactions