Cover different conduction methods in div_par_k_grad_par_mod tests

[ZedThree]

Hopefully will help narrow down #3500

[ZedThree]

Wait... @dschwoerer these tests are only run for FCI, right? so the different methods aren't used here and this was a bit pointless. But we should probably also have these tests for non-FCI

[dschwoerer]

Good spot. That means its only failing the first time. And here is a bug: <https://github.com/boutproject/BOUT-dev/blob/8177bdb76d9e90b245f87f78965f88080ead92c9/src/mesh/coordinates.cxx#L1132> We emplace an empty field. We must first fill it, and then emplace. Then it is not racy anymore.

…

On 8 October 2026 5:45:01 pm GMT+01:00, Peter Hill ***@***.***> wrote: ZedThree left a comment (boutproject/BOUT-dev#3509) Wait... @dschwoerer these tests are only run for FCI, right? so the different methods aren't used here and this was a bit pointless. But we should probably also have these tests for non-FCI -- Reply to this email directly or view it on GitHub: #3509 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[ZedThree]

I'm not sure I follow. We fill the emplaced field before we use it. Where's the race? I must be missing something because I can't see how it would make a difference either way.

Did you also mean to point to cell_area_x* -- that's not used in this derivative. In compute_cell_area_y, we do fill then emplace, so I'm not sure that can be the explanation.

[dschwoerer]

Indeed, I do not see how that should cause that.

https://github.com/boutproject/BOUT-dev/tree/refs/heads/openmp-race-emplace still fixes some race conditions that should be fixed, even if it is not the cause of #3500

The field aligned version of ylow / yhigh had a race conditions, but that should not affect the FCI tests, so still not sure what is going on.