Create THM components that wrap Navier-Stokes multi-D flow discretizations

[lindsayad]

Reason

We'd like users to be able to rapidly try different discretizations to determine what works best for a given geometry, flow conditions, etc.

Design

Create THM components for

1. INSFV
2. INSFE
3. PINSFV
4. PINSFE

1 and 3, and 2 and 4 may be able to be grouped together if we add a porous option

Impact

Rapid diagnosis of what kinds of discretizations work

[lindsayad]

@snschune @GiudGiud @rui-hu @lingzou feel free to weigh in here with desired requirements for this Component wrapping

[joshuahansel]

So what are these components trying to achieve that the existing NS actions cannot? Are you planning on setting up any systems with multiple mesh pieces?

[lindsayad]

So what are these components trying to achieve that the existing NS actions cannot?

Yea ... I think since we met in Chicago I've kind lost whatever that distinction was ... I was wondering this same question as I was opening this issue.

[joshuahansel]

I think the important question is whether you want to assemble simulations with multiple pieces (in a fully coupled way). Otherwise, probably just stick with actions.

[lindsayad]

Let's assume that we do 😄 I really think we do want to be able to at least try these kinds of fully coupled simulations with this theoretical new multi-D component as well as the components you already have

[joshuahansel]

I'll wait to start on this until we've had a team discussion - I just want to avoid the fate of #22354.

For the record, I like the idea of wrapping more things into components. To help the discussion, maybe we need some examples of existing input files that might have multiple components involved, or at least some theoretical examples. Then there are numerical questions about comparing the approaches of full coupling vs. tight coupling.

[joshuahansel]

Speaking of motivation for fully coupling 1D to multi-D, @Naktakala was asking today about this for NASA's NTP project. He has a bunch of assembly channels merging together, and was running into AD container size issues. I think this is a great example of why we need to have the full coupling ability. Having multi-D NS components, we could have a multi-D junction and then a coupling component between this component and the 1D flow channels.

[lindsayad]

Wouldn't full coupling make AD container size issues worse?

[GiudGiud]

I think the junction takes care of reducing the required container size.

[joshuahansel]

Wouldn't full coupling make AD container size issues worse?

Not what I have in mind. So for example, in Jan's case, he has 91 flow channels that get merged into a single junction, so that's a definite container size problem. What I have in mind is a multi-dimensional junction. Obviously I don't have any details worked out, but each flow channel would terminate on some subset of faces on the multi-D junction domain, maybe e.g., 1 face, 4 faces, depending on the mesh size of the multi-D domain and the diameter of the 1D channel.

[lindsayad]

Should one multi-D component be able to cover all the discretizations, as opposed to one component per multi-D discretization? That would be really nice for users and be a simplification from what we have now, because we have different actions in navier_stokes for the different multi-D discretizations.

Alternatively/in-addition it sounds like may have a totally different block where we specify the discretization type, and this discretization object gets passed as a parameter into the Component flow objects