WIP - New example chile2010_netcdf not working - #740
Draft
rjleveque wants to merge 3 commits into
Draft
Conversation
Eleven silent failures in crop_extent handling produced wrong answers with no message: wrapped spellings gave empty grids, sub-cell and non-overlapping crops gave the full file, a cropped type-4 read reported the full-file extent, and buffer was dropped for every descriptor-cropped NetCDF file. Adds the first Fortran regression coverage for the descriptor-crop path and documents what a Topography represents across the antimeridian. Signed-off-by: Kyle Mandli <kyle.mandli@gmail.com> Assisted-by: claude claude-opus-5[1m]
A URL in topofiles was mangled by os.path.abspath into a bogus local path before the reader's existing URL guard could see it; it is now rejected with the fetch_remote_topo recipe. A crop crossing the antimeridian raised 'crop_bounds exceed file extent' even though _compute_lon_entries already covered it; TopographyData.write now resolves entries before writing and splits such a crop into one descriptor entry per side, carrying buffer and coarsen onto each so the Fortran buffer fix applies. Adds byte-exact topo.data goldens and the first end-to-end test of two entries with differing lon_wrap_offset. Signed-off-by: Kyle Mandli <kyle.mandli@gmail.com> Assisted-by: claude claude-opus-5[1m]
Also testing cropping and coarsening. Works on standard domain starting at x_lower = -120, but with x_lower = -190 it seems to handle topo properly (specifying two grids in topo.data) but dtopo is no longer used properly, so no tsunami generated (when testing clawpack#739)
Member
|
Just want to clarify the input data so I can replicate:
|
Member
Author
|
@mandl - correct! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'm experimenting with this new
chile2010_netcdfexample, where I tried specifyingto test using a crop extent that crosses the date line at longitude -180.
Before PR #739, the
topo.datafile only listed one topo grid, and would only get part of thecrop_extent.With this PR,
topo.datalists the same.ncfile twice, as desired, so two topo grids are created, as expected, plus a third one internally corresponding to thedtopodata file (topo_for_dtopo).However, the dtopo is not longer applied, apparently -- no tsunami appears. Cutting the domain and
crop_extentback to starting atx_lower = -120, it works fine with the netCDF file as topo data, and the expected tsunami is generated.Another issue: Even though I have
topo.buffer = 1when GeoClaw runs it reports that the topo does not cover the full domain. Again it works fine withx_lower = -120. The problem I think is that there is a gap between the topo files at -180 that is hard to avoid with 2 files, since the GEBCO data starts atx = -179.99791666666667and ends atx = 179.99791666666667. But I thought that buffering was perhaps supposed to deal with this case too?