The option to override the usual ordering of topofiles (from coarsest to finest) that was introduced in v5.13.0 via #647, and recently "fixed" in #687 does not work as advertised in the case when the user also specifies one or more dtopo files, and can't be easily fixed. I think this option should be eliminated for now, or at least add a check to make sure no dtopo files are used if it is set.
The problem is that for moving topography (as specified by a dtopo file), internally geoclaw creates a new topo array at the resolution of each dtopo file in addition to the topo arrays created for each topofile that is provided by the user. All of these topo arrays are then updated as time evolves based on the dtopo, until the topo stops moving. The reason for doing this is that a dtopo file might be specified at higher resolution than the underlying topography in that region (especially in the case of a submarine slump on the continental shelf, for example, where the spatial dimensions of the slump may be small relative to the available ocean topography in that region). In this case we want to track the changing topography on the resolution specified by the dtopo file, as well as incorporating it into the other topo arrays.
The problem is that this new topo_for_dtopo array gets ordered along with the others, and since it was initially added to the end of the list of topo arrays, setting rundata.topo_data.override_order = True has the effect that the topo_for_dtopo array is given the highest priority, which is generally not what is desired since there will probably be coastal DEM topofiles that have much higher resolution. When this option is set, in any coastal region that is covered by the dtopo file (i.e. most of the near field coast for a subduction zone earthquake), the coastal DEM will be ignored and topo from the topo_for_dtopo array will be used onshore, which was interpolated from the ocean scale topo file much (probably much coarser etopo or GEBCO topography with at best 15" resolution) and so the fine grid coastal resolution (typically 1/3") will not be used and the results will be nonsense.
The original reason for introducing this feature was to deal with the situation where two overlapping topo files have "the same" resolution, in which case the latter one specified would have precedence. But sometimes due to rounding errors the resolution of the less desirable one is slightly better (i.e. cell areas dx*dy are slightly smaller) than the one that is considered more desirable to use, so we wanted a way to specify more precisely what order of priority they have. For that particular situation, the better option for now is to edit dx and/or dy in the topofile header (for topo_type 2 or 3) to make sure the more desirable one has slightly smaller dx*dy than the less desirable one. But don't vary them too much since all the x,y values are calculated from the lower left corner based on what's in this header.
Or we could add a fudge factor to our logic for determining the relative resolutions of topofiles, so that two files that are nearly the same resolution will be considered as being the same, and the one listed last will be used preferentially.
The option to override the usual ordering of topofiles (from coarsest to finest) that was introduced in v5.13.0 via #647, and recently "fixed" in #687 does not work as advertised in the case when the user also specifies one or more dtopo files, and can't be easily fixed. I think this option should be eliminated for now, or at least add a check to make sure no dtopo files are used if it is set.
The problem is that for moving topography (as specified by a dtopo file), internally geoclaw creates a new topo array at the resolution of each dtopo file in addition to the topo arrays created for each topofile that is provided by the user. All of these topo arrays are then updated as time evolves based on the dtopo, until the topo stops moving. The reason for doing this is that a dtopo file might be specified at higher resolution than the underlying topography in that region (especially in the case of a submarine slump on the continental shelf, for example, where the spatial dimensions of the slump may be small relative to the available ocean topography in that region). In this case we want to track the changing topography on the resolution specified by the dtopo file, as well as incorporating it into the other topo arrays.
The problem is that this new
topo_for_dtopoarray gets ordered along with the others, and since it was initially added to the end of the list of topo arrays, settingrundata.topo_data.override_order = Truehas the effect that thetopo_for_dtopoarray is given the highest priority, which is generally not what is desired since there will probably be coastal DEM topofiles that have much higher resolution. When this option is set, in any coastal region that is covered by the dtopo file (i.e. most of the near field coast for a subduction zone earthquake), the coastal DEM will be ignored and topo from thetopo_for_dtopoarray will be used onshore, which was interpolated from the ocean scale topo file much (probably much coarser etopo or GEBCO topography with at best 15" resolution) and so the fine grid coastal resolution (typically 1/3") will not be used and the results will be nonsense.The original reason for introducing this feature was to deal with the situation where two overlapping topo files have "the same" resolution, in which case the latter one specified would have precedence. But sometimes due to rounding errors the resolution of the less desirable one is slightly better (i.e. cell areas
dx*dyare slightly smaller) than the one that is considered more desirable to use, so we wanted a way to specify more precisely what order of priority they have. For that particular situation, the better option for now is to editdxand/ordyin the topofile header (fortopo_type2 or 3) to make sure the more desirable one has slightly smallerdx*dythan the less desirable one. But don't vary them too much since all thex,yvalues are calculated from the lower left corner based on what's in this header.Or we could add a fudge factor to our logic for determining the relative resolutions of topofiles, so that two files that are nearly the same resolution will be considered as being the same, and the one listed last will be used preferentially.