-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for interior face integrals #1223
Conversation
…in restriction class
…unctional, delete debugging print statements
/style |
cmake_dependent_option(SERAC_ENABLE_BENCHMARKS "Enable benchmark executables" ON "ENABLE_BENCHMARKS" OFF) | ||
if (ENABLE_BENCHMARKS) | ||
set(SERAC_ENABLE_BENCHMARKS ON) | ||
endif() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While cmake_dependent_option
is admittedly weird I think it is okay as is. SERAC_ENABLE_BENCHMARKS
generally shouldn't be set explicitly unless you want to enable benchmarks yet disable Serac's. Simply set ENABLE_BENCHMARKS
.
SERAC_ENABLE_BENCHMARKS
can only be set if ENABLE_BENCHMARKS
is ON
. If ENABLE_BENCHMARKS
is ON
, it will automatically set SERAC_ENABLE_BENCHMARKS
to ON
. Otherwise SERAC_ENABLE_BENCHMARKS
is forced to OFF
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please re-add cmake_dependent_option(SERAC_ENABLE_BENCHMARKS "Enable benchmark executables" ON "ENABLE_BENCHMARKS" OFF)
src/serac/numerics/functional/tests/dg_restriction_operators.cpp
Outdated
Show resolved
Hide resolved
src/serac/numerics/functional/tests/dg_restriction_operators.cpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm personally OK with disabling the .lua for now. We may be able to re-prioritize in the spring to revive, but we cannot keep this PR up forever, the scope is already massive.
/style |
|
||
// the dofs mfem returns for Hcurl include information about | ||
// dof orientation, but not for triangle faces on 3D elements. | ||
// So, we need to manually |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is unsupported for now, should we abort or warn?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question, I'll defer that decision for now (it appears that this is new code in the PR, but it's just a copy of existing code)
|
||
ordering = fes->GetOrdering(); | ||
// note: this assumes that all the elements are the same polynomial order |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an idea how we can enforce this? Check on the Domain
creation? Doesn't need to be in this PR, but maybe open as issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. We could just iterate through the elements and check that they agree, but that doesn't catch the (unlikely) case that the ParMesh was partitioned into chunks that each have constant (but different) p.
src/serac/numerics/functional/interior_face_integral_kernels.hpp
Outdated
Show resolved
Hide resolved
/style |
This PR aims to implement a feature requested by @tupek2 to be able to integrate over interior faces. The main challenge is in handling DG/L2 spaces for this type of integral, as they have separate values on each side.
The the new kind of integral behaves similarly to the existing boundary integral, except that for L2 spaces it represents:
where the domain of integration$\Omega$ represents the specified collection of interior faces, $\phi_1, \phi_2$ are the basis functions from side 1 and side 2, and $u_1, u_2$ are the values of the DG field evaluated from side 1 and side 2. For example, consider a mesh made of two adjacent quadrilateral elements, with a $\Omega$ .
L2<1, 1>
field defined on it. The red disks represent the nodes of the DG field (with the positions of the nodes shifted inward slightly to exaggerate which side of the interior face they belong to), and the blue edge represents the domainIn this example, the basis functions that appear in the integrand are:
where$N_0, N_1$ are the usual linear interpolation shape functions in 1D.
Here is an example of a residual calculation involving a vector-valued DG space and interior faces:
Here's a table showing which argument types are passed to qfunction and which weight functions are applied to the output of qfunctions, depending on the type of integral and trial/test space (respectively):