Potential parallel bug with solute transport in v1.5.1?

[smolins]

I identified two issues with solute transport in ATS v1.5.1. These issues have been affecting reactive transport but I was able to narrow down to potential issues with transport. I cannot reproduce these issues in a 1D test simulation but it is still unclear to me why these appear only in higher dimensionality simulations. Also, it is unclear whether they are related or not.

The file attached is a transport version of the demo under ats-demos/13_integrated_hydro_reactive_transport/hillslope_calcite_crunch_sigmoid.xml, which is described in Molins et al 2022 WRR. Here it is modified to include only 1 tracer, with initial concentration in the domain = 1 and =0 in the rain water ( hillslope_transport_sigmoid_100s.xml)

hillslope_transport_sigmoid_100s.txt

The 2 issues are

1. parallel simulations result in concentration hotspots that repeat as many times as the number processors one is using. The plot for time = 1 day is presented for a 4 processor run. (parallel.png)

2. as the water table drops in the uphill portion of the domain from the initial position due to drainage in the bottom, the concentrations of the tracer increase above 1. That cannot be. At the same time concentrations of the tracer in the downhill portion of the domain decrease below zero, as that area's liquid saturation increases so that the initial water can exit through the surface . This is apparent as early as time = 3 days (concentration.png , note: this was obtained in a serial run to avoid mixing in the parallel issues) but gets worse as time advances.

There is another issue with concentrations that appears at time = 1 day near the left boundary. This issue is buried by issue 2 at time = 3 days. The position of the cell with an off concentration is suspiciously close to the position of the "hot" cells in the parallel runs.

[smolins]

I am adding a figure for the last point I raise above. It seems related to the issue raised in point 1 but parallel runs may make it more apparent.

[dasvyat]

One of the source of this bug is subcyling. With simple week coupling there is no overshoots (at least on 1 core). I'm looking into this issue

[smolins]

I looked a little more into this issue and have not been able to link it clearly to anything. However, I do see that the initial velocities show the same striped pattern from some sort of parallel issue. This pattern disappears right away with the Darcy velocities but then little by little appears in the concentrations.

Could any of you @levuvietphong or @dasvyat comment whether there could an issue that connected the initial velocities with the concentration hotspots showing up in the early transport.

This issue is not a big deal for transport as these differences are small and they are soon overwhelmed by larger concentration differences (like when a front arrives) but when coupled to geochemistry, this leads to problems. For example, it may change mineral or sorbed concentrations which remain like that for the rest of the simulation.

[dasvyat]

@smolins , I looked into this issues and for my surprise, it is not a transport issue, in my opinion. The discrepancies are coming directly from flow. I don't know what is the reason at the moment. I've increased nonlinear tolerance with the hope that it can help, but it didn't. I'm looking into this issue.

[ecoon]

Is it in velocities or in fluxes? I would be very surprised if it was in fluxes, but less surprised if it was in velocities/reconstruction, since we rarely look at those. I know that most of transport uses fluxes, but are you using a velocity-dependent dispersion?

[smolins]

These simulations do no include dispersion (i.e. dispersion not in the input file) and diffusion uses default values (0.0, I assume).

[ecoon]

Ok, then I'm not sure if transport uses velocity anywhere else.

I'm not sure of the magnitudes here -- is it possible that this is due to block preconditioners? Does this go away if you use e.g. Boomer AMG?

[dasvyat]

I withdraw my previous comment. My comparison was wrong