Adding Equation of State Object

[snschune]

Add an EOS object that inherits from GeneralUserObject. It can be used
throughout MOOSE wherever thermodynamic properties of matter are required: heat conduction module, navies stokes etc.

First idea is to create EOSBase. It will have the purely virtual method rho giving density in terms of pressure and temperature. Virtual methods pressure and temperature can have default implementations inverting rho in some way.

Then SingleComponentEOS inherits from EOSBase and more methods:

1. vaporPressure(T)
2. criticalPointPressure() and criticalPointTemperature()
3. phaseState(p,T) is a MultiMooseEnum = 'solid liquid gas' returning all the existing phases.
4. Other properties such as fugacity etc.

[friedmud]

You're going to want input from the porous flow, Bison and Relap-7 teams. If there is an API made it should probably go in Modules and should definitely wrap water_steam_eos.

Pinging @WilkAndy @andrsd @jasondhales @bwspenc

[WilkAndy]

Also adding @cpgr .

[WilkAndy]

Chris (@cpgr) and I discussed this recently.

Our needs are quite diverse and we decided against a UserObject approach primarily because we didn't want to define consistent interfaces and back ourselves into a corner. For instance, "density" for one fluid might only depend on pressure, for another it depends on pressure and temperature, while for brine it depends of pressure, temperature and salt mass fraction. Then there are all the derivatives of the property (density) that we actually need for good convergence (we use NEWTON).

What we decided to do was use Namespaces for things that are used by multiple Materials, and single Materials for unique situations. The "single Material" situation will probably be the most common for us, e.g., we'll have a single Material that computes the viscosity of water-with-dissolved-salt-and-CO2, which will depend on salt fraction, CO2 fraction, temperature and pressure. The functions contained in that Material probably won't be used anywhere else.

I'm keen to hear other people's thoughts. Certainly it would be good to standardise this stuff throughout the whole of MOOSE.

[snschune]

@WilkAndy I haven't thought about the derivates; certainly another issue. Regarding the different dependencies of rho(P,T,w) with w being a or multiple weight fractions: this is why I thought to split this into SingleComponent and MultiComponent. SingleComponent only dependent on P and T and incompressible fluids depend on T only. I wasn't quite sure how to deal with the incompressible case if you try to get P from rho and T, as this is impossible in this case. Maybe have a separate IncompressibleSingleComponentEOS that makes it illegal to compute pressure as function of rho and T. I am not familiar with a fluid whose density only depends on pressure.

My focus is really the single component case here and I have not thought about the multicomponent case much.

Also, I think EOS should not contain any transport properties as diffusion coefficients, viscosity etc. They are not part of equilibrium thermodynamics so they do not really belong into an EOS object.

[WilkAndy]

@snschune - I agree with your last paragraph. Often these EOSs are extremely computationally expensive, however, so sometimes computing enthalpy, viscosity, density, blah, blah, all at one time is advantageous. No answers, sorry, just observations

[WilkAndy]

Actually i'm not sure i agree with what i just wrote. If we are going to design something like this, why can't it also include viscosity, thermal conductivity, enthalpy, etc, etc?

[snschune]

I was originally thinking about p-Rho-T relationships only, but there is no reason why we cannot include enthalpy, internal energy etc.. Transport properties such as thermal conductivity, viscosity could be made accessible by additionally inheriting from a TransportPropertiesBase. This way not all EOS classes have to carry them but they can if desired.

[dschwen]

Why does this need to be a user object as opposed to let's say a material?

On Mon, May 16, 2016, 7:50 AM Sebastian Schunert notifications@github.com
wrote:

I was originally thinking about p-Rho-T relationships only, but there is
no reason why we cannot include enthalpy, internal energy etc.. Transport
properties such as thermal conductivity, viscosity could be made accessible
by additionally inheriting from a TransportPropertiesBase. This way not all
EOS classes have to carry them but they can if desired.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#6972 (comment)

[snschune]

@dschwen I got this from Relap-7 where it's implemented as GeneralUO, but this isn't written in stone.

[permcody]

I'm definitely with Derek here. This needs to go into modules, not the framework. Also, we need to make sure the proposed interface can be used by all the applications that need this capability. Right now BISON uses the existing module which REALLY, REALLY needs to go away. We were asked to remove it nearly two years ago but it hasn't happened because it's still used by applications, sigh. RELAP-7 is using a different EOS library that we can't redistribute with MOOSE. Finally, I believe there is an effort partially funded by NEAMS to write an open EOS module. So before you go nuts with this, we need to make sure all of the current issues and needs are addressed.

[snschune]

I was vaguely aware of water_steam_eos but completely missed it when I searched EOS MAMMOTH-wide in *.C files...turns out it's Fortran.

@permcody do you have a reference to the NEAMS EOS module effort?

[permcody]

Certainly do not use the existing module! I needs to be ripped out. Let's talk to Martineau when he gets in. He's the one that knows about the NEAMS effort.

[WilkAndy]

For what it's worth - in porous flow we did decide to chiefly use Materials (DerivativeMaterials) because of the ease of having flexible interfaces with derivatives defined or not defined. There are already a lot of such materials defined and we plan to define a heap more. Certainly i'd be happy to have a "base" module from which everyone could use these without having to include the whole of porous_flow, if that's what you guys want.

[snschune]

@dschwen I assume you suggested materials for the same reason that @WilkAndy uses them. One of my concerns was that if you need EOS in ScalarKernels, you cannot couple in materials.

This capability could be useful if you want to implement simplified coolant channel model e.g. for MAMMOTH for those who don't have access to R7. Basically, this would simply be a single temperature per z-interval (== ScalarVariable). However, in the scalar kernels you would need some EOS object.

[andrsd]

This is what we have in RELAP-7. There is a class hierarchy developed for different types of models/equation sets. One branch for single phase, one for HEM, one for two phase. These classes are called fluid properties, because they provide not only secondary variables like pressure and temperature, but also viscosity, thermal conductivity, sound speed, etc. It is derived from GeneralUserObject because we need those values in various systems like materials, but also nodal constraints (MOOSE does not compute material properties at nodes - to answer @dschwen 's question why not material).

Currently we allow 2 different formulations, one based on density, momentum, total energy - let's call it DME, and one based on internal energy and specific volume - let's call it VU. We prefer VU, since our IAPWS formulation is using it and 99% of our runs will use it. Another reason to go away from DME is that they can be written in VU form. However, that shows how to deal with fluid properties that have dependent variables. What we currently do is that we have a material that takes the FluidProperties user object and computes p, T, dp_dUi (Ui's are our primary variables and we have different amount for a selected model), dT_dUi. This solves the issue, that you just need one version of a kernel, boundary conditions, or anything that does not live at a node. Based on the FluidProperty UO, you pick the right material, you provide the quantities and you are done.

The issue arrises when you want to do something at a node, like ICs, constraints, etc. Then, you just need two (or more) version of that class. That's why we want to remove the DME formulation as well.

As far as the separation of EOS from fluid properties go, we started that way and soon we ended up with a combinatorial amount of classes that need this EOS + those fluid props. So, I made a decision that those should be in one interface and it makes sense for our equation set. May, or may not work for others. We do not compute everything in one call in the UO, it is the material that asks the UO to provide the quantities. This way, we always compute only what we need. But, again, this may or may not fit into your equations. Also, the IAPWS package provides derivatives wrt to (v,u) in one call and out interface reflects that - we compute the derivatives in one call. Store them in the material, and reuse these pieces in kernels, so we do not have to recompute all of them based on jvar in computeOffDiagJacobian()

Last, we have a work scheduled for our base classes to go into a module, so they can be used in RELAP and bighorn. Besides the IAPWS, which was licensed only for RELAP-7, we have other ones like stiffened gas, ideal gas, etc. And those will be in the module. Then, RELAP-7 will use the module and have its own class for IAPWS. That said, if you can use the VU formulation, I can start moving the pieces into a module and save you some head scratching...

[WilkAndy]

Quick note - regarding the nodal+material thing. we store nodal properties at quad points inside our Material. This limits us to number-of-nodes = number-of-qps, but that's not a disaster for us. we need nodal information because we need to do full unwinding and mass lumping to the nodes. Would this idea work for you too, @andrsd ?

[WilkAndy]

Also, as far as we're concerned, if you all choose a UO approach, we can always use a UO from a custom PorousFlow Material. Then we wouldn't be duplicating the IAPWS code, which would be a very inefficient thing to do.

[snschune]

@andrsd thanks for the detailed explanation. As this work is already scheduled, I will hold off on anything I was going to do. There is not point for me to submit something and you guys are already moving capability into modules anyway. Let me know if I can help accelerate this process.

@WilkAndy I'd say we can reconvene and look for synergies once the tasks described by @andrsd's are complete.

[andrsd]

we store nodal properties at quad points inside our Material. This limits us to number-of-nodes = number-of-qps,

Sounds like a hack ;-) But you can do this only if you are lumping, right?

Would this idea work for you too, @andrsd ?

Most likely not. When we couple 1D pipe with 2D heat structure, we know the node in the pipe, but then what material property do we take? From left or right? Does it matter? This assumes that we add material properties to node-to-node and node-to-face constraint system. The major problem there is that we would have to project the material properties.

[andrsd]

@snschune I forgot to mention, our interface can provide rho = rho(p, T). This one you would get for free. We have critical pressure in the interface, but not temperature (that would be easy to add though). We do not need phase state, because our model does not work that way, but there is a function for it in the external package, so we could wrap it. That could satisfy your original requirements...

[snschune]

Yes, I think that will satisfy my needs. As a matter of fact, I got carried away somewhat when I put in the issue - rho(p,T) and some relation for enthalpy might be enough.

[WilkAndy]

we'd like as much as you can give us @andrsd

Nodal info at QPS - yes, a hack, and yes, we always do mass lumping. We also store QP info in the Materials, however, so we don't need to do lumping+full-upwinding. It's abusing the system, but is also not great because: (1) it's never check that numberQPs=numberNodes, but that will be dealt with soon by one of the framework guys; (2) we have to calculate things 8 times over (when using hexs) !

[andrsd]

Ok, so let me refactor the system into a submodule, so you guys have any idea what we already have and then let's see what we can do next...

[snschune]

Great thanks @andrsd

[andrsd]

I have done a lot of refactoring in RELAP, so I can start pulling these EoS things out in a module. My question is: Do we want a separate module just with fluid properties or should that be part of the NS module. The API I have assumes internal energy (e) and specific volume (v) for most calls (like pressure, temperature, sound speed, cp, cv, mu, k, etc.) Then we do have some aux kernels for pressure and temperature, and couple of ICs. These are tied to this system, so it would make sense to distribute them along with the fluid properties system... Any strong opinions anybody?

[WilkAndy]

I think this issue can be closed. We have a FluidProperties module now. Do you want to close the issue @snschune ?

[snschune]

Yes @WilkAndy, thanks.