Factor of molar_density missing in Alquimia wrapper for "mass_source"

[SaubhagyaGT]

There is a bug in the Alquimia wrapper when providing solute source through mass_source and geochemical condition. There is a factor of molar density of water missing. Attached picture contains the details. This factor is there in the boundary condition but not in mass_source.
@

[smolins]

Saubhagya,

I believe the qmass,source is in units of m/s. Can you point out where in the code you see this problem?
Thanks

Sergi

[ecoon]

Did this get solved?

[ecoon]

Ok, I think I see the confusion. If this is surface flow, we often use m/s as the mass source unit (e.g precipitation is typically recorded in m/s). But in the subsurface we assume that the mass source is in units of mol/m^3/s. And more generally, because our mass flow equation conserves mols of water, we require sources in mol/(volume unit)/s. So it is somewhat of an accident that this works as is for surface water.

I think I agree with Saubhagya here that we're missing a factor of 1/density, at least by default, and the user should have to tell us if they want to give a mass source in m/s.

[smolins]

I see what you are saying but in the test I have been working on https://github.com/amanzi/ats-regression-tests/blob/smolins/more-react-trans/07_reactive_transport/reactive_transport-column_infiltration_alquimia_tracer.xml This test builds on 06_transport/transport-column_infiltration.xml but it uses a "geochemical condition" The surface source works as it should. That is, a concentration of 5.55 mol/L is added to the surface cell (or in mol fraction: 0.1 mol-solute/mol-H2O.) The mass source is in m/s (2e-8 m/s) or so I thought, given that it is the same as for the 06_transport test noted above. The results show that the concentration goes to 0.1 mol-solute/mol-H2O as expected. So it may be that the potential error caused by the bug cancels out somehow, the accident you note, I guess.

…

On Tue, Feb 23, 2021 at 6:17 PM Ethan Coon ***@***.***> wrote: Ok, I think I see the confusion. If this is surface flow, we often use m/s as the mass source unit (e.g precipitation is typically recorded in m/s). But in the subsurface we assume that the mass source is in units of mol/m^3/s. And more generally, because our mass flow equation conserves mols of water, we require sources in mol/(volume unit)/s. So it is somewhat of an accident that this works as is for surface water. I think I agree with Saubhagya here that we're missing a factor of 1/density, at least by default, and the user should have to tell us if they want to give a mass source in m/s. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADXOTGR6B25FWTPCT6ZGZ6LTAROSFANCNFSM4VF5IO2Q> .

[saubhagya-gatech]

Once this issue is closed and changed are merged in the master, the input file for one of the sorption regression test need to be updated. Value of molar density of water need to be changed from 1 to 55500.
https://github.com/saubhagya-gatech/ats-regression-tests/blob/7bd34016dbb8e00432427ccad358b0a26f1bc90c/07_reactive_transport/reactive_transport-subsurface_sorption_logical.xml#L402

[ecoon]

Note this test has now been merged into ats-regression-tests master, so we'll have to update the test when @dasvyat rt-fixes branch pull request comes in.

[ecoon]

@smolins Sergi, I just wanted to point out that this is now closed for real, which likely breaks your test. For surface flow and coupled reactive transport, the "water source in meters" must be set to false, and the units of the water source must be in [mol m^-2 s^-1]. I recognize that this may be a bit annoying, but it is the natural unit of the source (as every other PDE is defined this way). If I can, I will try to find a way to have the MPC check for this option, and ensure it is correctly set in the flow PK.

I now believe that setting "water source in meters" to default to true was a mistake, and hopefully will likely change that default to false soon. It is a bit hard to change defaults though, because it is hard to catch input files that depended upon it...

The easiest way to fix your test would be to simply create an evaluator, e.g.:

   <ParameterList name="water_source" type="ParameterList">
     <Parameter name="field evaluator type" type="string" value="multiplicative evaluator" />
     <Parameter name="evaluator dependencies" type="Array(string)" value="{surface-precipitation_rain, surface-molar_density_liquid}" />
   </ParameterList>

Or something similar that multiples your current source (in m/s) times the density (mol / m^3) to get the right units (mol / m^2 / s).

[ecoon]

Ok, maybe I'm backtracking on this and will add a matching option to transport "water source in meters". This thing must however default to false (because it makes no sense in the subsurface case, it cannot be true there). So if you're doing surface transport, you can set this to true manually, which matches the default in flow.

[smolins]

Thanks Ethan. This clarifies it. I updated the test accordingly. Sergi

…

On Thu, May 6, 2021 at 1:47 PM Ethan Coon ***@***.***> wrote: Ok, maybe I'm backtracking on this and will add a matching option to transport "water source in meters". This thing *must* however default to false (because it makes no sense in the subsurface case, it cannot be true there). So if you're doing surface transport, you can set this to true manually, which matches the default in flow. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADXOTGVNMAJJUNYGJ6U3K73TML56TANCNFSM4VF5IO2Q> .