libMesh
C++ / petsc issue
CXX src/base/libmesh_opt_la-dirichlet_boundary.lo
In file included from ./include/libmesh/fe_base.h(26),
from ./include/libmesh/fem_context.h(27),
from ./include/libmesh/fem_function_base.h(26),
from ./include/libmesh/composite_fem_function.h(23),
from /admin/build/admin/rpms/stampede2/BUILD/libmesh-1.6.0/src/base/dirichlet_boundary.C(25):
./include/libmesh/fe_abstract.h(443): error: more than one operator "+" matches these operands:
built-in operator "arithmetic + arithmetic"
function "operator+(const PetscInt={int} &, const PetscComplex &)"
operand types are: const libMesh::OrderWrapper + const unsigned int
Order get_order() const { return static_cast<Order>(fe_type.order + _p_level); }
^
This is with the Intel 18 compiler and petsc 3.14. Let me know what log files you want.
This issue was discussed a bit in #2565, apparently with regard to Intel 19 and 20 rather than Intel 18. From what I can tell (and based on this comment, I don't think a suitable resolution was ever found unfortunately.
I don't understand why the compiler considers the line of code in question to be ambiguous... in my opinion, nothing should be getting confused with PetscComplex here, we are basically adding two integers together...
Leaving petsc out leads to other but similar confusions:
/admin/build/admin/rpms/stampede2/BUILD/libmesh-1.6.0/contrib/metaphysicl/src/core/include/metaphysicl/compare_types.h(220): error: more than one partial specialization matches the template argument list of class "MetaPhysicL::MinusType<MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double}, libMesh::dof_id_type={uint32_t={unsigned int}}>, MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double}, libMesh::dof_id_type={uint32_t={unsigned int}}>, false, void>"
"MetaPhysicL::MinusType<MetaPhysicL::DynamicSparseNumberArray<SubTypeArgs...>, MetaPhysicL::DynamicSparseNumberArray<SubTypeArgs...>, reverseorder, void>"
"MetaPhysicL::MinusType<MetaPhysicL::DynamicSparseNumberArray<SubTypeArgs...>, MetaPhysicL::DynamicSparseNumberArray<SubTypeArgs2...>, reverseorder, void>"
static const bool value = (sizeof(test<T>(0)) == sizeof(yes));
^
detected during:
instantiation of class "MetaPhysicL::DefinesSupertype<T> [with T=MetaPhysicL::MinusType<MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double}, libMesh::dof_id_type={uint32_t={unsigned int}}>, MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double}, libMesh::dof_id_type={uint32_t={unsigned int}}>, false, void>]" at line 2150 of "./include/libmesh/generic_projector.h"
instantiation of "void libMesh::GenericProjector<FFunctor, GFunctor, FValue, ProjectionAction>::ProjectVertices::operator()(const libMesh::GenericProjector<FFunctor, GFunctor, FValue, ProjectionAction>::node_range &) [with FFunctor=libMesh::OldSolutionCoefs<libMesh::Real={double}, &libMesh::FEMContext::point_value>, GFunctor=libMesh::OldSolutionCoefs<libMesh::RealGradient, &libMesh::FEMContext::point_gradient>, FValue=MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double},
libMesh::dof_id_type={uint32_t={unsigned int}}>, ProjectionAction=libMesh::MatrixFillAction<libMesh::Real={double}, libMesh::Number={libMesh::Real={double}}>]" at line 380 of "./include/libmesh/threads_pthread.h"
instantiation of "void libMesh::Threads::parallel_reduce(const Range &, Body &) [with Range=libMesh::StoredRange<__gnu_cxx::__normal_iterator<const std::pair<const libMesh::Node *, std::tuple<const libMesh::Elem *, unsigned short, std::set<libMesh::dof_id_type={uint32_t={unsigned int}}, std::less<libMesh::dof_id_type={uint32_t={unsigned int}}>, std::allocator<unsigned int>>>> *, std::vector<std::pair<const libMesh::Node *, std::tuple<const libMesh::Elem *, unsigned short,
std::set<libMesh::dof_id_type={uint32_t={unsigned int}}, std::less<libMesh::dof_id_type={uint32_t={unsigned int}}>, std::allocator<unsigned int>>>>, std::allocator<std::pair<const libMesh::Node *, std::tuple<const libMesh::Elem *, unsigned short, std::set<libMesh::dof_id_type={uint32_t={unsigned int}}, std::less<libMesh::dof_id_type={uint32_t={unsigned int}}>, std::allocator<unsigned int>>>>>>>, std::pair<const libMesh::Node *, std::tuple<const libMesh::Elem *, unsigned
short, std::set<libMesh::dof_id_type={uint32_t={unsigned int}}, std::less<libMesh::dof_id_type={uint32_t={unsigned int}}>, std::allocator<unsigned int>>>>>, Body=libMesh::GenericProjector<libMesh::OldSolutionCoefs<libMesh::Real={double}, &libMesh::FEMContext::point_value>, libMesh::OldSolutionCoefs<libMesh::RealGradient, &libMesh::FEMContext::point_gradient>, MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double}, libMesh::dof_id_type={uint32_t={unsigned int}}>,
libMesh::MatrixFillAction<libMesh::Real={double}, libMesh::Number={libMesh::Real={double}}>>::ProjectVertices]" at line 1207 of "./include/libmesh/generic_projector.h"
instantiation of "void libMesh::GenericProjector<FFunctor, GFunctor, FValue, ProjectionAction>::project(const libMesh::ConstElemRange &) [with FFunctor=libMesh::OldSolutionCoefs<libMesh::Real={double}, &libMesh::FEMContext::point_value>, GFunctor=libMesh::OldSolutionCoefs<libMesh::RealGradient, &libMesh::FEMContext::point_gradient>, FValue=MetaPhysicL::DynamicSparseNumberArray<libMesh::Real={double}, libMesh::dof_id_type={uint32_t={unsigned int}}>,
ProjectionAction=libMesh::MatrixFillAction<libMesh::Real={double}, libMesh::Number={libMesh::Real={double}}>]" at line 982 of "/admin/build/admin/rpms/stampede2/BUILD/libmesh-1.6.0/src/systems/system_projection.C"
OK, thanks for this additional information. In #2565, this comment, I believe it was determined that we can build with Intel-18 provided that libmesh is configured with --disable-metaphysicl.
That being said, I don't think libmesh-without-PETSc will be particularly useful to users of TACC systems...?
Well, minus metaphysicl / plus petsc still crashes on the same problem.
But hey, I just run a sed preprocessor stage over the source..... I understand that p_level and such is an enum? Can I safely static_cast it to unsigned int?
I'm not enough of a language lawyer to know if this cast should be done implicitly.
In the failing line of code above, FEAbstract::_p_level is an unsigned int, fe_type.order is of type OrderWrapper, which internally stores its value as int but provides implicit conversion-to-enum and conversion-to-int operators. My guess is that maybe
Order get_order() const { return static_cast<Order>(fe_type.order + static_cast<int>(_p_level)); }
would satisfy the compiler there, but hard to say for sure.
As to whether you could distill a fix like this into a sed script, I'm not sure... you may be much better at sed than I am. If some straightforward casts like this will get us compiling on Intel again, I think I'd be in favor of pushing them into upstream... just depends on how many there ends up being.
It's the .order thing that needs to be cast.
And I got the code to compile, but fixing all that stuff was not exactly elegant. Now let's hope it didn't break anything in subtle, undetectable ways. On the other hand, the fact that a static cast compiled gives me some faith. C++ is much better in not letting you do arbitrary casts.
OK, I'm glad you were able to get it working, and I agree that it's unlikely that anything was broken by the change. I assume that you were working from a 1.6.0 tar archive, but if it is possible for you to share the diff that you made I can try to get it merged into upstream.