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
If multiple topofiles are specified at different resolutions, then when computing cell integrals to determine the GeoClaw topo value in each cell, the finest resolution topofile will be used at each point. (Based on piecewise bilinear functions defined over the extent of each topofile.)
If two topofiles have the same resolution then which one is used in regions of overlap? This could be important if you have an improved version that covers only a subset of an earlier version.
Based on the logic in subroutine read_topo_settings of geoclaw/src/2d/shallow/topo_module.f90, it looks like the one that is listed last in setrun.py would be the one used by default. However, checking the resolution involves comparing two floating point areas computed by dxtopo*dytopo, and I think rounding error could make this behave in unexpected ways if the resolutions are "the same". It would be better to check if they are equal within some tolerance, and make sure we understand and are consistent about what order they are then used in.
We should also add something to the documentation about this.
The text was updated successfully, but these errors were encountered:
If multiple topofiles are specified at different resolutions, then when computing cell integrals to determine the GeoClaw topo value in each cell, the finest resolution topofile will be used at each point. (Based on piecewise bilinear functions defined over the extent of each topofile.)
If two topofiles have the same resolution then which one is used in regions of overlap? This could be important if you have an improved version that covers only a subset of an earlier version.
Based on the logic in subroutine
read_topo_settings
ofgeoclaw/src/2d/shallow/topo_module.f90
, it looks like the one that is listed last in setrun.py would be the one used by default. However, checking the resolution involves comparing two floating point areas computed by dxtopo*dytopo, and I think rounding error could make this behave in unexpected ways if the resolutions are "the same". It would be better to check if they are equal within some tolerance, and make sure we understand and are consistent about what order they are then used in.We should also add something to the documentation about this.
The text was updated successfully, but these errors were encountered: