Renaming modules to match what they contain

[GiudGiud]

Reason

• [x] Heat conduction is more like heat transfer https://github.com/idaholab/moose/pull/25585 FSI is more like acoustics in my understanding
• [ ] FSI could be renamed to fluid_structure_interaction by convention
• [x] Tensor mechanics -> solid mechanics. https://github.com/idaholab/moose/pull/26739
• [ ] Contact -> ContactMechanics ???
• [ ] Chemical_reactions -> Chemistry I think there's a few options there for contact. Either we split on a per-physics basis (multiple contactXXX modules), or we generalize the contact module (to be able to do mechanics, conduction, electromagnetics...) then either pull it from the other modules and do the contact there, or implement all the contact physics in a single contact module.

Are there any other ones?

Design

Good names make it clear what we're doing. There's nothing like reading the title and knowing what it contains.

At a high level this lowers the barrier to adoption for new users

Impact

Order!

[lindsayad]

FSI is more like acoustics in my understanding

There is acoustics, but there is also full-blown coupling of tensor mechanics and navier-stokes. It's one of the reasons I would like to have @fdkong back on the CCB so that he can review PRs like https://github.com/idaholab/moose/pull/24204

[fdkong]

I am not 100% sure we should change FSI to something else. I am interested in making the module work for real FSI even though we do not have much in it now

[milljm]

I miss your guy's banter =D

[rui-hu]

@GiudGiud, there are three heat transfer mechanisms: conduction, convection, and radiation. Does the current heat conduction module cover all three mechanisms? My understanding is that it focuses on heat conduction. If so, I would suggest keeping the module name of "heat conduction".

[GiudGiud]

convective heat flux BC is part of the module. CHT is not, because it involves NS at this point Radiation, from the simple gap treatment to the high fidelity ray tracing simulation, is also in the module.

If you look at the src/bcs folder you can see a little more diverse picture than heat conduction

[rui-hu]

If we look at src/kernels, it only handles the heat conduction equations. Note there is another module on ray tracing. My preference will be to keep it as the heat conduction module.

[GiudGiud]

It won't have radiation kernels in src/kernels. If you look at src/raykernels you can see the radiation kernels there.

The ray tracing module is a numerics module. It is preferrable to keep physics out of it

[recuero]

Are there any other ones?

Contact should probably be 'contact mechanics'.

[rui-hu]

It won't have radiation kernels in src/kernels. If you look at src/raykernels you can see the radiation kernels there.

The ray tracing module is a numerics module. It is preferrable to keep physics out of it

src/raykernels is under ray_tracing, not under heat_conduction.

[GiudGiud]

Radiation is done with actions & userobjects not raykernels but it's still done in that module. Same for convection at interfaces

[YaqiWang]

This module is not solving radiative heat transfer equation in general. General energy balance equation involving fluid is also not here.

[lindsayad]

src/raykernels is under ray_tracing, not under heat_conduction.

But because heat_conduction pulls in ray_tracing it also has the capabilities of ray_tracing. Even though the code does not reside in the heat_conduction directory, the ray_tracing capability is just as much a part of its capabilities as if it were. We could arbitrarily move the ray_tracing module contents into corresponding directories in heat_conduction and the capability of the heat_conduction module would not change one bit. So it's totally valid to consider the ray_tracing capabilities when naming the heat_conduction\heat_transfer module. Moreover, heat_transfer is a conceptual superset of heat_conduction. Even if it is missing some kind of heat transfer capability now, it does not make sense to pigeon-hole the module to be heat_conduction forever. I do not think it disrupts users to have a name like heat_transfer even if the module cannot handle every type of heat transfer right now. By keeping a name like heat_conduction you could confuse a developer who creates a heat transfer capability that is not conduction; they may wonder where to put the capability when we know we would like them to put it in heat_conduction/heat_transfer

[vincentlaboure]

I personally find it confusing to tell people that the heat_conduction module does more than just conduction (if only via BC and GapHeatTransfer, as mentioned above). So I think heat_transfer is a more appropriate name.

[lcarasik]

From a pure heat transfer perspective, the Heat Conduction Module is effectively an energy equation solver for solids or stagnant fluids. Even with the convective heat transfer boundary conditions, this is what ANSYS Mechanical or Thermal does.

By renaming it Heat Transfer, that would imply it is solving the energy equation in a moving fluid as opposed to applying a convective heat transfer boundary condition. I would strongly encourage renaming it a thermal energy solver as opposed to heat transfer.

Heat transfer to an outsider would normally imply the energy equation is being solved for the fluid that is moving involving the conservation of mass and momentum equations being solved as well.

[hugary1995]

I am not 100% sure we should change FSI to something else. I am interested in making the module work for real FSI even though we do not have much in it now

lol, not even fluid_structure_interaction? We had this battle before and agreed on fluid_structure_interaction... though no one had time to refactor that at that time.

[hugary1995]

I vote for heat transfer.

[lindsayad]

lol, not even fluid_structure_interaction? We had this battle before and agreed on fluid_structure_interaction... though no one had time to refactor that at that time.

I would be fine with that change. I was arguing against renaming it to acoustics

[hugary1995]

I personally want to rename tensor_mechanics to solid_mechanics. But I know @bwspenc has really good reasons not to do so.

[hugary1995]

By renaming it Heat Transfer, that would imply it is solving the energy equation in a moving fluid as opposed to applying a convective heat transfer boundary condition. I would strongly encourage renaming it a thermal energy solver as opposed to heat transfer.

Our navier_stokes module depends on "heat transfer" (or heat_conduction as it is now). Isn't that exactly what you want?

[YaqiWang]

I think BC can be considered as part of the heat conduction equation. GapHeatTransfer can probably be considered as a simple heat conduction approximation. View factors in this module is solving radiative heat transfer without participating medium. heat_transfer is a little too broad for what this module is doing. It could be also confusing to users in the future because they cannot find things they were hoping in this module.

[sapitts]

I vote for heat_transfer: it's an easier lift to convince our experimentalist partners that we can solve thermal problems of interest to them with a heat_transfer module rather than with the heat_conductionname

[jiangwen84]

I personally want to rename tensor_mechanics to solid_mechanics. But I know @bwspenc has really good reasons not to do so.

I vote for solid_mechanics. Do you know why @bwspenc is against that? I thought he likes solid mechanics.

[jiangwen84]

lol, not even fluid_structure_interaction? We had this battle before and agreed on fluid_structure_interaction... though no one had time to refactor that at that time.

I would be fine with that change. I was arguing against renaming it to acoustics

As it stands now, I prefer acoustic structure interaction. It is confusing that we called it FSI, but the majority of the examples are ASI.

[GiudGiud]

Alex is adding a whole lost of FSI that is not acoustics soon. So that name change is postponed until we maybe want to split off an independent acoustics module

[joshuahansel]

I wouldn't want to be the one to do this work and the resulting fallout/communication, but heat_transfer is probably the right name. In the future, I think it could also even contain models for heat transfer to fluids, so long as they aren't completely tied to the particular fluid model.

[bwspenc]

I've long thought that we should rename heat_conduction to heat_transfer

I appreciate @lcarasik's input as someone who is more knowledgable in that field, though, so if heat_transfer is misleading, I guess we want to be careful about that.

I've also always hated the name tensor_mechanics, and maybe this is a good excuse to rename it to solid_mechanics -- we've been planning to do that sometime anyway. I think enough time has passed since we retired the original solid_mechanics that it won't confuse people.

[GiudGiud]

It looks like a majority is in favor of heat transfer so we’re going to move ahead with that name

thanks everyone for pitching in!

[loganharbour]

we’re going to move ahead with that name

When did we decide?

[cticenhour]

I am in favor of heat_transfer generally and as a relative novice to this physics, but as @bwspenc mentioned, we should probably take @lcarasik's opinion into account here.

So the choice to me is between heat_transfer and thermal_energy. Where we see the module going in the future as far as core capability should make this choice.

[lindsayad]

To an expert thermal_energy may be a better name, but to non-experts I think heat_transfer is better and we probably have more non-expert users of that module than expert users.

There has been a clear majority in favor of heat_transfer. By my count I have:

Thermal energy: Lane (1) Heat transfer: Guillaume, Alex, Vincent, Gary, Stephanie, Josh, Ben, Casey (8) Heat conduction: Rui, Yaqi (2)

I think it's appropriate to use we in this case

[GiudGiud]

For renaming tensor mechanics to solid mechanics, I was thinking of doing that after the Physics system is merged in. So we transition from

[Modules]
  [TensorMechanics]

to

[Physics]
   [SolidMechanics]

at the same time (instead of having two transitions).

Thoughts? No opposition on the new name?

[dschwen]

Thoughts? No opposition on the new name?

The name is great and has been decided on a long time ago (basically when we deprecated the old solid mechanics module in favor of tensor mechanics). And if the Physics system ends up being a beefed up action system that syntax is fine, too.

[GiudGiud]

The more I think about the less I like Navier Stokes for the module. The heat equation is usually not called a Navier Stokes equation. The k-epsilon and other turbulence equations are not either. And naming the module not after the physics is the exception, with richards an unused module (coincidentally a fluid one) being the only other exception.

FluidDynamics? Daniel suggested it.

[hugary1995]

The name sounds good to me. It is up to you (and other developers of that module) to decide the scope of the module.

By convention, fluid related physics are categorized as follows:

• Fluid mechanics
  • Fluid statics
  • Fluid dynamics

The solid mechanics module was named that way because we solve both static and dynamic problems in that module. The same rule should apply to the fluid module as well, in my opinion.

If you name it "fluid mechanics", then you imply that the scope will eventually expand to fluid statics. (Plus it's a nice counterpart of the "solid mechanics" module.)

If you name it "fluid dynamics", then people who want to do fluid statics should start a new module, unless you are open to another module renaming when the time comes.

[lindsayad]

I'm ok with a change to fluid_mechanics although @grmnptr and @tanoret should weigh-in

[grmnptr]

I think we should think about this a bit more, we have multiple modules doing fluid mechanics. Unless you want to put them all in one module, I would prefer keeping NS for now. Another angle at this would be moving the energy transport routines out of NS and adding them to a new/existing module. I would say the turbulence closures are pretty NS-specific so I think that should stay.

[GiudGiud]

Is 1D flow really implied under fluid mechanics though? Or porous flow? I think the latter is but because we have a more precisely named module it s not a problem

[lcarasik]

I would argue that fluid mechanics as a name for a module is too general and does imply 1-D flow, porous flow, newtonian, non-newtonian, 3-D flow, etc inside of it.

I would strongly recommend against renaming NS module at this time unless it is planned to include non-newtonian fluid (and the resulting stress tensor relationship implemented), and wrapping those other modules in it.

I think it's reasonable to include turbulence models in a NS model, although I would indicate what is used to handle turbulent behavior.

[lcarasik]

The more I think about the less I like Navier Stokes for the module. The heat equation is usually not called a Navier Stokes equation. The k-epsilon and other turbulence equations are not either.

Is there a plan to have a specific module that solves for turbulent behavior of fluid flow for RANS, LES, DES, and DNS methods? Could rename NS to RANS instead?