barbagroup / geoclaw Goto Github PK

If a simulation is a restart session, then the tracer will lose the information from the previous simulation. But given that land-spill simulations are usually very short, restarting does not required frequently. So this issue will not be addressed in the near future.

To better merged back to the original GeoClaw repo, the implementation should:

• keep original Manning's equation,
• add runtime options for users to choose between different friction models, and
• let users set friction coefficients in runtime.

Optional functionalities include:

• spatially varying coefficients

We'll have to implement evaporation and infiltration models. According to previous communications, evaporation is more important than infiltration in the applications of our interest.

We haven't touched this issue a lot. So the first thing we will need to do regarding this issue is a literature review of the available models.

The issue #4 may be connected to this one.

According to the documentation of GeoClaw v5.4.0, the NetCDF topography input is already supported. However, outputting NetCDF from GeoClaw is not. The Python scripts provided by GeoClaw/ClawPack somehow support converting ASCII/binary output files to NetCDF. But I think native support from GeoClaw solver is a better way to do that. With native support from the solver, it's possible to output compressed NetCDF/HDF5 files during runtime without first outputting those fat ASCII/binary files.

The NetCDF convention considered is CF 1.7. A major concern here is that while GeoClaw uses AMR grids, CF 1.7 and GIS software only accept results on uniform grids. This means we'll have to do interpolations on the fly during simulations, which may give us a performance penalty.

Also, if we choose to do interpolation on the fly, then the users should have the capability to set the spatial resolutions and domains in output files. In addition, they should have an option for whether to also output raw results on AMR grids.

Another possibility is to output raw results on AMR grids with non-standard conventions in compressed NetCDF/HDF5 files. And we develop a standalone utility to interpolate data on to uniform grids after simulations.

When the working fluid contacts water bodies (rivers, ponds, lakes, etc.), we will just assume the water bodies capture all working fluid that is in contact with them. And the working fluid will neither cross the water bodies nor accumulate at the water/land interface. The transportation of working fluid by water bodies will be carried out by other numerical solvers.

This will require the solver to be able to:

• read hydrologic data files (e.g., shapefiles),
• identify which cells belong to water bodies, and
• remove the working fluid that flowing into water bodies from land.

A possible required need is to record the information of working fluid flowing into water bodies so that the subsequent hydrologic transport solver can use them as inputs. The information may include:

• a single total amount of working fluid for each water body,
• time history of volumetric data of working fluid, and
• the locations of working fluid/water bodies interfaces.

While this possible need is not in the original plan, we'll have to discuss this.

Evaporation of volatile fluids is not required but "nice to have", so we open a new issue to track the development of this feature.

See the discussion in #9

Currently, the outflow BC in GeoClaw seems to just copy the flow states (water elevations & discharges) from boundary cells to ghost cells. While this may be good enough for open ocean cases, it seems to be improper for overland flows. The results of benchmark simulations show the fluid accumulates at the outflow boundaries.

The current solution in my mind is assuming the ghost cells have the same topographic slopes as the boundary cells do. Tests with the flow over a single slope plate show promising results with this idea.

However, it may not be necessary to implement this because it seems the computational domains of overland flows are typically larger than the actual wet regions. That's why this issue is deemed as a minor one.

See the comment ins #9 .

The rupture points will be treated as point sources and source terms to the continuity equation. All settings should be done during runtime, i.e., no need of writing Fortran routines and re-compilation for every different rupture point.

The functionalities should include:

• enabling/disabling this feature,
• specifying the location of the point source, and
• specifying time history of the point source.

Optional features include:

• multiple point sources.

Due to the spec change, infiltration model is now not required but "nice to have". So I'll separate this from evaporation model implementation (#6). We now use this issue to track the implementation of the infiltration model.

Fortran does not initialize a newly allocated array with zeros, which is not what I expected. So there's a bug that the rows array of a SparsePattern object is not initialized correctly. It has to be manually initialized with zeros.

The physical properties may be needed by the evaporation and infiltration models in the future. The users should be able to set these properties during runtime as input parameters.

However, at the current stage, they are not needed, so this feature is deemed as a minor issue.

It seems the subroutine qad (in src/2d/shallow/qad.f) is doing something I don't understand. The comment shows some remarks like need to fix someday from upstream GeoClaw code. I doubt this has something to do with that, in coarse grids, the fluid will penetrate the hydro regions by two cells. The expected behavior is only penetrating one cell. Though for the fine grids, they are not affected.