Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use case 2 : The road to the hydrogeological model #51

Open
mbeaufils opened this issue Sep 23, 2022 · 2 comments
Open

Use case 2 : The road to the hydrogeological model #51

mbeaufils opened this issue Sep 23, 2022 · 2 comments
Labels
Use case Use case description to identify APIs roles

Comments

@mbeaufils
Copy link
Collaborator

This is to explicit the data the (hydro)geologist / geotechnical engineer will try to find and look at in order to build a comprehension of the hydrogeological context of the project.
The idea is to identify which APIs performing which queries on which data can help.

@mbeaufils mbeaufils added the Use case Use case description to identify APIs roles label Sep 23, 2022
@neilchadwick-dg
Copy link
Collaborator

I'm not an expert in hydrogeology, but I've worked with hydrogeologists so have some experience. Based on this and a little bit of research here are my thoughts on the general process...

The geological units in the geological observational model will be one of the main inputs to form a hydrogeological model with hydrogeological units (I've given my thoughts on hydrogeological units in #13). If the geological model does not yet exist then the hydrogeologist effectively has to create it themselves from the source borehole data!

Soil/rock description and some test data will also inform the construction of the hydrogeological model, i.e. helping determine how geological units map to hydrogeological units. However, this would generally be done at a high level, i.e. on the general dataset looking at units in general, not looking at individual results in space.

Surface water bodies will be an important part of any hydrogeological model, as they effectively provide boundary conditions for the analysis to follow. A good geological model will perhaps include these (FluidBodySurface #16 ?) , but that does not always happen! The hydrogeologist may need to find other inputs, e.g. from 2D mapping perhaps to fill the gaps.

Groundwater is the other critical input, of course. This is where things start to get complicated because:

  • groundwater levels and pressures vary with time
  • groundwater pressures may not be hydrostatic, e.g. confined aquifers, under-drained piezometric profiles, so the groundwater level (water table) is only part of the story

It would be useful to think about the methodology for providing information on groundwater pressure profiles. I've done it in written reports for geotechnical design but I'm not sure whether hydrogeologists have a robust and consistent way of doing it, in which case we should focus on that (they probably do as it will be an input to their analyses). Maybe the answer is in GroundwaterML - I've not looked.

The above is simplistic, covering just a basic model. Hydrogeologists deal with analysing pumping tests and all sort of other things. I would be out of my depth talking about those, so I will leave off here.

At this point I remind everyone that that groundwater levels/pressures are also relevant to geotechnical models and, in particular, geotechnical synthesis models that are intended to be used directly for design. For the latter the time problems goes away as a 'design' profile should have been determined.

@mbeaufils
Copy link
Collaborator Author

[From Derrick]

Here's a document from the USGS on the input/ouput of the MODFLOW software: https://water.usgs.gov/water-resources/software/MODFLOW-6/mf6io_6.3.0.pdf

[From Derrick]

I was considering water informaton needed in geotech by design purpose (settlement, liquefaction, seepage, dewatering/extraction, impoundment (dam/levee), injection (jetting/fracking), and scour (ground removal by water).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Use case Use case description to identify APIs roles
Projects
None yet
Development

No branches or pull requests

2 participants