Compile-time GLL quadrature.#1891
Conversation
lsawade
left a comment
There was a problem hiding this comment.
Was working with compiler explorer to analyze what's happening and it found some things that could improve loading.
| * @brief Populates poly.roots using the algo described in | ||
| * polynomial_zeros.ipynb |
There was a problem hiding this comment.
Those were my notes for rootfind when I initially wrote the code way back when.
|
|
||
| using numerical_type = Nodes::numerical_type; | ||
| static constexpr std::size_t N = Nodes::N; | ||
|
|
There was a problem hiding this comment.
| private: | |
| static constexpr auto coeff_table = | |
| impl::make_lagrange_coeff_table(Nodes::get_nodes()); | |
| struct Nodes { | ||
| private: | ||
| using initializer_node_type = decltype(NodeInitializer::get_nodes()); | ||
|
|
There was a problem hiding this comment.
| private: | |
| static constexpr auto nodes = NodeInitializer::get_nodes(); | |
There was a problem hiding this comment.
constexpr does not guarantee compile-time evaluation. Since NodeInitializer could be anything, I purposefully wrapped NodeInitializer::get_nodes() with a consteval function in case consteval was forgotten.
There was a problem hiding this comment.
I had set a private constexpr auto nodes = Nodes::get_nodes();, though, but I ended up removing that (elaborated in the comment about the nvcc issue below).
I re-added it since I found a bypass, so if this suggestion was based on a missing static constexpr variable, consider the suggestion followed. If this was a suggestion to remove the consteval Nodes::get_nodes(), I want to push back, due to the aforementioned behavior of constexpr.
| */ | ||
| static constexpr KOKKOS_INLINE_FUNCTION numerical_type | ||
| node(const int &node_index) { | ||
| return get_nodes()[node_index]; |
There was a problem hiding this comment.
| return get_nodes()[node_index]; | |
| return nodes[node_index]; |
There was a problem hiding this comment.
nvcc:
error: identifier "specfem::quadrature::compiletime::Lagrange< ::specfem::quadrature::compiletime::gll_initializer<(int)5, float> > ::Nodes::nodes" is undefined in device code
for some reason, declaring the constexpr nodes variable inside the KOKKOS_INLINE_FUNCTION does work, though.
There was a problem hiding this comment.
This was the fix I ended up with:
static constexpr KOKKOS_INLINE_FUNCTION numerical_type
node(const int &node_index) {
constexpr auto nodes_ = nodes;
// so for some reason this works, while directly referencing nodes has
// nvcc crying
return nodes_[node_index];
}It's a little hacky, but my nvcc is okay with it.
| static consteval Kokkos::Array<numerical_type, N> get_nodes() { | ||
| return NodeInitializer::get_nodes(); |
There was a problem hiding this comment.
| static consteval Kokkos::Array<numerical_type, N> get_nodes() { | |
| return NodeInitializer::get_nodes(); |
There was a problem hiding this comment.
see above comment, quote-copied here for reference:
constexprdoes not guarantee compile-time evaluation. SinceNodeInitializercould be anything, I purposefully wrappedNodeInitializer::get_nodes()with aconstevalfunction in caseconstevalwas forgotten.
I'm taking the care to ensure consteval, since (to my understanding) the C++20 standard requires compile-time evaluation
consteval- specifies that a function is an immediate function, that is, every call to the function must produce a compile-time constant
while (from my conversations with Rohit) constexpr does not have such an explicit requirement.
| } | ||
| KOKKOS_INLINE_FUNCTION numerical_type | ||
| operator()(const int &node_index) const { | ||
| return node(node_index); |
There was a problem hiding this comment.
| return node(node_index); | |
| return nodes[node_index]; |
There was a problem hiding this comment.
See comment on Nodes::node(const int&), quote-copied here for reference:
This was the fix I ended up with:
static constexpr KOKKOS_INLINE_FUNCTION numerical_type node(const int &node_index) { constexpr auto nodes_ = nodes; // so for some reason this works, while directly referencing nodes has // nvcc crying return nodes_[node_index]; }It's a little hacky, but my
nvccis okay with it.
Rohit-Kakodkar
left a comment
There was a problem hiding this comment.
Can we just hard code the polynomials for degree 5 and 8? I think it would make this implementation a lot simpler and easier to maintain. Thoughts @lsawade
|
While the legendre rootfinding is more elegant in the mathematical sense, I agree with @Rohit-Kakodkar that it would be much simpler to just take NGLL 5-12 and hardcode the GLL points instead for this. This is what I originally had commented as well: #1879 It would drastically reduce code complexity and these roots are not changing. |
Description
Please describe the changes/features in this pull request.
Issue Number
If there is an issue created for these changes, link it here
Checklist
Please make sure to check developer documentation on specfem docs.