Add back +mfem to intel spec

[bmhan12]

This PR:

• Adds mfem back to intel spec, applying fix suggestion from: Compiler error with intel-oneapi-compilers@2025.2.0 mfem/mfem#5250
  • Closes Re-enable +mfem for intel@2025.02.0 compiler #1677
• Adds -fp-model=precise flag to address correctness issue (notably this unit test):

  axom/src/axom/core/tests/numerics_determinants.hpp

  Line 200 in be2a0b4

  TEST(numerics_determinants, determinant_fma_reduces_ulp_for_cancellation)

[bmhan12]

Relaxes tolerance for intel:

axom/src/axom/primal/tests/primal_integral.cpp:647: Failure
The difference between axom_rule.weight(j) and mfem_rule.IntPoint(j).weight is 2.3001349089279977e-16, which exceeds axom::numeric_limits<double>::epsilon(), where
axom_rule.weight(j) evaluates to 0.00016824607436628127,
mfem_rule.IntPoint(j).weight evaluates to 0.00016824607436651128, and
axom::numeric_limits<double>::epsilon() evaluates to 2.2204460492503131e-16.

[kennyweiss]

Thanks @bmhan12 -- I have a similar fix in one of my PRs for other compilers with -march=native

Essentially:

+  // MFEM and Axom both generate Gauss-Legendre rules, but in builds that enable
+ // `-march=native` we can see ULP-level differences in the computed nodes/weights
+  // even though the rules are equivalent for integration purposes.
+ const double fp_tol = 8 * axom::numeric_limits<double>::epsilon();
- const double fp_tol = axom::numeric_limits<double>::epsilon();

See: https://github.com/llnl/axom/pull/1827/changes#diff-15ab7dd082a03dde95f0da64662e222a6ab7fa156756a3f1fc5752f2cf4dff8aR763-R766

[kennyweiss]

Thanks @bmhan12 !

[kennyweiss]

Thanks @bmhan12 -- can you please explain the double percent and repeat intel_25 at the end of this line?
%%intel_25 ... %intel_25

Presumably, something to do w/ compiler mixing (?)

[bmhan12]

Presumably, something to do w/ compiler mixing (?)

Yes, to give spack a stronger suggestion/preference to use the same compilers:
Documentation: https://spack.readthedocs.io/en/latest/spec_syntax.html#dependency-propagation
Original Issue Description: spack/spack#49696

You can also apparently do this for variants as well:
https://spack.readthedocs.io/en/latest/spec_syntax.html#variant-propagation-to-dependencies

[kennyweiss]

Thanks @bmhan12 -- I have a similar fix in one of my PRs for other compilers with -march=native

Essentially:

+  // MFEM and Axom both generate Gauss-Legendre rules, but in builds that enable
+ // `-march=native` we can see ULP-level differences in the computed nodes/weights
+  // even though the rules are equivalent for integration purposes.
+ const double fp_tol = 8 * axom::numeric_limits<double>::epsilon();
- const double fp_tol = axom::numeric_limits<double>::epsilon();

See: https://github.com/llnl/axom/pull/1827/changes#diff-15ab7dd082a03dde95f0da64662e222a6ab7fa156756a3f1fc5752f2cf4dff8aR763-R766