@note This tutorial has been developed (and is described in the introduction) for the problem of elasticity in three dimensions.
While the space dimension could be changed in the main() routine, care needs to be taken.
- Two-dimensional elasticity problems, in general, exist only as idealisations of three-dimensional ones.
+ Two-dimensional elasticity problems, in general, exist only as idealizations of three-dimensional ones.
That is, they are either plane strain or plane stress.
The assumptions that follow either of these choices needs to be consistently imposed.
For more information see the note in step-8.
@f}
-<h3> Discretisation of governing equations </h3>
+<h3> Discretization of governing equations </h3>
The three-field formulation used here is effective for quasi-incompressible materials,
that is where $\nu \rightarrow 0.5$ (where $\nu$ is <a
Using the Timer class, we can discern which parts of the code require the highest computational expense.
For a case with a large number of degrees-of-freedom (i.e. a high level of refinement), a typical output of the Timer is given below.
-Much of the code in the tutorial has been developed based on the optimisations described,
+Much of the code in the tutorial has been developed based on the optimizations described,
discussed and demonstrated in Step-18 and others.
With over 93% of the time being spent in the linear solver, it is obvious that it may be necessary
to invest in a better solver for large three-dimensional problems.
@endcode
-We then used ParaView to visualise the results for two cases.
+We then used ParaView to visualize the results for two cases.
The first was for the coarsest grid and the lowest-order interpolation method: $Q_1-DGPM_0-DGPM_0$.
The second was on a refined grid using a $Q_2-DGPM_1-DGPM_1$ formulation.
The vertical component of the displacement, the pressure $\widetilde{p}$ and the dilatation $\widetilde{J}$ fields
are shown below.
-For the first case it is clear that the coarse spatial discretisation coupled with large displacements leads to a low quality solution
+For the first case it is clear that the coarse spatial discretization coupled with large displacements leads to a low quality solution
(the loading ratio is $p/p_0=80$).
Additionally, the pressure difference between elements is very large.
The constant pressure field on the element means that the large pressure gradient is not captured.
the solution remains accurate.
The pressure field is captured in far greater detail than before.
There is a clear distinction and transition between regions of compression and expansion,
-and the linear approximation of the pressure field allows a refined visualisation
+and the linear approximation of the pressure field allows a refined visualization
of the pressure at the sub-element scale.
It should however be noted that the pressure field remains discontinuous
and could be smoothed on a continuous grid for the post-processing purposes.
BlockVector<double> solution_n;
// Then define a number of variables to store norms and update norms and
- // normalisation factors.
+ // normalization factors.
struct Errors
{
Errors()
p = 1.0;
J = 1.0;
}
- void normalise(const Errors &rhs)
+ void normalize(const Errors &rhs)
{
if (rhs.norm != 0.0)
norm /= rhs.norm;
// @sect4{Public interface}
-// We initialise the Solid class using data extracted from the parameter file.
+// We initialize the Solid class using data extracted from the parameter file.
template <int dim>
Solid<dim>::Solid(const std::string &input_file)
:
block_component[p_component] = p_dof; // Pressure
block_component[J_component] = J_dof; // Dilatation
- // The DOF handler is then initialised and we renumber the grid in an
+ // The DOF handler is then initialized and we renumber the grid in an
// efficient manner. We also record the number of DOFs per block.
dof_handler_ref.distribute_dofs(fe);
DoFRenumbering::Cuthill_McKee(dof_handler_ref);
// \\ \mathsf{\mathbf{F}}_{\widetilde{J}}(\widetilde{J}_{\textrm{i}})
//\end{bmatrix}}_{ \mathsf{\mathbf{F}}(\mathbf{\Xi}_{\textrm{i}}) } \, .
// @f}
- // We optimise the sparsity pattern to reflect this structure
+ // We optimize the sparsity pattern to reflect this structure
// and prevent unnecessary data creation for the right-diagonal
// block components.
Table<2, DoFTools::Coupling> coupling(n_components, n_components);
if (newton_iteration == 0)
error_residual_0 = error_residual;
- // We can now determine the normalised residual error and check for
+ // We can now determine the normalized residual error and check for
// solution convergence:
error_residual_norm = error_residual;
- error_residual_norm.normalise(error_residual_0);
+ error_residual_norm.normalize(error_residual_0);
if (newton_iteration > 0 && error_update_norm.u <= parameters.tol_u
&& error_residual_norm.u <= parameters.tol_f)
if (newton_iteration == 0)
error_update_0 = error_update;
- // We can now determine the normalised Newton update error, and
+ // We can now determine the normalized Newton update error, and
// perform the actual update of the solution increment for the current
// time step, update all quadrature point information pertaining to
// this new displacement and stress state and continue iterating:
error_update_norm = error_update;
- error_update_norm.normalise(error_update_0);
+ error_update_norm.normalize(error_update_0);
solution_delta += newton_update;
update_qph_incremental(solution_delta);
}
// Of course, we still have to define how we assemble the tangent matrix
-// contribution for a single cell. We first need to reset and initialise some
+// contribution for a single cell. We first need to reset and initialize some
// of the scratch data structures and retrieve some basic information
// regarding the DOF numbering on this cell. We can precalculate the cell
// shape function values and gradients. Note that the shape function gradients
if (map.find(cell) == map.end())
{
map[cell] = std::vector<std::shared_ptr<DataType> >(n_q_points);
- // we need to initialise one-by-one as the std::vector<>(q, T())
+ // we need to initialize one-by-one as the std::vector<>(q, T())
// will end with a single same T object stored in each element of the vector:
auto it = map.find(cell);
for (unsigned int q=0; q < n_q_points; q++)
hybrid,
/**
* The iterative QL algorithm with implicit shifts applied after
- * tridiagonalisation of the tensor using the householder method.
+ * tridiagonalization of the tensor using the householder method.
*
* This method offers a compromise between speed of computation and its
* robustness. This method is particularly useful when the elements
* class names in multithreading and non-MT mode and thus may be compiled
* with or without thread-support without the need to use conditional
* compilation. Since a barrier class only makes sense in non-multithread
- * mode if only one thread is to be synchronised (otherwise, the barrier
+ * mode if only one thread is to be synchronized (otherwise, the barrier
* could not be left, since the one thread is waiting for some other part of
* the program to reach a certain point of execution), the constructor of
* this class throws an exception if the <code>count</code> argument
public:
/**
* Constructor. Since barriers are only useful in single-threaded mode if
- * the number of threads to be synchronised is one, this constructor
+ * the number of threads to be synchronized is one, this constructor
* raises an exception if the <code>count</code> argument is one.
*/
DummyBarrier (const unsigned int count,
* many such examples, part of the work can be done entirely independently and
* in parallel, possibly using several processor cores on a machine with
* shared memory. However, some other part of this work may need to be
- * synchronised and be done in order. In the example of assembling a matrix,
+ * synchronized and be done in order. In the example of assembling a matrix,
* the computation of local contributions can be done entirely in parallel,
* but copying the local contributions into the global matrix requires some
* care: First, several threads can't write at the same time, but need to
- * synchronise writing using a mutex; secondly, we want the order in which
+ * synchronize writing using a mutex; secondly, we want the order in which
* local contributions are added to the global matrix to be always the same
* because floating point addition is not commutative and adding local
* contributions to the global matrix in different orders leads to subtly
* parallel on all of these objects and then passes each object to a
* postprocessor function that runs sequentially and gets objects in exactly
* the order in which they appear in the input iterator range. None of the
- * synchronisation work is exposed to the user of this class.
+ * synchronization work is exposed to the user of this class.
*
* Internally, the range given to the run() function of this class is split
* into a sequence of "items", which are then distributed according to some
* The indices of degrees of freedom located on lower dimensional objects,
* i.e. on lines for 2D and on quads and lines for 3D are treated
* similarly than that on cells. However, these geometrical objects, which
- * are called faces as a generalisation, are not organised in a
+ * are called faces as a generalization, are not organised in a
* hierarchical structure of levels. Therefore, the degrees of freedom
* located on these objects are stored in separate classes, namely the
* <tt>DoFFaces</tt> classes.
typedef typename BlockLinearOperator<Range, Domain, BlockPayload>::BlockType BlockType;
- BlockLinearOperator<Range, Domain, BlockPayload> return_op ((BlockPayload())); // TODO: Create block payload so that this can be initialised correctly
+ BlockLinearOperator<Range, Domain, BlockPayload> return_op ((BlockPayload())); // TODO: Create block payload so that this can be initialized correctly
return_op.n_block_rows = []() -> unsigned int
{
* <h3>Thread-safety</h3>
*
* The functions that operate as a matrix and do not change the internal state
- * of this object are synchronised and thus threadsafe. Consequently, you do
+ * of this object are synchronized and thus threadsafe. Consequently, you do
* not need to serialize calls to @p vmult or @p residual .
*
* @author Wolfgang Bangerth 2001, Luca Heltai 2006, Guido Kanschat 2007, 2008
LinearOperator<Range, Domain, Payload>
linear_operator(const OperatorExemplar &operator_exemplar, const Matrix &matrix)
{
- // Initialise the payload based on the input exemplar matrix
+ // Initialize the payload based on the input exemplar matrix
LinearOperator<Range, Domain, Payload> return_op (Payload(operator_exemplar,matrix));
// Always store a reference to matrix and operator_exemplar in the lambda
linear_operator(const LinearOperator<Range, Domain, Payload> &operator_exemplar,
const Matrix &matrix)
{
- // Initialise the payload based on the LinearOperator exemplar
+ // Initialize the payload based on the LinearOperator exemplar
auto return_op = operator_exemplar;
typename std::conditional<
/**
* It is not safe to elide additions of zeros to individual elements
* of this matrix. The reason is that additions to the matrix may
- * trigger collective operations synchronising buffers on multiple
+ * trigger collective operations synchronizing buffers on multiple
* processes. If an addition is elided on one process, this may lead
* to other processes hanging in an infinite waiting loop.
*/
/**
* Implementation of a parallel vector class based on PETSC and using MPI
- * communication to synchronise distributed operations. All the
+ * communication to synchronize distributed operations. All the
* functionality is actually in the base class, except for the calls to
* generate a parallel vector. This is possible since PETSc only works on
* an abstract vector type and internally distributes to functions that do
* time, all these additions are executed. However, if one process adds to
* an element, and another overwrites to it, the order of execution would
* yield non-deterministic behavior if we don't make sure that a
- * synchronisation with compress() happens in between.
+ * synchronization with compress() happens in between.
*
* In order to make sure these calls to compress() happen at the
* appropriate time, the deal.II wrappers keep a state variable that store
/**
* This quantity is added to the diagonal of the matrix during
- * factorisation.
+ * factorization.
*/
double damping;
};
* spent in the factorization, so this functionality may not always be of
* large benefit.
*
- * In contrast to the other direct solver classes, the initialisation method
- * does nothing. Therefore initialise is not automatically called by this
+ * In contrast to the other direct solver classes, the initialization method
+ * does nothing. Therefore initialize is not automatically called by this
* method, when the initialization step has not been performed yet.
*
* This function copies the contents of the matrix into its own storage; the
template <typename number>
void SwappableVector<number>::reload ()
{
- // if in MT mode: synchronise with
+ // if in MT mode: synchronize with
// possibly existing @p alert
// calls. if not in MT mode, this
// is a no-op
return;
#else
- // synchronise with possible other
+ // synchronize with possible other
// invocations of this function and
// other functions in this class
lock.acquire ();
/**
* Trilinos doesn't allow to mix additions to matrix entries and
- * overwriting them (to make synchronisation of %parallel computations
+ * overwriting them (to make synchronization of %parallel computations
* simpler). The way we do it is to, for each access operation, store
* whether it is an insertion or an addition. If the previous one was of
* different type, then we first have to flush the Trilinos buffers;
private:
/**
* Trilinos doesn't allow to mix additions to matrix entries and
- * overwriting them (to make synchronisation of parallel computations
+ * overwriting them (to make synchronization of parallel computations
* simpler). The way we do it is to, for each access operation, store
* whether it is an insertion or an addition. If the previous one was of
* different type, then we first have to flush the Trilinos buffers;
bool log_statistics;
/**
- * Mutex to synchronise access to internal data of this object from multiple
+ * Mutex to synchronize access to internal data of this object from multiple
* threads.
*/
static Threads::Mutex mutex;
* which we found can take a significant amount of time if it happens
* often even in the single threaded case (10-20 per cent in our
* measurements); however, most importantly, memory allocation requires
- * synchronisation in multithreaded mode. While that is done by the C++
+ * synchronization in multithreaded mode. While that is done by the C++
* library and has not to be handcoded, it nevertheless seriously damages
* the ability to efficiently run the functions of this class in parallel,
- * since they are quite often blocked by these synchronisation points,
+ * since they are quite often blocked by these synchronization points,
* slowing everything down by a factor of two or three.
*
* Thus, every thread gets an instance of this class to work with and
- * needs not allocate memory itself, or synchronise with other threads.
+ * needs not allocate memory itself, or synchronize with other threads.
*
* The sizes of the arrays are initialized with the maximal number of
* entries necessary for the hp case. Within the loop over individual
* points for each of the solution vectors (i.e. a temporary value).
* This vector is not allocated inside the functions that use it, but
* rather globally, since memory allocation is slow, in particular in
- * presence of multiple threads where synchronisation makes things even
+ * presence of multiple threads where synchronization makes things even
* slower.
*/
std::vector<std::vector<std::vector<number> > > phi;
/**
- * Specialisation of TimeStepBase which addresses some aspects of grid
+ * Specialization of TimeStepBase which addresses some aspects of grid
* handling. In particular, this class is thought to make handling of grids
* available that are adaptively refined on each time step separately or with
* a loose coupling between time steps. It also takes care of deleting and
// These might be required when the faces contribution is computed
- // Therefore they will be initialised at this point.
+ // Therefore they will be initialized at this point.
std::vector<AnisotropicPolynomials<dim>* > polynomials_abf(dim);
// Generate x_1^{i} x_2^{r+1} ...
}
- // Now initialise edge interior weights for the ABF elements.
+ // Now initialize edge interior weights for the ABF elements.
// These are completely independent from the usual edge moments. They
// stem from applying the Gauss theorem to the nodal values, which
// was necessary to cast the ABF elements into the deal.II framework
const Point<dim> (&corners) [dim],
const bool colorize)
{
- // Equalise number of subdivisions in each dim-direction, their
+ // Equalize number of subdivisions in each dim-direction, their
// validity will be checked later
unsigned int n_subdivisions_ [dim];
for (unsigned int i=0; i<dim; ++i)
// now for what is done in each loop: we have to fulfill several
// tasks at the same time, namely several mesh smoothing algorithms
- // and mesh regularisation, by which we mean that the next mesh
+ // and mesh regularization, by which we mean that the next mesh
// fulfills several requirements such as no double refinement at
// each face or line, etc.
//
// these were done at once, so the code was rather impossible to
// join into this, only, function), we do them one after each
// other. the order in which we do them is such that the important
- // tasks, namely regularisation, are done last and the least
+ // tasks, namely regularization, are done last and the least
// important things are done the first. the following order is
// chosen:
//
static GrowingVectorMemory<GVMVectorType> vector_memory;
GVMVectorType *i = vector_memory.alloc();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorDomainMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
const_cast<TrilinosPayload &>(first_op).transpose();
const_cast<TrilinosPayload &>(second_op).transpose();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorRangeMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
static GrowingVectorMemory<GVMVectorType> vector_memory;
GVMVectorType *i = vector_memory.alloc();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorRangeMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
const_cast<TrilinosPayload &>(first_op).transpose();
const_cast<TrilinosPayload &>(second_op).transpose();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorDomainMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
static GrowingVectorMemory<GVMVectorType> vector_memory;
GVMVectorType *i = vector_memory.alloc();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorDomainMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
const_cast<TrilinosPayload &>(first_op).transpose();
const_cast<TrilinosPayload &>(second_op).transpose();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorRangeMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
static GrowingVectorMemory<GVMVectorType> vector_memory;
GVMVectorType *i = vector_memory.alloc();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorRangeMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
const_cast<TrilinosPayload &>(first_op).transpose();
const_cast<TrilinosPayload &>(second_op).transpose();
- // Initialise intermediate vector
+ // Initialize intermediate vector
const Epetra_Map &first_op_init_map = first_op.OperatorDomainMap();
i->reinit(IndexSet(first_op_init_map),
first_op.get_mpi_communicator(),
// ---------------------------------------------------------------------
-// we used to synchronise child tasks with the one that spawned it by
+// we used to synchronize child tasks with the one that spawned it by
// using a mutex, but this could lead to deadlocks if there are more
// tasks than processors available, see the emails on the mailing
// lists in late nov 2010.
// ---------------------------------------------------------------------
-// Tests reinitialisation of square and rectangle LAPACKFullMatrix
+// Tests reinitialization of square and rectangle LAPACKFullMatrix
#include "../tests.h"
#include <deal.II/lac/lapack_full_matrix.h>
logfile.precision(3);
deallog.attach(logfile);
- // Test square matrix initialisation
+ // Test square matrix initialization
test (4, true);
test (5, true);
test (6, true);
- // Test rectangle matrix initialisation
+ // Test rectangle matrix initialization
test (4, false);
test (5, false);
test (6, false);
// initialised to 0+0i.
void init_petsc_complex ()
{
- deallog << "Check PetscScalar initialisation" << std::endl;
+ deallog << "Check PetscScalar initialization" << std::endl;
// Initialise (no argument) to zero.
const PetscScalar alpha;
{
Utilities::MPI::MPI_InitFinalize mpi_initialization (argc, argv, 1);
{
- // initialisation (zero and nonzero)
+ // initialization (zero and nonzero)
init_petsc_complex ();
make_petsc_complex ();
- // initialisation from std::complex (and vice versa)
+ // initialization from std::complex (and vice versa)
make_petsc_complex_from_std_complex ();
make_std_complex_from_petsc_complex ();
-DEAL::Check PetscScalar initialisation
+DEAL::Check PetscScalar initialization
DEAL::OK
DEAL::Check a nonzero PetscScalar
DEAL::OK
projects / dealii.git / commitdiff