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'm confused what retrieve_bathymetry is supposed to do. It looks in a file for an object called "bathymetry"? Why don't we want users to write jldopen(filename)["bathymetry"]? And otherwise looks at the grid (which I guess has to be ImmersedBoundaryGrid?
I don't grasp the design principles of this function. How does it help users to open a file for them? And when the file is provided, the argument grid does nothing? It seems like those two possibilities are totally unrelated to one another, so why would we put them together in this function?
Also it seems like it should be called retrieve_bottom_height, not retrieve_bathymetry. We should stick with one term in the user interface. "Bathymetry" is appropriate for oceans, but ImmersedBoundaryGrid uses bottom_height in order to be more general. Probably, unless we are specifically talking about oceans, we should call it bottom_height.
Okay, here's how I understand the workflow we want to support:
Download high-resolution "reference" bathymetry for Earth, probably ETOPO1, from the internet.
Pre-process the reference bathymetry in a few possible ways:
a. Use the reference bathymetry to generate the simulation bathymetry on the simulation grid. This involves both interpolation or (conservative) regridding, plus potentially smoothing
b. Remove isolated basins from the bathymetry, in the case that we are interested in simulating just 1 basin.
Create an ImmersedBoundaryGrid from the simulation bathymetry
Now, steps 1 and 2 are potentially costly. So, it would be nice to design a utility that allows us to repeatedly re-run a simulation script, while only re-downloading and re-computing the bathymetry if it is needed. So for example the utility needs to
Save the reference bathymetry to a known location, and check that location to see if it has already been downloaded or not. Let's call this download_reference_Earth_bathymetry.
Save the results of the preprocessing step, including parameters used during the preprocessing. If a previously generated bathymetry is found that is (i) on the right grid and (ii) uses the same parameters during processing, then there is no need to re-run the processing.
I'm not sure what to call the function that does the second job --- "make_bottom_height"? "map_bathymetry_to_grid"? "process_bathymetry"?
I'm confused what
retrieve_bathymetry
is supposed to do. It looks in a file for an object called "bathymetry"? Why don't we want users to writejldopen(filename)["bathymetry"]
? And otherwise looks at the grid (which I guess has to beImmersedBoundaryGrid
?I don't grasp the design principles of this function. How does it help users to open a file for them? And when the file is provided, the argument
grid
does nothing? It seems like those two possibilities are totally unrelated to one another, so why would we put them together in this function?Also it seems like it should be called
retrieve_bottom_height
, notretrieve_bathymetry
. We should stick with one term in the user interface. "Bathymetry" is appropriate for oceans, butImmersedBoundaryGrid
usesbottom_height
in order to be more general. Probably, unless we are specifically talking about oceans, we should call itbottom_height
.ClimaOcean.jl/src/Bathymetry.jl
Lines 353 to 363 in 9005d74
The text was updated successfully, but these errors were encountered: