Template usage in kernel_dispatch.hpp is difficult to interpret (for SWIG)? #4530
Comments
|
That part of the code uses some kind of complicated templates and macros. Is it possible to simply skip that file when running SWIG? It's not really user-facing, so we don't actually need to generate any Python bindings for this. |
|
I already tried to skip it by %ignore directive in SWIG, but it does not work, probably because this line does not make sense at all for SWIG. While we don't need to expose it in Python binding, SWIG need to know the MFEM_REGISTER_KERNELS macro, which is defined above in the same file, in order to interpret bilininteg.hpp and quadinterpolator.hpp. I will try bit more to find a work-around. |
|
I think I was able to fix the original issue. Then, I am facing another build issue on MacOS. |
|
What compiler (and version) are you using? It's related to this. We can add a fix/workaround if needed. |
|
@pazner, Thank you for prompt response. The compiler is from Apple default. (/usr/bin/c++), and --version spits out Typical compiler command line generated by CMAKE is as follows Thank you in advance. The MacOS version is bit old (Monterey) due to some reason. I hope this is not the problem. |
|
Actually I think the problem has to do with the version of the standard library rather than the compiler version:
Are you for some reason using an old version of the standard library? This was fixed in libstdc++ (gcc's standard library) in version 6.1.0 and libc++ (clang's standard library) in version 4 (both in 2013). |
|
@panzer, thank you for your advise. After a lot of trial and error, I found that I need to set -std=c++14, instead of c++11. Following is an example of compiler call, which works for me. Note that -std=c++14 is added before -std=c++11 is specified. The first one is enforced using -DCMAKE_CXX_FLAGS flag when calling CMAKE. There is still -std=c++11 remained, perhaps coming from MFEM's CMAKE default setting? |
|
Hi @sshiraiwa, The problem you were running into is caused by the compiler flag: This is sets the "system root directory", which will cause the compiler to use the C++ standard library found at Note that this is not exactly a C++14 vs. C++11 issue — it's not about the language per se, but rather about the implementation of the standard library. This should work with a C++11 compiler, as long as the standard library supports hashing enums. |
|
Hi @pazner I think we can close this since there is work around and the root cause of issue is identified. |
|
There shouldn't be any issue setting -std=c++14 (or any standard newer than C++11), but just FYI that fix doesn't work for me. Are you running on an older version of Mac OS? BTW, this is the workaround I mentioned earlier. Does it also fix the issue for you? I'm hesitant to recommend merging this because the same code will need to be added for any enum used in the kernel dispatch and it's really just a workaround for pretty old versions of the standard library, once we move to C++17 (hopefully soon!) it should be irrelevant. diff --git a/fem/fespace.hpp b/fem/fespace.hpp
index 7edb9e640..b8a006964 100644
--- a/fem/fespace.hpp
+++ b/fem/fespace.hpp
@@ -47,6 +47,10 @@ public:
static void DofsToVDofs(int ndofs, int vdim, Array<int> &dofs);
};
+// Note: std::hash is specialized for QVectorLayout below (outside the mfem
+// namespace). This is a workaround for a defect in older versions of the
+// standard library. Hashing is needed for kernel dispatch.
+
/// @brief Type describing possible layouts for Q-vectors.
/// @sa QuadratureInterpolator and FaceQuadratureInterpolator.
enum class QVectorLayout
@@ -1385,6 +1389,15 @@ inline bool UsesTensorBasis(const FiniteElementSpace& fes)
/// elements, otherwise, return NATIVE.
ElementDofOrdering GetEVectorOrdering(const FiniteElementSpace& fes);
-}
+} // namespace mfem
+
+template <> struct std::hash<mfem::QVectorLayout>
+{
+ size_t operator()(const mfem::QVectorLayout &x) const
+ {
+ return std::hash<int>()(static_cast<int>(x));
+ // Could also just do: return static_cast<size_t>(x);
+ }
+};
#endif |
|
Thank you. As I wrote earlier, the MacOS version is bit old (Monterey=2022) due to some reason. I was hoping this is not the problem, but it seems this is a part of problem. |
|
Thanks @sshiraiwa. Closing for now. Please re-open if it continues to be an issue. |
I am opening this message here to get help from C++ experts.
With recent MFEM master, I am having a problem of running SWIG to generate PyMFEM.
It somehow crashes. Looking into the root cause, it appears that SWIG have a difficulty tin understanding how template is used in kernel_dispatch.hpp.
When I give this header file to SWIG separately, it spits out the following error message
/home/sshiraiw/venvs/env20220809/lib/python3.9/site-packages/mfem/external/ser/include/mfem/fem/kernel_dispatch.hpp:128: Error: Template partial specialization has more arguments than primary template 4 1.
Can someone tell what is going on? Is this an issue which has to be fixed in SWIG?
The text was updated successfully, but these errors were encountered: