\n Static Private Attributes | |
| static std::mutex | mutex |
The abstract base class of all algorithms in this library. An operator is an object with an operator(), which transforms a set of named vectors into another set of named vectors.
\nFurthermore, an operator can be notified of parameter changes by the calling routine. The outer iteration can notify() the Operator of an Event, which could be for instance a change of mesh, a different time step size or too slow convergence of Newton's method, which would then trigger reassembling of a matrix or similar things.
\nThis is probably the most prominent use for Operator, where an outer iterative method calls an inner solver and so on. Typically, the innermost method in such a nested system will have to compute a residual using values from all outer iterations. Since the depth and order of such a nesting is hardly predictable when designing a general tool, we use AnyData to access these vectors. Typically, the first vector in out contains the start vector when operator()() is called, and the solution when the function returns. The object in is providing additional information and forwarded to the inner Operator objects of the nested iteration.
Definition at line 65 of file operator.h.
\nStore any amount of any type of data accessible by an identifier string.
\n-\n+\n \nDefinition at line 35 of file any_data.h.
\nThis class generates output from faces of a triangulation. It might be used to generate output only for the surface of the triangulation (this is the default of this class), or for all faces of active cells, as specified in the constructor. The output of this class is a set of patches (as defined by the class DataOutBase::Patch()), one for each face for which output is to be generated. These patches can then be written in several graphical data formats by the functions of the underlying classes.
\nThe interface of this class is copied from the DataOut class. Furthermore, they share the common parent class DataOut_DoFData. See the reference of these two classes for a discussion of the interface.
\nThe sequence of faces to generate patches from is generated in the same way as in the DataOut class; see there for a description of the respective interface. The functions generating the sequence of faces which shall be used to generate output, are called first_face() and next_face().
\nSince we need to initialize objects of type FEValues with the faces generated from these functions, it is not sufficient that they only return face iterators. Rather, we need a pair of cell and the number of the face, as the values of finite element fields need not necessarily be unique on a face (think of discontinuous finite elements, where the value of the finite element field depend on the direction from which you approach a face, thus it is necessary to use a pair of cell and face, rather than only a face iterator). Therefore, this class defines an alias which creates a type FaceDescriptor that is an abbreviation for a pair of cell iterator and face number. The functions first_face and next_face operate on objects of this type.
Extending this class might, for example, be useful if you only want output from certain portions of the boundary, e.g. as indicated by the boundary indicator of the respective faces. However, it is also conceivable that one generates patches not from boundary faces, but from interior faces that are selected due to other criteria; one application might be to use only those faces where one component of the solution attains a certain value, in order to display the values of other solution components on these faces. Other applications certainly exist, for which the author is not imaginative enough.
\n-Definition at line 108 of file data_out_faces.h.
\nSame as above, except that the additional first parameter defines a mapping that is to be used in the generation of output. If n_subdivisions>1, the points interior of subdivided patches which originate from cells at the boundary of the domain can be computed using the mapping, i.e. a higher order mapping leads to a representation of a curved boundary by using more subdivisions.
Even for non-curved cells the mapping argument can be used for the Eulerian mappings (see class MappingQ1Eulerian) where a mapping is used not only to determine the position of points interior to a cell, but also of the vertices. It offers an opportunity to watch the solution on a deformed triangulation on which the computation was actually carried out, even if the mesh is internally stored in its undeformed configuration and the deformation is only tracked by an additional vector that holds the deformation of each vertex.
\n-mapping argument should be replaced by a hp::MappingCollection in case of a DoFHandler with hp-capabilities. mapping argument should be replaced by a hp::MappingCollection in case of a DoFHandler with hp-capabilities. Definition at line 345 of file data_out_faces.cc.
\n \n| using DoFHandler< dim, spacedim >::active_fe_index_type = types::fe_index | \n
The type in which we store the active FE index.
\n-Definition at line 536 of file dof_handler.h.
\n \nFor each locally owned cell, set the active finite element index to the corresponding value given in active_fe_indices.
The vector active_fe_indices needs to have as many entries as there are active cells. The FE indices must be in the order in which we iterate over active cells. Vector entries corresponding to active cells that are not locally owned are ignored.
Active FE indices will only be set for locally owned cells. Ghost and artificial cells will be ignored; no active FE index will be assigned to them. To exchange active FE indices on ghost cells, call distribute_dofs() afterwards.
\n-For each locally relevant cell, extract the active finite element index and fill the vector active_fe_indices in the order in which we iterate over active cells. This vector is resized, if necessary.
As we do not know the active FE index on artificial cells, they are set to the invalid value numbers::invalid_fe_index.
\nFor DoFHandler objects without hp-capabilities, the vector will consist of zeros, indicating that all cells use the same finite element. In hp-mode, the values may be different, though.
\nThe returned vector has as many entries as there are active cells.
\n-Invalid index of the finite element to be used on a given cell.
\n-Definition at line 528 of file dof_handler.h.
\n \nInvalid active FE index which will be used as a default value to determine whether a future FE index has been set or not.
\n-Definition at line 549 of file dof_handler.h.
\n \nImplementation of Arnold-Boffi-Falk (ABF) elements, conforming with the space Hdiv. These elements generate vector fields with normal components continuous between mesh cells.
\nThese elements are based on an article from Arnold, Boffi and Falk: Quadrilateral H(div) finite elements, SIAM J. Numer. Anal. Vol.42, No.6, pp.2429-2451
\nIn this article, the authors demonstrate that the usual RT elements and also BDM and other proposed finite dimensional subspaces of H(div) do not work properly on arbitrary FE grids. I.e. the convergence rates deteriorate on these meshes. As a solution the authors propose the ABF elements, which are implemented in this class.
\nThis class is not implemented for the codimension one case (spacedim != dim).
The interpolation operators associated with the RT element are constructed such that interpolation and computing the divergence are commuting operations. We require this from interpolating arbitrary functions as well as the restriction matrices. It can be achieved by two interpolation schemes, the simplified one in FE_RaviartThomasNodal and the original one here:
\nOn edges or faces, the node values are the moments of the normal component of the interpolated function with respect to the traces of the RT polynomials. Since the normal trace of the RT space of degree k on an edge/face is the space Qk, the moments are taken with respect to this space.
\nHigher order RT spaces have interior nodes. These are moments taken with respect to the gradient of functions in Qk on the cell (this space is the matching space for RTk in a mixed formulation).
\nThe Brezzi-Douglas-Marini element.
\nThe matching pressure space for FE_BDM of order k is the element FE_DGP of order k-1.
\nThe BDM element of order p has p+1 degrees of freedom on each face. These are implemented as the function values in the p+1 Gauss points on each face.
Additionally, for order greater or equal 2, we have additional p(p-1), the number of vector valued polynomials in Pp, interior degrees of freedom. These are the vector function values in the first p(p-1)/2 of the p2 Gauss points in the cell.
\n \n \nDefinition at line 150 of file cuda_vector.h.
\n \nDefinition at line 345 of file trilinos_epetra_vector.h.
\n \nDefinition at line 312 of file read_write_vector.h.
\n \nDefinition at line 341 of file read_write_vector.h.
\n \nDefinition at line 371 of file read_write_vector.h.
\n \nDefinition at line 403 of file read_write_vector.h.
\n \nDefinition at line 435 of file read_write_vector.h.
\n \nDefinition at line 464 of file read_write_vector.h.
\n \nDefinition at line 493 of file read_write_vector.h.
\n \nBase class used to declare the operations needed by a concrete class implementing prolongation and restriction of vectors in the multigrid context. This class is abstract and has no implementation of these operations.
\nThere are several derived classes, reflecting the fact that vector types and numbering of the fine-grid discretization and of the multi-level implementation are independent.
\nIf you use multigrid for a single PDE or for your complete system of equations, you will use MGTransferPrebuilt together with Multigrid. The vector types used on the fine grid as well as for the multilevel operations may be Vector or BlockVector. In both cases, MGTransferPrebuilt will operate on all components of the solution.
\nFor mixed systems, it may be required to do multigrid only for a single component or for some components. The classes MGTransferSelect and MGTransferBlock handle these cases.
\nMGTransferSelect is used if you use multigrid (on Vector objects) for a single component, possibly grouped using mg_target_component.
The class MGTransferBlock handles the case where your multigrid method operates on BlockVector objects. These can contain all or a consecutive set of the blocks of the complete system. Since most smoothers cannot operate on block structures, it is not clear whether this case is really useful. Therefore, a tested implementation of this case will be supplied when needed.
\n \n \nHere, the weights \\(\\text{JxW}_q\\) of each quadrature point (where JxW mnemonically stands for Jacobian times Quadrature Weights) take the role of the \\(dx\\) in the original integral. Consequently, they appear in all code that computes integrals approximated by quadrature, and are accessed by FEValues::JxW().
\n-The transformation of vector fields or differential forms (gradients of scalar functions) \\(\\mathbf v\\), and gradients of vector fields \\(\\mathbf T\\) follows the general form
\n\n \\[\n \\mathbf v(\\mathbf x) = \\mathbf A(\\hat{\\mathbf x})\n \\hat{\\mathbf v}(\\hat{\\mathbf x}),\n \\qquad\n@@ -1072,15 +1072,15 @@\n \n \n
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
| [in] | input | An array (or part of an array) of input objects that should be mapped. |
| [in] | kind | The kind of mapping to be applied. |
| [in] | internal | A pointer to an object of type Mapping::InternalDataBase that contains information previously stored by the mapping. The object pointed to was created by the get_data(), get_face_data(), or get_subface_data() function, and will have been updated as part of a call to fill_fe_values(), fill_fe_face_values(), or fill_fe_subface_values() for the current cell, before calling the current function. In other words, this object also represents with respect to which cell the transformation should be applied to. |
| [out] | output | An array (or part of an array) into which the transformed objects should be placed. (Note that the array view is const, but the tensors it points to are not.) |
Assemble local residuals into global residuals.
\nThe global residuals are expected as an FEVectors object. The local residuals are block vectors.
\nDepending on whether the BlockInfo object was initialize with BlockInfo::initialize_local(), the comprehensive or block data model is used locally.
\nIn the block model, each of the blocks of the local vectors corresponds to the restriction of a single block of the system to this cell (see GlossBlock). Thus, the size of this local block is the number of degrees of freedom of the corresponding base element of the FESystem.
\n-Definition at line 110 of file assembler.h.
\nConstructor, selecting the solver and other parameters specified in additional_data.
Definition at line 495 of file nonlinear.h.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 368 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 439 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 341 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 466 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 547 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 314 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 404 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 575 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 610 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 264 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 520 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 493 of file petsc_solver.cc.
\n \nConstructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
\n-\n+\n \nDefinition at line 650 of file petsc_solver.cc.
\n \n| std::function<void(const real_type t, VectorType &y)> PETScWrappers::TimeStepper< VectorType, PMatrixType, AMatrixType >::distribute | \n
update_constrained_components, but is deprecated. Use update_constrained_components instead. update_constrained_components, but is deprecated. Use update_constrained_components instead. Definition at line 621 of file petsc_ts.h.
\n \n| std::function<void(const real_type t, const unsigned int step, const VectorType &y, bool &resize)> PETScWrappers::TimeStepper< VectorType, PMatrixType, AMatrixType >::decide_for_coarsening_and_refinement | \n
decide_and_prepare_for_remeshing except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing instead. decide_and_prepare_for_remeshing except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing instead. Definition at line 656 of file petsc_ts.h.
\n \n| std::function<void(const std::vector<VectorType> &all_in, std::vector<VectorType> &all_out)> PETScWrappers::TimeStepper< VectorType, PMatrixType, AMatrixType >::interpolate | \n
transfer_solution_vectors_to_new_mesh, but is deprecated. Use transfer_solution_vectors_to_new_mesh instead. transfer_solution_vectors_to_new_mesh, but is deprecated. Use transfer_solution_vectors_to_new_mesh instead. Definition at line 688 of file petsc_ts.h.
\n \nCallback function that should be called before every refinement and when writing checkpoints. This function is used to register pack_callback() with the triangulation. This function is used in step-70.
\n-Definition at line 2186 of file particle_handler.cc.
\n \nCallback function that should be called after every refinement and after resuming from a checkpoint. This function is used to register unpack_callback() with the triangulation. This function is used in step-70.
\n-Definition at line 2233 of file particle_handler.cc.
\n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nDetermine the orientation of the current entity described by its vertices vertices_1 relative to an entity described by vertices_0. The two arrays given as arguments can be arrays of global vertex indices or local vertex indices, arrays of vertex locations, or arrays of any other objects identifying the vertices and the order in which they are encountered in a cell.
The size of the arrays, i.e., the template argument N, must be equal to or larger than the number of vertices of the current entity. If it is larger, only those elements of the input and output arrays are read from or written to that correspond to valid vertex indices.
Definition at line 3183 of file reference_cell.h.
\n \nInverse function of compute_orientation(): Given a set of vertex-associated objects (such as vertex indices, locations, etc.) and a desired orientation permutation, return the permuted vertex information.
\nThe size of the input and output arrays, i.e., the template argument N, must be equal to or larger than the number of vertices of the current entity. If it is larger, only those elements of the input and output arrays are read from or written to that correspond to valid vertex indices.
Definition at line 3259 of file reference_cell.h.
\n \n| std::function<VectorType &()> SUNDIALS::KINSOL< VectorType >::get_solution_scaling | \n
A function object that users may supply and that is intended to return a vector whose components are the weights used by KINSOL to compute the vector norm of the solution. The implementation of this function is optional, and it is used only if implemented.
\n-The intent for this scaling factor is for problems in which the different components of a solution have vastly different numerical magnitudes – typically because they have different physical units and represent different things. For example, if one were to solve a nonlinear Stokes problem, the solution vector has components that correspond to velocities and other components that correspond to pressures. These have different physical units and depending on which units one chooses, they may have roughly comparable numerical sizes or maybe they don't. To give just one example, in simulations of flow in the Earth's interior, one has velocities on the order of maybe ten centimeters per year, and pressures up to around 100 GPa. If one expresses this in SI units, this corresponds to velocities of around \\(0.000,000,003=3 \\times 10^{-9}\\) m/s, and pressures around \\(10^9 \\text{kg}/\\text{m}/\\text{s}^2\\), i.e., vastly different. In such cases, computing the \\(l_2\\) norm of a solution-type vector (e.g., the difference between the previous and the current solution) makes no sense because the norm will either be dominated by the velocity components or the pressure components. The scaling vector this function returns is intended to provide each component of the solution with a scaling factor that is generally chosen as the inverse of a \"typical velocity\" or \"typical pressure\" so that upon multiplication of a vector component by the corresponding scaling vector component, one obtains a number that is of order of magnitude of one (i.e., a reasonably small multiple of one times the typical velocity/pressure). The KINSOL manual states this as follows: \"The user should supply values \\_form#2573,\n-which are diagonal elements of the scaling matrix such that \\_form#2590 has\n+
The intent for this scaling factor is for problems in which the different components of a solution have vastly different numerical magnitudes – typically because they have different physical units and represent different things. For example, if one were to solve a nonlinear Stokes problem, the solution vector has components that correspond to velocities and other components that correspond to pressures. These have different physical units and depending on which units one chooses, they may have roughly comparable numerical sizes or maybe they don't. To give just one example, in simulations of flow in the Earth's interior, one has velocities on the order of maybe ten centimeters per year, and pressures up to around 100 GPa. If one expresses this in SI units, this corresponds to velocities of around \\(0.000,000,003=3 \\times 10^{-9}\\) m/s, and pressures around \\(10^9 \\text{kg}/\\text{m}/\\text{s}^2\\), i.e., vastly different. In such cases, computing the \\(l_2\\) norm of a solution-type vector (e.g., the difference between the previous and the current solution) makes no sense because the norm will either be dominated by the velocity components or the pressure components. The scaling vector this function returns is intended to provide each component of the solution with a scaling factor that is generally chosen as the inverse of a \"typical velocity\" or \"typical pressure\" so that upon multiplication of a vector component by the corresponding scaling vector component, one obtains a number that is of order of magnitude of one (i.e., a reasonably small multiple of one times the typical velocity/pressure). The KINSOL manual states this as follows: \"The user should supply values \\_form#2664,\n+which are diagonal elements of the scaling matrix such that \\_form#2685 has\n all components roughly the same magnitude when \\_form#304 is close to a\n solution\".
\nIf no function is provided to a KINSOL object, then this is interpreted as implicitly saying that all of these scaling factors should be considered as one.
\nDefinition at line 651 of file kinsol.h.
\n \n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -367,16 +367,16 @@\n the pressure components. The scaling vector this function returns is intended\n to provide each component of the solution with a scaling factor that is\n generally chosen as the inverse of a \"typical velocity\" or \"typical pressure\"\n so that upon multiplication of a vector component by the corresponding scaling\n vector component, one obtains a number that is of order of magnitude of one\n (i.e., a reasonably small multiple of one times the typical velocity/pressure).\n The _\bK_\bI_\bN_\bS_\bO_\bL manual states this as follows: \"The user should supply values\n-\\_form#2573, which are diagonal elements of the scaling matrix such that\n-\\_form#2590 has all components roughly the same magnitude when \\_form#304 is\n+\\_form#2664, which are diagonal elements of the scaling matrix such that\n+\\_form#2685 has all components roughly the same magnitude when \\_form#304 is\n close to a solution\".\n If no function is provided to a _\bK_\bI_\bN_\bS_\bO_\bL object, then this is interpreted as\n implicitly saying that all of these scaling factors should be considered as\n one.\n Note\n This variable represents a _\bu_\bs_\be_\br_\b _\bp_\br_\bo_\bv_\bi_\bd_\be_\bd_\b _\bc_\ba_\bl_\bl_\bb_\ba_\bc_\bk. See there for a\n description of how to deal with errors and other requirements and\n"}]}, {"source1": "./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/classTriangulation.html", "source2": "./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/classTriangulation.html", "unified_diff": "@@ -1221,15 +1221,15 @@\n| using Triangulation< dim, spacedim >::CellStatus = ::CellStatus | \n
The elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Load the refinement information saved with save() back in. The mesh must contain the same coarse mesh that was used in save() before calling this function.
\nYou do not need to load with the same number of MPI processes that you saved with. Rather, if a mesh is loaded with a different number of MPI processes than used at the time of saving, the mesh is repartitioned so that the number of cells is balanced among all processes. Individual repartitioning with non-identical weights for each cell, e.g., based on the number of dofs or particles per cell, needs to be invoked manually by calling repartition() afterwards.
\nCell-based data that was saved with DistributedTriangulationBase::DataTransfer::register_data_attach() can be read in with DistributedTriangulationBase::DataTransfer::notify_ready_to_unpack() after calling load().
\n-Implements parallel::DistributedTriangulationBase< dim, spacedim >.
\n \n \n \nDefinition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Load the triangulation saved with save() back in. The mesh must be empty before calling this function.
\nYou need to load with the same number of MPI processes that you saved with, hence autopartition is disabled.
\nCell-based data that was saved with register_data_attach() can be read in with notify_ready_to_unpack() after calling load().
\n-Implements parallel::DistributedTriangulationBase< dim, spacedim >.
\n \nDefinition at line 741 of file fully_distributed_tria.cc.
\n \nDefinition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nThe elements of this enum are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
\n \n \n \n \nDefinition at line 2241 of file tria.h.
\n \n \n \n \nDefinition at line 2248 of file tria.h.
\n \n \n \n \nDefinition at line 2255 of file tria.h.
\n \n \n \n \nstd::map instead. std::map instead. std::map instead. std::map instead. std_cxx20::type_identity instead. ShortPRM instead of ShortText. PRM instead of Text. decide_and_prepare_for_remeshing except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing instead. decide_and_prepare_for_remeshing except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing instead. update_constrained_components, but is deprecated. Use update_constrained_components instead. update_constrained_components, but is deprecated. Use update_constrained_components instead. transfer_solution_vectors_to_new_mesh, but is deprecated. Use transfer_solution_vectors_to_new_mesh instead. transfer_solution_vectors_to_new_mesh, but is deprecated. Use transfer_solution_vectors_to_new_mesh instead. Extract the set of global DoF indices that are active on the current DoFHandler. For regular DoFHandlers, these are all DoF indices, but for DoFHandler objects built on parallel::distributed::Triangulation this set is a superset of DoFHandler::locally_owned_dofs() and contains all DoF indices that live on all locally owned cells (including on the interface to ghost cells). However, it does not contain the DoF indices that are exclusively defined on ghost or artificial cells (see the glossary).
\nThe degrees of freedom identified by this function equal those obtained from the dof_indices_with_subdomain_association() function when called with the locally owned subdomain id.
\n-Definition at line 1105 of file dof_tools.cc.
\n \nSame function as above but for a certain (multigrid-)level. This function returns all DoF indices that live on all locally owned cells (including on the interface to ghost cells) on the given level.
\n-Definition at line 1152 of file dof_tools.cc.
\n \nExtract the set of global DoF indices that are active on the current DoFHandler. For regular DoFHandlers, these are all DoF indices, but for DoFHandler objects built on parallel::distributed::Triangulation this set is the union of DoFHandler::locally_owned_dofs() and the DoF indices on all ghost cells. In essence, it is the DoF indices on all cells that are not artificial (see the glossary).
\n-Definition at line 1202 of file dof_tools.cc.
\n \nSame as extract_locally_relevant_dofs() but for multigrid DoFs for the given level.
Definition at line 1258 of file dof_tools.cc.
\n \nFor each active cell of a DoFHandler, extract the active finite element index and fill the vector given as second argument. This vector is assumed to have as many entries as there are active cells.
\nFor DoFHandler objects without hp-capabilities given as first argument, the returned vector will consist of only zeros, indicating that all cells use the same finite element. In hp-mode, the values may be different, though.
\nAs we do not know the active FE index on artificial cells, we set them to the invalid value numbers::invalid_fe_index.
\n-Definition at line 1499 of file dof_tools.cc.
\n \nA version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map instead. A version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map instead. Definition at line 2430 of file dof_tools.cc.
\n \nA version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map instead. A version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map instead. Definition at line 2451 of file dof_tools.cc.
\n \nThis is the opposite function to the one above. It generates a map where the keys are the support points of the degrees of freedom, while the values are the DoF indices. For a definition of support points, see this glossary entry.
\nSince there is no natural order in the space of points (except for the 1d case), you have to provide a map with an explicitly specified comparator object. This function is therefore templatized on the comparator object. Previous content of the map object is deleted in this function.
\nJust as with the function above, it is assumed that the finite element in use here actually supports the notion of support points of all its components.
\n-Same as above but for a specific number of sub-elements.
\n-Take a FiniteElement object and return a boolean vector describing the restriction_is_additive_flags (see the documentation of the FiniteElement class) for each shape function of the mixed element consisting of N1, N2, ... copies of the sub-elements fe1, fe2, ...
The \"restriction is additive\" flags are properties of individual shape functions that do not depend on whether the composed element uses the tensor product or combination strategy outlined in the documentation of the FETools::Composition namespace. Consequently, this function does not have a do_tensor_product argument.
Compute the non-zero vector components of a composed finite element. This function is similar to the previous one, except that the pointers indicate the elements to be composed, and the arguments N1, N2, ... the multiplicities. Null pointers indicate that an argument is to be skipped.
If do_tensor_product is true, the number of components (and thus the size of the ComponentMask objects) is the sum over the product of the number of components in each of the finite elements times the corresponding multiplicity. Otherwise the number of components is taken from the first finite element with non-zero multiplicity, and all other elements with non-zero multiplicities need to have the same number of vector components.
See the documentation of namespace FETools::Compositing for more information about the do_tensor_product argument.
Definition at line 241 of file grid_tools.cc.
\n \nGiven a triangulation and a list of cells whose children have become distorted as a result of mesh refinement, try to fix these cells up by moving the center node around.
\nThe function returns a list of cells with distorted children that couldn't be fixed up for whatever reason. The returned list is therefore a subset of the input argument.
\nFor a definition of the concept of distorted cells, see the glossary entry. The first argument passed to the current function is typically the exception thrown by the Triangulation::execute_coarsening_and_refinement function.
\n-Definition at line 2759 of file grid_tools.cc.
\n \nIf the library is configured to use multithreading, this function works in parallel.
\nweight: an optional weight for the computation of the mass matrix. If no weight is given, it is set to one. In case you want to specify component_mapping and use the default argument for the coefficient you have to specify the (unused) coefficient argument as (const Function <spacedim,number> *const)nullptr.component_mapping: if the components in boundary_functions and dof do not coincide, this vector allows them to be remapped. If the vector is not empty, it has to have one entry for each component in dof. This entry is the component number in boundary_functions that should be used for this component in dof. By default, no remapping is applied.| [in] | axis | A unit vector that defines the axis of rotation |
| [in] | angle | The rotation angle in radians |
Definition at line 1092 of file sparsity_tools.cc.
\n \nThe same trick with the mixed system does not work here, because we would end up with both Dirichlet and Neumann boundary conditions for \\(u\\), but none for \\(v\\).
\nThe solution to this conundrum arrived with the Discontinuous Galerkin method wave in the 1990s and early 2000s: In much the same way as one can use discontinuous shape functions for the Laplace equation by penalizing the size of the discontinuity to obtain a scheme for an equation that has one derivative on each shape function, we can use a scheme that uses continuous (but not \\(C^1\\) continuous) shape functions and penalize the jump in the derivative to obtain a scheme for an equation that has two derivatives on each shape function. In analogy to the Interior Penalty (IP) method for the Laplace equation, this scheme for the biharmonic equation is typically called the \\(C^0\\) IP (or C0IP) method, since it uses \\(C^0\\) (continuous but not continuously differentiable) shape functions with an interior penalty formulation.
\nIt is worth noting that the C0IP method is not the only one that has been developed for the biharmonic equation. step-82 shows an alternative method.
\nWe base this program on the \\(C^0\\) IP method presented by Susanne Brenner and Li-Yeng Sung in the paper \"C \\_form#5167 Interior Penalty Method\n+
We base this program on the \\(C^0\\) IP method presented by Susanne Brenner and Li-Yeng Sung in the paper \"C \\_form#5272 Interior Penalty Method\n for Linear Fourth Order Boundary Value Problems on polygonal\n domains\" [Brenner2005] where the method is derived for the biharmonic equation with \"clamped\" boundary conditions.
\nAs mentioned, this method relies on the use of \\(C^0\\) Lagrange finite elements where the \\(C^1\\) continuity requirement is relaxed and has been replaced with interior penalty techniques. To derive this method, we consider a \\(C^0\\) shape function \\(v_h\\) which vanishes on \\(\\partial\\Omega\\). We introduce notation \\( \\mathbb{F} \\) as the set of all faces of \\(\\mathbb{T}\\), \\( \\mathbb{F}^b \\) as the set of boundary faces, and \\( \\mathbb{F}^i \\) as the set of interior faces for use further down below. Since the higher order derivatives of \\(v_h\\) have two values on each interface \\(e\\in \\mathbb{F}\\) (shared by the two cells \\(K_{+},K_{-} \\in \\mathbb{T}\\)), we cope with this discontinuity by defining the following single-valued functions on \\(e\\):
\n \\begin{align*}\n \\jump{\\frac{\\partial^k v_h}{\\partial \\mathbf n^k}}\n &=\n \\frac{\\partial^k v_h|_{K_+}}{\\partial \\mathbf n^k} \\bigg |_e\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -175,15 +175,15 @@\n (C^0\\) IP (or C0IP) method, since it uses \\(C^0\\) (continuous but not\n continuously differentiable) shape functions with an interior penalty\n formulation.\n It is worth noting that the C0IP method is not the only one that has been\n developed for the biharmonic equation. _\bs_\bt_\be_\bp_\b-_\b8_\b2 shows an alternative method.\n *\b**\b**\b**\b* D\bDe\ber\bri\biv\bva\bat\bti\bio\bon\bn o\bof\bf t\bth\bhe\be C\bC0\b0I\bIP\bP m\bme\bet\bth\bho\bod\bd *\b**\b**\b**\b*\n We base this program on the \\(C^0\\) IP method presented by Susanne Brenner and\n-Li-Yeng Sung in the paper \"C \\_form#5167 Interior Penalty Method for Linear\n+Li-Yeng Sung in the paper \"C \\_form#5272 Interior Penalty Method for Linear\n Fourth Order Boundary Value Problems on polygonal domains\" [\b[B\bBr\bre\ben\bnn\bne\ber\br2\b20\b00\b05\b5]\b] where\n the method is derived for the biharmonic equation with \"clamped\" boundary\n conditions.\n As mentioned, this method relies on the use of \\(C^0\\) Lagrange finite elements\n where the \\(C^1\\) continuity requirement is relaxed and has been replaced with\n interior penalty techniques. To derive this method, we consider a \\(C^0\\) shape\n function \\(v_h\\) which vanishes on \\(\\partial\\Omega\\). We introduce notation \\\n"}]}, {"source1": "./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/step_58.html", "source2": "./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/step_58.html", "unified_diff": "@@ -566,16 +566,16 @@\n \\left(\\psi^{(n,2)}+\\psi^{(n,1)}\\right)\\right]\n +\n V \\left[\\frac 12 \\left(\\psi^{(n,2)}+\\psi^{(n,1)}\\right)\\right] = 0.\n \\end{align*}\n
\nHere, the \"previous\" solution \\(\\psi^{(n,1)}\\) (or the \"initial\n condition\" for this part of the time step) is the output of the first phase rotation half-step; the output of the current step will be denoted by \\(\\psi^{(n,2)}\\). \\(k_{n+1}=t_{n+1}-t_n\\) is the length of the time step. (One could argue whether \\(\\psi^{(n,1)}\\) and \\(\\psi^{(n,1)}\\) live at time step \\(n\\) or \\(n+1\\) and what their upper indices should be. This is a philosophical discussion without practical impact, and one might think of \\(\\psi^{(n,1)}\\) as something like \\(\\psi^{(n+\\tfrac 13)}\\), and \\(\\psi^{(n,2)}\\) as \\(\\psi^{(n+\\tfrac 23)}\\) if that helps clarify things – though, again \\(n+\\frac 13\\) is not to be understood as \"one third time step after\n- \\_form#432\" but more like \"we've already done one third of the work necessary\n-for time step \\_form#3258\".)
\n+ \\_form#375\" but more like \"we've already done one third of the work necessary\n+for time step \\_form#3218\".)\nIf we multiply the whole equation with \\(k_{n+1}\\) and sort terms with the unknown \\(\\psi^{(n+1,2)}\\) to the left and those with the known \\(\\psi^{(n,2)}\\) to the right, then we obtain the following (spatial) partial differential equation that needs to be solved in each time step:
\n \\begin{align*}\n -i\\psi^{(n,2)}\n -\n \\frac 14 k_{n+1} \\Delta \\psi^{(n,2)}\n +\n \\frac 12 k_{n+1} V \\psi^{(n,2)}\n", "details": [{"source1": "html2text {}", "source2": "html2text {}", "unified_diff": "@@ -378,16 +378,16 @@\n step; the output of the current step will be denoted by \\(\\psi^{(n,2)}\\). \\(k_\n {n+1}=t_{n+1}-t_n\\) is the length of the time step. (One could argue whether \\\n (\\psi^{(n,1)}\\) and \\(\\psi^{(n,1)}\\) live at time step \\(n\\) or \\(n+1\\) and\n what their upper indices should be. This is a philosophical discussion without\n practical impact, and one might think of \\(\\psi^{(n,1)}\\) as something like \\\n (\\psi^{(n+\\tfrac 13)}\\), and \\(\\psi^{(n,2)}\\) as \\(\\psi^{(n+\\tfrac 23)}\\) if\n that helps clarify things \u2013 though, again \\(n+\\frac 13\\) is not to be\n-understood as \"one third time step after \\_form#432\" but more like \"we've\n-already done one third of the work necessary for time step \\_form#3258\".)\n+understood as \"one third time step after \\_form#375\" but more like \"we've\n+already done one third of the work necessary for time step \\_form#3218\".)\n If we multiply the whole equation with \\(k_{n+1}\\) and sort terms with the\n unknown \\(\\psi^{(n+1,2)}\\) to the left and those with the known \\(\\psi^{\n (n,2)}\\) to the right, then we obtain the following (spatial) partial\n differential equation that needs to be solved in each time step:\n \\begin{align*} -i\\psi^{(n,2)} - \\frac 14 k_{n+1} \\Delta \\psi^{(n,2)} + \\frac 12\n k_{n+1} V \\psi^{(n,2)} = -i\\psi^{(n,1)} + \\frac 14 k_{n+1} \\Delta \\psi^{(n,1)}\n - \\frac 12 k_{n+1} V \\psi^{(n,1)}. \\end{align*}\n"}]}, {"source1": "./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/structCellData.html", "source2": "./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/structCellData.html", "unified_diff": "@@ -126,22 +126,22 @@\n
\n Public Attributes | ||
| std::vector< unsigned int > | vertices | |
| union { | ||
| union { | ||
| types::material_id material_id | ||
| types::boundary_id boundary_id | ||
| }; | ||
| types::material_id material_id | ||
| types::boundary_id boundary_id | ||
| }; | ||
| types::manifold_id | manifold_id | |
The CellData class (and the related SubCellData class) is used to provide a comprehensive, but minimal, description of the cells when creating a triangulation via Triangulation::create_triangulation(). Specifically, each CellData object – describing one cell in a triangulation – has member variables for indices of the \\(2^d\\) vertices (the actual coordinates of the vertices are described in a separate vector passed to Triangulation::create_triangulation(), so the CellData object only needs to store indices into that vector), the material id of the cell that can be used in applications to describe which part of the domain a cell belongs to (see the glossary entry on material ids), and a manifold id that is used to describe the geometry object that is responsible for this cell (see the glossary entry on manifold ids) to describe the manifold this object belongs to.
\nThis structure is also used to represent data for faces and edges when used as a member of the SubCellData class. In this case, the template argument structdim of an object will be less than the dimension dim of the triangulation. If this is so, then vertices array represents the indices of the vertices of one face or edge of one of the cells passed to Triangulation::create_triangulation(). Furthermore, for faces the material id has no meaning, and the material_id field is reused to store a boundary_id instead to designate which part of the boundary the face or edge belongs to (see the glossary entry on boundary ids).
The boundary id of a face or edge being described. See the documentation of the CellData class for examples of how to use this field.
\nThis variable can only be used if the current object is used to describe a face or edge, i.e., if structdim is less than the dimension dim of a triangulation. In this case, the CellData object this variable belongs to will be part of a SubCellData object.
Definition at line 129 of file tria_description.h.
\n \n| union { ... } CellData< structdim > | \n|
\n Static Public Member Functions | |
| static std::size_t | memory_consumption () |
\n Public Attributes | ||
| union { | ||
| union { | ||
| types::boundary_id boundary_id | ||
| types::material_id material_id | ||
| }; | ||
| types::boundary_id boundary_id | ||
| types::material_id material_id | ||
| }; | ||
We use this union to store boundary and material data. Because only one out of these two is actually needed here, we use an union.
\n \nDefinition at line 135 of file tria_objects.h.
\nDefinition at line 140 of file tria_objects.h.
\n \n| union { ... } internal::TriangulationImplementation::TriaObjects::BoundaryOrMaterialId | \n|
| template<class Archive > | |
| void | serialize (Archive &ar, const unsigned int version) |
\n Public Attributes | ||
| union { | ||
| union { | ||
| void * p | ||
| unsigned int i | ||
| }; | ||
| void * p | ||
| unsigned int i | ||
| }; | ||
The data type storing user pointers or user indices.
\n \nDefinition at line 312 of file tria_objects.h.
\nThe entry used as user index.
\n \nDefinition at line 321 of file tria_objects.h.
\n \n| union { ... } internal::TriangulationImplementation::TriaObjects::UserData | \n