Comments (12)
It would usually be preferable to incorporate any changes to the spec as soon as possible so that we create the least confusion in the future. So the question is whether we want any of this part of the next release (v1.1?).
from ats.
Yes, I would like to have this settled before release. Those names have given us a ton of trouble trying to reverse engineer what they do.
from ats.
@saubhagya-gatech @ajkhattak Can you guys touch base with Sergi and agree on some names either by this ticket or by a quick meeting? Would be good to get these agreed upon and documented.
from ats.
To my understanding, in its current form, we have (as Sergi mentioned)
- concentration source has units: moles of solute/(m^2 * second)
- water mass has units: moles of water / (m^2 * second)
How about calling them:
- solute_source_rate (for standalone ats)
- water_source_rate (for geochemical)
If we assume, the name "source" by default includes "rate" then we can remove the "_rate".
Another option would be to include explicit "water source" in the input file for ATS-only transport (no Alquimia) too, i.e., independent of transport (reactive or non-reactive) user should provide "water source". In that case, for conservative transport (ats-only) the user will provide both solute_source and water_source, and for reactive transport water source will be provided in the input file and solute_source will be picked through Alquimia. Just a thought.
from ats.
I am not sure if I follow everything you say Ahmad. The water_source_rate for the "geochemical" source is typically given in the State and given as m/s if in the surface (for precipitation). In any case, I think I would go for something simpler
1 . mass_rate (for setting a rate that adds mass of a transported quantity) with units of mol/m2/s.
2. geochemical (for setting the concentrations via an Alquimia constraint). Units handled by the interface. Tied to water source in State (that is, no water added means no solute added)
3. concentration (for setting a concentration with ATS). Units of mol-solute/mol-H2O. Tied to water source in State (that is, no water added means no solute added). Currently not coded in the ats transport pk but I think it would used more than option 1.
4. domain coupling (for coupling surface-subsurface)
To me, other than the question about naming there is the question about hierarchy. I am not sure why the option 1 and option 4 are currently under the same type of source (currently (mis)named "concentration"). Unless there is a strong argument against it, I would also suggest to flatten this hierarchy.
from ats.
-
I would prefer component_mass_source or something similar, agree on units. This is in comparison to what I'm starting to think should be the default name in ATS, "water_mass_source" or "water_volumetric_source" to distinguish between [mol m^-2 s^-1] vs [m s^-1].
-
right
-
I agree that it would be nice to have this in ATS. And agree that it should be called something like "source_concentration" or "component_source_concentration" by default.
The only trickiness in 1&4 being in the same concept is that there are several more of these, for instance well models (were the source is in mol/s, and the source is evenly divided across volume of the well's region), and a few others. I'm good with flattening them.
Flattening the changes may require either generating xml or changes to Amanzi, as beyond the "top level" name of "concentration" or "geochemical" I think all of that gets parsed in Amanzi's TransportDomainFunction code. I'm not against that, but we should check with Konstantin before changing DomainFunctions because they get used by a lot of Amanzi's PKs.
from ats.
- I like component_mass_source. I was stuck with "solute" which I did not like. Consistency with other named mass sources is important.
- component_source_concentration sounds good to me, or maybe even component_concentration_source could work.
- not to complicate things more but maybe then geochemical_source would be a better choice.
It sounds to me that flattening would be the preferable option but it is unlikely we can get the needed changes in before the next release, so I would focus on picking the names and leave potential additional development for later. At worst, we would be creating a separate source for "domain coupling" at a later date.
from ats.
-
I like component_mass_source [moles/(m2*s)] too.
-
Currently we use the name "mass_source" [moles_water/(m2 * s)] in the state for water source when using geochemical condition. Are you guys saying the names will changes like:
geochemical --> component_concentration_source
mass_source --> water_mass_source (??)
Just trying to understand.
from ats.
from ats.
No matter how it is done, the exact name should be left to the user. Keys::readKey() provides a code-wide paradigm for reading keys from the input file, and we should allow the user to call the water mass source whatever they want.
Sergi, realize also that mass_source is by default mol/m^s/s, and you are exploiting a magic feature of surface flow when you use m/s. :D I don't want to depend upon that feature in transport, because it isn't even valid for subsurface transport, and by default the surface mass source is mol/m^2/s (you have to tell surface flow "mass source in meters"=True to get m/s). So it will be assumed that the transport code is provided with a water mass source in mol/m^2/s (meaning @saubhagya-gatech bug #72 needs to be fixed too).
from ats.
As for component_concentration_source, it would be a new one to give concentrations of components, tied to water sources.
…
We should check with @lipnikov on this -- does Amanzi currently have a way of providing a mass of water source and a concentration of the incoming source to the transport PK? Obviously one could externally multiply these two things and provide a mass of component source, but doing the multiply in the code is handy from a user perspective, especially for flow + transport runs where you need to supply the mass of water source to the flow PK already. Does such a TransportDomainFunction exist in Amanzi?
(Note this does exist for a geochemical condition with Alquimia, I'm talking about non-reactive transport.)
from ats.
TransportDomainFunction is a simple base class for PK_DomainDunctionXXX classes that implement various source models. Mathematically we have only one Q in dC/dT + div (v C) = Q and it is in [mol/m3/s]. My understanding of what you are trying to achieve is to calculate Q as a function of other input data, e.g. Q = Q(solute_mass, water_mass, water_flux, etc). Often this is just a post-processing step (after calculating data using a source function) and could be delegated to a sub-model. In Amanzi, sub-models are supported by the base class. Since TransportDomainFunction is almost empty it is possible either to extend it or to implement a separate base class in ATS's transport.
Transport PK in Amanzi has one example of pumping out just water. Unfortunately, it is not yet implemented as a sub-model, so examples of using submodes are in Flow PK only.
from ats.
Related Issues (20)
- reconsider deep water problem solution
- dead code
- Spack fails to collect ATS version info HOT 1
- domain sets hang on vis-ing individual columns HOT 1
- add evaluators for interpolation in time, use them in ats transport
- Running ATS in cluster promtps me with missing libraries HOT 2
- enforce negative depth for nonplanar faces
- Supersaturated water HOT 2
- Why the installation of ATS failed? HOT 4
- restarted observations with "integrated in time" are bad for the first observation HOT 1
- Add B&C WRM, allow magic omega rel perm model to use B&C lambda
- richards hydrostatic ICs use cell_centroid
- aspect incorrect in the upper left quadrant HOT 1
- ApplyInverse() return code
- Restore CI for new TPLs on david/amanzi-tpls-0.98.8 branch
- refactor transport HOT 1
- Misses by Input File Convertors HOT 2
- "restart from checkpoint file" not working HOT 1
- tests requiring geochemistry still run when compiling with --disable-geochemistry HOT 1
- Can ATS write output directly for ESSDIVE?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ats.