You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is to track the progress of porting finite difference methods to Trixi. I propose to use my package SummationByPartsOperators.jl to get the basic methods. Then, we could use the following approach (implemented in #617).
Pack an SBP derivative operator from SummationByPartsOperators.jl as basis in Trixi's DG struct
Organize methods written for general DG operators such that they can use these new basis types
Implement the weak-form volume integral in 2D for these SBP operators and the TreeMesh with conforming interfaces (no mortar, no AMR)
We shouldn't look at performance too much at this stage. It will probably be okay to just compute the fluxes and use mul!. However, that will require multiple mul!s for each component, reinterpreting arrays to have SVectors as contents, or to use something like StructArrays.jl, see also #557.
Some limitations of this first approach and open questions are
We will use the same number of nodes per coordinate direction
Efficient parallelization will probably require new/more code. Will we have enough elements such that threading across elements is still optimal? Or will we have a few huge elements such that we also need threading inside of the elements?
Truly multi-dimensional implementations can be more (cache-) efficient than dimension-by-dimension versions implemented at first
How should we handle a single truly periodic block? The basic option above will give us one SBP element coupled via numerical fluxes. Do we also want to enable a single truly periodic FD block?
Shall we also allow upwind SBP operators? If so, how can we do that efficiently?
This will be a basic proof-of-concept and allows us to see whether/how our current abstractions need to be changed. Afterwards, some possible next steps are
This is to track the progress of porting finite difference methods to Trixi. I propose to use my package SummationByPartsOperators.jl to get the basic methods. Then, we could use the following approach (implemented in #617).
basis
in Trixi'sDG
structTreeMesh
with conforming interfaces (no mortar, no AMR)We shouldn't look at performance too much at this stage. It will probably be okay to just compute the fluxes and use
mul!
. However, that will require multiplemul!
s for each component,reinterpret
ing arrays to haveSVector
s as contents, or to use something like StructArrays.jl, see also #557.Some limitations of this first approach and open questions are
This will be a basic proof-of-concept and allows us to see whether/how our current abstractions need to be changed. Afterwards, some possible next steps are
DG
: Current sub-methods are FDSBP and DGSEMdg_common.jl
, adgsem_common.jl
, and afdsbp_common.jl
tree_2d_dgsem
,tree_2d_fdsbp
etc.convergence_test
to different refinement types (number of elements, number of nodes per element)UnstructuredMesh2D
#1773mortar=nothing
forDG
(https://github.com/trixi-framework/Trixi.jl/pull/617/files#r643664755) and add more explanation ofmortar
and the other terms (https://github.com/trixi-framework/Trixi.jl/pull/617/files#r644461598)The text was updated successfully, but these errors were encountered: