Deep excavations are among the most technically demanding elements of urban construction. They combine complex soil–structure interaction, strong nonlinearity, and high sensitivity to ground conditions that are rarely uniform, even across a single site. As a result, design relies heavily on numerical modelling, most commonly staged Finite Element Analyses (FEA) to assess stability, deformation, and structural demand at each excavation stage.
However, anyone who has delivered a deep excavation project will recognise a familiar challenge: design iteration can be slow and expensive. Changes in ground model interpretation, excavation geometry, or strut layout often require substantial rework – rebuilding models, rerunning analyses, and manually checking outputs. When this process depends on specialist desktop software and largely manual workflows, it can become a bottleneck in program-critical decisions.
This article describes a pilot study carried out to explore a different approach: cloud-based numerical modelling using Oasys Gofer, automated via an API, with surrogate modelling as one potential downstream application. While surrogate models were a motivating research goal, one of the key findings was that the underlying Gofer–AWS–API combination is valuable for everyday engineering design.
Rethinking the modelling workflow
The starting point for the study was a common deep excavation workflow:
- Build a geometric model (using Rhino).
- Define excavation stages and geometry.
- Reconstruct critical sections in Gofer.
- Performing additional checks (for example, toe stability or strut demand) in spreadsheets.
The long-term goal of the pilot study was to explore whether site-specific surrogate models (lightweight AI models trained in high-quality numerical simulations) could accelerate this process. However, to get there, a more fundamental problem had to be solved first: how to run large numbers of simulations efficiently and reproducibly.
Why Gofer was chosen
Gofer was selected as the primary solver for the pilot study for three reasons.
First, Gofer is cloud-based, with Amazon Web Services (AWS) as its computational backend. In principle, this allows any number of simulations to be executed in parallel by spinning up multiple containers. This is a significant departure from traditional desktop-based modelling, where run times and license availability constrain iteration.
Second, Gofer uses a transparent JSON input format. Models can be generated, modified, and validated programmatically, without manually interacting with a graphical user interface. This makes Gofer particularly well-suited for automation.
Third, Gofer is under active development as a potential replacement for certain other existing tools used for excavation analysis. Using it in a pilot study provided an opportunity to feed real usage for engineering problems back into its development.
Automation through the Gofer API
A key enabler of the study was the Gofer API, which allows users to upload models, run simulations, retrieve results, and clean up completed jobs programmatically. Python scripts were developed to:
- Generate Gofer input files from spreadsheet-based geometry and ground data.
- Batch submit simulations via the API.
- Download and post-process results automatically.
This meant that once a model definition existed, hundreds or thousands of variations could be evaluated with minimal additional effort. For the pilot study, approximately 1,500 excavation simulations were run, varying soil parameters, and strut preloads.
Crucially, this capability is not limited to surrogate modelling. An engineer could just as easily implement:
- Automated sensitivity studies.
- Iterative design refinement loops.
- Scenario testing for ground uncertainty.
- Rapid option screening during early design.
In other words, even a simple rule-based or optimisation-based algorithm can benefit from the ability to run many simulations in the cloud without manual intervention.
Practical insights from the pilot study
The pilot study focused on a braced excavation with varying ground properties and strut preloads. Vertical settlement behind the excavation wall was used as a primary output parameter.
One important observation was that not all simulations converged. Roughly half of the runs terminated early, indicating severe instability or collapse. Rather than discarding these cases, they were treated as useful information, highlighting unsafe regions of the design space.
Preliminary analysis of the results also showed that upper soil unit weight dominated excavation performance, while strut preload had limited influence on the geometry tested. Strong correlations were also observed between early-stage and final-stage displacements, suggesting that not all excavation stages need equal attention during assessment.
These insights demonstrate how bulk simulation, even without a final surrogate model, can inform engineering judgement in a way that is difficult to achieve with a small number of hand-written analyses.
Looking ahead
While surrogate modelling remains a promising long-term objective, the most immediately transferable outcome of this work is the demonstration that API-driven, cloud-based simulation changes how engineers can explore design space.
For civil engineers working on complex geotechnical problems, tools like Gofer enable a shift away from single “best-guess” models toward a more systematic, data-informed understanding of uncertainty and sensitivity, using methods that integrate naturally with existing engineering workflows.
The technology is still evolving, but the direction is clear: automation and cloud computing are becoming practical tools for everyday engineering design, not just research.
