Add interface types for FEM/FVM/DG discretizations on general domains#61
Add interface types for FEM/FVM/DG discretizations on general domains#61ChrisRackauckas-Claude wants to merge 2 commits into
Conversation
This addresses issue SciML#5 by providing foundational abstract types and interfaces for discretizations on unstructured meshes. The key additions are: Domain types (src/domains.jl): - AbstractDiscretizedDomain{T}: Abstract supertype for mesh-based domains - MeshDomain{T,M}: Generic wrapper for mesh objects from external libraries - BoundaryRegion{D}: Named boundary regions for BC specification - ConditionalBoundary{D,C}: Boundary selection via conditions Variational method types (src/variational.jl): - AbstractVariationalMethod: Base type for variational formulations - AbstractGalerkinMethod, AbstractRitzGalerkin, AbstractPetrovGalerkin - RitzGalerkin: Marker type for standard Galerkin FEM - AbstractUnstructuredDiscretization, AbstractUnstructuredDiscreteSpace - FEM traits for querying weak/strong form support Interface functions: - get_mesh, get_boundary_markers, mark_boundary! - get_parent_domain, get_boundary_name, get_condition - get_variational_method, is_galerkin, is_symmetric_galerkin - get_supported_form Documentation added for both domain types and variational methods. Closes SciML#5 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Remove @ref link to AbstractCartesianDiscreteSpace which doesn't have a docstring, causing Documenter.jl to fail. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
termi-official
left a comment
termi-official
left a comment
There was a problem hiding this comment.
I left some first comments to get the discussion started.
| mesh::M | ||
| boundary_markers::Dict{String, Any} |
There was a problem hiding this comment.
I am not sure about this design here. Shouldn't we either have also the domain markers (e.g. in a fluid-solid interaction domain some maker for the fluid domain and for the solid subdomain) or retrieve everything directly from the mesh?
| where B(·,·) is a bilinear (or semilinear) form and L(·) is a linear form. | ||
|
|
||
| # Subtypes | ||
| - [`AbstractRitzGalerkin`](@ref): Vₕ = Wₕ (standard Galerkin) |
There was a problem hiding this comment.
I think what you mean here is Bubnov-Galerkin. Ritz-Galerkin is typically some functional minimization (as e.g. in energy minimization), implying symmetry of the resulting bilinear form.
| """ | ||
| is_symmetric_galerkin(method::AbstractVariationalMethod) -> Bool | ||
|
|
||
| Check if a Galerkin method uses symmetric test/trial spaces (Ritz-Galerkin). |
There was a problem hiding this comment.
I do not think that this association is correct. You can choose your test and trial spaces to match and still construct a non-symmetric problem.
| - [`AbstractRitzGalerkin`](@ref): Vₕ = Wₕ (standard Galerkin) | ||
| - [`AbstractPetrovGalerkin`](@ref): Vₕ ≠ Wₕ (e.g., SUPG, DG) | ||
| """ | ||
| abstract type AbstractGalerkinMethod <: AbstractVariationalMethod end |
There was a problem hiding this comment.
Isn't this the wrong way around in the type hierarchy?
| Standard finite element methods use Ritz-Galerkin formulations. The weak form is: | ||
| Find uₕ ∈ Vₕ such that a(uₕ, vₕ) = b(vₕ) for all vₕ ∈ Vₕ |
There was a problem hiding this comment.
This is just true for linear problems, right?
|
|
||
| Base type for traits describing FEM discretization capabilities. | ||
| """ | ||
| abstract type AbstractFEMTrait end |
There was a problem hiding this comment.
More a general question on such designs: Why do we need a common supertype for traits?
|
|
||
| When working with weak forms, the PDE is expressed as: | ||
|
|
||
| **Find u in V such that:** `a(u, v) = L(v)` for all v in V |
There was a problem hiding this comment.
So the interface is really restricted to linear problems for now?
| # 1. Introduce test functions v for each trial function u | ||
| # 2. Multiply equations by test functions | ||
| # 3. Integrate over domain | ||
| # 4. Apply integration by parts where needed |
| polynomial_order::Int | ||
| quadrature::Q |
There was a problem hiding this comment.
While this is fine for an example, we need to make sure that we do not rely on the existence of these fields. For example, different parts of the weak form can use different quadrature rules and different fields can use different ansatz functions (or just different orders, as e.g. in Taylor-Hood elements for incompressible problems).
3 participants
Summary
This PR addresses issue #5 by providing foundational abstract types and interfaces for discretizations on unstructured meshes and general domains.
Domain Types (
src/domains.jl)AbstractDiscretizedDomain{T}: Abstract supertype for mesh-based domains (subtype ofDomainSets.Domain{T})MeshDomain{T,M}: Generic wrapper for mesh objects from external libraries (Ferrite, Gridap, etc.)BoundaryRegion{D}: Named boundary regions for BC specificationConditionalBoundary{D,C}: Boundary selection via coordinate conditionsVariational Method Types (
src/variational.jl)AbstractVariationalMethod: Base type for variational formulationsAbstractGalerkinMethod,AbstractRitzGalerkin,AbstractPetrovGalerkin: Type hierarchy for Galerkin methodsRitzGalerkin: Concrete marker type for standard Galerkin FEMAbstractUnstructuredDiscretization,AbstractUnstructuredDiscreteSpace: For unstructured mesh discretizationsSupportsWeakForm,SupportsStrongForm,SupportsBothForms) for querying discretization capabilitiesInterface Functions
get_mesh,get_boundary_markers,mark_boundary!: Mesh access and boundary managementget_parent_domain,get_boundary_name,get_condition: Boundary region accessget_variational_method,is_galerkin,is_symmetric_galerkin: Variational method queriesget_supported_form: Query what form (weak/strong) a discretization supportsDocumentation
docs/src/domains.mdexplaining domain types and usage with external mesh librariesdocs/src/variational.mdexplaining FEM interface types and implementation patternsThis provides the foundation discussed in issue #5 while leaving framework-specific implementations to downstream packages.
Closes #5
cc @ChrisRackauckas @termi-official @xtalax @koehlerson
Test Plan
🤖 Generated with Claude Code