Update documentation for "CO2 Plume Evolution and Leakage Through an Abandoned Well"

[beckyggbbh]

volumetric flow rate

Hello, guys. Can someone document the formula used to obtain the volumetric flow rate? When reviewing example "CO2 Plume Evolution and Leakage Through an Abandoned Well," I notice that to obtain the flow rate graphically, they divide "PHASEOUTFLUX" by 10000 (TIMESTEP). I don't understand this division; I thought the flow rate already came out in m³/s but Im not sure now.

This would help the user guide. Thanks!

[klevzoff]

Hi @beckyggbbh,

The phase fluxes computed and stored internally in GEOS are integral over a time step, so they are in units of volume (m³). The computation takes place here, you can see there is a dt multiplier. I agree there could be additional comments in the script clarifying the unit conversions that take place.

[beckyggbbh]

Thanks @klevzoff, It would be great that when updating the examples, you also update the Matplotlib code to avoid incorrect results. In the case I mentioned, currently, the XML file configures a timestep of 1E7, and for plotting, it divides the flow by 1e4. Greetings and thank you very much!

[paveltomin]

I suggest we keep this issue open since there is clearly desynchronization between description and input file in the repo. My expectation from a user point of view - examples from docs run as described.

[paveltomin]

Hi @beckyggbbh,

The phase fluxes computed and stored internally in GEOS are integral over a time step, so they are in units of volume (m³). The computation takes place here, you can see there is a dt multiplier. I agree there could be additional comments in the script clarifying the unit conversions that take place.

just realized: dt is current time step in that compute? how can one ensure it is constant during the simulation???

[klevzoff]

just realized: dt is current time step in that compute? how can one ensure it is constant during the simulation???

In that input file the time step is manually set to 1e5 instead of relying on solver heuristics, so barring any time step cuts (which empirically don't happen in this case) it's ok.

It would certainly be more robust if the time intervals were picked from the hdf file. IIUC the problem there is collection and history output tasks are performed at different intervals than time steps, but every time they execute they only capture the cumulative flux over the most recent time step, so it's not easy to associate it with correct time intervals.

Alternatively, we could compute and store fluxes per unit time instead of integral. I believe those fluxes were introduced for the purpose of CFL number computation, not sure if it would be trivial to hoist the dt factor out.

[paveltomin]

maxEventDt is max time step, forced time step is forceDt, no? it's probably ok specifically for this example to hand-configure once it into a specific configuration to reproduce the published results, but one should not rely on that output in general case