681
Technical Committee 103 /
Comité technique 103
the differences are in loading conditions, duration of the
construction process and influences from adjacent buildings,
between the new project and the existing projects, and how that
affects the numerical model.
Care should be taken to use common practice and experience
to design a new project on a larger scale than the projects on
which common practice and experiences are based. Because of
the high non-linear character of soil behaviour, the design of a
larger system is not simply an extrapolation from a smaller size
project. This principle in the design process should also be
realised when using finite element models.
It might be worth to model a project with different software
packages and compare the results. No doubt, this will lead to
different results, whereby the engineer should realize that the
different packages may use different models and methods, and
there could be differences in the way how these models and
methods have been implemented. However, when it was
intended to create very similar models, the results should be less
than 10% different from each other to conclude that they are
actually similar. This is a necessary condition for a positive
validation, but it is not the only condition, since modelling
errors can still be made in one or both software packages, such
that the results are still within 10% difference from each other.
It could be that two errors in one model accidentally cancel each
other out and still lead to results that are more or less right. It
can also be that errors made in both packages lead to similar
results, which are both wrong. Therefore the validation of
numerical models purely on the basis of a comparison with
other software is not a sufficient validation. In fact, both models
need to be validated individually and other types of validations
(as described above) need to be performed as well.
Considering the modelling of the same situation in different
software packages brings us to the issue of Benchmarking.
4.5
Benchmarking
A
Benchmark
, in the framework of validation and verification,
is a well-defined example problem for which a reference
solution exists, whereas the term
Benchmarking
can be defined
as the process to evaluate the variation in results from different
modellers or different computer software for a well-defined
example problem. Although the latter definition is probably
mostly related with how users translate the example problem
into a computer model and how they interpret the results, it can
also be used to benchmark different software packages against
each other or against the reference solution. According to
NAFEMS, a
Benchmark
is a standard test designed to probe the
accuracy or efficiency of a finite element system or model
(Baguley, 1994). This definition clearly addresses the role of the
system (hardware + software), but also involves the role of the
user in creating an appropriate and accurate finite element
model.
The solution of a benchmark example is not a theoretical
solution, but a reference solution that is considered to be ‘a right
solution’ for that particular problem. Most benchmarks are
simplified practical problems for which no analytical solution
exists. Modellers can use a benchmark to check if they obtain a
similar solution with their own software. Since the solution is
obtained using numerical methods, a small deviation (few
percent) from the reference solution is likely to occur and is
quite acceptable. Larger deviations may still be acceptable,
depending on the type of problem and the level of detail that is
provided with the benchmark. Published benchmarks have
shown that quite large differences can occur, which underlines
the need for validation of numerical models.
A number of benchmark examples for geotechnical
engineering have been defined and published (e.g. Jeffries,
1995; Schweiger, 1998, 2002, 2006; Andersen et al., 2005).
In conclusion, benchmarks are not only useful for
verification purposes, but they are also relevant for the
validation process. In summary, benchmarks can serve the
following purposes:
To verify computer software.
To train unexperienced geotechnical engineers to help
them becoming familiar with numerical analysis.
To let modellers prove their competence in numerical
analysis of geotechnical problems.
To make modellers aware of differences in results for a
well-defined problem, irrespective of their origin. This
point highlights the importance of validation of
numerical models.
To highlight the importance to use appropriate
constitutive models.
To identify limitations of the present state of the art in
numerical modelling in practice (Carter et al., 2000).
To date this is still true.
4.6
Checklists
A checklist of the various sources of discrepancies, as described
in Chapter 3, can be helpful to remind the numerical modellers
of the possible modelling errors that they could make. Thinking
about the various sources of discrepancies will increase the
awareness of possible mistakes and will lead to better computer
models. In the NAFEMS document (Brinkgreve, 2013) an
extensive checklist is given, based on various sources of
discrepancies. Moreover, a list of possible questions that
modellers may ask themselves as part of the validation process
is included in the document. The checklist and the list of
possible questions may also be used by managers and
supervisors to get an impression how well a model has been
validated by the engineer.
5 NON-TECHNICAL ISSUES
In addition to the ‘technical’ issues related to the validation of
finite element models for geotechnical applications, there are a
number of non-technical issues involved with the validation
process. Such issues include decisions, responsibilities and
organizational issues, which are to be considered primarily by
the management of a company or a project. Nevertheless, it
should be realised by each individual working on numerical
modelling that these issues exist.
5.1
Availability of data
Besides knowledge and experience, another key issue to be able
to make an accurate finite element model is the availability of
data. This involves:
Geometric data
Soil data
Structural data (if structures are involved)
Data of external conditions (loads, water levels,
adjacent structures)
Information about the construction process
Soil data is probably the most important, although this is not
always recognized by project owners. In practice, there is often
a lack of soil investigation data because it costs money. It is
important to convince clients or project owners of the need of
sufficient and good quality soil investigation. It does not only
reduce the uncertainties in ground conditions, but it will also
facilitate the validation of model parameters, thereby reducing
the risk that the design is inadequate because it is based on
insufficient or wrong geotechnical data.
5.2
Responsibilities
Regarding the use of numerical models for geotechnical
engineering applications and the use of its results for
geotechnical engineering and design, four main responsibilities
can be identified.
