Closed piyueh closed 5 years ago
@mandli This PR is ready for review. The Docker image: https://hub.docker.com/r/barbagroup/landspill/ with tag PR10. Thank you so much!!
@mandli More commits have been added to this PR. The new commits are about tracing the locations where the working fluid is removed and the volumes removed from these locations.
I didn't use the fixed grid monitors or gauges. What I want to record is the total volumes removed, so this requires some modification in the original GeoClaw source code, which is I try to avoid.
The tracer implemented in this PR is a sparse matrix in which the non-zero elements represent the locations of the boundaries of hydro features. The module creates a virtual Cartesian grid with domain size equal to the computational domain and with cell size equal to the finest cell size in AMR setting. A 2D Cartesian grid can be represented as a matrix. This matrix records the volume removed from each cell. The removal of fluid can only happen at the boundaries of hydrological features, so very few elements in this matrix (i.e., cells in this virtual grid) are non-zero. And hence I use a sparse matrix to represent this grid and store the removed volumes at hydrological boundaries.
Thanks for your review, @mandli! Since this PR is not blocking my current development, we can keep it open and keep finding a new name for the functionality.
Thank you @mandli! Yes, I believe renaming should be easy.
Removing working fluid when encountering hydrological features
If the working fluid is not water, then when it flows into water bodies/hydrological features, another solver will be used for this hydrographic transport. And the working fluid flowing into water bodies requires to be removed from the overland flow solver, which in this case is GeoClaw. This PR implements the following items to achieve this:
Reading hydrological features: Users will have to provide raster files of the hydrological features. The number of files can be arbitrary, but currently, only Esri ASCII format is accepted. The setup is through the
HydroFeatureData
object insetrun.py
. For example (Note, in the future, after merging back to GeoClaw and Clawpack repos, the registration ofHydroFeatureData
will happen in the initialization ofrundata
, so users won't have to doimport
andrundata.add_data
manually insetrun.py
.):Identifying which cells belong to hydro features: I store this information in
aux
array. Thesetaux.f90
is in charge of initializing this information whenever there's a new grid created. The tricky part is that users will have to set up thenum_aux
correctly in theirsetrun.py
. For the sake of defensive programming, the solver will check if the number of aux datasets is correct or not at the initialization stage of the hydro feature class.Removing the fluid flowing into hydro features: this is done in
src2.f90
.A new example for hydrological features: See
examples/landspill/utah_dem_hydro_feat
.Miscellaneous
Some items/bugs unrelated to hydrological features are also implemented/fixed in this PR.
pyclaw.Solution
object in the post-processing Python scripts for the solution I/O.writenc.py
.