Rounding errors in the StepsizeCallback on Windows machines

[bennibolm]

Currently, we get slightly different results in simulations with StructuredMesh and P4estMesh on Windows machines as for Linux. Example: Elixir structured_2d_dgsem/elixir_euler_source_terms.jl yields the following errors

Win: (l2 = [9.321181254838921e-7, 1.4181210744350037e-6, 1.4181210743541553e-6, 4.824553091330434e-6], linf = [9.577246538050588e-6, 1.17075259897792e-5, 1.1707525990667378e-5, 4.886961560135461e-5])
Lin: (l2 = [9.321181253839765e-7, 1.4181210743825254e-6, 1.4181210743462775e-6, 4.824553091292202e-6], linf = [9.577246538938766e-6, 1.1707525993776002e-5, 1.1707525987336709e-5, 4.8869615597801896e-5])

The differences are within floating point accuracy

julia> win.l2 - lin.l2
4-element Vector{Float64}:
 9.991558294164364e-17
 5.2478349763613805e-17
 7.87782992593862e-18
 3.82316791072701e-17

julia> win.linf - lin.linf
4-element Vector{Float64}:
 -8.881784197001252e-16
 -3.9968028886505635e-15
  3.3306690738754696e-15
  3.552713678800501e-15

So, the current tests do not fail on Windows. Note: In some examples, the errors can add up and result in failing tests.

The differences seem to occur in the StepsizeCallback. Simulations with disabled StepsizeCallback and fixed time step get identical errors. This also explains why TreeMesh is not affected, which uses its own routine.

Some Windows' weirdness seems to be the reason.

[ranocha]

Floating point differences are to be expected if you run something on different systems with possibly different instruction sets? You could check the specific CPU architecture you are using and tell Julia to compile code for the greatest common divisor to see whether that makes a difference.