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 5 : The road to the GeotechSynthesis Model #54

Open
mbeaufils opened this issue Sep 23, 2022 · 1 comment
Open

Use case 5 : The road to the GeotechSynthesis Model #54

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

Comments

@mbeaufils
Copy link
Collaborator

This is to explicit the data the geotechnical engineer will try to find and look at in order to build the geotech synthesis model of the project as defined by #45
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

As I have said before, I struggle slightly with the difference between geotechnical model and geotechnical synthesis model. I think of the synthesis model as a type of geotechnical model but with a very specific purpose, e.g. input to a specific analysis. I will answer the question on this basis.

(1) Geometry of the geotechnical units

Get geometry of the geotechnical units from geotechnical model (or possibly geological unit from geological unit). Filtered by unit(s) and location, which in this case may be a request for a 2D alignment along an alignment for a section.

The location perhaps could be a single point in plan, i.e. akin to a synthetic borehole - a profile used for design at that particular location, e.g. profile used in pile design.

Exploratory hole data also useful to obtain as this provides information to allow uncertainty to be addressed

Note: it is questionable where an API could or should deliver a section from a 3D model. Should this be left for applications only? What do others think about this?

(2) Properties/parameters for geotechnical units

Either:

Get parameters (property value for design) direct from parent geotechnical model if available, i.e. already assessed as single value/design line, for required unit/location, or (e.g. if not mater model or parameters assessed as a range only)

Get full set of property data from geological or geotechnical model as applicable filtered for relevant unit and location (and possibly by investigation etc.,) to allow data to be plotted and design parameters(s) to be assessed for the specific application.

Note: for any properties/parameters input or output during this process, it is important that the type of property/parameter is clearly defined and transmitted. e.g. is a design parameter an Eurocode 7 characteristic property, or is it something else? (FYI 'characteristic' will change to 'representative' in next revision of EC7! So we need to do it in a flexible and code agnostic way.)

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