From f7436e05af117a19be98226da9d99a3d4c6abb04 Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Thu, 11 Jan 2024 11:17:41 +0000 Subject: [PATCH] build based on f88e752 --- dev/Adaptivity/index.html | 4 +- dev/Algebra/index.html | 22 +++--- dev/Arrays/index.html | 40 +++++----- dev/CellData/index.html | 2 +- dev/FESpaces/index.html | 28 +++---- dev/Fields/index.html | 6 +- dev/Geometry/index.html | 90 +++++++++++------------ dev/Gridap/index.html | 2 +- dev/Helpers/index.html | 10 +-- dev/Io/index.html | 2 +- dev/MultiField/index.html | 6 +- dev/Polynomials/index.html | 4 +- dev/ReferenceFEs/index.html | 64 ++++++++-------- dev/TensorValues/index.html | 2 +- dev/Visualization/index.html | 6 +- dev/dev-notes/block-assemblers/index.html | 2 +- dev/getting-started/index.html | 2 +- dev/index.html | 2 +- dev/search/index.html | 2 +- 19 files changed, 148 insertions(+), 148 deletions(-) diff --git a/dev/Adaptivity/index.html b/dev/Adaptivity/index.html index eb9759197..42823a646 100644 --- a/dev/Adaptivity/index.html +++ b/dev/Adaptivity/index.html @@ -1,6 +1,6 @@ -Gridap.Adaptivity · Gridap.jl
Edit on GitHub

Gridap.Adaptivity

The adaptivity module provides a framework to work with adapted (refined/coarsened/mixed) meshes.

It provides

  • A generic interface to represent adapted meshes and a set of tools to work with Finite Element spaces defined on them. In particular, moving CellFields between parent and child meshes.
  • Particular implementations for conformally refining/coarsening 2D/3D meshes using several well-known strategies. In particular, Red-Green refinement and longest-edge bisection.

Interface

The following types are defined in the module:

Gridap.Adaptivity.RefinementRule — Type

Structure representing the map between a single parent cell and its children.

Contains:

  • T :: RefinementRuleType, indicating the refinement method.
  • poly :: Polytope, representing the geometry of the parent cell.
  • ref_grid :: DiscreteModel defined on poly, giving the parent-to-children cell map.
source
Gridap.Adaptivity.AdaptivityGlue — Type

Glue containing the map between two nested triangulations. The contained datastructures will depend on the type of glue. There are two types of AdaptivityGlue:

  • RefinementGlue :: All cells in the new mesh are children of cells in the old mesh. I.e given a new cell, it is possible to find a single old cell containing it (the new cell might be exactly the old cell if no refinement).
  • MixedGlue :: Some cells in the new mesh are children of cells in the old mesh, while others are parents of cells in the old mesh.

Contains:

  • n2o_faces_map :: Given a new face gid, returns
    • if fine, the gid of the old face containing it.
    • if coarse, the gids of its children (in child order)
  • n2o_cell_to_child_id :: Given a new cell gid, returns
    • if fine, the local child id within the (old) coarse cell containing it.
    • if coarse, a list of local child ids of the (old) cells containing it.
  • refinement_rules :: Array conatining the RefinementRule used for each coarse cell.
source
Gridap.Adaptivity.AdaptedDiscreteModel — Type

DiscreteModel created by refining/coarsening another DiscreteModel.

The refinement/coarsening hierarchy can be traced backwards by following the parent pointer chain. This allows the transfer of dofs between FESpaces defined on this model and its ancestors.

source
Gridap.Adaptivity.AdaptedTriangulation — Type

Triangulation produced from an AdaptedDiscreteModel.

Contains:

  • adapted_model :: AdaptedDiscreteModel for the triangulation.
  • trian :: Triangulation extracted from the background model, i.e get_model(adapted_model).
source

The high-level interface is provided by the following methods:

Gridap.Adaptivity.refine — Function

function refine(model::DiscreteModel,args...;kwargs...) :: AdaptedDiscreteModel

Returns an AdaptedDiscreteModel that is the result of refining the given DiscreteModel.

source
Gridap.Adaptivity.coarsen — Function

function coarsen(model::DiscreteModel,args...;kwargs...) :: AdaptedDiscreteModel

Returns an AdaptedDiscreteModel that is the result of coarsening the given DiscreteModel.

source
Gridap.Adaptivity.adapt — Function

function adapt(model::DiscreteModel,args...;kwargs...) :: AdaptedDiscreteModel

Returns an AdaptedDiscreteModel that is the result of adapting (mixed coarsening and refining) the given DiscreteModel.

source

Edge-Based refinement

The module provides a refine method for UnstructuredDiscreteModel. The method takes a string refinement_method that determines the refinement strategy to be used. The following strategies are available:

  • "red_green" :: Red-Green refinement, default.
  • "nvb" :: Longest-edge bisection (only for meshes of TRIangles)

Additionally, the method takes a kwarg cells_to_refine that determines which cells will be refined. Possible input types are:

  • Nothing :: All cells get refined.
  • AbstractArray{<:Bool} of size num_cells(model) :: Only cells such that cells_to_refine[iC] == true get refined.
  • AbstractArray{<:Integer} :: Cells for which gid ∈ cells_to_refine get refined

The algorithms try to respect the cells_to_refine input as much as possible, but some additional cells might get refined in order to guarantee that the mesh remains conforming.

  function refine(model::UnstructuredDiscreteModel;refinement_method="red_green",kwargs...)
+Gridap.Adaptivity · Gridap.jl
Edit on GitHub
Gridap.Adaptivity
The adaptivity module provides a framework to work with adapted (refined/coarsened/mixed) meshes.
It provides
  • A generic interface to represent adapted meshes and a set of tools to work with Finite Element spaces defined on them. In particular, moving CellFields between parent and child meshes.
  • Particular implementations for conformally refining/coarsening 2D/3D meshes using several well-known strategies. In particular, Red-Green refinement and longest-edge bisection.
Interface
The following types are defined in the module:
Gridap.Adaptivity.RefinementRule — Type
Structure representing the map between a single parent cell and its children.
Contains: 
  • T :: RefinementRuleType, indicating the refinement method.
  • poly :: Polytope, representing the geometry of the parent cell.
  • ref_grid :: DiscreteModel defined on poly, giving the parent-to-children cell map. 
source
Gridap.Adaptivity.AdaptivityGlue — Type
Glue containing the map between two nested triangulations. The contained datastructures will  depend on the type of glue. There are two types of AdaptivityGlue: 
  • RefinementGlue :: All cells in the new mesh are children of cells in the old mesh. I.e given  a new cell, it is possible to find a single old cell containing it (the new cell might be exactly the old cell if no refinement).
  • MixedGlue :: Some cells in the new mesh are children of cells in the old mesh, while others are parents of cells in the old mesh. 
Contains: 
  • n2o_faces_map :: Given a new face gid, returns
    • if fine, the gid of the old face containing it.
    • if coarse, the gids of its children (in child order)
  • n2o_cell_to_child_id :: Given a new cell gid, returns 
    • if fine, the local child id within the (old) coarse cell containing it.
    • if coarse, a list of local child ids of the (old) cells containing it.
  • refinement_rules :: Array conatining the RefinementRule used for each coarse cell.
source
Gridap.Adaptivity.AdaptedDiscreteModel — Type
DiscreteModel created by refining/coarsening another DiscreteModel.
The refinement/coarsening hierarchy can be traced backwards by following the    parent pointer chain. This allows the transfer of dofs    between FESpaces defined on this model and its ancestors.
source
Gridap.Adaptivity.AdaptedTriangulation — Type
Triangulation produced from an AdaptedDiscreteModel.
Contains: 
  • adapted_model :: AdaptedDiscreteModel for the triangulation.
  • trian :: Triangulation extracted from the background model, i.e get_model(adapted_model).
source
The high-level interface is provided by the following methods:
Gridap.Adaptivity.refine — Function
function refine(model::DiscreteModel,args...;kwargs...) :: AdaptedDiscreteModel
Returns an AdaptedDiscreteModel that is the result of refining the given DiscreteModel.
source
Gridap.Adaptivity.coarsen — Function
function coarsen(model::DiscreteModel,args...;kwargs...) :: AdaptedDiscreteModel
Returns an AdaptedDiscreteModel that is the result of coarsening the given DiscreteModel.
source
Gridap.Adaptivity.adapt — Function
function adapt(model::DiscreteModel,args...;kwargs...) :: AdaptedDiscreteModel
Returns an AdaptedDiscreteModel that is the result of adapting (mixed coarsening and refining)    the given DiscreteModel.
source
Edge-Based refinement
The module provides a refine method for UnstructuredDiscreteModel. The method takes a string refinement_method that determines the refinement strategy to be used. The following strategies are available:
  • "red_green" :: Red-Green refinement, default.
  • "nvb" :: Longest-edge bisection (only for meshes of TRIangles)
Additionally, the method takes a kwarg cells_to_refine that determines which cells will be refined. Possible input types are:
  • Nothing :: All cells get refined.
  • AbstractArray{<:Bool} of size num_cells(model) :: Only cells such that cells_to_refine[iC] == true get refined.
  • AbstractArray{<:Integer} :: Cells for which gid ∈ cells_to_refine get refined
The algorithms try to respect the cells_to_refine input as much as possible, but some additional cells might get refined in order to guarantee that the mesh remains conforming.
  function refine(model::UnstructuredDiscreteModel;refinement_method="red_green",kwargs...)
     [...]
   end
CartesianDiscreteModel refining
The module provides a refine method for CartesianDiscreteModel. The method takes a Tuple of size Dc (the dimension of the model cells) that will determine how many times cells will be refined in each direction. For example, for a 2D model, refine(model,(2,3)) will refine each QUAD cell into a 2x3 grid of cells.
  function refine(model::CartesianDiscreteModel{Dc}, cell_partition::Tuple) where Dc
     [...]
-  end
Notes for users
Most of the tools provided by this module are showcased in the tests of the module itself, as well as the following tutorial (coming soon).
However, we want to stress a couple of key performance-critical points:
  • The refining/coarsening routines are not optimized for performance. In particular, they are not parallelized. If you require an optimized/parallel implementation, please consider leveraging specialised meshing libraries. For instance, we provide an implementation of refine/coarsen using P4est in the GridapP4est.jl library.
  • Although the toolbox allows you to evaluate CellFields defined on both fine/coarse meshes on their parent/children mesh, both directions of evaluation are not equivalent. As a user, you should always try to evaluate/integrate on the finest mesh for maximal performance. Evaluating a fine CellField on a coarse mesh relies on local tree searches, and is therefore a very expensive operation that should be avoided whenever possible.
Notes for developers
RefinementRule API
Given a RefinementRule, the library provides a set of methods to compute the mappings between parent (coarse) face ids and child (fine) face ids (and vice-versa). The ids are local to the RefinementRule.
Gridap.Adaptivity.get_d_to_face_to_child_faces — Function
Given a RefinementRule, returns for each parent/coarse face the child/fine faces of the  same dimension that it contains. Therefore, only fine faces at the coarse cell boundary are  listed in the returned structure.
Returns: [Face dimension][Coarse Face id] -> [Fine faces]
source
Gridap.Adaptivity.get_d_to_face_to_parent_face — Function
Given a RefinementRule, returns for each fine/child face the parent/coarse face containing it. The parent face can have higher dimension. 
Returns the tuple (A,B) with 
  • A = [Face dimension][Fine Face id] -> [Parent Face]
  • B = [Face dimension][Fine Face id] -> [Parent Face Dimension]
source
Gridap.Adaptivity.get_face_subface_ldof_to_cell_ldof — Function
Given a RefinementRule of dimension Dc and a Dc-Tuple fine_orders of approximation orders,  returns a map between the fine nodal dofs of order fine_orders in the reference grid and the  coarse nodal dofs of order 2⋅fine_orders in the coarse parent cell. 
The result is given for each coarse/parent face of dimension D as a list of the corresponding  fine dof lids, i.e 
  • [coarse face][coarse dof lid] -> fine dof lid
source
AdaptivityGlue API
Gridap.Adaptivity.get_d_to_fface_to_cface — Function
For each child/fine face, returns the parent/coarse face containing it. The parent   face might have higher dimension. 
Returns two arrays: 
  • [dimension][fine face gid] -> coarse parent face gid
  • [dimension][fine face gid] -> coarse parent face dimension
source
New-to-old field evaluations
When a cell is refined, we need to be able to evaluate the fields defined on the children cells on the parent cell. To do so, we bundle the fields defined on the children cells into a new type of Field called FineToCoarseField. When evaluated on a Point, a FineToCoarseField will select the child cell that contains the Point and evaluate the mapped point on the corresponding child field.
Gridap.Adaptivity.FineToCoarseField — Type
Given a domain and a non-overlapping refined cover, a FineToCoarseField   is a Field defined in the domain and constructed by a set of fields defined on    the subparts of the covering partition.   The refined cover is represented by a RefinementRule. 
source

+  end

Notes for users

Most of the tools provided by this module are showcased in the tests of the module itself, as well as the following tutorial (coming soon).

However, we want to stress a couple of key performance-critical points:

  • The refining/coarsening routines are not optimized for performance. In particular, they are not parallelized. If you require an optimized/parallel implementation, please consider leveraging specialised meshing libraries. For instance, we provide an implementation of refine/coarsen using P4est in the GridapP4est.jl library.

  • Although the toolbox allows you to evaluate CellFields defined on both fine/coarse meshes on their parent/children mesh, both directions of evaluation are not equivalent. As a user, you should always try to evaluate/integrate on the finest mesh for maximal performance. Evaluating a fine CellField on a coarse mesh relies on local tree searches, and is therefore a very expensive operation that should be avoided whenever possible.

Notes for developers

RefinementRule API

Given a RefinementRule, the library provides a set of methods to compute the mappings between parent (coarse) face ids and child (fine) face ids (and vice-versa). The ids are local to the RefinementRule.

Gridap.Adaptivity.get_d_to_face_to_child_faces — Function

Given a RefinementRule, returns for each parent/coarse face the child/fine faces of the same dimension that it contains. Therefore, only fine faces at the coarse cell boundary are listed in the returned structure.

Returns: [Face dimension][Coarse Face id] -> [Fine faces]

source
Gridap.Adaptivity.get_d_to_face_to_parent_face — Function

Given a RefinementRule, returns for each fine/child face the parent/coarse face containing it. The parent face can have higher dimension.

Returns the tuple (A,B) with

  • A = [Face dimension][Fine Face id] -> [Parent Face]
  • B = [Face dimension][Fine Face id] -> [Parent Face Dimension]
source
Gridap.Adaptivity.get_face_subface_ldof_to_cell_ldof — Function

Given a RefinementRule of dimension Dc and a Dc-Tuple fine_orders of approximation orders, returns a map between the fine nodal dofs of order fine_orders in the reference grid and the coarse nodal dofs of order 2⋅fine_orders in the coarse parent cell.

The result is given for each coarse/parent face of dimension D as a list of the corresponding fine dof lids, i.e

  • [coarse face][coarse dof lid] -> fine dof lid
source

AdaptivityGlue API

Gridap.Adaptivity.get_d_to_fface_to_cface — Function

For each child/fine face, returns the parent/coarse face containing it. The parent face might have higher dimension.

Returns two arrays:

  • [dimension][fine face gid] -> coarse parent face gid
  • [dimension][fine face gid] -> coarse parent face dimension
source

New-to-old field evaluations

When a cell is refined, we need to be able to evaluate the fields defined on the children cells on the parent cell. To do so, we bundle the fields defined on the children cells into a new type of Field called FineToCoarseField. When evaluated on a Point, a FineToCoarseField will select the child cell that contains the Point and evaluate the mapped point on the corresponding child field.

Gridap.Adaptivity.FineToCoarseField — Type

Given a domain and a non-overlapping refined cover, a FineToCoarseField is a Field defined in the domain and constructed by a set of fields defined on the subparts of the covering partition. The refined cover is represented by a RefinementRule.

source
diff --git a/dev/Algebra/index.html b/dev/Algebra/index.html index b453c66a6..a3c05854e 100644 --- a/dev/Algebra/index.html +++ b/dev/Algebra/index.html @@ -1,32 +1,32 @@ -Gridap.Algebra · Gridap.jl
Edit on GitHub

Gridap.Algebra

Gridap.Algebra — Module

The exported names are

source
Gridap.Algebra.AffineOperator — Type
struct AffineOperator{A<:AbstractMatrix,B<:AbstractVector} <: NonlinearOperator
+Gridap.Algebra · Gridap.jl
Edit on GitHub
Gridap.Algebra
Gridap.Algebra — Module
The exported names are
source
Gridap.Algebra.BackslashSolver — Type
struct BackslashSolver <: LinearSolver end
Wrapper of the backslash solver available in julia This is typically faster than LU for a single solve
source
Gridap.Algebra.BackslashSolver — Type
struct BackslashSolver <: LinearSolver end
Wrapper of the backslash solver available in julia This is typically faster than LU for a single solve
source
Gridap.Algebra.NLSolver — Type
struct NLSolver <: NonlinearSolver
   # private fields
-end
The cache generated when using this solver has a field result that hosts the result object generated by the underlying nlsolve function. It corresponds to the most latest solve.
source
Gridap.Algebra.NLSolver — Method
NLSolver(ls::LinearSolver;kwargs...)
-NLSolver(;kwargs...)
Same kwargs as in nlsolve. If ls is provided, it is not possible to use the linsolve kw-argument.
source
Gridap.Algebra.NewtonRaphsonSolver — Type
struct NewtonRaphsonSolver <:NonlinearSolver
+end
The cache generated when using this solver has a field result that hosts the result object generated by the underlying nlsolve function. It corresponds to the most latest solve.
source
Gridap.Algebra.NLSolver — Method
NLSolver(ls::LinearSolver;kwargs...)
+NLSolver(;kwargs...)
Same kwargs as in nlsolve. If ls is provided, it is not possible to use the linsolve kw-argument.
source
Gridap.Algebra.get_matrix — Method
get_matrix(operator)
Return the matrix corresponding to the assembled left hand side of the operator. This matrix incorporates all boundary conditions and constraints.
source
Gridap.Algebra.get_vector — Method
get_vector(operator)
Return the vector corresponding to the assembled right hand side of the operator. This vector includes all boundary conditions and constraints.
source
Gridap.Algebra.get_matrix — Method
get_matrix(operator)
Return the matrix corresponding to the assembled left hand side of the operator. This matrix incorporates all boundary conditions and constraints.
source
Gridap.Algebra.get_vector — Method
get_vector(operator)
Return the vector corresponding to the assembled right hand side of the operator. This vector includes all boundary conditions and constraints.
source
Gridap.Algebra.solve! — Method
solve!(x::AbstractVector,nls::NonlinearSolver,op::NonlinearOperator,cache)
Solve using the cache object from a previous solve.
source
Gridap.Algebra.solve! — Method
solve!(x::AbstractVector,nls::NonlinearSolver,op::NonlinearOperator)
Usage:
cache = solve!(x,nls,op)
The returned cache object can be used in subsequent solves:
cache = solve!(x,nls,op,cache)
source
Gridap.Algebra.solve! — Method
solve!(x::AbstractVector,nls::NonlinearSolver,op::NonlinearOperator,cache)
Solve using the cache object from a previous solve.
source
Gridap.Algebra.solve! — Method
solve!(x::AbstractVector,nls::NonlinearSolver,op::NonlinearOperator)
Usage:
cache = solve!(x,nls,op)
The returned cache object can be used in subsequent solves:
cache = solve!(x,nls,op,cache)
source

+  pred::Function=isapprox)
source
diff --git a/dev/Arrays/index.html b/dev/Arrays/index.html index 1de755da4..858d81ea0 100644 --- a/dev/Arrays/index.html +++ b/dev/Arrays/index.html @@ -1,5 +1,5 @@ -Gridap.Arrays · Gridap.jl
Edit on GitHub

Gridap.Arrays

Gridap.Arrays — Module

This module provides:

  • An extension of the AbstractArray interface in order to properly deal with mutable caches.
  • A mechanism to generate lazy arrays resulting from operations between arrays.
  • A collection of concrete implementations of AbstractArray.

The exported names in this module are:

source
Gridap.Arrays.Broadcasting — Type
Broadcasting(f)

Returns a mapping that represents the "broadcasted" version of the function f.

Example

using Gridap.Arrays
+Gridap.Arrays · Gridap.jl
Edit on GitHub
Gridap.Arrays
Gridap.Arrays — Module
This module provides:
  • An extension of the AbstractArray interface in order to properly deal with mutable caches.
  • A mechanism to generate lazy arrays resulting from operations between arrays.
  • A collection of concrete implementations of AbstractArray.
The exported names in this module are:
source
Gridap.Arrays.Broadcasting — Type
Broadcasting(f)
Returns a mapping that represents the "broadcasted" version of the function f.
Example
using Gridap.Arrays
 
 a = [3,2]
 b = [2,1]
@@ -11,21 +11,21 @@
 println(c)
 
 # output
-[5, 3]
source
Gridap.Arrays.CachedArray — Type
mutable struct CachedArray{T, N, A<:AbstractArray{T, N}} <: AbstractArray{T, N}
Type providing a re-sizable array.
The size of a CachedArray is changed via the setsize! function.
A CachedArray can be build with the constructors
using Gridap.Arrays
 # Create an empty CachedArray
 a = CachedArray(Float64,2)
 # Resize to new shape (2,3)
 setsize!(a,(2,3))
 size(a)
 # output
-(2, 3)
source
Gridap.Arrays.CompressedArray — Type
struct CompressedArray{T,N,A,P} <: AbstractArray{T,N}
   values::A
   ptrs::P
-end
Type representing an array with a reduced set of values. The array is represented by a short array of values, namely the field values, and a large array of indices, namely the field ptrs. The i-th component of the resulting array is defined as values[ptrs[i]]. The type parameters A, and P are restricted to be array types by the inner constructor of this struct.
source
Gridap.Arrays.CompressedArray — Method
CompressedArray(values::AbstractArray,ptrs::AbstractArray)
Creates a CompressedArray object by the given arrays of values and ptrs.
source
Gridap.Arrays.LazyArray — Type
Subtype of AbstractArray which is the result of lazy_map. It represents the result of lazy_mapping a Map to a set of arrays that contain the mapping arguments. This struct makes use of the cache provided by the mapping in order to compute its indices (thus allowing to prevent allocation). The array is lazy, i.e., the values are only computed on demand. It extends the AbstractArray API with two methods:
array_cache(a::AbstractArray)    getindex!(cache,a::AbstractArray,i...)
source
Gridap.Arrays.Map — Type
Abstract type representing a function (mapping) that provides a cache and an in-place evaluation for performance. This is the type to be used in the lazy_map function.
Derived types must implement the following method:
and optionally these ones:
The mapping interface can be tested with the test_map function.
Note that most of the functionality implemented in terms of this interface relies in duck typing. That is, it is not strictly needed to work with types that inherit from Map. This is specially useful in order to accommodate existing types into this framework without the need to implement a wrapper type that inherits from Map. For instance, a default implementation is available for Function objects.  However, we recommend that new types inherit from Map.
source
Gridap.Arrays.Operation — Type
Operation(op)
Returns the map that results after applying an operation f over a set of map(s) args. That is Operation(f)(args)(x...) is formally defined as f(map(a->a(x...),args)...).
Example
using Gridap.Arrays
+end
Type representing an array with a reduced set of values. The array is represented by a short array of values, namely the field values, and a large array of indices, namely the field ptrs. The i-th component of the resulting array is defined as values[ptrs[i]]. The type parameters A, and P are restricted to be array types by the inner constructor of this struct.
source
Gridap.Arrays.CompressedArray — Method
CompressedArray(values::AbstractArray,ptrs::AbstractArray)
Creates a CompressedArray object by the given arrays of values and ptrs.
source
Gridap.Arrays.LazyArray — Type
Subtype of AbstractArray which is the result of lazy_map. It represents the result of lazy_mapping a Map to a set of arrays that contain the mapping arguments. This struct makes use of the cache provided by the mapping in order to compute its indices (thus allowing to prevent allocation). The array is lazy, i.e., the values are only computed on demand. It extends the AbstractArray API with two methods:
array_cache(a::AbstractArray)    getindex!(cache,a::AbstractArray,i...)
source
Gridap.Arrays.Map — Type
Abstract type representing a function (mapping) that provides a cache and an in-place evaluation for performance. This is the type to be used in the lazy_map function.
Derived types must implement the following method:
and optionally these ones:
The mapping interface can be tested with the test_map function.
Note that most of the functionality implemented in terms of this interface relies in duck typing. That is, it is not strictly needed to work with types that inherit from Map. This is specially useful in order to accommodate existing types into this framework without the need to implement a wrapper type that inherits from Map. For instance, a default implementation is available for Function objects.  However, we recommend that new types inherit from Map.
source
Gridap.Arrays.Operation — Type
Operation(op)
Returns the map that results after applying an operation f over a set of map(s) args. That is Operation(f)(args)(x...) is formally defined as f(map(a->a(x...),args)...).
Example
using Gridap.Arrays
 
 fa(x) = x.*x
 fb(x) = sqrt.(x)
@@ -38,14 +38,14 @@
 println(c)
 
 # output
-[0.0, 1.0, 2.0, 3.0, 4.0, 5.0]
source
Gridap.Arrays.OperationMap — Type
OperationMap(f,args)
Returns a mapping that represents the result of applying the function f to the arguments in the tuple args. That is, OperationMap(f,args)(x...) is formally defined as f(map(a->a(x...),args)...)
source
Gridap.Arrays.PosNegPartition — Type
struct representing a binary partition of a range of indices
Using this allows one to do a number of important optimizations when working with PosNegReindex
source
Gridap.Arrays.OperationMap — Type
OperationMap(f,args)
Returns a mapping that represents the result of applying the function f to the arguments in the tuple args. That is, OperationMap(f,args)(x...) is formally defined as f(map(a->a(x...),args)...)
source
Gridap.Arrays.PosNegPartition — Type
struct representing a binary partition of a range of indices
Using this allows one to do a number of important optimizations when working with PosNegReindex
source
Gridap.Arrays.Table — Type
 struct Table{T,Vd<:AbstractVector{T},Vp<:AbstractVector} <: AbstractVector{Vector{T}}
+end
source
Gridap.Arrays.Table — Type
 struct Table{T,Vd<:AbstractVector{T},Vp<:AbstractVector} <: AbstractVector{Vector{T}}
     data::Vd
     ptrs::Vp
- end
Type representing a list of lists (i.e., a table) in compressed format.
source
Gridap.Arrays.Table — Method
Table(a::AbstractArray{<:AbstractArray})
Build a table from a vector of vectors. If the inputs are multidimensional arrays instead of vectors, they are flattened.
source
Gridap.Arrays.array_cache — Method
array_cache(a::AbstractArray)
Returns a cache object to be used in the getindex! function. It defaults to
array_cache(a::T) where T = nothing
for types T such that uses_hash(T) == Val(false), and
function array_cache(a::T) where T
+ end
Type representing a list of lists (i.e., a table) in compressed format.
source
Gridap.Arrays.Table — Method
Table(a::AbstractArray{<:AbstractArray})
Build a table from a vector of vectors. If the inputs are multidimensional arrays instead of vectors, they are flattened.
source
Gridap.Arrays.array_cache — Method
array_cache(a::AbstractArray)
Returns a cache object to be used in the getindex! function. It defaults to
array_cache(a::T) where T = nothing
for types T such that uses_hash(T) == Val(false), and
function array_cache(a::T) where T
   hash = Dict{UInt,Any}()
   array_cache(hash,a)
 end
for types T such that uses_hash(T) == Val(true), see the uses_hash function. In the later case, the type T should implement the following signature:
array_cache(hash::Dict,a::AbstractArray)
where we pass a dictionary (i.e., a hash table) in the first argument. This hash table can be used to test if the object a has already built a cache and re-use it as follows
id = objectid(a)
@@ -54,10 +54,10 @@
 else
   cache = ... # Build a new cache depending on your needs
   hash[id] = cache # Register the cache in the hash table
-end
This mechanism is needed, e.g., to re-use intermediate results in complex lazy operation trees. In multi-threading computations, a different hash table per thread has to be used in order to avoid race conditions.
source
Gridap.Arrays.evaluate! — Method
evaluate!(cache,f,x...)
Applies the mapping f at the arguments x... using the scratch data provided in the given cache object. The cache object is built with the return_cache function using arguments of the same type as in x. In general, the returned value y can share some part of its state with the cache object. If the result of two or more calls to this function need to be accessed simultaneously (e.g., in multi-threading), create and use several cache objects (e.g., one cache per thread).
source
Gridap.Arrays.evaluate — Method
evaluate(f,x...)
evaluates the mapping f at the arguments in x by creating a temporary cache internally. This functions is equivalent to
cache = return_cache(f,x...)
-evaluate!(cache,f,x...)
source
Gridap.Arrays.getindex! — Method
getindex!(cache,a::AbstractArray,i...)
Returns the item of the array a associated with index i by (possibly) using the scratch data passed in the cache object.
It defaults to
getindex!(cache,a::AbstractArray,i...) = a[i...]
As for standard Julia arrays, the user needs to implement only one of the following signatures depending on the IndexStyle of the array.
getindex!(cache,a::AbstractArray,i::Integer)
+end
This mechanism is needed, e.g., to re-use intermediate results in complex lazy operation trees. In multi-threading computations, a different hash table per thread has to be used in order to avoid race conditions.
source
Gridap.Arrays.evaluate! — Method
evaluate!(cache,f,x...)
Applies the mapping f at the arguments x... using the scratch data provided in the given cache object. The cache object is built with the return_cache function using arguments of the same type as in x. In general, the returned value y can share some part of its state with the cache object. If the result of two or more calls to this function need to be accessed simultaneously (e.g., in multi-threading), create and use several cache objects (e.g., one cache per thread).
source
Gridap.Arrays.evaluate — Method
evaluate(f,x...)
evaluates the mapping f at the arguments in x by creating a temporary cache internally. This functions is equivalent to
cache = return_cache(f,x...)
+evaluate!(cache,f,x...)
source
Gridap.Arrays.getindex! — Method
getindex!(cache,a::AbstractArray,i...)
Returns the item of the array a associated with index i by (possibly) using the scratch data passed in the cache object.
It defaults to
getindex!(cache,a::AbstractArray,i...) = a[i...]
As for standard Julia arrays, the user needs to implement only one of the following signatures depending on the IndexStyle of the array.
getindex!(cache,a::AbstractArray,i::Integer)
 getindex!(cache,a::AbstractArray{T,N},i::Vararg{Integer,N}) where {T,N}
Examples
Iterating over an array using the getindex! function
using Gridap.Arrays
 
 a = collect(10:15)
@@ -74,7 +74,7 @@
 3 -> 12
 4 -> 13
 5 -> 14
-6 -> 15
source
Gridap.Arrays.lazy_map — Method
lazy_map(f,a::AbstractArray...) -> AbstractArray
Applies the Map (or Function) f to the entries of the arrays in a (see the definition of Map).
The resulting array r is such that r[i] equals to evaluate(f,ai...) where ai is the tuple containing the i-th entry of the arrays in a (see function evaluate for more details). In other words, the resulting array is numerically equivalent to:
map( (x...)->evaluate(f,x...), a...)
Examples
Using a function as mapping
using Gridap.Arrays
+6 -> 15
source
Gridap.Arrays.lazy_map — Method
lazy_map(f,a::AbstractArray...) -> AbstractArray
Applies the Map (or Function) f to the entries of the arrays in a (see the definition of Map).
The resulting array r is such that r[i] equals to evaluate(f,ai...) where ai is the tuple containing the i-th entry of the arrays in a (see function evaluate for more details). In other words, the resulting array is numerically equivalent to:
map( (x...)->evaluate(f,x...), a...)
Examples
Using a function as mapping
using Gridap.Arrays
 
 a = collect(0:5)
 b = collect(10:15)
@@ -101,9 +101,9 @@
 println(c)
 
 # output
-[10, 12, 14, 16, 18, 20]
source
Gridap.Arrays.return_cache — Method
return_cache(f,x...)
Returns the cache needed to lazy_map mapping f with arguments of the same type as the objects in x. This function returns nothing by default, i.e., no cache.
source
Gridap.Arrays.return_type — Method
return_type(f,x...)
Returns the type of the result of calling mapping f with arguments of the types of the objects x.
source
Gridap.Arrays.setsize! — Method
setsize!(a, s)
-
Changes the size of the CachedArray a to the size described the the tuple s. After calling setsize!, the array can store uninitialized values.
source
Gridap.Arrays.test_array — Method
test_array(
-  a::AbstractArray{T,N}, b::AbstractArray{S,N},cmp=(==)) where {T,S,N}
Checks if the entries in a and b are equal using the comparison function cmp. It also stresses the new methods added to the AbstractArray interface.
source
Gridap.Arrays.test_map — Method
test_map(y,f,x...;cmp=(==))
Function used to test if the mapping f has been implemented correctly. f is a Map sub-type, x is a tuple in the domain of the mapping and y is the expected result. Function cmp is used to compare the computed result with the expected one. The checks are done with the @test macro.
source
Gridap.Arrays.testargs — Method
testargs(f,x...)
The default implementation of this function is testargs(f,x...) = x. One can overload it in order to use lazy_map with 0-length array and maps with non-trivial domains.
source
Gridap.Arrays.return_cache — Method
return_cache(f,x...)
Returns the cache needed to lazy_map mapping f with arguments of the same type as the objects in x. This function returns nothing by default, i.e., no cache.
source
Gridap.Arrays.return_type — Method
return_type(f,x...)
Returns the type of the result of calling mapping f with arguments of the types of the objects x.
source
Gridap.Arrays.setsize! — Method
setsize!(a, s)
+
Changes the size of the CachedArray a to the size described the the tuple s. After calling setsize!, the array can store uninitialized values.
source
Gridap.Arrays.test_array — Method
test_array(
+  a::AbstractArray{T,N}, b::AbstractArray{S,N},cmp=(==)) where {T,S,N}
Checks if the entries in a and b are equal using the comparison function cmp. It also stresses the new methods added to the AbstractArray interface.
source
Gridap.Arrays.test_map — Method
test_map(y,f,x...;cmp=(==))
Function used to test if the mapping f has been implemented correctly. f is a Map sub-type, x is a tuple in the domain of the mapping and y is the expected result. Function cmp is used to compare the computed result with the expected one. The checks are done with the @test macro.
source
Gridap.Arrays.testargs — Method
testargs(f,x...)
The default implementation of this function is testargs(f,x...) = x. One can overload it in order to use lazy_map with 0-length array and maps with non-trivial domains.
source
Gridap.Arrays.testitem — Method
testitem(a::AbstractArray{T}) -> Any
 
Returns an arbitrary instance of eltype(a). The default returned value is the first entry in the array if length(a)>0 and testvalue(eltype(a)) if length(a)==0 See the testvalue function.
Examples
using Gridap.Arrays
 
 a = collect(3:10)
@@ -116,4 +116,4 @@
 
 # output
 (3, 0)
-
source
Gridap.Arrays.testvalue — Function
testvalue(::Type{T}) where T
Returns an arbitrary instance of type T. It defaults to zero(T) for non-array types and to an empty array for array types. It can be overloaded for new types T if zero(T) does not makes sense. This function is used to compute  testitem for 0-length arrays.
source
Gridap.Arrays.uses_hash — Method
uses_hash(::Type{<:AbstractArray})
This function is used to specify if the type T uses the hash-based mechanism to reuse caches.  It should return either Val(true) or Val(false). It defaults to
uses_hash(::Type{<:AbstractArray}) = Val(false)
Once this function is defined for the type T it can also be called on instances of T.
source

+
source
Gridap.Arrays.testvalue — Function
testvalue(::Type{T}) where T

Returns an arbitrary instance of type T. It defaults to zero(T) for non-array types and to an empty array for array types. It can be overloaded for new types T if zero(T) does not makes sense. This function is used to compute testitem for 0-length arrays.

source
Gridap.Arrays.uses_hash — Method
uses_hash(::Type{<:AbstractArray})

This function is used to specify if the type T uses the hash-based mechanism to reuse caches. It should return either Val(true) or Val(false). It defaults to

uses_hash(::Type{<:AbstractArray}) = Val(false)

Once this function is defined for the type T it can also be called on instances of T.

source
diff --git a/dev/CellData/index.html b/dev/CellData/index.html index 0a4b0e6ed..566d97746 100644 --- a/dev/CellData/index.html +++ b/dev/CellData/index.html @@ -1,2 +1,2 @@ -Gridap.CellData · Gridap.jl
Edit on GitHub

Gridap.CellData

Gridap.CellData — Module
source
Gridap.CellData.CellDatum — Type

Data associated with the cells of a Triangulation. CellDatum objects behave as if they are defined in the physical space of the triangulation. But in some cases they are implemented as reference quantities plus some transformation to the physical domain.

source
Gridap.CellData.CellPoint — Type

A single point or an array of points on the cells of a Triangulation CellField objects can be evaluated efficiently at CellPoint instances.

source
Gridap.CellData.CompositeMeasure — Type

Composite Measure

Measure such that the integration and target triangulations are different.

  • ttrian: Target triangulation, where the domain contribution lives.
  • itrian: Integration triangulation, where the integration takes place.
  • quad : CellQuadrature, defined in itrian
source
Gridap.CellData.SkeletonCellFieldPair — Type

SkeletonCellFieldPair is a special construct for allowing uh.plus and uh.minus to be two different CellFields. In particular, it is useful when we need one of the CellFields to be the dualized version of the other for performing ForwardDiff AD of a Skeleton integration DomainContribution wrt to the degrees of freedom of the CellField, plus and minus sensitivities done separately, so as to restrict the interaction between the dual numbers.

It takes in two CellFields and stores plus version of CellFieldAt of the first CellField and minus version of CellFieldAt of the second the CellField. SkeletonCellFieldPair is associated with same triangulation as that of the CellFields (we check if the triangulations of both CellFields match)

SkeletonCellFieldPair is an internal convenience artifact/construct to aid in dualizing plus and minus side around a Skeleton face separately to perform the sensitivity of degrees of freedom of cells sharing the Skeleton face, without the interaction dual numbers of the two cells. The user doesn't have to deal with this construct anywhere when performing AD of functionals involving integration over Skeleton faces using the public API.

source
Gridap.CellData.distance — Method

dist = distance(polytope::ExtrusionPolytope, inv_cmap::Field, x::Point)

Calculate distance from point x to the polytope. The polytope is given by its type and by the inverse cell map, i.e. by the map from the physical to the reference space.

Positive distances are outside the polytope, negative distances are inside the polytope.

The distance is measured in an unspecified norm, currently the L∞ norm.

source
+Gridap.CellData · Gridap.jl
Edit on GitHub

Gridap.CellData

Gridap.CellData — Module
source
Gridap.CellData.CellDatum — Type

Data associated with the cells of a Triangulation. CellDatum objects behave as if they are defined in the physical space of the triangulation. But in some cases they are implemented as reference quantities plus some transformation to the physical domain.

source
Gridap.CellData.CellPoint — Type

A single point or an array of points on the cells of a Triangulation CellField objects can be evaluated efficiently at CellPoint instances.

source
Gridap.CellData.CompositeMeasure — Type

Composite Measure

Measure such that the integration and target triangulations are different.

  • ttrian: Target triangulation, where the domain contribution lives.
  • itrian: Integration triangulation, where the integration takes place.
  • quad : CellQuadrature, defined in itrian
source
Gridap.CellData.SkeletonCellFieldPair — Type

SkeletonCellFieldPair is a special construct for allowing uh.plus and uh.minus to be two different CellFields. In particular, it is useful when we need one of the CellFields to be the dualized version of the other for performing ForwardDiff AD of a Skeleton integration DomainContribution wrt to the degrees of freedom of the CellField, plus and minus sensitivities done separately, so as to restrict the interaction between the dual numbers.

It takes in two CellFields and stores plus version of CellFieldAt of the first CellField and minus version of CellFieldAt of the second the CellField. SkeletonCellFieldPair is associated with same triangulation as that of the CellFields (we check if the triangulations of both CellFields match)

SkeletonCellFieldPair is an internal convenience artifact/construct to aid in dualizing plus and minus side around a Skeleton face separately to perform the sensitivity of degrees of freedom of cells sharing the Skeleton face, without the interaction dual numbers of the two cells. The user doesn't have to deal with this construct anywhere when performing AD of functionals involving integration over Skeleton faces using the public API.

source
Gridap.CellData.distance — Method

dist = distance(polytope::ExtrusionPolytope, inv_cmap::Field, x::Point)

Calculate distance from point x to the polytope. The polytope is given by its type and by the inverse cell map, i.e. by the map from the physical to the reference space.

Positive distances are outside the polytope, negative distances are inside the polytope.

The distance is measured in an unspecified norm, currently the L∞ norm.

source
diff --git a/dev/FESpaces/index.html b/dev/FESpaces/index.html index 153e300bd..96ef8f44e 100644 --- a/dev/FESpaces/index.html +++ b/dev/FESpaces/index.html @@ -1,26 +1,26 @@ -Gridap.FESpaces · Gridap.jl
Edit on GitHub

Gridap.FESpaces

Gridap.FESpaces — Module

The exported names are

source
Gridap.FESpaces.CellConformity — Type

Minimum data required to describe dof ownership. At this moment, the cell-wise ownership is compressed on cell types. This can be relaxed in the future, to have an arbitrary cell-wise dof ownership.

source
Gridap.FESpaces.CellFE — Type

Minimum data required to build a conforming FE space. At this moment, the some cell-wise info is compressed on cell types. This can be relaxed in the future, and have an arbitrary cell-wise data.

source
Gridap.FESpaces.DirichletFESpace — Type
struct DirichletFESpace <: SingleFieldFESpace
+Gridap.FESpaces · Gridap.jl
Edit on GitHub
Gridap.FESpaces
Gridap.FESpaces — Module
The exported names are
source
Gridap.FESpaces.CellConformity — Type
Minimum data required to describe dof ownership. At this moment, the cell-wise ownership is compressed on cell types. This can be relaxed in the future, to have an arbitrary cell-wise dof ownership.
source
Gridap.FESpaces.CellFE — Type
Minimum data required to build a conforming FE space. At this moment, the some cell-wise info is compressed on cell types. This can be relaxed in the future, and have an arbitrary cell-wise data.
source
Gridap.FESpaces.FEFunction — Method
FEFunction(
-  fs::SingleFieldFESpace, free_values::AbstractVector, dirichlet_values::AbstractVector)
The resulting FEFunction will be in the space if and only if dirichlet_values are the ones provided by get_dirichlet_dof_values(fs)
source
Gridap.FESpaces.FEOperator — Type
abstract type FEOperator <: GridapType
A FEOperator contains finite element problem, that is assembled as far as possible and ready to be solved. See also FETerm
source
Gridap.FESpaces.GridWithFEMap — Type
Given a Discrete Model and a reffe, builds a new grid in which the geometrical map is a FEFunction. This is useful when considering geometrical maps that are the result of a FE problem (mesh displacement).
source
Gridap.FESpaces.FEFunction — Method
FEFunction(
+  fs::SingleFieldFESpace, free_values::AbstractVector, dirichlet_values::AbstractVector)
The resulting FEFunction will be in the space if and only if dirichlet_values are the ones provided by get_dirichlet_dof_values(fs)
source
Gridap.FESpaces.FEOperator — Type
abstract type FEOperator <: GridapType
A FEOperator contains finite element problem, that is assembled as far as possible and ready to be solved. See also FETerm
source
Gridap.FESpaces.GridWithFEMap — Type
Given a Discrete Model and a reffe, builds a new grid in which the geometrical map is a FEFunction. This is useful when considering geometrical maps that are the result of a FE problem (mesh displacement).
source
Gridap.FESpaces.NodeToDofGlue — Type
struct NodeToDofGlue{T}
   free_dof_to_node::Vector{Int32}
   free_dof_to_comp::Vector{Int16}
   dirichlet_dof_to_node::Vector{Int32}
   dirichlet_dof_to_comp::Vector{Int16}
   node_and_comp_to_dof::Vector{T}
-end
source
Gridap.Algebra.solve! — Method
uh, cache = solve!(uh,solver,op,cache)
This function changes the state of the input and can render it in a corrupted state. It is recommended to rewrite the input uh with the output as illustrated to prevent any issue. If cache===nothing, then it creates a new cache object.
source
Gridap.Algebra.solve! — Method
uh, cache = solve!(uh,solver,op)
This function changes the state of the input and can render it in a corrupted state. It is recommended to rewrite the input uh with the output as illustrated to prevent any issue.
source
Gridap.Algebra.solve! — Method
uh, cache = solve!(uh,solver,op,cache)
This function changes the state of the input and can render it in a corrupted state. It is recommended to rewrite the input uh with the output as illustrated to prevent any issue. If cache===nothing, then it creates a new cache object.
source
Gridap.Algebra.solve! — Method
uh, cache = solve!(uh,solver,op)
This function changes the state of the input and can render it in a corrupted state. It is recommended to rewrite the input uh with the output as illustrated to prevent any issue.
source
Gridap.FESpaces.compute_conforming_cell_dofs — Function
The result is the tuple
(cell_dofs, nfree, ndiri, dirichlet_dof_tag, dirichlet_cells)
If dirichlet_components  is given, then get_dof_to_comp has to be defined for the reference elements in reffes.
source
Gridap.FESpaces.get_algebraic_operator — Method
get_algebraic_operator(feop)
-
Return an "algebraic view" of an operator. Algebraic means, that the resulting operator acts on plain arrays, instead of FEFunctions. This can be useful for solving with external tools like NLsolve.jl. See also FEOperator.
source
Gridap.FESpaces.interpolate — Method
The resulting FE function is in the space (in particular it fulfills Dirichlet BCs even in the case that the given cell field does not fulfill them)
source

+tag_to_mask::AbstractVector) where T
source
Gridap.FESpaces.compute_conforming_cell_dofs — Function

The result is the tuple

(cell_dofs, nfree, ndiri, dirichlet_dof_tag, dirichlet_cells)

If dirichlet_components is given, then get_dof_to_comp has to be defined for the reference elements in reffes.

source
Gridap.FESpaces.get_algebraic_operator — Method
get_algebraic_operator(feop)
+

Return an "algebraic view" of an operator. Algebraic means, that the resulting operator acts on plain arrays, instead of FEFunctions. This can be useful for solving with external tools like NLsolve.jl. See also FEOperator.

source
Gridap.FESpaces.interpolate — Method

The resulting FE function is in the space (in particular it fulfills Dirichlet BCs even in the case that the given cell field does not fulfill them)

source
diff --git a/dev/Fields/index.html b/dev/Fields/index.html index 40f72ef98..dd9757bba 100644 --- a/dev/Fields/index.html +++ b/dev/Fields/index.html @@ -1,9 +1,9 @@ -Gridap.Fields · Gridap.jl
Edit on GitHub

Gridap.Fields

Gridap.Fields.Field — Type
abstract type Field <: Map

Abstract type representing a physical (scalar, vector, or tensor) field. The domain is a Point and the range a scalar (i.e., a sub-type of Julia Number), a VectorValue, or a TensorValue.

These different cases are distinguished by the return value obtained when evaluating them. E.g., a physical field returns a vector of values when evaluated at a vector of points, and a basis of nf fields returns a 2d matrix (np x nf) when evaluated at a vector of np points.

The following functions (i.e., the Map API) need to be overloaded:

and optionally

A Field can also provide its gradient if the following function is implemented

Higher derivatives can be obtained if the resulting object also implements this method.

The next paragraph is out-of-date:

Moreover, if the gradient(f) is not provided, a default implementation that uses the following functions will be used.

Higher order derivatives require the implementation of

These four methods are only designed to be called by the default implementation of field_gradient(f) and thus cannot be assumed that they are available for an arbitrary field. For this reason, these functions are not exported. The general way of evaluating a gradient of a field is to build the gradient with gradient(f) and evaluating the resulting object. For evaluating the hessian, use two times gradient.

The interface can be tested with

For performance, the user can also consider a vectorised version of the Field API that evaluates the field in a vector of points (instead of only one point). E.g., the evaluate! function for a vector of points returns a vector of scalar, vector or tensor values.

source
Gridap.Fields.FieldGradient — Type

Type that represents the gradient of a field. The wrapped field must implement evaluate_gradient! and return_gradient_cache for this gradient to work.

N is how many times the gradient is applied

source
Gridap.Fields.Point — Type
const Point{D,T} = VectorValue{D,T}

Type representing a point of D dimensions with coordinates of type T. Fields are evaluated at vectors of Point objects.

source
Gridap.Fields.TransposeFieldIndices — Type

Given a matrix np x nf1 x nf2 result of the evaluation of a field vector on a vector of points, it returns an array in which the field axes (second and third axes) are permuted. It is equivalent as Base.permutedims(A,(1,3,2)) but more performant, since it does not involve allocations.

source
Base.:∘ — Method
f∘g

It returns the composition of two fields, which is just Operation(f)(g)

source
Gridap.Arrays.evaluate! — Method

Implementation of return_cache for a array of Field.

If the field vector has length nf and it is evaluated in one point, it returns an nf vector with the result. If the same array is applied to a vector of np points, it returns a matrix np x nf.

source
Gridap.Fields.test_field — Function
test_field(
+Gridap.Fields · Gridap.jl
Edit on GitHub
Gridap.Fields
Gridap.Fields.Field — Type
abstract type Field <: Map
Abstract type representing a physical (scalar, vector, or tensor) field. The domain is a Point and the range a scalar (i.e., a sub-type of Julia Number), a VectorValue, or a TensorValue.
These different cases are distinguished by the return value obtained when evaluating them. E.g., a physical field returns a vector of values when evaluated at a vector of points, and a basis of nf fields returns a 2d matrix (np x nf) when evaluated at a vector of np points.
The following functions (i.e., the Map API) need to be overloaded:
and optionally
A Field can also provide its gradient if the following function is implemented
Higher derivatives can be obtained if the resulting object also implements this method.
The next paragraph is out-of-date:
Moreover, if the gradient(f) is not provided, a default implementation that uses the following functions will be used.
Higher order derivatives require the implementation of
These four methods are only designed to be called by the default implementation of field_gradient(f) and thus cannot be assumed that they are available for an arbitrary field. For this reason, these functions are not exported. The general way of evaluating a gradient of a field is to build the gradient with gradient(f) and evaluating the resulting object. For evaluating the hessian, use two times gradient.
The interface can be tested with
For performance, the user can also consider a vectorised version of the Field API that evaluates the field in a vector of points (instead of only one point). E.g., the evaluate! function for a vector of points returns a vector of scalar, vector or tensor values.
source
Gridap.Fields.FieldGradient — Type
Type that represents the gradient of a field. The wrapped field must implement evaluate_gradient! and return_gradient_cache for this gradient to work.
N is how many times the gradient is applied
source
Gridap.Fields.Point — Type
const Point{D,T} = VectorValue{D,T}
Type representing a point of D dimensions with coordinates of type T. Fields are evaluated at vectors of Point objects.
source
Gridap.Fields.TransposeFieldIndices — Type
Given a matrix np x nf1 x nf2 result of the evaluation of a field vector on a vector of points, it returns an array in which the field axes (second and third axes) are permuted. It is equivalent as Base.permutedims(A,(1,3,2)) but more performant, since it does not involve allocations.
source
Base.:∘ — Method
f∘g
It returns the composition of two fields, which is just Operation(f)(g)
source
Gridap.Arrays.evaluate! — Method
Implementation of return_cache for a array of Field.
If the field vector has length nf and it is evaluated in one point, it returns an nf vector with the result. If the same array is applied to a vector of np points, it returns a matrix np x nf.
source
Gridap.Fields.test_field — Function
test_field(
   f::Union{Field,AbstractArray{<:Field}},
   x,
   v,
   cmp=(==);
   grad=nothing,
-  gradgrad=nothing)
Function used to test the field interface. v is an array containing the expected result of evaluating the field f at the point or vector of points x. The comparison is performed using the cmp function. For fields objects that support the gradient function, the keyword argument grad can be used. It should contain the result of evaluating gradient(f) at x. Idem for gradgrad. The checks are performed with the @test macro.
source

+  gradgrad=nothing)

Function used to test the field interface. v is an array containing the expected result of evaluating the field f at the point or vector of points x. The comparison is performed using the cmp function. For fields objects that support the gradient function, the keyword argument grad can be used. It should contain the result of evaluating gradient(f) at x. Idem for gradgrad. The checks are performed with the @test macro.

source
diff --git a/dev/Geometry/index.html b/dev/Geometry/index.html index ad01bed47..1d7b79bff 100644 --- a/dev/Geometry/index.html +++ b/dev/Geometry/index.html @@ -1,111 +1,111 @@ -Gridap.Geometry · Gridap.jl
Edit on GitHub

Gridap.Geometry

Gridap.Geometry — Module

Exported names are

source
Gridap.Geometry.BoundaryTriangulation — Method
BoundaryTriangulation(model::DiscreteModel,labeling::FaceLabeling;tags::Vector{Int})
+Gridap.Geometry · Gridap.jl
Edit on GitHub
Gridap.Geometry
Gridap.Geometry — Module
Exported names are
source
Gridap.Geometry.BoundaryTriangulation — Method
BoundaryTriangulation(model::DiscreteModel,labeling::FaceLabeling;tags::Vector{Int})
 BoundaryTriangulation(model::DiscreteModel,labeling::FaceLabeling;tags::Vector{String})
 BoundaryTriangulation(model::DiscreteModel,labeling::FaceLabeling;tag::Int)
-BoundaryTriangulation(model::DiscreteModel,labeling::FaceLabeling;tag::String)
source
Gridap.Geometry.BoundaryTriangulation — Method
BoundaryTriangulation(model::DiscreteModel,tags::Vector{Int})
 BoundaryTriangulation(model::DiscreteModel,tags::Vector{String})
 BoundaryTriangulation(model::DiscreteModel,tag::Int)
-BoundaryTriangulation(model::DiscreteModel,tag::String)
source
Gridap.Geometry.CartesianDescriptor — Type
struct CartesianDescriptor{D,T,F<:Function}
   origin::Point{D,T}
   sizes::NTuple{D,T}
   partition::NTuple{D,Int}
   map::F
-end
Struct that stores the data defining a Cartesian grid.
source
Gridap.Geometry.CartesianDescriptor — Method
CartesianDescriptor(
   domain,
   partition;
   map::Function=identity,
-  isperiodic::NTuple{D,Bool}=tfill(false,Val{D}))
domain and partition are 1D indexable collections of arbitrary type.
source
Gridap.Geometry.CartesianDescriptor — Method
CartesianDescriptor(
   origin::Point{D},
   sizes::NTuple{D},
   partition;
   map::Function=identity,
-  isperiodic::NTuple{D,Bool}=tfill(false,Val{D})) where D
partition is a 1D indexable collection of arbitrary type.
source
Gridap.Geometry.CartesianDescriptor — Method
CartesianDescriptor(
   pmin::Point{D},
   pmax::Point{D},
   partition;
   map::Function=identity,
-  isperiodic::NTuple{D,Bool}=tfill(false,Val{D})) where D
partition is a 1D indexable collection of arbitrary type.
source
Gridap.Geometry.CartesianDiscreteModel — Type
struct CartesianDiscreteModel{D,T,F} <: DiscreteModel{D,D}
+  isperiodic::NTuple{D,Bool}=tfill(false,Val{D})) where D
partition is a 1D indexable collection of arbitrary type.
source
Gridap.Geometry.CartesianDiscreteModel — Method
CartesianDiscreteModel(desc::CartesianDescriptor{D,T,F},                           cmin::CartesianIndex,                           cmax::CartesianIndex)
Builds a CartesianDiscreteModel object which represents a subgrid of   a (larger) grid represented by desc. This subgrid is described by its   D-dimensional minimum (cmin) and maximum (cmax) CartesianIndex   identifiers.
source
Gridap.Geometry.CartesianDiscreteModel — Method
CartesianDiscreteModel(desc::CartesianDescriptor{D,T,F},                           cmin::CartesianIndex,                           cmax::CartesianIndex)
Builds a CartesianDiscreteModel object which represents a subgrid of   a (larger) grid represented by desc. This subgrid is described by its   D-dimensional minimum (cmin) and maximum (cmax) CartesianIndex   identifiers.
source
Gridap.Geometry.DiscreteModel — Type
abstract type DiscreteModel{Dc,Dp} <: Grid
Abstract type holding information about a physical grid, the underlying grid topology, and a labeling of the grid faces. This is the information that typically provides a mesh generator, and it is what one needs to perform a simulation.
The DiscreteModel interface is defined by overloading the methods:
The interface is tested with this function:
source
Gridap.Geometry.DiscreteModel — Type
abstract type DiscreteModel{Dc,Dp} <: Grid
Abstract type holding information about a physical grid, the underlying grid topology, and a labeling of the grid faces. This is the information that typically provides a mesh generator, and it is what one needs to perform a simulation.
The DiscreteModel interface is defined by overloading the methods:
The interface is tested with this function:
source
Gridap.Geometry.FaceLabeling — Type
struct FaceLabeling <: GridapType
   d_to_dface_to_entity::Vector{Vector{Int32}}
   tag_to_entities::Vector{Vector{Int32}}
   tag_to_name::Vector{String}
-end
source
Gridap.Geometry.GridPortion — Type
struct GridPortion{Dc,Dp,G} <: Grid{Dc,Dp}
   parent::G
   cell_to_parent_cell::Vector{Int32}
   node_to_parent_node::Vector{Int32}
-end
source
Gridap.Geometry.GridTopology — Type
abstract type GridTopology{Dc,Dp}
Abstract type representing the topological information associated with a grid.
The GridTopology interface is defined by overloading the methods:
The GridTopology interface has the following traits
and tested with this function:
source
Gridap.Geometry.OrientationStyle — Method
OrientationStyle(::Type{<:GridTopology})
-OrientationStyle(::GridTopology)
Oriented() if has oriented faces, NonOriented() otherwise (default).
source
Gridap.Geometry.GridTopology — Type
abstract type GridTopology{Dc,Dp}
Abstract type representing the topological information associated with a grid.
The GridTopology interface is defined by overloading the methods:
The GridTopology interface has the following traits
and tested with this function:
source
Gridap.Geometry.OrientationStyle — Method
OrientationStyle(::Type{<:GridTopology})
+OrientationStyle(::GridTopology)
Oriented() if has oriented faces, NonOriented() otherwise (default).
source
Gridap.Geometry.UnstructuredDiscreteModel — Type
struct UnstructuredDiscreteModel{Dc,Dp,Tp,B} <: DiscreteModel{Dc,Dp}
   grid::UnstructuredGrid{Dc,Dp,Tp,B}
   grid_topology::UnstructuredGridTopology{Dc,Dp,Tp,B}
   face_labeling::FaceLabeling
-end
source
Gridap.Geometry.UnstructuredGrid — Type
struct UnstructuredGrid{Dc,Dp,Tp,Ti,O} <: Grid{Dc,Dp}
   node_coordinates::Vector{Point{Dp,Tp}}
   cell_node_ids::Table{Ti,Int32}
   reffes::Vector{<:LagrangianRefFE{Dc}}
   cell_types::Vector{Int8}
-end
source
Gridap.Geometry.UnstructuredGrid — Method
function UnstructuredGrid(
   node_coordinates::Vector{Point{Dp,Tp}},
   cell_node_ids::Table{Ti},
   reffes::Vector{<:LagrangianRefFE{Dc}},
   cell_types::Vector,
   orientation_style::OrientationStyle=NonOriented()) where {Dc,Dp,Tp,Ti}
-end
Low-level inner constructor.
source
Gridap.Geometry.UnstructuredGridTopology — Type
UnstructuredGridTopology(
   vertex_coordinates::Vector{<:Point},
   cell_vertices::Table,
   cell_type::Vector{<:Integer},
   polytopes::Vector{<:Polytope},
-  orientation_style::OrientationStyle=NonOriented())
source
Gridap.Geometry.UnstructuredGridTopology — Type
UnstructuredGridTopology(
   vertex_coordinates::Vector{<:Point},
   d_to_dface_vertices::Vector{<:Table},
   cell_type::Vector{<:Integer},
   polytopes::Vector{<:Polytope},
-  orientation_style::OrientationStyle=NonOriented())
source
Gridap.Geometry._find_ncube_face_neighbor_deltas — Method
findncubefaceneighbor_deltas(p::ExtrusionPolytope{D}) -> Vector{CartesianIndex}
Given an n-cube type ExtrusionPolytope{D}, returns V=Vector{CartesianIndex} with as many   entries as the number of faces in the boundary of the Polytope. For an entry facelid   in this vector, V[facelid] returns what has to be added to the CartesianIndex of a   cell in order to obtain the CartesianIndex of the cell neighbour of K across the face F   with local ID face_lid.
source
Gridap.Geometry._find_ncube_face_neighbor_deltas — Method
findncubefaceneighbor_deltas(p::ExtrusionPolytope{D}) -> Vector{CartesianIndex}
Given an n-cube type ExtrusionPolytope{D}, returns V=Vector{CartesianIndex} with as many   entries as the number of faces in the boundary of the Polytope. For an entry facelid   in this vector, V[facelid] returns what has to be added to the CartesianIndex of a   cell in order to obtain the CartesianIndex of the cell neighbour of K across the face F   with local ID face_lid.
source
Gridap.Geometry.add_tag_from_tags! — Method
add_tag_from_tags!(lab::FaceLabeling, name::String, tags::Vector{Int})
 add_tag_from_tags!(lab::FaceLabeling, name::String, tags::Vector{String})
 add_tag_from_tags!(lab::FaceLabeling, name::String, tag::Int)
-add_tag_from_tags!(lab::FaceLabeling, name::String, tag::String)
source
Gridap.Geometry.get_cell_reffe — Method
get_cell_reffe(trian::Grid) -> Vector{<:LagrangianRefFE}
It is not desirable to iterate over the resulting array for large number of cells if the underlying reference FEs are of different Julia type.
source
Gridap.Geometry.get_face_mask — Method
get_face_mask(labeling::FaceLabeling,tags::Vector{Int},d::Integer)
+add_tag_from_tags!(lab::FaceLabeling, name::String, tag::String)
source
Gridap.Geometry.get_cell_reffe — Method
get_cell_reffe(trian::Grid) -> Vector{<:LagrangianRefFE}
It is not desirable to iterate over the resulting array for large number of cells if the underlying reference FEs are of different Julia type.
source
Gridap.Geometry.get_face_mask — Method
get_face_mask(labeling::FaceLabeling,tags::Vector{Int},d::Integer)
 get_face_mask(labeling::FaceLabeling,tags::Vector{String},d::Integer)
 get_face_mask(labeling::FaceLabeling,tag::Int,d::Integer)
-get_face_mask(labeling::FaceLabeling,tag::String,d::Integer)
source
Gridap.Geometry.get_face_tag — Method
get_face_tag(labeling::FaceLabeling,tags::Vector{Int},d::Integer)
+get_face_mask(labeling::FaceLabeling,tag::String,d::Integer)
source
Gridap.Geometry.get_face_tag — Method
get_face_tag(labeling::FaceLabeling,tags::Vector{Int},d::Integer)
 get_face_tag(labeling::FaceLabeling,tags::Vector{String},d::Integer)
 get_face_tag(labeling::FaceLabeling,tag::Int,d::Integer)
 get_face_tag(labeling::FaceLabeling,tag::String,d::Integer)
-get_face_tag(labeling::FaceLabeling,d::Integer)
The first of the given tags appearing in the face is taken. If there is no tag on a face, this face will have a value equal to UNSET. If not tag or tags are provided, all the tags in the model are considered
source
Gridap.Geometry.get_face_tag_index — Method
get_face_tag_index(labeling::FaceLabeling,tags::Vector{Int},d::Integer)
+get_face_tag(labeling::FaceLabeling,d::Integer)
The first of the given tags appearing in the face is taken. If there is no tag on a face, this face will have a value equal to UNSET. If not tag or tags are provided, all the tags in the model are considered
source
Gridap.Geometry.get_face_tag_index — Method
get_face_tag_index(labeling::FaceLabeling,tags::Vector{Int},d::Integer)
 get_face_tag_index(labeling::FaceLabeling,tags::Vector{String},d::Integer)
 get_face_tag_index(labeling::FaceLabeling,tag::Int,d::Integer)
-get_face_tag_index(labeling::FaceLabeling,tag::String,d::Integer)
Like get_face_tag by provides the index into the array tags instead of the tag stored in tags.
source

+get_face_tag_index(labeling::FaceLabeling,tag::String,d::Integer)

Like get_face_tag by provides the index into the array tags instead of the tag stored in tags.

source
diff --git a/dev/Gridap/index.html b/dev/Gridap/index.html index a2682ff70..3520e973c 100644 --- a/dev/Gridap/index.html +++ b/dev/Gridap/index.html @@ -1,2 +1,2 @@ -Gridap · Gridap.jl
Edit on GitHub

Gridap

Gridap — Module

Gridap, grid-based approximation of PDEs in the Julia programming language

This module provides rich set of tools for the numerical solution of PDE, mainly based on finite element methods.

The module is structured in the following sub-modules:

The exported names are:

source
+Gridap · Gridap.jl
Edit on GitHub

Gridap

Gridap — Module

Gridap, grid-based approximation of PDEs in the Julia programming language

This module provides rich set of tools for the numerical solution of PDE, mainly based on finite element methods.

The module is structured in the following sub-modules:

The exported names are:

source
diff --git a/dev/Helpers/index.html b/dev/Helpers/index.html index 26242803b..99f51e894 100644 --- a/dev/Helpers/index.html +++ b/dev/Helpers/index.html @@ -1,6 +1,6 @@ -Gridap.Helpers · Gridap.jl
Edit on GitHub

Gridap.Helpers

Gridap.Helpers.tfill — Method
tfill(v, ::Val{D}) where D

Returns a tuple of length D that contains D times the object v. In contrast to tuple(fill(v,D)...) which returns the same result, this function is type-stable.

source
Gridap.Helpers.@check — Macro

@check condition @check condition "Error message"

Macro used to make sure that condition is fulfilled, like @assert but the check gets deactivated when running Julia with –boundscheck=no

source
+Gridap.Helpers · Gridap.jl
Edit on GitHub

Gridap.Helpers

Gridap.Helpers.tfill — Method
tfill(v, ::Val{D}) where D

Returns a tuple of length D that contains D times the object v. In contrast to tuple(fill(v,D)...) which returns the same result, this function is type-stable.

source
Gridap.Helpers.@check — Macro

@check condition @check condition "Error message"

Macro used to make sure that condition is fulfilled, like @assert but the check gets deactivated when running Julia with –boundscheck=no

source
diff --git a/dev/Io/index.html b/dev/Io/index.html index ad3b0e511..4c6b2e15c 100644 --- a/dev/Io/index.html +++ b/dev/Io/index.html @@ -1,2 +1,2 @@ -Gridap.Io · Gridap.jl
Edit on GitHub

Gridap.Io

Gridap.Io.check_dict — Method
check_dict(::Type{T},dict::Dict) where T

Check validity of a dictionary dict for an object of type T. It runs successfully if the dictionary is valid for a particular type or throws an error in any other case.

source
Gridap.Io.from_dict — Method
from_dict(::Type{T},dict::Dict) where T

De-serialize an object of type T from the dictionary dict. Values stored into this dictionary must be of any native Julia data type (Real, Integer, String, etc.) Dictionary keys are Symbols.

source
Gridap.Io.from_jld2_file — Function
function from_jld2_file(filename::AbstractString,dataset::AbstractString="data")

Loads an object from a JLD2 file given its filename and, optionally, the dataset name. The dataset specifies the name and the root location of the data inside the generated JLD2 file.

source
Gridap.Io.from_jld2_file — Method
function from_jld2_file(::Type{T},filename::AbstractString,dataset::AbstractString="data") where T

Loads an object from a JLD2 file given its filename and, optionally, the dataset name. The dataset specifies the name and the root location of the data inside the generated JLD2 file. Checks if the returned object is of the expected Type{T}, if not return error.

source
Gridap.Io.to_dict — Method
to_dict(object) -> Dict

Serialize object into a dictionary of type Dict{Symbol,Any}. Values stored into this dictionary must be of any native Julia data type (Real, Integer, String, etc.) Dictionary keys are Symbols.

source
Gridap.Io.to_jld2_file — Function
function to_jld2_file(object,filename::AbstractString,dataset::AbstractString="data")

Stores an object to a JLD2 file given its filename and, optionally, the dataset name. The dataset specifies the name and the root location of the data inside the JLD2 file.

source
+Gridap.Io · Gridap.jl
Edit on GitHub

Gridap.Io

Gridap.Io.check_dict — Method
check_dict(::Type{T},dict::Dict) where T

Check validity of a dictionary dict for an object of type T. It runs successfully if the dictionary is valid for a particular type or throws an error in any other case.

source
Gridap.Io.from_dict — Method
from_dict(::Type{T},dict::Dict) where T

De-serialize an object of type T from the dictionary dict. Values stored into this dictionary must be of any native Julia data type (Real, Integer, String, etc.) Dictionary keys are Symbols.

source
Gridap.Io.from_jld2_file — Function
function from_jld2_file(filename::AbstractString,dataset::AbstractString="data")

Loads an object from a JLD2 file given its filename and, optionally, the dataset name. The dataset specifies the name and the root location of the data inside the generated JLD2 file.

source
Gridap.Io.from_jld2_file — Method
function from_jld2_file(::Type{T},filename::AbstractString,dataset::AbstractString="data") where T

Loads an object from a JLD2 file given its filename and, optionally, the dataset name. The dataset specifies the name and the root location of the data inside the generated JLD2 file. Checks if the returned object is of the expected Type{T}, if not return error.

source
Gridap.Io.to_dict — Method
to_dict(object) -> Dict

Serialize object into a dictionary of type Dict{Symbol,Any}. Values stored into this dictionary must be of any native Julia data type (Real, Integer, String, etc.) Dictionary keys are Symbols.

source
Gridap.Io.to_jld2_file — Function
function to_jld2_file(object,filename::AbstractString,dataset::AbstractString="data")

Stores an object to a JLD2 file given its filename and, optionally, the dataset name. The dataset specifies the name and the root location of the data inside the JLD2 file.

source
diff --git a/dev/MultiField/index.html b/dev/MultiField/index.html index 3a9685ba4..b9566087c 100644 --- a/dev/MultiField/index.html +++ b/dev/MultiField/index.html @@ -1,8 +1,8 @@ -Gridap.MultiField · Gridap.jl
Edit on GitHub

Gridap.MultiField

Gridap.MultiField.BlockMultiFieldStyle — Type

Similar to ConsecutiveMultiFieldStyle, but we keep the original DoF ids of the individual spaces for better block assembly (see BlockSparseMatrixAssembler). Takes three parameters:

  • NB: Number of assembly blocks
  • SB: Size of each assembly block, as a Tuple.
  • P : Permutation of the variables of the multifield space when assembling, as a Tuple.
source
Gridap.MultiField.MultiFieldFEFunction — Type
struct MultiFieldFEFunction <: CellField
+Gridap.MultiField · Gridap.jl
Edit on GitHub
Gridap.MultiField
Gridap.MultiField.BlockMultiFieldStyle — Type
Similar to ConsecutiveMultiFieldStyle, but we keep the original DoF ids of the   individual spaces for better block assembly (see BlockSparseMatrixAssembler).   Takes three parameters: 
  • NB: Number of assembly blocks
  • SB: Size of each assembly block, as a Tuple.
  • P : Permutation of the variables of the multifield space when assembling, as a Tuple.
source
Gridap.FESpaces.interpolate — Method
The resulting MultiFieldFEFunction is in the space (in particular it fulfills Dirichlet BCs even in the case that the given cell field does not fulfill them)
source
Gridap.FESpaces.interpolate_everywhere — Method
like interpolate, but also compute new degrees of freedom for the dirichlet component. The resulting MultiFieldFEFunction does not necessary belongs to the underlying space
source

+end
source
Gridap.FESpaces.interpolate — Method

The resulting MultiFieldFEFunction is in the space (in particular it fulfills Dirichlet BCs even in the case that the given cell field does not fulfill them)

source
Gridap.FESpaces.interpolate_everywhere — Method

like interpolate, but also compute new degrees of freedom for the dirichlet component. The resulting MultiFieldFEFunction does not necessary belongs to the underlying space

source
diff --git a/dev/Polynomials/index.html b/dev/Polynomials/index.html index ec8c2053c..327799bf5 100644 --- a/dev/Polynomials/index.html +++ b/dev/Polynomials/index.html @@ -1,5 +1,5 @@ -Gridap.Polynomials · Gridap.jl
Edit on GitHub

Gridap.Polynomials

Gridap.Polynomials.MonomialBasis — Type
struct MonomialBasis{D,T} <: AbstractVector{Monomial}

Type representing a basis of multivariate scalar-valued, vector-valued, or tensor-valued, iso- or aniso-tropic monomials. The fields of this struct are not public. This type fully implements the Field interface, with up to second order derivatives.

source
Gridap.Polynomials.MonomialBasis — Method
MonomialBasis{D}(::Type{T}, order::Int [, filter::Function]) where {D,T}

Returns an instance of MonomialBasis representing a multivariate polynomial basis in D dimensions, of polynomial degree order, whose value is represented by the type T. The type T is typically <:Number, e.g., Float64 for scalar-valued functions and VectorValue{D,Float64} for vector-valued ones.

Filter function

The filter function is used to select which terms of the tensor product space of order order in D dimensions are to be used. If the filter is not provided, the full tensor-product space is used by default leading to a multivariate polynomial space of type Q. The signature of the filter function is

(e,order) -> Bool

where e is a tuple of D integers containing the exponents of a multivariate monomial. The following filters are used to select well known polynomial spaces

  • Q space: (e,order) -> true
  • P space: (e,order) -> sum(e) <= order
  • "Serendipity" space: (e,order) -> sum( [ i for i in e if i>1 ] ) <= order
source
Gridap.Polynomials.MonomialBasis — Method
MonomialBasis{D}(::Type{T}, orders::Tuple [, filter::Function]) where {D,T}

This version of the constructor allows to pass a tuple orders containing the polynomial order to be used in each of the D dimensions in order to construct an anisotropic tensor-product space.

source
Gridap.Polynomials.PCurlGradMonomialBasis — Type

struct PCurlGradMonomialBasis{...} <: AbstractArray{Monomial}

This type implements a multivariate vector-valued polynomial basis spanning the space needed for Raviart-Thomas reference elements on simplices. The type parameters and fields of this struct are not public. This type fully implements the Field interface, with up to first order derivatives.

source
Gridap.Polynomials.PCurlGradMonomialBasis — Method

PCurlGradMonomialBasis{D}(::Type{T},order::Int) where {D,T}

Returns a PCurlGradMonomialBasis object. D is the dimension of the coordinate space and T is the type of the components in the vector-value. The order argument has the following meaning: the divergence of the functions in this basis is in the P space of degree order.

source
Gridap.Polynomials.QCurlGradMonomialBasis — Type
struct QCurlGradMonomialBasis{...} <: AbstractArray{Monomial}

This type implements a multivariate vector-valued polynomial basis spanning the space needed for Raviart-Thomas reference elements on n-cubes. The type parameters and fields of this struct are not public. This type fully implements the Field interface, with up to first order derivatives.

source
Gridap.Polynomials.QCurlGradMonomialBasis — Method
QCurlGradMonomialBasis{D}(::Type{T},order::Int) where {D,T}

Returns a QCurlGradMonomialBasis object. D is the dimension of the coordinate space and T is the type of the components in the vector-value. The order argument has the following meaning: the divergence of the functions in this basis is in the Q space of degree order.

source
Gridap.Polynomials.QGradMonomialBasis — Type
struct QGradMonomialBasis{...} <: AbstractVector{Monomial}

This type implements a multivariate vector-valued polynomial basis spanning the space needed for Nedelec reference elements on n-cubes. The type parameters and fields of this struct are not public. This type fully implements the Field interface, with up to first order derivatives.

source
Gridap.Polynomials.QGradMonomialBasis — Method
QGradMonomialBasis{D}(::Type{T},order::Int) where {D,T}

Returns a QGradMonomialBasis object. D is the dimension of the coordinate space and T is the type of the components in the vector-value. The order argument has the following meaning: the curl of the functions in this basis is in the Q space of degree order.

source
Gridap.Polynomials.get_exponents — Method
get_exponents(b::MonomialBasis)

Get a vector of tuples with the exponents of all the terms in the monomial basis.

Examples

using Gridap.Polynomials
+Gridap.Polynomials · Gridap.jl
Edit on GitHub
Gridap.Polynomials
Gridap.Polynomials.MonomialBasis — Type
struct MonomialBasis{D,T} <: AbstractVector{Monomial}
Type representing a basis of multivariate scalar-valued, vector-valued, or tensor-valued, iso- or aniso-tropic monomials. The fields of this struct are not public. This type fully implements the Field interface, with up to second order derivatives.
source
Gridap.Polynomials.MonomialBasis — Method
MonomialBasis{D}(::Type{T}, order::Int [, filter::Function]) where {D,T}
Returns an instance of MonomialBasis representing a multivariate polynomial basis in D dimensions, of polynomial degree order, whose value is represented by the type T. The type T is typically <:Number, e.g., Float64 for scalar-valued functions and VectorValue{D,Float64} for vector-valued ones.
Filter function
The filter function is used to select which terms of the tensor product space of order order in D dimensions are to be used. If the filter is not provided, the full tensor-product space is used by default leading to a multivariate polynomial space of type Q. The signature of the filter function is
(e,order) -> Bool
where e is a tuple of D integers containing the exponents of a multivariate monomial. The following filters are used to select well known polynomial spaces
  • Q space: (e,order) -> true
  • P space: (e,order) -> sum(e) <= order
  • "Serendipity" space: (e,order) -> sum( [ i for i in e if i>1 ] ) <= order
source
Gridap.Polynomials.MonomialBasis — Method
MonomialBasis{D}(::Type{T}, orders::Tuple [, filter::Function]) where {D,T}
This version of the constructor allows to pass a tuple orders containing the polynomial order to be used in each of the D dimensions in order to  construct an anisotropic tensor-product space.
source
Gridap.Polynomials.PCurlGradMonomialBasis — Type
struct PCurlGradMonomialBasis{...} <: AbstractArray{Monomial}
This type implements a multivariate vector-valued polynomial basis spanning the space needed for Raviart-Thomas reference elements on simplices. The type parameters and fields of this struct are not public. This type fully implements the Field interface, with up to first order derivatives.
source
Gridap.Polynomials.PCurlGradMonomialBasis — Method
PCurlGradMonomialBasis{D}(::Type{T},order::Int) where {D,T}
Returns a PCurlGradMonomialBasis object. D is the dimension of the coordinate space and T is the type of the components in the vector-value. The order argument has the following meaning: the divergence of the  functions in this basis is in the P space of degree order.
source
Gridap.Polynomials.QCurlGradMonomialBasis — Type
struct QCurlGradMonomialBasis{...} <: AbstractArray{Monomial}
This type implements a multivariate vector-valued polynomial basis spanning the space needed for Raviart-Thomas reference elements on n-cubes. The type parameters and fields of this struct are not public. This type fully implements the Field interface, with up to first order derivatives.
source
Gridap.Polynomials.QCurlGradMonomialBasis — Method
QCurlGradMonomialBasis{D}(::Type{T},order::Int) where {D,T}
Returns a QCurlGradMonomialBasis object. D is the dimension of the coordinate space and T is the type of the components in the vector-value. The order argument has the following meaning: the divergence of the  functions in this basis is in the Q space of degree order.
source
Gridap.Polynomials.QGradMonomialBasis — Type
struct QGradMonomialBasis{...} <: AbstractVector{Monomial}
This type implements a multivariate vector-valued polynomial basis spanning the space needed for Nedelec reference elements on n-cubes. The type parameters and fields of this struct are not public. This type fully implements the Field interface, with up to first order derivatives.
source
Gridap.Polynomials.QGradMonomialBasis — Method
QGradMonomialBasis{D}(::Type{T},order::Int) where {D,T}
Returns a QGradMonomialBasis object. D is the dimension of the coordinate space and T is the type of the components in the vector-value. The order argument has the following meaning: the curl of the  functions in this basis is in the Q space of degree order.
source
Gridap.Polynomials.get_exponents — Method
get_exponents(b::MonomialBasis)
Get a vector of tuples with the exponents of all the terms in the monomial basis.
Examples
using Gridap.Polynomials
 
 b = MonomialBasis{2}(Float64,2)
 
@@ -8,4 +8,4 @@
 println(exponents)
 
 # output
-Tuple{Int,Int}[(0, 0), (1, 0), (2, 0), (0, 1), (1, 1), (2, 1), (0, 2), (1, 2), (2, 2)]
source

+Tuple{Int,Int}[(0, 0), (1, 0), (2, 0), (0, 1), (1, 1), (2, 1), (0, 2), (1, 2), (2, 2)]
source
diff --git a/dev/ReferenceFEs/index.html b/dev/ReferenceFEs/index.html index 63d122a8a..e287e7563 100644 --- a/dev/ReferenceFEs/index.html +++ b/dev/ReferenceFEs/index.html @@ -1,8 +1,8 @@ -Gridap.ReferenceFEs · Gridap.jl
Edit on GitHub

Gridap.ReferenceFEs

Gridap.ReferenceFEs — Module

The exported names are

source
Gridap.ReferenceFEs.ExtrusionPolytope — Type
struct ExtrusionPolytope{D} <: Polytope{D}
+Gridap.ReferenceFEs · Gridap.jl
Edit on GitHub
Gridap.ReferenceFEs
Gridap.ReferenceFEs — Module
The exported names are
source
Gridap.ReferenceFEs.ExtrusionPolytope — Method
ExtrusionPolytope(extrusion::Int...)
Generates an ExtrusionPolytope from the tuple extrusion. The values in extrusion are either equal to the constant HEX_AXIS or the constant TET_AXIS.
Examples
Creating a quadrilateral, a triangle, and a wedge
using Gridap.ReferenceFEs
+end
Concrete type for polytopes that can be represented with an "extrusion" tuple. The underlying extrusion is available in the field extrusion. Instances of this type can be obtained with the constructors
source
Gridap.ReferenceFEs.ExtrusionPolytope — Method
ExtrusionPolytope(extrusion::Int...)
Generates an ExtrusionPolytope from the tuple extrusion. The values in extrusion are either equal to the constant HEX_AXIS or the constant TET_AXIS.
Examples
Creating a quadrilateral, a triangle, and a wedge
using Gridap.ReferenceFEs
 
 quad = ExtrusionPolytope(HEX_AXIS,HEX_AXIS)
 
@@ -18,13 +18,13 @@
 true
 true
 true
-
source
Gridap.ReferenceFEs.GenericQuadrature — Type
struct GenericQuadrature{D,T,C <: AbstractVector{Point{D,T}},W <: AbstractVector{T}} <: Quadrature{D,T}
   coordinates::Vector{Point{D,T}}
   weights::Vector{T}
   name::String
-end
source
Gridap.ReferenceFEs.GenericRefFE — Type
struct GenericRefFE{T,D} <: ReferenceFE{D}
   # + private fields
-end
This type is a materialization of the ReferenceFE interface. That is, it is a struct that stores the values of all abstract methods in the ReferenceFE interface. This type is useful to build reference FEs from the underlying ingredients without the need to create a new type.
Note that some fields in this struct are type unstable deliberately in order to simplify the type signature. Don't access them in computationally expensive functions, instead extract the required fields before and pass them to the computationally expensive function.
source
Gridap.ReferenceFEs.GenericRefFE — Method
  GenericRefFE{T}(
+end
This type is a materialization of the ReferenceFE interface. That is, it is a struct that stores the values of all abstract methods in the ReferenceFE interface. This type is useful to build reference FEs from the underlying ingredients without the need to create a new type.
Note that some fields in this struct are type unstable deliberately in order to simplify the type signature. Don't access them in computationally expensive functions, instead extract the required fields before and pass them to the computationally expensive function.
source
Gridap.ReferenceFEs.GenericRefFE — Method
  GenericRefFE{T}(
   ndofs::Int,
   polytope::Polytope{D},
   prebasis::AbstractVector{<:Field},
@@ -32,7 +32,7 @@
   conformity::Conformity,
   metadata,
   face_dofs::Vector{Vector{Int}},
-  shapefuns::AbstractVector{<:Field}=compute_shapefuns(dofs,prebasis)) where {T,D}
Constructs a GenericRefFE object with the provided data.
source
Gridap.ReferenceFEs.GenericRefFE — Method
  GenericRefFE{T}(
+  shapefuns::AbstractVector{<:Field}=compute_shapefuns(dofs,prebasis)) where {T,D}
Constructs a GenericRefFE object with the provided data.
source
Gridap.ReferenceFEs.GenericRefFE — Method
  GenericRefFE{T}(
   ndofs::Int,
   polytope::Polytope{D},
   prebasis::AbstractVector{<:Field},
@@ -41,16 +41,16 @@
   metadata,
   face_dofs::Vector{Vector{Int}},
   shapefuns::AbstractVector{<:Field},
-  dofs::AbstractVector{<:Dof}=compute_dofs(predofs,shapefuns)) where {T,D}
Constructs a GenericRefFE object with the provided data.
source
Gridap.ReferenceFEs.LagrangianDofBasis — Type
struct LagrangianDofBasis{P,V} <: AbstractArray{<:Dof}
+  dofs::AbstractVector{<:Dof}=compute_dofs(predofs,shapefuns)) where {T,D}
Constructs a GenericRefFE object with the provided data.
source
Gridap.ReferenceFEs.LagrangianDofBasis — Type
struct LagrangianDofBasis{P,V} <: AbstractArray{<:Dof}
   nodes::Vector{P}
   dof_to_node::Vector{Int}
   dof_to_comp::Vector{Int}
   node_and_comp_to_dof::Vector{V}
-end
Type that implements a Lagrangian dof basis.
Fields:
  • nodes::Vector{P} vector of points (P<:Point) storing the nodal coordinates
  • node_and_comp_to_dof::Vector{V} vector such that node_and_comp_to_dof[node][comp] returns the dof associated with node node and the component comp in the type V.
  • dof_to_node::Vector{Int} vector of integers such that dof_to_node[dof] returns the node id associated with dof id dof.
  • dof_to_comp::Vector{Int} vector of integers such that dof_to_comp[dof] returns the component id associated with dof id dof.
source
Gridap.ReferenceFEs.LagrangianDofBasis — Method
LagrangianDofBasis(::Type{T},nodes::Vector{<:Point}) where T
Creates a LagrangianDofBasis for fields of value type T associated with the vector of nodal coordinates nodes.
source
Gridap.ReferenceFEs.LagrangianRefFE — Type
abstract type LagrangianRefFE{D} <: ReferenceFE{D}
Abstract type representing a Lagrangian reference FE. Lagrangian in the sense that get_dof_basis returns an instance of LagrangianDofBasis. The interface for this type is defined with the methods of ReferenceFE plus the following ones
source
Gridap.ReferenceFEs.LagrangianRefFE — Method
LagrangianRefFE(::Type{T},p::Polytope,orders) where T
-LagrangianRefFE(::Type{T},p::Polytope,order::Int) where T
Builds a LagrangianRefFE object on top of the given polytope. T is the type of the value of the approximation space (e.g., T=Float64 for scalar-valued problems, T=VectorValue{N,Float64} for vector-valued problems with N components). The arguments order or orders are for the polynomial order of the resulting space, which allows isotropic or anisotropic orders respectively (provided that the cell topology allows the given anisotropic order). The argument orders should be an indexable collection of D integers (e.g., a tuple or a vector), being D the number of space dimensions.
In order to be able to use this function, the type of the provided polytope p has to implement the following additional methods. They have been implemented for ExtrusionPolytope in the library. They need to be implemented for new polytope types in order to build Lagangian reference elements on top of them.
The following methods are also used in the construction of the LagrangianRefFE object. A default implementation of them is available in terms of the three previous methods. However, the user can also implement them for new polytope types increasing customization possibilities.
source
Gridap.ReferenceFEs.LinearCombinationDofVector — Type
struct LinearCombinationDofVector{T} <: AbstractVector{Dof}
+end
Type that implements a Lagrangian dof basis.
Fields:
  • nodes::Vector{P} vector of points (P<:Point) storing the nodal coordinates
  • node_and_comp_to_dof::Vector{V} vector such that node_and_comp_to_dof[node][comp] returns the dof associated with node node and the component comp in the type V.
  • dof_to_node::Vector{Int} vector of integers such that dof_to_node[dof] returns the node id associated with dof id dof.
  • dof_to_comp::Vector{Int} vector of integers such that dof_to_comp[dof] returns the component id associated with dof id dof.
source
Gridap.ReferenceFEs.LagrangianDofBasis — Method
LagrangianDofBasis(::Type{T},nodes::Vector{<:Point}) where T
Creates a LagrangianDofBasis for fields of value type T associated with the vector of nodal coordinates nodes.
source
Gridap.ReferenceFEs.LagrangianRefFE — Type
abstract type LagrangianRefFE{D} <: ReferenceFE{D}
Abstract type representing a Lagrangian reference FE. Lagrangian in the sense that get_dof_basis returns an instance of LagrangianDofBasis. The interface for this type is defined with the methods of ReferenceFE plus the following ones
source
Gridap.ReferenceFEs.LagrangianRefFE — Method
LagrangianRefFE(::Type{T},p::Polytope,orders) where T
+LagrangianRefFE(::Type{T},p::Polytope,order::Int) where T
Builds a LagrangianRefFE object on top of the given polytope. T is the type of the value of the approximation space (e.g., T=Float64 for scalar-valued problems, T=VectorValue{N,Float64} for vector-valued problems with N components). The arguments order or orders are for the polynomial order of the resulting space, which allows isotropic or anisotropic orders respectively (provided that the cell topology allows the given anisotropic order). The argument orders should be an indexable collection of D integers (e.g., a tuple or a vector), being D the number of space dimensions.
In order to be able to use this function, the type of the provided polytope p has to implement the following additional methods. They have been implemented for ExtrusionPolytope in the library. They need to be implemented for new polytope types in order to build Lagangian reference elements on top of them.
The following methods are also used in the construction of the LagrangianRefFE object. A default implementation of them is available in terms of the three previous methods. However, the user can also implement them for new polytope types increasing customization possibilities.
source
Gridap.ReferenceFEs.LinearCombinationDofVector — Type
struct LinearCombinationDofVector{T} <: AbstractVector{Dof}
   change_of_basis::Matrix{T}
   dof_basis::AbstractVector{<:Dof}
-end
Type that implements a dof basis (a) as the linear combination of a dof basis (b). The dofs are first evaluated at dof basis (b) (field dof_basis) and the dof values are next mapped to dof basis (a) applying a change of basis (field change_of_basis).
Fields:
  • change_of_basis::Matrix{T} the matrix of the change from dof basis (b) to (a)
  • dof_basis::AbstractVector{<:Dof} A type representing dof basis (b)
source
Gridap.ReferenceFEs.Polytope — Type
abstract type Polytope{D} <: GridapType
Abstract type representing a polytope (i.e., a polyhedron in arbitrary dimensions). D is the environment dimension (typically, 0, 1, 2, or 3). This type parameter is needed since there are functions in the Polytope interface that return containers with Point{D} objects. We adopt the usual nomenclature for polytope-related objects. All objects in a polytope (from vertices to the polytope itself) are called n-faces or simply faces. The notation n-faces is used only when it is needed to refer to the object dimension n. Otherwise we simply use face. In addition, we say
  • vertex (pl. vertices): for 0-faces
  • edge: for 1-faces
  • facet: for (D-1)-faces
The Polytope interface is defined by overloading the following functions
And optionally these ones:
The interface can be tested with the function
source
Gridap.ReferenceFEs.Polytope — Method
Polytope{N}(p::Polytope,faceid::Integer) where N
Returns a Polytope{N} object representing the "reference" polytope of the N-face with id faceid. The value faceid refers to the numeration restricted to the dimension N (it starts with 1 for the first N-face).
source
Gridap.ReferenceFEs.ReferenceFE — Type
abstract type ReferenceFE{D} <: GridapType
Abstract type representing a Reference finite element. D is the underlying coordinate space dimension. We follow the Ciarlet definition. A reference finite element is defined by a polytope (cell topology), a basis of an interpolation space of top of this polytope (denoted here as the prebasis), and a basis of the dual of this space (i.e. the degrees of freedom). From this information one can compute the shape functions (i.e, the canonical basis of w.r.t. the degrees of freedom) with a simple change of basis. In addition, we also encode in this type information about how the interpolation space in a reference finite element is "glued" with neighbors in order to build conforming cell-wise spaces.
The ReferenceFE interface is defined by overloading these methods:
The interface is tested with
source
Base.:== — Method
(==)(a::LagrangianRefFE{D}, b::LagrangianRefFE{D}) where D
source
Base.:== — Method
(==)(a::Polytope{D},b::Polytope{D}) where D
Returns true if the polytopes a and b are equivalent. Otherwise, it returns false. Note that the operator == returns false by default for polytopes of different dimensions. Thus, this function has to be overloaded only for the case of polytopes a and b of same dimension.
source
Gridap.ReferenceFEs.BDMRefFE — Method
BDMRefFE(::Type{et},p::Polytope,order::Integer) where et
The order argument has the following meaning: the divergence of the  functions in this basis is in the Q space of degree order.
source
Gridap.ReferenceFEs.ModalC0RefFE — Method
ModalC0RefFE(::Type{T},p::Polytope{D},orders) where {T,D}
Returns an instance of GenericRefFE{ModalC0} representing a ReferenceFE with Modal C0-continuous shape functions (multivariate scalar-valued, vector-valued, or tensor-valued, iso- or aniso-tropic).
For more details about the shape functions, see Section 1.1.5 in
Ern, A., & Guermond, J. L. (2013). Theory and practice of finite elements (Vol. 159). Springer Science & Business Media.
and references therein.
The constructor is only implemented for for n-cubes and the minimum order in any dimension must be greater than one. The DoFs are numbered by n-faces in the same way as with CLagrangianRefFEs.
source
Gridap.ReferenceFEs.NedelecRefFE — Method
NedelecRefFE(::Type{et},p::Polytope,order::Integer) where et
The order argument has the following meaning: the curl of the  functions in this basis is in the Q space of degree order.
source
Gridap.ReferenceFEs.RaviartThomasRefFE — Method
RaviartThomasRefFE(::Type{et},p::Polytope,order::Integer) where et
The order argument has the following meaning: the divergence of the  functions in this basis is in the Q space of degree order.
source
Gridap.ReferenceFEs.SerendipityRefFE — Method
SerendipityRefFE(::Type{T},p::Polytope,order::Int) where T
+end
Type that implements a dof basis (a) as the linear combination of a dof basis (b). The dofs are first evaluated at dof basis (b) (field dof_basis) and the dof values are next mapped to dof basis (a) applying a change of basis (field change_of_basis).
Fields:
  • change_of_basis::Matrix{T} the matrix of the change from dof basis (b) to (a)
  • dof_basis::AbstractVector{<:Dof} A type representing dof basis (b)
source
Gridap.ReferenceFEs.Polytope — Type
abstract type Polytope{D} <: GridapType
Abstract type representing a polytope (i.e., a polyhedron in arbitrary dimensions). D is the environment dimension (typically, 0, 1, 2, or 3). This type parameter is needed since there are functions in the Polytope interface that return containers with Point{D} objects. We adopt the usual nomenclature for polytope-related objects. All objects in a polytope (from vertices to the polytope itself) are called n-faces or simply faces. The notation n-faces is used only when it is needed to refer to the object dimension n. Otherwise we simply use face. In addition, we say
  • vertex (pl. vertices): for 0-faces
  • edge: for 1-faces
  • facet: for (D-1)-faces
The Polytope interface is defined by overloading the following functions
And optionally these ones:
The interface can be tested with the function
source
Gridap.ReferenceFEs.Polytope — Method
Polytope{N}(p::Polytope,faceid::Integer) where N
Returns a Polytope{N} object representing the "reference" polytope of the N-face with id faceid. The value faceid refers to the numeration restricted to the dimension N (it starts with 1 for the first N-face).
source
Gridap.ReferenceFEs.ReferenceFE — Type
abstract type ReferenceFE{D} <: GridapType
Abstract type representing a Reference finite element. D is the underlying coordinate space dimension. We follow the Ciarlet definition. A reference finite element is defined by a polytope (cell topology), a basis of an interpolation space of top of this polytope (denoted here as the prebasis), and a basis of the dual of this space (i.e. the degrees of freedom). From this information one can compute the shape functions (i.e, the canonical basis of w.r.t. the degrees of freedom) with a simple change of basis. In addition, we also encode in this type information about how the interpolation space in a reference finite element is "glued" with neighbors in order to build conforming cell-wise spaces.
The ReferenceFE interface is defined by overloading these methods:
The interface is tested with
source
Base.:== — Method
(==)(a::LagrangianRefFE{D}, b::LagrangianRefFE{D}) where D
source
Base.:== — Method
(==)(a::Polytope{D},b::Polytope{D}) where D
Returns true if the polytopes a and b are equivalent. Otherwise, it returns false. Note that the operator == returns false by default for polytopes of different dimensions. Thus, this function has to be overloaded only for the case of polytopes a and b of same dimension.
source
Gridap.ReferenceFEs.BDMRefFE — Method
BDMRefFE(::Type{et},p::Polytope,order::Integer) where et
The order argument has the following meaning: the divergence of the  functions in this basis is in the Q space of degree order.
source
Gridap.ReferenceFEs.ModalC0RefFE — Method
ModalC0RefFE(::Type{T},p::Polytope{D},orders) where {T,D}
Returns an instance of GenericRefFE{ModalC0} representing a ReferenceFE with Modal C0-continuous shape functions (multivariate scalar-valued, vector-valued, or tensor-valued, iso- or aniso-tropic).
For more details about the shape functions, see Section 1.1.5 in
Ern, A., & Guermond, J. L. (2013). Theory and practice of finite elements (Vol. 159). Springer Science & Business Media.
and references therein.
The constructor is only implemented for for n-cubes and the minimum order in any dimension must be greater than one. The DoFs are numbered by n-faces in the same way as with CLagrangianRefFEs.
source
Gridap.ReferenceFEs.NedelecRefFE — Method
NedelecRefFE(::Type{et},p::Polytope,order::Integer) where et
The order argument has the following meaning: the curl of the  functions in this basis is in the Q space of degree order.
source
Gridap.ReferenceFEs.RaviartThomasRefFE — Method
RaviartThomasRefFE(::Type{et},p::Polytope,order::Integer) where et
The order argument has the following meaning: the divergence of the  functions in this basis is in the Q space of degree order.
source
Gridap.ReferenceFEs.SerendipityRefFE — Method
SerendipityRefFE(::Type{T},p::Polytope,order::Int) where T
 SerendipityRefFE(::Type{T},p::Polytope,orders::Tuple) where T
Returns an instance of LagrangianRefFE, whose underlying approximation space is the serendipity space of order order. Implemented for order from 1 to 4. The type of the polytope p has to implement all the queries detailed in the constructor LagrangianRefFE(::Type{T},p::Polytope{D},orders) where {T,D}.
Examples
using Gridap.ReferenceFEs
 
 order = 2
@@ -60,16 +60,16 @@
 
 # output
 8
-
source
Gridap.ReferenceFEs.compute_dofs — Method
compute_dofs(predofs,shapefuns)
Helper function used to compute the dof basis associated with the dof basis predofs and the basis shapefuns.
It is equivalent to
change = inv(evaluate(predofs,shapefuns))
-linear_combination(change,predofs) # i.e. transpose(change)*predofs
source
Gridap.ReferenceFEs.compute_face_orders — Method
compute_face_orders(p::Polytope,face::Polytope,iface::Int,orders)
Returns a vector or a tuple with the order per direction at the face face of the polytope p when restricting the order per direction orders to this face. iface is the face id of face in the numeration restricted to the face dimension.
source
Gridap.ReferenceFEs.compute_lagrangian_reffaces — Method
compute_lagrangian_reffaces(::Type{T},p::Polytope,orders) where T
Returns a tuple of length D being the number of space dimensions. The entry d+1 of this tuple contains a vector of LagrangianRefFE one for each face of dimension d on the boundary of the polytope.
source
Gridap.ReferenceFEs.compute_monomial_basis — Method
compute_monomial_basis(::Type{T},p::Polytope,orders) where T -> MonomialBasis
Returns the monomial basis of value type T and order per direction described by orders on top of the polytope p.
source
Gridap.ReferenceFEs.compute_nodes — Method
compute_nodes(p::Polytope,orders)
When called
node_coords, face_own_nodes = compute_nodes(p,orders)
Returns node_coords, the nodal coordinates of all the Lagrangian nodes associated with the order per direction orders, and face_own_nodes, being a vector of vectors indicating which nodes are owned by each of the faces of the polytope p.
source
Gridap.ReferenceFEs.compute_own_nodes — Method
compute_own_nodes(p::Polytope{D},orders) where D -> Vector{Point{D,Float64}}
Returns the coordinates of the nodes owned by the interior of the polytope associated with a Lagrangian space with the order per direction described by orders.
source
Gridap.ReferenceFEs.compute_shapefuns — Method
compute_shapefuns(dofs,prebasis)
Helper function used to compute the shape function basis associated with the dof basis dofs and the basis prebasis.
It is equivalent to
change = inv(evaluate(dofs,prebasis))
-linear_combination(change,prebasis) # i.e. transpose(change)*prebasis
source
Gridap.ReferenceFEs.get_dimranges — Method
get_dimranges(p::Polytope) -> Vector{UnitRange{Int}}
Given a polytope p it returns a vector of ranges. The entry d+1 in this vector contains the range of face ids for the faces of dimension d.
Examples
using Gridap.ReferenceFEs
+
source
Gridap.ReferenceFEs.compute_dofs — Method
compute_dofs(predofs,shapefuns)
Helper function used to compute the dof basis associated with the dof basis predofs and the basis shapefuns.
It is equivalent to
change = inv(evaluate(predofs,shapefuns))
+linear_combination(change,predofs) # i.e. transpose(change)*predofs
source
Gridap.ReferenceFEs.compute_face_orders — Method
compute_face_orders(p::Polytope,face::Polytope,iface::Int,orders)
Returns a vector or a tuple with the order per direction at the face face of the polytope p when restricting the order per direction orders to this face. iface is the face id of face in the numeration restricted to the face dimension.
source
Gridap.ReferenceFEs.compute_lagrangian_reffaces — Method
compute_lagrangian_reffaces(::Type{T},p::Polytope,orders) where T
Returns a tuple of length D being the number of space dimensions. The entry d+1 of this tuple contains a vector of LagrangianRefFE one for each face of dimension d on the boundary of the polytope.
source
Gridap.ReferenceFEs.compute_monomial_basis — Method
compute_monomial_basis(::Type{T},p::Polytope,orders) where T -> MonomialBasis
Returns the monomial basis of value type T and order per direction described by orders on top of the polytope p.
source
Gridap.ReferenceFEs.compute_nodes — Method
compute_nodes(p::Polytope,orders)
When called
node_coords, face_own_nodes = compute_nodes(p,orders)
Returns node_coords, the nodal coordinates of all the Lagrangian nodes associated with the order per direction orders, and face_own_nodes, being a vector of vectors indicating which nodes are owned by each of the faces of the polytope p.
source
Gridap.ReferenceFEs.compute_own_nodes — Method
compute_own_nodes(p::Polytope{D},orders) where D -> Vector{Point{D,Float64}}
Returns the coordinates of the nodes owned by the interior of the polytope associated with a Lagrangian space with the order per direction described by orders.
source
Gridap.ReferenceFEs.compute_shapefuns — Method
compute_shapefuns(dofs,prebasis)
Helper function used to compute the shape function basis associated with the dof basis dofs and the basis prebasis.
It is equivalent to
change = inv(evaluate(dofs,prebasis))
+linear_combination(change,prebasis) # i.e. transpose(change)*prebasis
source
Gridap.ReferenceFEs.get_dimranges — Method
get_dimranges(p::Polytope) -> Vector{UnitRange{Int}}
Given a polytope p it returns a vector of ranges. The entry d+1 in this vector contains the range of face ids for the faces of dimension d.
Examples
using Gridap.ReferenceFEs
 
 ranges = get_dimranges(SEGMENT)
 println(ranges)
 
 # output
-UnitRange{Int}[1:2, 3:3]
Face ids for the vertices in the segment range from 1 to 2 (2 vertices), the face ids for edges in the segment range from 3 to 3 (only one edge with id 3).
source
Gridap.ReferenceFEs.get_edge_tangent — Method
get_edge_tangent(p::Polytope) -> Vector{VectorValue{D,Float64}}
Given a polytope p, returns a vector of VectorValue objects representing the unit tangent vectors to the polytope edges.
source
Gridap.ReferenceFEs.get_face_dofs — Method
get_face_dofs(reffe::ReferenceFE) -> Vector{Vector{Int}}
Returns a vector of vector that, for each face, stores the dofids in the closure of the face.
source
Gridap.ReferenceFEs.get_face_type — Method
get_face_type(p::Polytope,d::Integer) -> Vector{Int}
Return a vector of integers denoting, for each face of dimension d, an index to the vector get_reffaces(Polytope{d},p)
Examples
Get the unique polytopes for the facets of a wedge and identify of which type each face is.
using Gridap.ReferenceFEs
+UnitRange{Int}[1:2, 3:3]
Face ids for the vertices in the segment range from 1 to 2 (2 vertices), the face ids for edges in the segment range from 3 to 3 (only one edge with id 3).
source
Gridap.ReferenceFEs.get_edge_tangent — Method
get_edge_tangent(p::Polytope) -> Vector{VectorValue{D,Float64}}
Given a polytope p, returns a vector of VectorValue objects representing the unit tangent vectors to the polytope edges.
source
Gridap.ReferenceFEs.get_face_dofs — Method
get_face_dofs(reffe::ReferenceFE) -> Vector{Vector{Int}}
Returns a vector of vector that, for each face, stores the dofids in the closure of the face.
source
Gridap.ReferenceFEs.get_face_type — Method
get_face_type(p::Polytope,d::Integer) -> Vector{Int}
Return a vector of integers denoting, for each face of dimension d, an index to the vector get_reffaces(Polytope{d},p)
Examples
Get the unique polytopes for the facets of a wedge and identify of which type each face is.
using Gridap.ReferenceFEs
 
 reffaces = get_reffaces(Polytope{2},WEDGE)
 
@@ -81,16 +81,16 @@
 # output
 Gridap.ReferenceFEs.ExtrusionPolytope{2}[TRI, QUAD]
 [1, 1, 2, 2, 2]
-
The three first facets are of type 1, i.e, QUAD, and the last ones of type 2, i.e., TRI.
source
Gridap.ReferenceFEs.get_facedims — Method
get_facedims(p::Polytope) -> Vector{Int}
Given a polytope p, returns a vector indicating the dimension of each face in the polytope
Examples
using Gridap.ReferenceFEs
+
The three first facets are of type 1, i.e, QUAD, and the last ones of type 2, i.e., TRI.
source
Gridap.ReferenceFEs.get_facedims — Method
get_facedims(p::Polytope) -> Vector{Int}
Given a polytope p, returns a vector indicating the dimension of each face in the polytope
Examples
using Gridap.ReferenceFEs
 
 dims = get_facedims(SEGMENT)
 println(dims)
 
 # output
 [0, 0, 1]
-
The first two faces in the segment (the two vertices) have dimension 0 and the third face (the segment itself) has dimension 1
source
Gridap.ReferenceFEs.get_faces — Method
get_faces(p::Polytope,dimfrom::Integer,dimto::Integer) -> Vector{Vector{Int}}
For dimfrom >= dimto returns a vector that for each face of dimension dimfrom stores a vector of the ids of faces of dimension dimto on its boundary.
For dimfrom < dimto returns a vector that for each face of dimfrom stores a vector of the face ids of faces of dimension dimto that touch it.
The numerations used in this function are the ones restricted to each dimension.
using Gridap.ReferenceFEs
+
The first two faces in the segment (the two vertices) have dimension 0 and the third face (the segment itself) has dimension 1
source
Gridap.ReferenceFEs.get_faces — Method
get_faces(p::Polytope,dimfrom::Integer,dimto::Integer) -> Vector{Vector{Int}}
For dimfrom >= dimto returns a vector that for each face of dimension dimfrom stores a vector of the ids of faces of dimension dimto on its boundary.
For dimfrom < dimto returns a vector that for each face of dimfrom stores a vector of the face ids of faces of dimension dimto that touch it.
The numerations used in this function are the ones restricted to each dimension.
using Gridap.ReferenceFEs
 
 edge_to_vertices = get_faces(QUAD,1,0)
 println(edge_to_vertices)
@@ -100,20 +100,20 @@
 
 # output
 Array{Int,1}[[1, 2], [3, 4], [1, 3], [2, 4]]
-Array{Int,1}[[1, 3], [1, 4], [2, 3], [2, 4]]
source
Gridap.ReferenceFEs.get_faces — Method
get_faces(p::Polytope) -> Vector{Vector{Int}}
Given a polytope p the function returns a vector of vectors defining the incidence relation of the faces in the polytope.
Each face in the polytope receives a unique integer id. The id 1 is assigned to the first 0-face. Consecutive increasing ids are assigned to the other 0-faces, then to 1-faces, and so on. The polytope itself receives the largest id which coincides with num_faces(p). For a face id iface, get_faces(p)[iface] is a vector of face ids, corresponding to the faces that are incident with the face labeled with iface. That is, faces that are either on its boundary or the face itself. In this vector of incident face ids, faces are ordered by dimension, starting with 0-faces. Within each dimension, the labels are ordered in a consistent way with the polyope object for the face iface itself.
Examples
using Gridap.ReferenceFEs
+Array{Int,1}[[1, 3], [1, 4], [2, 3], [2, 4]]
source
Gridap.ReferenceFEs.get_faces — Method
get_faces(p::Polytope) -> Vector{Vector{Int}}
Given a polytope p the function returns a vector of vectors defining the incidence relation of the faces in the polytope.
Each face in the polytope receives a unique integer id. The id 1 is assigned to the first 0-face. Consecutive increasing ids are assigned to the other 0-faces, then to 1-faces, and so on. The polytope itself receives the largest id which coincides with num_faces(p). For a face id iface, get_faces(p)[iface] is a vector of face ids, corresponding to the faces that are incident with the face labeled with iface. That is, faces that are either on its boundary or the face itself. In this vector of incident face ids, faces are ordered by dimension, starting with 0-faces. Within each dimension, the labels are ordered in a consistent way with the polyope object for the face iface itself.
Examples
using Gridap.ReferenceFEs
 
 faces = get_faces(SEGMENT)
 println(faces)
 
 # output
-Array{Int,1}[[1], [2], [1, 2, 3]]
The constant SEGMENT is bound to a predefined instance of polytope that represents a segment. The face labels associated with a segment are [1,2,3], being 1 and 2 for the vertices and 3 for the segment itself. In this case, this function returns the vector of vectors [[1],[2],[1,2,3]] meaning that vertex 1 is incident with vertex 1 (idem for vertex 2), and that the segment (id 3) is incident with the vertices 1 and 2 and the segment itself.
source
Gridap.ReferenceFEs.get_facet_normal — Method
get_facet_normal(p::Polytope) -> Vector{VectorValue{D,Float64}}
Given a polytope p, returns a vector of VectorValue objects representing the unit outward normal vectors to the polytope facets.
source
Gridap.ReferenceFEs.get_facet_orientations — Method
get_facet_orientations(p::Polytope) -> Vector{Int}
Given a polytope p returns a vector of integers of length num_facets(p). Facets, whose vertices are ordered consistently with the outwards normal vector, receive value 1 in this vector. Otherwise, facets receive value -1.
source
Gridap.ReferenceFEs.get_offsets — Method
get_offsets(p::Polytope) -> Vector{Int}
Given a polytope p, it returns a vector of integers. The position in the d+1 entry in this vector is the offset that transforms a face id in the global numeration in the polytope to the numeration restricted to faces to dimension d.
Examples
using Gridap.ReferenceFEs
+Array{Int,1}[[1], [2], [1, 2, 3]]
The constant SEGMENT is bound to a predefined instance of polytope that represents a segment. The face labels associated with a segment are [1,2,3], being 1 and 2 for the vertices and 3 for the segment itself. In this case, this function returns the vector of vectors [[1],[2],[1,2,3]] meaning that vertex 1 is incident with vertex 1 (idem for vertex 2), and that the segment (id 3) is incident with the vertices 1 and 2 and the segment itself.
source
Gridap.ReferenceFEs.get_facet_normal — Method
get_facet_normal(p::Polytope) -> Vector{VectorValue{D,Float64}}
Given a polytope p, returns a vector of VectorValue objects representing the unit outward normal vectors to the polytope facets.
source
Gridap.ReferenceFEs.get_facet_orientations — Method
get_facet_orientations(p::Polytope) -> Vector{Int}
Given a polytope p returns a vector of integers of length num_facets(p). Facets, whose vertices are ordered consistently with the outwards normal vector, receive value 1 in this vector. Otherwise, facets receive value -1.
source
Gridap.ReferenceFEs.get_offsets — Method
get_offsets(p::Polytope) -> Vector{Int}
Given a polytope p, it returns a vector of integers. The position in the d+1 entry in this vector is the offset that transforms a face id in the global numeration in the polytope to the numeration restricted to faces to dimension d.
Examples
using Gridap.ReferenceFEs
 
 offsets = get_offsets(SEGMENT)
 println(offsets)
 
 # output
 [0, 2]
-
source
Gridap.ReferenceFEs.get_reffaces — Method
get_reffaces(::Type{Polytope{d}},p::Polytope) where d -> Vector{Polytope{d}}
Get a vector of the unique polytopes for the faces of dimension d.
Examples
Get the unique polytopes for the facets of a wedge.
using Gridap.ReferenceFEs
+
source
Gridap.ReferenceFEs.get_reffaces — Method
get_reffaces(::Type{Polytope{d}},p::Polytope) where d -> Vector{Polytope{d}}
Get a vector of the unique polytopes for the faces of dimension d.
Examples
Get the unique polytopes for the facets of a wedge.
using Gridap.ReferenceFEs
 
 reffaces = get_reffaces(Polytope{2},WEDGE)
 
@@ -121,20 +121,20 @@
 
 # output
 Gridap.ReferenceFEs.ExtrusionPolytope{2}[TRI, QUAD]
-
source
Gridap.ReferenceFEs.get_reffaces — Method
get_reffaces(
   ::Type{ReferenceFE{d}},
-  reffe::GenericLagrangianRefFE{GradConformity}) where d -> Vector{GenericLagrangianRefFE{GradConformity,M,d}}
source
Gridap.ReferenceFEs.get_shapefuns — Method
get_shapefuns(reffe::ReferenceFE) -> Field
Returns the basis of shape functions (i.e. the canonical basis) associated with the reference FE. The result is encoded as a Field object.
source
Gridap.ReferenceFEs.get_vertex_permutations — Method
get_vertex_permutations(p::Polytope) -> Vector{Vector{Int}}
Given a polytope p, returns a vector of vectors containing all admissible permutations of the polytope vertices. An admissible permutation is one such that, if the vertices of the polytope are re-labeled according to this permutation, the resulting polytope preserves the shape of the original one.
Examples
using Gridap.ReferenceFEs
+  reffe::GenericLagrangianRefFE{GradConformity}) where d -> Vector{GenericLagrangianRefFE{GradConformity,M,d}}
source
Gridap.ReferenceFEs.get_shapefuns — Method
get_shapefuns(reffe::ReferenceFE) -> Field
Returns the basis of shape functions (i.e. the canonical basis) associated with the reference FE. The result is encoded as a Field object.
source
Gridap.ReferenceFEs.get_vertex_permutations — Method
get_vertex_permutations(p::Polytope) -> Vector{Vector{Int}}
Given a polytope p, returns a vector of vectors containing all admissible permutations of the polytope vertices. An admissible permutation is one such that, if the vertices of the polytope are re-labeled according to this permutation, the resulting polytope preserves the shape of the original one.
Examples
using Gridap.ReferenceFEs
 
 perms = get_vertex_permutations(SEGMENT)
 println(perms)
 
 # output
 Array{Int,1}[[1, 2], [2, 1]]
-
The first admissible permutation for a segment is [1,2],i.e., the identity. The second one is [2,1], i.e., the first vertex is relabeled as 2 and the second vertex is relabeled as 1.
source
Gridap.ReferenceFEs.next_corner! — Method
Sweep through the dim-dimensional hypercube recursively, collecting all simplices.
We represent vertices as bit patterns. In dim dimensions, the lowermost dim bits are either zero or one. Interpreted as integer, this labels the vertices of the hypercube from the origin ("bottom") 0 to the diagonally opposite vertex ("top") 2^dim-1.
Each simplex contains both the bottom vertex 0 as well as the top vertex 2^dim-1. Its other vertices trace a path from the bottom to the top. The algorithm below finds all possible paths.
  • simplices is the accumulator where the simplices are collected.
  • vertices is the current set of vertices as we sweep from the origin to the diagonally opposide vertex.
  • corner is the current corner.
source
Gridap.ReferenceFEs.test_dof — Method
test_dof(dof,field,v;cmp::Function=(==))
Test that the Dof interface is properly implemented for object dof. It also checks if the object dof when evaluated at the field field returns the same value as v. Comparison is made with the comp function.
source
Gridap.ReferenceFEs.test_polytope — Method
test_polytope(p::Polytope{D}; optional::Bool=false) where D
Function that stresses out the functions in the Polytope interface. It tests whether the function in the polytope interface are defined for the given object, and whether they return objects of the expected type. With optional=false (the default), only the mandatory functions are checked. With optional=true, the optional functions are also tested.
source

+

The first admissible permutation for a segment is [1,2],i.e., the identity. The second one is [2,1], i.e., the first vertex is relabeled as 2 and the second vertex is relabeled as 1.

source
Gridap.ReferenceFEs.next_corner! — Method

Sweep through the dim-dimensional hypercube recursively, collecting all simplices.

We represent vertices as bit patterns. In dim dimensions, the lowermost dim bits are either zero or one. Interpreted as integer, this labels the vertices of the hypercube from the origin ("bottom") 0 to the diagonally opposite vertex ("top") 2^dim-1.

Each simplex contains both the bottom vertex 0 as well as the top vertex 2^dim-1. Its other vertices trace a path from the bottom to the top. The algorithm below finds all possible paths.

  • simplices is the accumulator where the simplices are collected.
  • vertices is the current set of vertices as we sweep from the origin to the diagonally opposide vertex.
  • corner is the current corner.
source
Gridap.ReferenceFEs.test_dof — Method
test_dof(dof,field,v;cmp::Function=(==))

Test that the Dof interface is properly implemented for object dof. It also checks if the object dof when evaluated at the field field returns the same value as v. Comparison is made with the comp function.

source
Gridap.ReferenceFEs.test_polytope — Method
test_polytope(p::Polytope{D}; optional::Bool=false) where D

Function that stresses out the functions in the Polytope interface. It tests whether the function in the polytope interface are defined for the given object, and whether they return objects of the expected type. With optional=false (the default), only the mandatory functions are checked. With optional=true, the optional functions are also tested.

source
diff --git a/dev/TensorValues/index.html b/dev/TensorValues/index.html index f1f51f4a9..aba5b24c2 100644 --- a/dev/TensorValues/index.html +++ b/dev/TensorValues/index.html @@ -10,4 +10,4 @@ B = fill(t,(1,5)) C = inner.(g,B) # inner product of g against all TensorValues in the array B @show C -# C = [2494 2494 2494 2494 2494]

The exported names are:

source
Gridap.TensorValues.MultiValue — Type

Type representing a multi-dimensional value

source
Gridap.TensorValues.SymFourthOrderTensorValue — Type

Type representing a symmetric fourth-order tensor

source
Gridap.TensorValues.SymTensorValue — Type

Type representing a symmetric second-order tensor

source
Gridap.TensorValues.TensorValue — Type

Type representing a second-order tensor

source
Gridap.TensorValues.ThirdOrderTensorValue — Type

Type representing a third-order tensor

source
Gridap.TensorValues.VectorValue — Type

Type representing a first-order tensor

source
Gridap.TensorValues.meas — Method
source
Gridap.TensorValues.outer — Method
source
Gridap.TensorValues.symmetric_part — Method
source
+# C = [2494 2494 2494 2494 2494]

The exported names are:

source
Gridap.TensorValues.MultiValue — Type

Type representing a multi-dimensional value

source
Gridap.TensorValues.SymFourthOrderTensorValue — Type

Type representing a symmetric fourth-order tensor

source
Gridap.TensorValues.SymTensorValue — Type

Type representing a symmetric second-order tensor

source
Gridap.TensorValues.TensorValue — Type

Type representing a second-order tensor

source
Gridap.TensorValues.ThirdOrderTensorValue — Type

Type representing a third-order tensor

source
Gridap.TensorValues.VectorValue — Type

Type representing a first-order tensor

source
Gridap.TensorValues.meas — Method
source
Gridap.TensorValues.outer — Method
source
Gridap.TensorValues.symmetric_part — Method
source
diff --git a/dev/Visualization/index.html b/dev/Visualization/index.html index 3652fc748..826ba1785 100644 --- a/dev/Visualization/index.html +++ b/dev/Visualization/index.html @@ -1,10 +1,10 @@ -Gridap.Visualization · Gridap.jl
Edit on GitHub

Gridap.Visualization

Gridap.Visualization.create_vtk_file — Method
create_vtk_file(
+Gridap.Visualization · Gridap.jl
Edit on GitHub
Gridap.Visualization
Gridap.Visualization.create_vtk_file — Method
create_vtk_file(
   trian::Grid,
   filebase;
   celldata=Dict(),
-  nodaldata=Dict())
Low level entry point to vtk. Other vtk-related routines in Gridap eventually call this one. This function only creates the vtkFile, without writing to disk.
source
Gridap.Visualization.write_vtk_file — Method
write_vtk_file(
+  nodaldata=Dict())
Low level entry point to vtk. Other vtk-related routines in Gridap eventually call this one. This function only creates the vtkFile, without writing to disk.
source
Gridap.Visualization.write_vtk_file — Method
write_vtk_file(
   trian::Grid,
   filebase;
   celldata=Dict(),
-  nodaldata=Dict())
Low level entry point to vtk. Other vtk-related routines in Gridap eventually call this one.
source

+  nodaldata=Dict())

Low level entry point to vtk. Other vtk-related routines in Gridap eventually call this one.

source
diff --git a/dev/dev-notes/block-assemblers/index.html b/dev/dev-notes/block-assemblers/index.html index ca9cbf256..0743324ae 100644 --- a/dev/dev-notes/block-assemblers/index.html +++ b/dev/dev-notes/block-assemblers/index.html @@ -71,4 +71,4 @@ end end end -end

In the monolithic assembly of MultiFieldFESpaces, the variable A is an ArrayCounter. As you can see, all contribution blocks (coming from different fields) are assembled into the same ArrayCounter. The block-assembly counterpart will have the input A be a MatrixBlock{<:ArrayCounter}, and assembles each contribution block to it's corresponding ArrayCounter (notice the A.array[i,j]).

B) Assembling multiple FE Fields into the same Block

The BlockMultiFieldStyle constructor can take up to three parameters:

  1. NB :: Integer, representing the number of final blocks. Then the matrix and vector will have NBxNB and NB blocks respectively.
  2. SB :: Tuple of integers, of length NB. In each position, SB[ib] is the number of fields that will be assembled in that block.
  3. P :: Tuple of integers, of length the number of fields. This represents a field permutation, such that the fields will be reordered as[P[1],P[2],....,P[n]].

Using this three parameters, one can assemble an arbitrary number of fields into any number of blocks.

Example: Consider we are solving an MHD problem with variables (u,p,j,q) , i.e (fluid velocity, fluid pressure, magnetic current, electric potential). Although the variables are in this specific order in the MultiFieldFESpace, we want to build a block-preconditioner that solves (u,j) together in a single block then p and q separately in two other blocks. Then we would need to assemble our system using NB=3, SB=(2,1,1) and P=(1,3,2,4). With this configuration, we will create 3 blocks. The first block will have size 2 and hold variables [P[1],P[2]] = [1,3] = [u,j]. The second block will have size 1 and hold variables [P[3]] = [2] = [p]. Finally, the third block will hold variables [P[4]] = [4] = [q].

In terms of implementation, everything is the same. We use ArrayBlockViews (which is a view counterpart of ArrayBlock) so that an array of NBxNB array builders / array counters can be indexed using the field indexes. This allows us to use the same dispatches as we had in part A.

+end

In the monolithic assembly of MultiFieldFESpaces, the variable A is an ArrayCounter. As you can see, all contribution blocks (coming from different fields) are assembled into the same ArrayCounter. The block-assembly counterpart will have the input A be a MatrixBlock{<:ArrayCounter}, and assembles each contribution block to it's corresponding ArrayCounter (notice the A.array[i,j]).

B) Assembling multiple FE Fields into the same Block

The BlockMultiFieldStyle constructor can take up to three parameters:

  1. NB :: Integer, representing the number of final blocks. Then the matrix and vector will have NBxNB and NB blocks respectively.
  2. SB :: Tuple of integers, of length NB. In each position, SB[ib] is the number of fields that will be assembled in that block.
  3. P :: Tuple of integers, of length the number of fields. This represents a field permutation, such that the fields will be reordered as[P[1],P[2],....,P[n]].

Using this three parameters, one can assemble an arbitrary number of fields into any number of blocks.

Example: Consider we are solving an MHD problem with variables (u,p,j,q) , i.e (fluid velocity, fluid pressure, magnetic current, electric potential). Although the variables are in this specific order in the MultiFieldFESpace, we want to build a block-preconditioner that solves (u,j) together in a single block then p and q separately in two other blocks. Then we would need to assemble our system using NB=3, SB=(2,1,1) and P=(1,3,2,4). With this configuration, we will create 3 blocks. The first block will have size 2 and hold variables [P[1],P[2]] = [1,3] = [u,j]. The second block will have size 1 and hold variables [P[3]] = [2] = [p]. Finally, the third block will hold variables [P[4]] = [4] = [q].

In terms of implementation, everything is the same. We use ArrayBlockViews (which is a view counterpart of ArrayBlock) so that an array of NBxNB array builders / array counters can be indexed using the field indexes. This allows us to use the same dispatches as we had in part A.

diff --git a/dev/getting-started/index.html b/dev/getting-started/index.html index f01e12fea..dcf734e60 100644 --- a/dev/getting-started/index.html +++ b/dev/getting-started/index.html @@ -1,2 +1,2 @@ -Getting Started · Gridap.jl
Edit on GitHub

Getting Started

Installation requirements

Gridap is tested on Linux, but it should be also possible to use it on Mac OS and Windows since it is written exclusively in Julia and it only depends on registered Julia packages.

Installation

Gridap is a registered package. Thus, the installation should be straight forward using the Julia's package manager Pkg. To this end, open the Julia REPL (i.e., execute the julia binary), type ] to enter package mode, and install Gridap as follows

pkg> add Gridap

That's all.

For further information about how to install and manage Julia packages, see the Pkg documentation.

Further steps

We recommend to follow the Gridap Tutorials in order to get familiar with the library.

+Getting Started · Gridap.jl
Edit on GitHub

Getting Started

Installation requirements

Gridap is tested on Linux, but it should be also possible to use it on Mac OS and Windows since it is written exclusively in Julia and it only depends on registered Julia packages.

Installation

Gridap is a registered package. Thus, the installation should be straight forward using the Julia's package manager Pkg. To this end, open the Julia REPL (i.e., execute the julia binary), type ] to enter package mode, and install Gridap as follows

pkg> add Gridap

That's all.

For further information about how to install and manage Julia packages, see the Pkg documentation.

Further steps

We recommend to follow the Gridap Tutorials in order to get familiar with the library.

diff --git a/dev/index.html b/dev/index.html index 3c7e19318..3be50c1a6 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Home · Gridap.jl
Edit on GitHub

Gridap.jl

Documentation of the Gridap library.

Note

These documentation pages are under construction.

Introduction

Gridap provides a set of tools for the grid-based approximation of partial differential equations (PDEs) written in the Julia programming language. The main motivation behind the development of this library is to provide an easy-to-use framework for the development of complex PDE solvers in a dynamically typed style without sacrificing the performance of statically typed languages. The library currently supports linear and nonlinear PDE systems for scalar and vector fields, single and multi-field problems, conforming and nonconforming finite element discretizations, on structured and unstructured meshes of simplices and hexahedra.

How to use this documentation

  • The first step for new users is to visit the Getting Started page.

  • A set of tutorials written as Jupyter notebooks and html pages are available here.

  • The detailed documentation is in the Manual section.

  • Guidelines for developers of the Gridap project is found in the Gridap wiki page.

Julia educational resources

A basic knowledge of the Julia programming language is needed to use the Gridap package. Here, one can find a list of resources to get started with this programming language.

Manual

+Home · Gridap.jl
Edit on GitHub

Gridap.jl

Documentation of the Gridap library.

Note

These documentation pages are under construction.

Introduction

Gridap provides a set of tools for the grid-based approximation of partial differential equations (PDEs) written in the Julia programming language. The main motivation behind the development of this library is to provide an easy-to-use framework for the development of complex PDE solvers in a dynamically typed style without sacrificing the performance of statically typed languages. The library currently supports linear and nonlinear PDE systems for scalar and vector fields, single and multi-field problems, conforming and nonconforming finite element discretizations, on structured and unstructured meshes of simplices and hexahedra.

How to use this documentation

  • The first step for new users is to visit the Getting Started page.

  • A set of tutorials written as Jupyter notebooks and html pages are available here.

  • The detailed documentation is in the Manual section.

  • Guidelines for developers of the Gridap project is found in the Gridap wiki page.

Julia educational resources

A basic knowledge of the Julia programming language is needed to use the Gridap package. Here, one can find a list of resources to get started with this programming language.

Manual

diff --git a/dev/search/index.html b/dev/search/index.html index b974d6f35..e2abb14c4 100644 --- a/dev/search/index.html +++ b/dev/search/index.html @@ -1,2 +1,2 @@ -Search · Gridap.jl

Loading search...

    +Search · Gridap.jl

    Loading search...