* (a mutex) rather than task scheduler resources. The result is a
* deadlock.
*
- * The bottom line is that tasks can not use mutices or condition variables to
+ * The bottom line is that tasks can not use mutexes or condition variables to
* synchronize with other tasks. If communication between tasks is necessary,
* you need to use threads because the operating system makes sure that all
* threads eventually get to run, independent of the total number of threads.
* Note however that the same is not true if you only use a Thread::Mutex on
* each task separately to protect access to a variable that the tasks may
- * write to: this use of mutices is ok; tasks may simply not want to wait for
+ * write to: this use of mutexes is ok; tasks may simply not want to wait for
* another task to do something.
*
*
<h4> Adding the point value and the mean (see extension above) into the .h5 file</h4>
-After outputing the solution, the file can be opened again to include
+After outputting the solution, the file can be opened again to include
more datasets. This allows us to keep all the necessary information
of our experiment in a single result file, which can then be read and
processed by some postprocessing script.
the people who wrote the posts mentioned in the links above. It
does, however, show the character of the solution as a wave equation
if you look at the shaded part of the domain outside the circle of
-radius 0.7 in which the potential is zero -- you can see how everytime
+radius 0.7 in which the potential is zero -- you can see how every time
one of the bumps (showing the amplitude $|\psi_h(\mathbf x,t)|^2$)
bumps into the area where the potential is large: a wave travels
outbound from there. Take a look at the video:
HDF5::DataSet frequency_dataset;
HDF5::DataSet probe_positions_dataset;
- // HDF5 dataset that stores the values of the energy measured by the proble.
+ // HDF5 dataset that stores the values of the energy measured by the probe.
HDF5::DataSet displacement;
// relaxation parameter.
// Since multiplicative methods tend to be more powerful than additive method,
- // fewer smoothing steps are required to see convergence indepedent of mesh
+ // fewer smoothing steps are required to see convergence independent of mesh
// size. The same holds for block smoothers over point smoothers. This is
// reflected in the choice for the number of smoothing steps for each type of
// smoother below.
* Authors: Bruno Turcksin, Daniel Arndt, Oak Ridge National Laboratory, 2019
*/
-// First include the necessary files from the deal.II libary known from the
+// First include the necessary files from the deal.II library known from the
// previous tutorials.
#include <deal.II/base/conditional_ostream.h>
#include <deal.II/base/quadrature_lib.h>
// This solve() function finally contains the calls to the new classes
- // previously dicussed. Here we don't use any preconditioner, i.e.
+ // previously discussed. Here we don't use any preconditioner, i.e.,
// precondition by the identity matrix, to focus just on the peculiarities of
// the CUDAWrappers::MatrixFree framework. Of course, in a real application
// the choice of a suitable preconditioner is crucial but we have at least the
// the machine, there is nothing we can do about it: All MPI ranks on
// that machine need to share it. But if there are more than one GPU,
// then it is better to address different graphic cards for different
-// processes. The choice below is based on the MPI proccess id by
+// processes. The choice below is based on the MPI process id by
// assigning GPUs round robin to GPU ranks. (To work correctly, this
// scheme assumes that the MPI ranks on one machine are
// consecutive. If that were not the case, then the rank-GPU
because the new points placed along interior cells intersect with the boundary
as they are not following the circular shape along the toroidal direction. The
simple case of a torus can still be fixed because we know that the toroidal
-direction follows a cylindrical coordindate system, so attaching a
+direction follows a cylindrical coordinate system, so attaching a
TorusManifold to the surface combined with CylindricalManifold with
appropriate periodicity in toroidal direction applied to all interior entities
would produce a high-quality mesh as follows, now shown with two top cells
polynomial degree, and note that one would make different choices depending
also on the flow configuration. The default choice is $p+2$ points -- a bit
more than the minimum possible of $p+1$ points. The FEEvaluation and
-FEFaceEvaluation classes allow to seemlessly change the number of points by a
+FEFaceEvaluation classes allow to seamlessly change the number of points by a
template parameter, such that the program does not get more complicated
because of that.
</table>
The tables show that we get optimal $\mathcal O\left(h^{p+1}\right)$
-convergence rates for both numerical fluxes. The errors are slighly smaller
+convergence rates for both numerical fluxes. The errors are slightly smaller
for the Lax--Friedrichs flux for $p=2$, but the picture is reversed for
$p=3$; in any case, the differences on this testcase are relatively
small.
// points. Whereas we previously always set the number of quadrature points
// to equal the polynomial degree plus one (ensuring exact integration on
// affine element shapes), we now set the number quadrature points as a
- // separate variable (e.g. the polynomial degree plus two or three halfs of
+ // separate variable (e.g. the polynomial degree plus two or three halves of
// the polynomial degree) to more accurately handle nonlinear terms. Since
// the evaluator is fed with the appropriate loop lengths via the template
// argument and keeps the number of quadrature points in the whole cell in
// choose a constant inflow profile, whereas we set a subsonic outflow at
// the right. For the boundary around the cylinder (boundary id equal to 2)
// as well as the channel walls (boundary id equal to 3) we use the wall
- // boundary type, which is no-normal flow. Furthermore, for the 3D cyclinder
+ // boundary type, which is no-normal flow. Furthermore, for the 3D cylinder
// we also add a gravity force in vertical direction. Having the base mesh
// in place (including the manifolds set by
// GridGenerator::channel_with_cylinder()), we can then perform the
* output/solution_0003.pvtu
* @endcode
* where the `.0.vtu` file contains the output of the first half of the
- * proceses grouped together, and the `.1.vtu` the data from the remaining
+ * processes grouped together, and the `.1.vtu` the data from the remaining
* half.
*
* A specified @p directory and a @p filename_without_extension
{
public:
/**
- * Constructor. Blocks until it can aquire the lock.
+ * Constructor. Blocks until it can acquire the lock.
*/
explicit ScopedLock(CollectiveMutex &mutex, const MPI_Comm &comm)
: mutex(mutex)
~CollectiveMutex();
/**
- * Aquire the mutex and, if necessary, wait until we can do so.
+ * Acquire the mutex and, if necessary, wait until we can do so.
*
* This is a collective call that needs to be executed by all processors
* in the communicator.
/**
* Construct a MutableBind object specifying only the function. By default,
- * the arguments are left to their defult constructor values.
+ * the arguments are left to their default constructor values.
*/
template <class FunctionType>
MutableBind(FunctionType function);
* The parameter @p has_to_be_set can be used in order to declare this
* parameter as a parameter whose default value has to be overwritten by
* one of the methods provided by this class. Whether a parameter has been set
- * succesfully can be queried by the functions get_entries_wrongly_not_set()
+ * successfully can be queried by the functions get_entries_wrongly_not_set()
* and assert_that_entries_have_been_set().
*
* @note An entry can be declared more than once without generating an
* The parameter @p has_to_be_set can be used in order to declare this
* parameter as a parameter whose default value has to be overwritten by
* one of the methods provided by this class. Whether a parameter has been set
- * succesfully can be queried by the functions get_entries_wrongly_not_set()
+ * successfully can be queried by the functions get_entries_wrongly_not_set()
* and assert_that_entries_have_been_set().
*/
template <class ParameterType>
* output_table() also writes in this file in the format deduced from its
* extension;
* @param precision How many digits to use when writing the error;
- * @param compute_error Control wether the filling of the table is enabled
+ * @param compute_error Control whether the filling of the table is enabled
* or not. This flag may be used to disable at run time any error computation;
*
* The parameters you specify with this constructor can be written to a
* thus determined by the size of the vector passed.
*
* Note that all the derivatives evaluate to zero at the border between
- * intervals (assuming exact arithmetics) in the interior of the unit
+ * intervals (assuming exact arithmetic) in the interior of the unit
* interval, as there is no unique gradient value in that case for a
* piecewise polynomial. This is not always desired (e.g., when evaluating
* jumps of gradients on the element boundary), but it is the user's
* space for @p n_derivatives + 1 values.
*
* Note that all the derivatives evaluate to zero at the border between
- * intervals (assuming exact arithmetics) in the interior of the unit
+ * intervals (assuming exact arithmetic) in the interior of the unit
* interval, as there is no unique gradient value in that case for a
* piecewise polynomial. This is not always desired (e.g., when evaluating
* jumps of gradients on the element boundary), but it is the user's
* expression, together with its derivatives (if required). These are then
* used in all subsequent evaluations. Calling
* set_additional_function_arguments() will evaluate the passed
- * subsitution map on the fly during evaluation time, *after* all
+ * substitution map on the fly during evaluation time, *after* all
* derivatives have been computed.
*
* @note The difference between this class and the FunctionParser class is
LAPACKFullMatrix<Number> lapack_matrix(dim);
LAPACKFullMatrix<Number> result(dim);
- // todo: find or add dealii functionallity to copy in one step.
+ // todo: find or add dealii functionality to copy in one step.
matrix.copy_from(tensor);
lapack_matrix.copy_from(matrix);
// Use the SVD results to orthogonalize: $U V^T$
lapack_matrix.get_svd_u().mmult(result, lapack_matrix.get_svd_vt());
- // todo: find or add dealii functionallity to copy in one step.
+ // todo: find or add dealii functionality to copy in one step.
matrix = result;
matrix.copy_to(output_tensor);
return output_tensor;
VectorizedArray &
operator+=(const VectorizedArray &vec)
{
- // if the compiler supports vector arithmetics, we can simply use +=
+ // if the compiler supports vector arithmetic, we can simply use +=
// operator on the given data type. this allows the compiler to combine
// additions with multiplication (fused multiply-add) if those
// instructions are available. Otherwise, we need to use the built-in
VectorizedArray &
operator+=(const VectorizedArray &vec)
{
- // if the compiler supports vector arithmetics, we can simply use +=
+ // if the compiler supports vector arithmetic, we can simply use +=
// operator on the given data type. this allows the compiler to combine
// additions with multiplication (fused multiply-add) if those
// instructions are available. Otherwise, we need to use the built-in
VectorizedArray &
operator+=(const VectorizedArray &vec)
{
- // if the compiler supports vector arithmetics, we can simply use +=
+ // if the compiler supports vector arithmetic, we can simply use +=
// operator on the given data type. this allows the compiler to combine
// additions with multiplication (fused multiply-add) if those
// instructions are available. Otherwise, we need to use the built-in
VectorizedArray &
operator+=(const VectorizedArray &vec)
{
- // if the compiler supports vector arithmetics, we can simply use +=
+ // if the compiler supports vector arithmetic, we can simply use +=
// operator on the given data type. this allows the compiler to combine
// additions with multiplication (fused multiply-add) if those
// instructions are available. Otherwise, we need to use the built-in
* @param output_values The evaluated numerical outcome of the
* substitution.
* @param substitution_values The values with which to associate each
- * individial independent symbol.
+ * individual independent symbol.
*/
static void
substitute(typename Optimizer::OptimizerType *optimizer,
* @param output_values The evaluated numerical outcome of the
* substitution.
* @param substitution_values The values with which to associate each
- * individial independent symbol.
+ * individual independent symbol.
*/
static void
substitute(typename Optimizer::OptimizerType *optimizer,
* practices" that can be adopted in order to mitigate this cost as much
* as possible:
* 1. Reuse a single instance of the class as much as possible.
- * The most obvious wat that this can be achieved would be to place an
+ * The most obvious way that this can be achieved would be to place an
* instance of this class in a centralized location where it can
- * potentially be used by mulitple calling functions and objects, if
+ * potentially be used by multiple calling functions and objects, if
* contextually possible.
* 2. Another form of reuse would entail generalizing the dependent
* functions/expressions to be evaluated by the optimizer as much as
- * possible. For example, material coeffients need not necessarily be
+ * possible. For example, material coefficients need not necessarily be
* hard-coded, and one generalized statement of a constitutive law could
- * then be broadly used in other material subdomains goverened by the
- * same class of constiutive law, but with different constitutive
+ * then be broadly used in other material subdomains governed by the
+ * same class of constitutive law, but with different constitutive
* parameters. The same principle applies if using symbolic expressions
* to describe boundary conditions, systems of linear equations, etc.
* 3. When possible, consider using serialization to save and load the state
*
* @note In contrast to the other variants of this function, the order of
* the returned entries is an internal implementation detail, and cannot
- * be guarenteed under all conditions. The entries in the returned vector
+ * be guaranteed under all conditions. The entries in the returned vector
* are, in general, identical to the order in which the dependent
* expressions are originally registered. However, when registering
* tensors and symmetric tensors of expressions, these are "unrolled"
* to store the result of a substitution sweep as some optimizers
* work on all symbolic expressions in a single batch. In this way
* they can employ methods such as common subexpression elimination
- * to minimise the number of terms evaluated across all symbolic
+ * to minimize the number of terms evaluated across all symbolic
* functions.
*
* This variable is marked as mutable. This facilitates the substitution
std::vector<MPI_Request> requests(cells_to_send.size());
std::vector<unsigned int> destinations;
- // Protect the communcation below:
+ // Protect the communication below:
static Utilities::MPI::CollectiveMutex mutex;
Utilities::MPI::CollectiveMutex::ScopedLock lock(mutex, communicator);
protected:
/**
- * This is the main function overriden from the base class MappingQGeneric.
+ * This is the main function overridden from the base class MappingQGeneric.
*/
virtual std::vector<Point<spacedim>>
compute_mapping_support_points(
/**
* Vertical distance from airfoil chord to upper boundary of the mesh
- * i.e. half of the total mesh hight.
+ * i.e. half of the total mesh height.
*/
double height;
* nonequidistand airfoil points.
* Increasing the provided nonequidistant airfoil points leads to
* a better approximation of the airfoil geometry. Parameter
- * "airfoil_sampling_factor" therby defines the relation of
+ * "airfoil_sampling_factor" thereby defines the relation of
* provided_nonequidistant_points to required_equidistant_points.
*/
unsigned int airfoil_sampling_factor;
}
}
- // Protect the following communcation:
+ // Protect the following communication:
static Utilities::MPI::CollectiveMutex mutex;
Utilities::MPI::CollectiveMutex::ScopedLock lock(mutex,
tria->get_communicator());
* @return Description to be used to set up a Triangulation.
*
* @note If construct_multigrid_hierarchy is set in the settings, the
- * @p smooting parameter is extended with the
+ * @p smoothing parameter is extended with the
* limit_level_difference_at_vertices flag.
*
* @author Peter Munch, 2019
* all elements associated with the provided set of indices @p fes.
*
* You may find information about the domination behavior of finite elements
- * in their respecitve class documentation or in the implementation of their
+ * in their respective class documentation or in the implementation of their
* inherited member function FiniteElement::compare_for_domination().
* Consider that a finite element may or may not dominate itself (e.g.
* FE_Nothing elements).
* dominated by all elements associated with the provided set of indices @p fes.
*
* You may find information about the domination behavior of finite elements
- * in their respecitve class documentation or in the implementation of their
+ * in their respective class documentation or in the implementation of their
* inherited member function FiniteElement::compare_for_domination().
* Consider that a finite element may or may not dominate itself (e.g.
* FE_Nothing elements).
* that dominates all other elements of this very set.
*
* You may find information about the domination behavior of finite elements
- * in their respecitve class documentation or in the implementation of their
+ * in their respective class documentation or in the implementation of their
* inherited member function FiniteElement::compare_for_domination().
* Consider that a finite element may or may not dominate itself (e.g.
* FE_Nothing elements).
* that is dominated by all other elements of this very set.
*
* You may find information about the domination behavior of finite elements
- * in their respecitve class documentation or in the implementation of their
+ * in their respective class documentation or in the implementation of their
* inherited member function FiniteElement::compare_for_domination().
* Consider that a finite element may or may not dominate itself (e.g.
* FE_Nothing elements).
* provided set @p fes are part of.
*
* You may find information about the domination behavior of finite elements
- * in their respecitve class documentation or in the implementation of their
+ * in their respective class documentation or in the implementation of their
* inherited member function FiniteElement::compare_for_domination().
* Consider that a finite element may or may not dominate itself (e.g.
* FE_Nothing elements).
* element space which includes all finite elements of the provided set @p fes.
*
* You may find information about the domination behavior of finite elements
- * in their respecitve class documentation or in the implementation of their
+ * in their respective class documentation or in the implementation of their
* inherited member function FiniteElement::compare_for_domination().
* Consider that a finite element may or may not dominate itself (e.g.
* FE_Nothing elements).
namespace hp
{
/**
- * We supply adaptive methods to align computational ressources with the
+ * We supply adaptive methods to align computational resources with the
* complexity of the numerical solution. Error estimates are an appropriate
* means of determining where adjustments need to be made.
*
*
* Such functions take two numbers as arguments: The first one corresponds
* to the provided criterion, while the other one conforms to the reference.
- * The result of the comparision will be returned as a boolean.
+ * The result of the comparison will be returned as a boolean.
*/
template <typename Number>
using ComparisonFunction =
* different, and their parent cell will be assigned to their least
* dominating finite element that belongs to its most general child. Thus,
* we will always interpolate on an enclosing finite element space.
- * Additionaly assuming that the finite elements on the cells to be
+ * Additionally assuming that the finite elements on the cells to be
* coarsened are sufficient to represent the solution correctly (e.g. at
* least quadratic basis functions for a quadratic solution), we are
* confident to say that the error will not change by sole interpolation on
virtual void
vector_compress_finish() = 0;
- /// Zeros part of the vector accroding to a given range as stored in
+ /// Zeros part of the vector according to a given range as stored in
/// DoFInfo
virtual void
zero_dst_vector_range(const unsigned int range_index) = 0;
* DOFINFO objects are gathered in a DoFInfoBox. In those objects, we store
* the results of local operations on each cell and its faces. Once all this
* information has been gathered, an ASSEMBLER is used to assemble it into
- * golbal data.
+ * global data.
*
* <h4>INFOBOX</h4>
*
// done recursively in our own code. take care of the two special formats
// first
- // explicity compress the tree if requested
+ // explicitly compress the tree if requested
if ((style & Short) && (style & (XML | JSON)))
{
// modify the copy of the tree
// >>> File or directory not found! <<<
// , every time a query is made about a non-existent tape.
// So either way we have to guard that check with something more
- // conervative so that we don't output useless messages for our users.
+ // conservative so that we don't output useless messages for our users.
const std::vector<typename Types<ADNumberType>::tape_index>
registered_tape_indices = get_registered_tape_indices();
const auto it = std::find(registered_tape_indices.begin(),
// coefficient. Upon serialization, this might be dropped, meaning
// that when we reload the expressions they now look somewhat
// different to as before. If all data that the user uses is
- // guarenteed to either have been serialized or never serialized, then
+ // guaranteed to either have been serialized or never serialized, then
// there would be no problem. However, users might rebuild their
// dependent expression and just reload the optimizer. This is
// completely legitimate. But in this scenario we might be out of sync
const Expression new_map_expr =
serialize_and_deserialize_expression(e.first);
- // Add a new map entry and re-search. This is guarenteed to be
+ // Add a new map entry and re-search. This is guaranteed to
// return a valid entry. Note that we must do a string comparison,
// because the data structures that form the expressions might
// still be different.
{
Assert(spacedim == 2, ExcInternalError());
- // For accuracy reasons, we do all arithmetics in extended precision
+ // For accuracy reasons, we do all arithmetic in extended precision
// (long double). This has a noticeable effect on the hit rate for
// borderline cases and thus makes the algorithm more robust.
const long double x = p(0);
// number of global refinements
const unsigned int refinements;
- // numer of subdivisions of coarse grid in blocks 1 and 4
+ // number of subdivisions of coarse grid in blocks 1 and 4
const unsigned int n_subdivision_x_0;
- // numer of subdivisions of coarse grid in blocks 2 and 5
+ // number of subdivisions of coarse grid in blocks 2 and 5
const unsigned int n_subdivision_x_1;
- // numer of subdivisions of coarse grid in blocks 3 and 6
+ // number of subdivisions of coarse grid in blocks 3 and 6
const unsigned int n_subdivision_x_2;
- // numer of subdivisions of coarse grid in all blocks (normal to
+ // number of subdivisions of coarse grid in all blocks (normal to
// airfoil or in y-direction, respectively)
const unsigned int n_subdivision_y;
// (C-Mesh) that arises after interpolation in blocks 1 and 4
const double height;
- // lenght block 3 and 6
+ // length block 3 and 6
const double length_b2;
// factor to move points G and I horizontal to the right, i.e. make
* Joukowski transformation of circle points created by function
* joukowski_circle().
*
- * @param[in] circle_points Vector containing oints of joukowski circle.
+ * @param[in] circle_points Vector containing points of joukowski
+ * circle.
* @return joukowski_points Vector containing joukowski airfoil points.
*/
static std::vector<Point<2>>
* by interpolation among factor*number_points NACA-airfoil points to
* obtain a better approximation of the airfoil geometry
*
- * @param[in] serialnumber NACA serial numer for different airfoil
+ * @param[in] serialnumber NACA serial number for different airfoil
* shapes (so far only 4-digit-series implemented).
* @param[in] number_points Number of required airfoil points for each
* side to being conform with amount of cells along the airfoil after
5 * t *
(0.2969 * std::pow(x, 0.5) - 0.126 * x -
0.3516 * std::pow(x, 2) + 0.2843 * std::pow(x, 3) -
- 0.1036 * std::pow(x, 4)); // half thicknes at a position x
+ 0.1036 * std::pow(x, 4)); // half thickness at a position x
const double theta = std::atan(dy_c);
* x-axis (by definition of points A-L), blocks 1&4, 2&4 and 3&6 can be
* interpolated with the same geometric computations Consider a
* bias_factor and incline_factor during interpolation to obtain a more
- * dense mesh next to airfoil geometry and recieve an inclined boundary
+ * dense mesh next to airfoil geometry and receive an inclined boundary
* between block 2&3 and 5&6, respectively
*/
void interpolate(Triangulation<2> &tria) const
// 1 so that A(0) is on y-axis so that faces AD and BC are
// horizontal. This simplifies the computation of the
// required indices for interpolation (all x-nodes are
- // positiv) Move trapeze to be in first quadrant by addig
+ // positive) Move trapeze to be in first quadrant by adding
// trapeze_offset
Point<2, double> node_;
if (cell.material_id() == id_block_1)
namespace
{
/**
- * Given a GridGenerator function pointer, a string containig a text
+ * Given a GridGenerator function pointer, a string containing a text
* version of the function arguments and an empty Triangulation, calls the
* corresponding function, after parsing the arguments from the given
* string.
// We assume the last used cell contains the point: checking it
if (cell_candidate_idx != -1)
if (!box_cell[cell_candidate_idx].first.point_inside(points[p]))
- // Point ouside candidate cell: we have no candidate
+ // Point outside candidate cell: we have no candidate
cell_candidate_idx = -1;
// If there's no candidate, run a tree search
"Vector containing patch cells should not be an empty vector!"));
// In order to extract the set of cells with the coarsest common level from
// the give vector of cells: First it finds the number associated with the
- // minimum level of refinmenet, namely "min_level"
+ // minimum level of refinement, namely "min_level"
int min_level = patch[0]->level();
for (unsigned int i = 0; i < patch.size(); ++i)
for (types::global_dof_index i = 0; i < n_dofs; ++i)
{
SparseMatrix<double>::iterator
- anfang = prolongation_matrices[level]
- ->block(iblock, jblock)
- .begin(i),
- ende = prolongation_matrices[level]
- ->block(iblock, jblock)
- .end(i);
- for (; anfang != ende; ++anfang)
+ begin = prolongation_matrices[level]
+ ->block(iblock, jblock)
+ .begin(i),
+ end = prolongation_matrices[level]
+ ->block(iblock, jblock)
+ .end(i);
+ for (; begin != end; ++begin)
{
const types::global_dof_index column_number =
- anfang->column();
+ begin->column();
// convert global indices into local ones
const BlockIndices block_indices_coarse(
// Create the memory pool that will store all particle properties
property_pool = std_cxx14::make_unique<PropertyPool>(n_properties);
- // Create the grid cache to cache the informations about the triangulation
+ // Create the grid cache to cache the information about the triangulation
// that is used to locate the particles into subdomains and cells
triangulation_cache =
std_cxx14::make_unique<GridTools::Cache<dim, spacedim>>(new_triangulation,
projects / dealii.git / commitdiff