Automating CPT interpretation
got the image from nextgov.. just so you know ;-)

Automating CPT interpretation

I have taken some time to compare modern day CPT interpretation methods, either Python packages or API based. Let's see how it went!

Meet the following methods

Geolib is an initiative by Deltares which offers a python package to execute common geotechnical tasks like converting CTPs to soillayers. The package is under development and the used version is 0.1.0.

MLAS is my own python code / package which offers 3 methods to interpret CPTs including one used by geolib but with a slight adjustment. The method is available through an API.

Crux CEMS is a company that offers API's for geotechnical calculations. They have recently opened up an API for CPT interpretation based on a machine learning model developed by Ritchie Vink.

I have coded with all three of them and used a specific levee to check how the methods score compared to the borehole data that was also available. Here is an overview of the levee and soil investigation location;

No alt text provided for this image

Every CPT (red dots) was converted to soillayers using five methods;

  • MLAS threetyperule
  • MLAS nl_rf
  • GeolibPlus Robertson with fixed waterlevel
  • GeolibPlus Robertson with waterlevel at cpt top minus 1m
  • CEMS default settings

Now a bit more about the methods;

Geolibplus

Geolibplus has the power of the masses. It's developed under supervision of a lot of geotechnical companies and Deltares is known as one of the leading institutes with respect to geotechnical engineering. The package contains a method based on the Robertson correlation.

Geolibplus is not available on PyPi so you would have to get a copy from Deltares.

MLAS

MLAS is my own code so I hope I am not too biased ;-) The code implements three methods for CPT interpretation. One is the threetype rule which simply converts the CPT to either clay, sand and peat layers. This is a rough method but I actually like simplicity because sometimes automation can lead to a false sense of accuracy, something that's happening in geotechnical engineering quite a lot. The second method uses a common Dutch interpretation based on the friction number. Again, really simple. The last one is the Robertson method which uses the geolibplus interpretation but removes the waterlevel.. well it does not remove it but it uses a default of a waterlevel of 1m minus the top of the CPT or a user defined waterlevel.

MLAS is not open source right now and the API is online but limited to just a couple of users and I still have to see how this will develop in time.

CEMS API

CEMS API is code made by CRUX Engineering who are ahead of other engineering companies because they offer API solutions for geotechnical problems which is something I expected from other large companies as well.. so kudos for being flexible and innovative. They have offered me the usage of their API so all I had to do was sent the CPT data to the API and it returns the interpretation result. They use a quite (and I think currently the most) advanced model based on a machine learning method which is explained in great details in this article by Ritchie Vink. Now I am a great fan of adding machine learning knowledge into the field of engineering and especially when it is well executed so I was very curious to see how this method performs.

Pro's and cons

In short, these are the pro's and cons I found during all tests.

No alt text provided for this image


let me elaborate a little;

I am not a huge fan of the implementation of the waterlevel for the Robertson method in geolibplus. You will need a waterlevel in your CPT to be able to use the Robertson method and the way it is dealt with now is that they added a shapefile for The Netherlands with polder waterlevels which also explains the usage of the pyproj package. For Pyproj they have chosen to use version 2.6.1.post1 which can be a real pain to install but conda or carefully handling virtualenv should do the trick. However, I did not want to mess up my QGis / ArcGIS and Python setup too much and I did not install this pyproj version. Instead I used my own adjusted geolibplus version with different waterlevels to see how it works out. So in a way you might say that I did not use geolibplus but the only thing I changed was removing the automated waterlevel.

MLAS is based on my own code but now also implements the (slightly adjusted) geolib method so the quality should be fine. (For me) it's available as a package as well as an API which makes it really easy to use in either Python code or another application. MLAS also uses pyproj (for other purposes then CPT interpretation) but the easier to install version 3+. The nice thing of MLAS is that it implements three methods and hopefully later on even more.

The CEMS method is based on an excellent study and model by Ritchie Vink which makes it very up to date. I highly recommend that you read his article although it might be a bit hard for pure geotechnical engineers. CEMS offer their services as an API so you do not need to install a package or anything. Simply connect to the API and use their method. This is the way to go for automation

Results from a geotechnical perspective

I compared 10 CPT's with their closest boreholes but I am only going to show you three were the distance between the CPT and borehole was less than 5m. Here's number one;

No alt text provided for this image

This CPT and borehole are located at the crest of the levee within a 1 meter range. Let me explain what you see..

I have plotted the CPT cone resistance (blue line with scale) and cone friction (yellowish line no scale) on the left. Then I have plotted 5 different interpretation methods with their names on top of the highest layer. On the right you will see the borehole plot which could be considered as the ground truth.

The first thing that we see is that the CEMS interpretation (left, called crux_*) does not take the predrilled part of the CPT into account which is actually a good thing since the borehole shows that we are dealing with the foundation of a road.

The top peat layer is found in CEMS, MLAS threetype and nlrf method but not in both Robertson methods which is a bad thing since peat is very important as a low strength soil layer. The clayey middle layer is recognized by all methods although the nl_rf finds way too many sandy or even sand layers. The lower sand layer is recognized by all methods.

Let's check another one where both the CPT and the borehole are close together.

No alt text provided for this image

We find the same pattern. The Robertson correlations misses the peat layers and the nl_rf method again inserts all kinds of sandy layers in what should be a clay layer. Also the three type rule is quite accurate.

Let's look at the last comparison where both CPT and borehole are close together.

No alt text provided for this image

Here the only three type method and the nl_rf method find the top peat layer and again the Robertson correlations do not seem to match. Funny enough the CEMS method also seems to have some trouble here.

Looking at all the locations my findings are;

  • the three type rule might be a rough estimate but it is an accurate one
  • the Robertson correlation misses a lot of important layers
  • the nl_rf correlation scores nicely on peat but is not useable for clay layers because they are often mistaken for sandy layers
  • the CEMS method correctly identifies most soillayers and takes the predrilled area into account
  • the waterlevel fixed or based on the CPT toplevel does not make a lot of difference in the Robertson method

Note that all CPTs were without waterpressure measurements which might have a negative effect on the Robertson correlation

My interpretation of the results

For my levee assessments I would choose the threetyperule for course calculations and the CEMS method for fine calculations. For a global and rough estimate of the state of my levee it is very important to correctly identify peat and clay layers which is fine with the threetype rule. However, this rule will result in only three soiltypes, clay, peat and sand so I could only convert it to three sets of strength parameters and this will limit the value of your model. But still, it would be great for a first rough estimate to filter out locations that are really in need for a finer model.

The CEMS method, nl_rf and Robertson generate more soiltypes. The nice thing about the CEMS method is that it comes up with names like 'Zs2k1' as well as the full name in Dutch which means that you can use that code to generate soil parameters (like MLAS does). The geolibplus Robertson methods generates names like 'Klei/Sterk zandig/-' which might be a bit harder to automate although I think the geolib package will add this feature later on.

short addition, all methods are (CEMS / MLAS) or will be (GeolibPlus) able to convert CPTs to soillayers including default strength parameters but very often you want to convert soil names to your own local strength parameter collection which is relatively easy to do with codes like 'Zs2k1'.

From a developer perspective

As a developer I have some other points;

  • API's are the future and it is nice to be able to get your data using an API instead of a Python package
  • CRUX CEMS does not yet seem to be able to accept API authentication by using
  • I dislike the geolibplus inclusion of (old) pyproj and the shapefile, this might make installation a nasty business
  • My personal plan is to implement CEMS access in MLAS as a new choice but that will complicate things since CEMS will be a paid service but that should not be an obstacle.

Final result

API's and packages are a good thing and it makes life of geotechnical engineers really interesting because of the automation possibilities. For my levee assessment projects I will definitely use API's. As stated before my choice would be to use the threetyperule for a coarse assessment and CEMS for fine assessments. This will mean some work on my side but that's fine if the end result is a better assessments.

The shown methods are probably not the only possibilities in this big geotechnical world so if you have any other methods let me know!

Disclaimer (important!)

This comparison is made in the little time I had available which means that I could not fully check out the possibilities of both the geolibplus package and the CEMS API. For better comparison it would be advised to focus on the following points;

  • why does Robertson score so badly on identifying peat layers
  • what is the effect of the waterlevel in both the Robertson as well as the CEMS method
  • can we tweak the CEMS method to get even better results
  • can we improve the simple nl_rf method (which might offer an option with an increased accuracy without the need for complicated calculations).

I also made some choices that should be noted;

  • I used the default CEMS API settings
  • For Robertson I used a waterlevel of CPT top minus 1m and a fixed level of NAP-5m which is fine for the polder CPTs but not so much for the crest CPTs

And finally

  • I wrote MLAS but I've written this article without bias (blue eyes again ;-)
  • Crux CEMS provided me with API access but I have no financial connection with them in any way
  • geolibplus is version 0.1.0 so in development and things might change

Thoughts? Errors? Inaccuracies? Angry? Happy? Also not a fan of soccer? Let me know using [email protected] or LinkedIn messages.

update 2021-06-21: The CEMS API can be called using an authentication header, see next sample code provided by CEMS;

import requests

username = "my-username"

password = "my-little-secret"



r = requests.post(

  "https://crux-nuclei.com/login",

  json={"username": username, "password": password},

)

ACCESS_TOKEN = r.json()["access_token"]



# use access token

r = requests.get(

  "https://crux-nuclei.com/api/gef-model/url-behind-auth",

  headers={"Authorization": f"Bearer {ACCESS_TOKEN}"},

)


Ritchie Vink

Author of Polars | CEO & Founder Polars Inc | Building scalable Polars

3 年

Nice post Rob! One thing that we could've documented better was get the authentication token. You can indeed access the API with the client library we send which abstract that for you. Another method is using the API from any http client you like. The following gist shows an example with `python requests`: https://gist.github.com/ritchie46/2506392af3b71959420692923ffa289e

You just tested the ability of three automated methods to reproduce something with (to the audience) unknown accuracy and/or interpretation guidelines, right? Who made the borehole and with what type of equipment? (hand drilling, mechanical method that compresses soft soil layers during drilling, Begeman drilling?) Who interpreted the borehole and through which 'lens'? (TNO geologist, geotechnical engineer, ...) For what purpose whas this borehole interpreted? Since boreholes are normally interpreted by human beings, this matters. That clay layers may well include many small silt of sand layers (depending of geological context) but for the geotechnical purpose it may not have been important to provide such a detailed log. However, the CPT doesn't know this and will report these layers anyway, if they in fact exist. At this scale, it's hard to see the qc profile in detail. There must be actual qc spikes in the profile, otherwise the nlrf rule should not show alternate soil types (or there is an implementation problem :-). Just checking: the Robertson charts are all based on a standardized confining pressure, so in order to correct for that you'd need to guess the volumetric weights of the layers and correct for depth (in iterative manner). Is that part of any of the current methods? I'm super excited by all the new efforts in CPT interpretation by the way. Just curious how the basics of the science are covered before all the fancy automation and machine learning. Gerbage in = garbage out and all that ;-)

Adrian McCallum

Explorer of people, places and possibilities...

3 年

This is very interesting and timely Rob van Putten. Only yesterday I was briefly examining packages that I might be able to use to reevaluate ~100 CPT tests in dry polar snow; snow is not soil, but I'm keen to look at my data with fresh eyes to see what correlations etc. might be apparent. I might drop you a line sometime, thank you.

Christian Valerio-Herrera, MBE-ICPL

Project Manager/Senior Geotechnical Engineering bei AFRY

3 年
回复

要查看或添加评论,请登录

Rob van Putten的更多文章

社区洞察

其他会员也浏览了