This article describes a Python-based workflow I developed recently for automated pile design. It uses AGSi data (ground model) and AGS Piling data (design requirements schedule) as input, and outputs updated AGS Piling data (full design schedule, ready for construction). This was a proof of concept, a demonstration of how AGSi and AGS Piling can be used in the real world, right now, with the help of a modest amount of Python scripting.
In the following I describe the workflow and share some of the lessons learned along the way, including some feedback for AGSi and AGS Piling.
Process overview
The process implemented is summarised in the main image above.
In the absence of software that can output AGSi directly, I started with data in spreadsheets. I then created Python scripts to transform the spreadsheet data into AGSi and AGS Piling data.
The pile design process was the main element. The Python script for this ingested the AGSi and AGS Piling data and calculated required pile lengths. It then output a new AGS Piling file incorporating the full pile design schedule, including designed pile lengths and levels. A spreadsheet version of the schedule was output at the same time.
In this case I decided to create the pile design script from scratch. However, another way of working would be to utilise existing pile design software alongside scripts processing the inputs and outputs to/from AGSi/AGS Piling at each end. My understanding is that this should now be possible with Oasys Pile as this uses JSON files for both input and output, which is easy to manipulate in Python and other scripting languages. Similar may be possible with other software. Alternatively, scripts could be developed to work with existing pile design spreadsheets (but I have more to say about spreadsheets later!)
Let’s now look at each of the steps in more detail.
Pile design requirements (AGS Piling)
AGS Piling is a data transfer format for piling data, incorporating pile design schedules, pile testing and construction records. It is still in development and the current draft, whilst not quite ready for commercial use, is sufficiently mature to be suitable for developing and testing potential new tools and workflows.
To keep things simple for this proof of concept, my starting point was a schedule of individual piles with locations, specified diameters and applied loads (to EC7). I assembled the data using the Federation of Piling Specialists (FPS) e-pile spreadsheet. This is supposed to be a ‘standard’ for the industry but its take-up to date has been rather patchy. I used it because it deals with the complexities of Eurocode design clearly and comprehensively and it is fully compatible with the design part of AGS Piling (I drafted AGS Piling, so I should know!)
The script used to create the AGS Piling data was an amended version of one I had already developed for AGSi (further discussed below). To make this work I modified the e-pile spreadsheet to smooth the process. However, there is no technical reason I can think of that would prevent an unmodified e-pile schedule from being directly used by a script to create AGS Piling data.
The objects in AGS Piling that I created data for were:
- agspileDesignSchedule
- agspileDesignRequirement
- agspileDesignLoad
- agspileDesignLoadAction
- agspileDesignLoadCombination
I did not create agsProject or other metadata objects because these were not critical for this proof of concept. Strictly speaking, these should always be provided in AGS Piling data.
Ground model (AGSi)
The design ground model was simple but typical of what we routinely use for pile design, namely a one-dimensional (layer) model. In this case the site had two different zones with slightly different sequences in each. The model also incorporated the parameters required for pile design, which in this case included a non-linear undrained shear strength profile to provide a bit more of a challenge.
The model data was assembled in a spreadsheet in a bespoke format. I then used a previously developed Python script to read this data and create an AGSi data file. For the record, the AGSi file included the following objects:
- agsProject
- agsProjectCoordinateSystem
- agsiModel
- agsiModelElement
- agsiGeometryLayer
- agsiDataParameterValue
A general observation from this work is that whilst creating a script to read data from a spreadsheet is fairly easy, the processing required to assemble correctly nested AGSi data (i.e. child objects within parent objects, etc.) can be a little bit tricky. However, as with all scripting, once such a tool has been developed for the first application, it can then be used time and time again. In fact, the hope (from AGS) is that open source tools will develop to address the anticipated demand.
Some feedback on points of detail:
- AGSi requires that each model element must have a unique ID (within the file). I had two models for two zones (A and B) which had the same geotechnical units (MG and GC) but I ended up having to name the elements “A_MG”, “B_MG” etc. This was a little cumbersome and counter intuitive. Perhaps something to look at for AGSi.
- Should AGSi include other parameters for design that are not fundamental soil parameters? In this particular case I included the alpha (adhesion factor) value as a parameter as this seemed reasonable given the use case. However, I did not include the limitations on skin friction values that often feature in pile design. These were input to the design script separately (represented by the ‘Additional design parameters’ box show in the diagram above).
Pile design script
Creating a Python script for pile design is something I have been looking to have a go at for a while now. In my opinion, the reliance of our industry on spreadsheets for pile design is a bad thing. Often these spreadsheets are copied from project to project, frequently edited along the way and rarely checked properly. As a designer I have had the misfortune to come across several cases of erroneous pile design arising from misused or ‘bodged’ spreadsheets. I feel quite strongly about this and could devote a whole blog post to my thoughts on the subject. But I will spare you that, at least for now. How did my scripting go?
Fairly well as it happens. Ingestion and use of the AGSi and AGS Piling data was straightforward, as was output of the updated AGS Piling data at the end. The main challenge was dealing with the non-linear (with depth) undrained shear strength profile and then ensuring that the design limits on skin friction (input as ‘additional design parameters’) were correctly applied in the calculations. However, anyone who has ever done any pile design in a stiff clay, whether by spreadsheet or any other method, will recognise these problems. In fact, it is one of the main causes of error in pile design when using spreadsheets.
I will admit to taking a few liberties with my pile design script to save a bit of time given that this was only intended as a proof of concept. As a result, the script as it stands right now can only deal with relatively simple design cases. However, there is nothing to stop it from being expanded to cover more complex cases.
Only geotechnical design was considered. Structural design to inform the reinforcement was not covered, although this would typically come from a separate workflow in any case.
A snippet from the output AGS Piling data is given below…
Conclusions
This work has shown that AGSi and AGS piling can be successfully used to power automated pile design with the help of what I considered to be a modest amount of scripting. It is certainly modest when judged in the context of the value of pile design that commercial organisations are dealing with every day.
I have provided some nuggets of feedback along the way, including an observation on AGSi relating to how model elements are named/identified. Other than that, I found AGSi and AGS Piling data to be fairly easy to work with in Python. The main takeaway is that the ‘nested’ structure of AGSi and AGS Piling can be a little bit tricky to create if you are starting off with a flat data structure, e.g. data in a spreadsheet. However, I can confirm that this is not a new observation; it is already on the radar of the AGSi and AGS Piling teams.
I am not sharing my source code at this stage as it is not robust enough for public consumption. I took a few liberties in my coding to save time given that this was only intended as a proof of concept.
However, if you are interested in what I have done then you are welcome to contact me (aka Digital Geotechnical Ltd – my business). I would be happy to work with you if you would like to develop something similar.
If you are keen to give it a go yourself but are perhaps in need of guidance in relation to AGSi or AGS Piling, then you are also welcome to reach out to me.
