Add the DuMux adapter and Micro-Manager into the system tests workflows

[MakisH]

Integrates the DuMux adapter tests into the regular system tests:

• Adds the two-scale-heat-conduction case to the release_test suite
• Adds the respective DuMux adapter variables to the nightly and PR workflows

Follow-up of #696 and #737.

The system tests run on this PR used the tests.yml from the develop branch. Here is another run that takes the tests.yml from this branch as well.

Further runs:

• https://github.com/precice/tutorials/actions/runs/23764549879
• https://github.com/precice/tutorials/actions/runs/23764701005
• https://github.com/precice/tutorials/actions/runs/23784037711/job/69302950180

[IshaanDesai]

We indeed need to set the Micro Manager version to develop. @Fujikawas, we had this at some point, right? Did we remove it?

[Fujikawas]

We indeed need to set the Micro Manager version to develop. @Fujikawas, we had this at some point, right? Did we remove it?

We have MICRO_MANAGER_VERSION instead of MICRO_MANAGER_REF (I'm not quite sure of the scope of the naming rules for these two).
In #737, I added the variable MICRO_MANAGER_PR to the Dockerfile. I thought this MM_PR would represent the latest status for testing when we want to use something newer than MM_VERSION, so I didn't add MM_REF.

[MakisH]

The (partially undocumented) intention of these variables is generally the following:

• _REF: The git reference to checkout
• _PR: A GitHub PR to fetch, which contains the _REF to checkout
• _VERSION: A dependency version (fixed)

Since the Micro-Manager is a stage in the Dockerfile, and it is built from its repository, I would rename the MICRO_MANAGER_VERSION to MICRO_MANAGER_REF in this PR.

I will also add this to the documentation.

[MakisH]

@Fujikawas any idea why this run failed with both DuMux cases having issues building DuMux?

Sample log: system-tests_macro-dumux.log

[IshaanDesai]

Seems like the incorrect adapter version got used again.

[MakisH]

Ah, I see, I thought that using the default components in that job run would have been enough.

In another run with the latest components, the free-flow-over-porous-media worked, while the two-scale-heat-conduction failed at the numerical comparisons step, but I think that all of the absolute differences are too small to consider these relative differences valid: stdout.log

Until we find a better solution for #393, I suggest that we exclude this test from the release_test suite.

We could also add it again after adding an override option to run the tests but not compare results (partially related to #404).

[MakisH]

Are we fine with this for now? See explanation in #758 (comment)

Without this test in the release_test suite, the Micro-Manager will not be covered by any nightly test. I would still keep it in the dumux_test so that it is triggered in dumux-adapter PRs.

[MakisH]

I also added a micro_manager_test test suite in 6af9ebd, which will be the target of a system tests workflow in the Micro-Manager repository.

[IshaanDesai]

Is there a place I can see the relative measure of comparison or something similar? I want to find out how small too small is, and why the comparison now fails.

[MakisH]

We don't have some single-number metric. I suggested that to fieldcompare, but this seemed to be complicated at the time.

Looking at the stdout.log, here are some examples:

field-compare-1  | Comparing '/runs/two-scale-heat-conduction_macro-dumux-micro-dumux_2026-03-31-085933/precice-exports/Macro-Mesh-Micro-Manager.dt2.vtk'
field-compare-1  |       and '/runs/two-scale-heat-conduction_macro-dumux-micro-dumux_2026-03-31-085933/reference-results-unpacked/macro-dumux_micro-dumux/Macro-Mesh-Micro-Manager.dt2.vtk'
field-compare-1  |   Reading '/runs/two-scale-heat-conduction_macro-dumux-micro-dumux_2026-03-31-085933/precice-exports/Macro-Mesh-Micro-Manager.dt2.vtk'
field-compare-1  |   Reading '/runs/two-scale-heat-conduction_macro-dumux-micro-dumux_2026-03-31-085933/reference-results-unpacked/macro-dumux_micro-dumux/Macro-Mesh-Micro-Manager.dt2.vtk'
field-compare-1  |    -- Comparing the field 'K00': FAILED
field-compare-1  |      -- Report: Deviation above tolerance detected -> [0.5141269880086446] vs. [0.5141186814702282] ([0.00] %)
field-compare-1  |      -- Predicate: DefaultEquality (abs_tol: 0., rel_tol: 3.e-07)
field-compare-1  |    -- Comparing the field 'K01': FAILED
field-compare-1  |      -- Report: Deviation above tolerance detected -> [-2.8569661945372316e-17] vs. [-3.152737885150525e-15] ([-10935.26] %)
field-compare-1  |      -- Predicate: DefaultEquality (abs_tol: 0., rel_tol: 3.e-07)
field-compare-1  |    -- Comparing the field 'K10': FAILED
field-compare-1  |      -- Report: Deviation above tolerance detected -> [1.0382603233439358e-15] vs. [-1.382181217583312e-15] ([233.12] %)
field-compare-1  |      -- Predicate: DefaultEquality (abs_tol: 0., rel_tol: 3.e-07)

This means that, at dt2:

• K00 differed at the 5th decimal (smaller than the printed 0.00%)
• K01 values are extremely close to zero (e-15/e-17)
• K10 the same (e-15)

The relative difference is in parentheses, but it is rather useless.

We could also already experiment with an absolute tolerance computed based on the maximum, see #393 (comment)

[MakisH]

@IshaanDesai Actually, could this result (again in dt2) show that something in the functionality has recently changed?

field-compare-1  |    -- Comparing the field 'Active-Steps': FAILED
field-compare-1  |      -- Report: Deviation above tolerance detected -> [1.] vs. [0.] ([100.00] %)
field-compare-1  |      -- Predicate: DefaultEquality (abs_tol: 0., rel_tol: 3.e-07)

[IshaanDesai]

The data K01 and K10 are expected to be close to zero, but the difference in K00 concerns me, as it suggests the result of the two-scale problem has changed. This is probably because of the change in Active-Steps, which should ideally not change at all. All these differences point to the Micro Manager. Let me check the latest changes and try to find potential culprits.

[MakisH]

@IshaanDesai ready for review, you can use this output (without the two-scale-heat-conduction, which I removed in de856c5) for comparison.

[IshaanDesai]

I do not fully understand all the changes, but I see they are consistent.

[IshaanDesai]

The failure in the comparison of the run results to the reference results is expected. I will handle this in a separate PR. Lets merge this.