Issue with metaphysicl tests when running "make check"

[CBqk3762]

Hi,

I've been having problems with code dependent on libmesh (moose) which seem to trace back to libmesh itself. I have just reconfigured and run "make" successfully and attempted to run "make check", this fails when it gets to using the file "metaphysicl/test/nd_derivs_unit.C"

The errors are all similar:

In file included from ../../../../contrib/metaphysicl/test/nd_derivs_unit.C(5):
../../../../contrib/metaphysicl/test/math_structs.h(433): error: template argument list must match the parameter list
  metaphysicl_const_return_def(operator(), VectorValue<double>)
  ^

Though the specific error varies, sometimes error: a type qualifier is not allowed on a nonmember function metaphysicl_const_return_def(operator(), VectorValue<double>) , sometimes, error: "this" may only be used inside a nonstatic member function metaphysicl_const_return_def(operator(), VectorValue<double>) Which seems like errors within the file/test rather than my libmesh build? I am unsure.

Before I began building I sourced the profile I use for Moose to set compilers etc:

module purge
module load rhel8/default-icl python/3.11.0-icl gcc
export CC=mpicc
export CXX=mpicxx
export F90=mpif90
export F77=mpif77
export FC=mpif90
export MOOSE_DIR=/home/ir-byer1/rds/rds-ukaea-ap002-mOlK9qn0PlQ/ir-byer1/moose-dev-gcc-thm/moose
unset I_MPI_PMI_LIBRARY

And I ran configure with flags for VTK as follows

../configure --with-vtk-include=/home/ir-byer1/rds/rds-ukaea-ap002-mOlK9qn0PlQ/ir-byer1/moose-dev-gcc-thm/vtk/include --with-vtk-lib=/home/ir-byer1/rds/rds-ukaea-ap002-mOlK9qn0PlQ/ir-byer1/moose-dev-gcc-thm/vtk/lib64

Do you have any thoughts on what might be happening? I've attached a file showing all the errors

libmesh_check_errs.txt

[roystgnr]

What's your underlying compiler version?

Pinging @lindsayad since he wrote the macros triggering the failures, but it looks to me as if your compiler is complaining about seeing this inside decltype in a trailing return type? But that would make no sense - the whole point of a trailing return type is to allow function arguments (including the implicit this for non-static member functions) to be in scope. If that's the problem then we might be able to work around it by switching to an auto return type, but I wouldn't want to trust a compiler that required the workaround.

[lindsayad]

What is icl? I sense Intel compiler. The MOOSE team has had horrible luck with Intel compilers over the years to the point that we (MOOSE team) stopped trying to support them about five years ago

[CBqk3762]

I'm using intel oneAPI compilers from 2021 and Make v4.2.1 on a rhel8 cluster, these are just the defaults. I'll try changing these thanks!

Could I also check what the latest version of VTK that libmesh compiles with is?

[lindsayad]

I've compiled libmesh with vtk 9.3. That's my only data point. Maybe @roystgnr can say more

[roystgnr]

You're ahead of me - at a quick glance I've been testing against 9.2.6 and 9.3.0rc1.