[RomApp] Fix race condition on ROM simulations

[Rbravo555]

📝 Description

Fixes #14579

Running the same ROM simulation several times with more than one OpenMP thread gave results that differed at round-off level (~1e-15 relative L2, ~1e-12 absolute). The first differing time step changed randomly between runs. Single-thread runs were bit-identical.

Cause: in Build, the elements loop was declared #pragma omp for schedule(guided, 512) nowait. Because of nowait, threads that ran out of element chunks started the conditions loop straight away. Condition and element contributions were then added to the same A/b entries (the boundary nodes) at the same time. AtomicAdd makes each addition safe but doesn't fix the order of the additions, so the last bits of the assembled system changed from run to run. The Galerkin projection Φᵀ A Φ spreads that into every reduced entry, and the nonlinear iterations carry it forward.

Fix: remove nowait from the elements loop, so elements are fully assembled before conditions start. The cost is one implicit barrier per Build.

Before change:

After change:

🆕 Changelog

• Fixed non-deterministic multi-threaded assembly in the ROM builder-and-solvers by removing nowait from the elements loop in Build ([RomApp] Consistency on ConvectionDiffusion ROMs #14579):
  • GlobalROMBuilderAndSolver
  • LeastSquaresPetrovGalerkinROMBuilderAndSolver
  • AnnPromGlobalROMBuilderAndSolver
  • AnnPromLeastSquaresPetrovGalerkinROMBuilderAndSolver

[Rbravo555]

not solving the issue in Windows. Investigating further