moose
moose copied to clipboard
idaholab
Renaming modules to match what they contain
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!
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
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
@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".
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
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.
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
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.
Radiation is done with actions & userobjects not raykernels but it's still done in that module. Same for convection at interfaces
This module is not solving radiative heat transfer equation in general. General energy balance equation involving fluid is also not here.
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
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.
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.
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.
lol, not even
fluid_structure_interaction? We had this battle before and agreed onfluid_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
I personally want to rename tensor_mechanics to solid_mechanics. But I know @bwspenc has really good reasons not to do so.
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?
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.
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
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.
lol, not even
fluid_structure_interaction? We had this battle before and agreed onfluid_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.
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
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.
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.
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!
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.
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