Regression tester regressed e23583

[tamiko]

[start automated regression testsuite report]

Dear all,

this is the automated regression testsuite reporting a new regression between

• new revision: e235839 regression testsuite results
• old revision: 8849960 regression testsuite results

Summary:

• 😠 new test failures introduced for configuration GNU-11.4.0-master-avx512-lts-22.04 on site tester-tng

I have identified the following pull requests as possible candidates:

• Augment documentation of Utilities::type_to_string(). #16841 (authored-by: @bangerth; merged-by: @kronbichler)
• Provide an implementation for VectorizedArray::dot_product(). #16837 (authored-by: @bangerth; merged-by: @kronbichler)
• Fix naming of output files. #16832 (authored-by: @bangerth; merged-by: @kronbichler)

Notes:

• The regression reported above is a subset of the following full set of regressions compared to the baseline:
  • 😠 test failures for configuration GNU-11.4.0-master-avx256-lts-22.04 on site tester-tng
  • 😠 test failures for configuration GNU-11.4.0-master-avx512-lts-22.04 on site tester-tng
  • 😠 test failures for configuration GNU-13.2.0-master-debian-13 on site tester-tng
• I will close and unpin this issue automatically once a full run is complete and compares cleanly to the baseline.
• If closed I will reopen the issue if the testsuite run identified an additional regression compared to what I have reported so far.

[end automated regression testsuite report]

[bangerth]

This is:

--------------------------------------------------------
An error occurred in line <75> of file </scratch/users/testsuite/testsuite-Exjc50B8/dealii/tests/fe/fe_values_view_07.cc> in function
    void test(const dealii::Triangulation<dim, dim>&, const dealii::FiniteElement<dim>&) [with int dim = 3]
The violated condition was: 
    (scalar_values[q] - vector_values[q][c]).norm() <= 1e-12 * scalar_values[q].norm()
Additional information: 
    This exception -- which is used in many places in the library --
    usually indicates that some condition which the author of the code
    thought must be satisfied at a certain point in an algorithm, is not
    fulfilled. An example would be that the first part of an algorithm
    sorts elements of an array in ascending order, and a second part of
    the algorithm later encounters an element that is not larger than the
    previous one.
    
    There is usually not very much you can do if you encounter such an
    exception since it indicates an error in deal.II, not in your own
    program. Try to come up with the smallest possible program that still
    demonstrates the error and contact the deal.II mailing lists with it
    to obtain help.

I think we talked about that at some other point in time already.

[tamiko]

@bangerth Yup. Depending on moon cycle some instruction gets reordered and we trigger this thing. I unfortunately didn't find the time to submit a patch for this today.

So if someone beats me to it: I suggest to replace the Assert(A <= 1.e-12 * B, ...) logic with Assert(A <= 1.e-14 || A <= 1.e-12 * B, ...).