search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.77k stars 1.05k forks source link

Merge/converge/unify finite volume and rDG #18321

Open lindsayad opened 3 years ago

lindsayad commented 3 years ago

Reason

My understanding is that the current rDG implementation is limited to first or second order approximation error, which is also the case for our finite volume implementation. At this level of approximation, my understanding is that the resulting discretizations (given choice of interpolation) are equivalent. If this is so, then we should merge the development streamlines to make sure we have all our best people working on one product.

Design

Probably not removal of the rDG module but maybe we change the back-end? Ideally we would not disrupt any user input files. And if there is functionality in rDG that we don't yet have in FV we make sure that the merged product has the set union of functionality.

Impact

Ensure that all of our fluids people are working on the same product. It would be great if we could get our FV developers (myself, @GiudGiud , @snschune, etc.) working in the same sandbox as @joshuahansel and @andrsd, etc. If this were to move forward it would bleed down into pretty much all of our downstream fluids codes. I'm working on TMAP which is leveraging THM. It would be really neat if THM and navier_stokes were using the same kind of technology. Ideally users shouldn't have to think/learn about two different implementations.

andrsd commented 3 years ago

Yes, this would be nice. I think the biggest customer of rDG is THM and bighorn. Originally, flow-wise, the rDG module was not able to do variable cross-sectional area in 1D. We had to make some changes to allow that in THM. Bighorn uses 1D (w/o variable cross-sectional area), 2D and 3D. Note that for 2D and 3D we have to do 2 sweeps over mesh to allow for slope limiting (I think). This is not needed in 1D and you probably do not need that for FV.

IDK if there are another apps using the rdg module.

lindsayad commented 3 years ago

I talked with @joshuahansel about this this morning. I think once #15062 is resolved, which @csdechant is working on this summer, we can really start moving forward on this issue.

@joshuahansel I am curious ... if you are solving for your flow variables using FV/rDG, what variables are you coupling to that do not use that same discretization and also exist in the flow domain? I'm trying to establish whether #15062 is truly a pre-req for this issue.

joshuahansel commented 3 years ago

I guess I misunderstood the coupling issue. We're not coupling to any non-FV variables on the flow domain, just to FE variables on an adjacent heat structure domain.

lindsayad commented 3 years ago

Remind me how you do that coupling? E.g. how do you sample the finite element solutions in your current implementation? (I vaguely remember some user-object/aux thingy that we were able to simplify using global AD indexing)

joshuahansel commented 3 years ago

Yeah, you wrote VariableValueTransferMaterial in Sockeye to get the heat structure side temperature as a material property on the flow domain. Then we have a element user object (In Sockeye, HTHeatStructure3PhaseUserObject) on the flow domain that computes the heat fluxes and caches them by element id and qp index, to be used by a kernel on the flow domain and a boundary condition on the heat structure.

lindsayad commented 3 years ago

Yea that same material and approach should actually be close to working right out of the box with FV. You're similarly using CONSTANT MONOMIAL for your flow variables and bumping the quadrature in some inputs I've looked at I'm guessing in order to have more accurate heat transfer between the flow channel and the heat structure. You have that *RDG3EqnMaterial that appears to interpolate from the cell centroid to the potentially higher-order quadrature rule quadrature points (by default the qrule for CONSTANT MONOMIAL would be a single point located at the cell/element centroid). We have not yet done something like that for FV so that would be new, but that's something we should be adding in the vein of #15062. It would not be difficult to add since we have all the tools: cell values, cell gradients, and global interpolation functions that can take limiters.

andrsd commented 3 years ago

Just for the record in the variable area formulation we have area as CONST, MONOMIAL and also as FIRST, LAGRANGE, because we need grad A.