Functional feature: Computes matrix entries for H1/Hcurl#484
Functional feature: Computes matrix entries for H1/Hcurl#484
Conversation
…ure/jonwong12/variational_form
…2/gradient_matrix_kernel
Codecov Report
@@ Coverage Diff @@
## develop #484 +/- ##
===========================================
+ Coverage 94.72% 95.06% +0.34%
===========================================
Files 68 70 +2
Lines 3678 3934 +256
===========================================
+ Hits 3484 3740 +256
Misses 194 194
Continue to review full report at Codecov.
|
src/serac/physics/utilities/functional/tests/functional_comparisons.cpp
Outdated
Show resolved
Hide resolved
|
@joshessman-llnl I have a issue/branch in MFEM to do this matrix assembly, but I don't know what the timeline for that is. I think they are interested in seeing some benchmarks. In that branch, I just One point of contention is that MFEM seems more concerned with higher order elements where assembling a matrix may have declining payoffs, whereas for the problems we solve, matrices are useful. Alternatively this PR doesn't support L2 (LEXICOGRAPHIC ordering, but NATIVE ordering is fine?), because |
…ents to Assembled Sparse Matrix
…on. removed dead code and unused variables
src/serac/physics/utilities/functional/detail/metaprogramming.hpp
Outdated
Show resolved
Hide resolved
Co-authored-by: samuelpmishLLNL <61714427+samuelpmishLLNL@users.noreply.github.com>
Co-authored-by: samuelpmishLLNL <61714427+samuelpmishLLNL@users.noreply.github.com>
|
This all looks very promising to me! I want to apologize again for not providing a rich enough set of tools to make the implementation of |
…related methods to make it easier to understand the intent of the indexing
Co-authored-by: samuelpmishLLNL <61714427+samuelpmishLLNL@users.noreply.github.com>
Co-authored-by: samuelpmishLLNL <61714427+samuelpmishLLNL@users.noreply.github.com>
Co-authored-by: samuelpmishLLNL <61714427+samuelpmishLLNL@users.noreply.github.com>
|
@samuelpmishLLNL @samuelpmishLLNL , any open issues in this PR? |
|
I think it looks good, approving now |
joshessman-llnl
left a comment
There was a problem hiding this comment.
Just some minor style comments; otherwise, looks good to me!
Co-authored-by: Josh Essman <68349992+joshessman-llnl@users.noreply.github.com>
Co-authored-by: Josh Essman <68349992+joshessman-llnl@users.noreply.github.com>
Co-authored-by: Josh Essman <68349992+joshessman-llnl@users.noreply.github.com>
This PR adds a
gradient_matrix_kernelto functional which will compute the element tangent entries of the residual in the form of a continuous vectorK_eof size (test_ndof * test_dim * trial_ndof * trial_dim * num_elem). It should work for H1, Hcurl, and L2 spaces. However L2 is not tested specifically in this PR.Afterwards an
serac::mfem_ext::AssembledSparseMatrixis constructed. This holds the mapping fromK_eto a rank-local assembled CSR-matrix. CallingAssembledSparseMatrix.FillData(K_e)will maintain the same sparsity pattern but change matrix entries.AssembledSparseMatrixis derived frommfem::SparseMatrix; howeverFillData()andParallelAssemble()methods were added.Note:
Currently
AssembledSparseMatrixuses some "forbidden C++ calls" to get at protected information inmfem::ElementRestriction. Ideally this information would bepublicin mfem. Additionally there is an mfem issue with L2 when using LEXICOGRAPHIC ordering which a follow-up PR will try to address. ForNATIVEordering, see this branch for a working H1-L2 matrix assembly.TODO: