This topic called my attention because of some projects where I gave support, for the forum and for @jousefm.
The issue is, boundary condition models for Heat Transfer analysis seem limited and confusing in their names and description. I can see that we currently have:
Fixed temperature
Surface heat flux
Convective heat flux (which technically is not exactly a convective heat flux but heat exchange with a coefficient)
Volume heat flux (source?)
While having a look at Code_Aster document u4.44.02, I can see that the solver offers the following models:
Fixed temperature
Surface heat flux
Temperature-dependent surface heat flux (for linear simulations)
Surface radiation (using the Steffan-Boltzmann fourth power model)
Heat exchange (according to some heat exchange constant)
Volumetric heat source
Initial temperature gradient (do not ask me about this one, I do not know its application)
Convection (taking into account relative velocity to fluid)
Temperature-dependent volumetric heat source (for linear simulations)
Various connection models
So, with such a rich set of options available in the solver, why is this not reflected in the platform? Is there any technical reason? I can see for example a blocker in the convection because the velocity field must be defined for each node, but what about the rest?
Hi @ggiraldo,
thanks for asking!
In general we try to prioritize the features we implement based on the requests we get from users and the need we see for our target applications as we canât just implement every feature due to limited resources.
In this particular case I think we cover most of the relevant boundary conditions that you mentioned also in SimScale:
Fixed temperature (TEMP_IMPO)
-> yes: âFixed temperatureâ
Temperature-dependent surface heat flux (for linear simulations) (FLUX_NL)
-> yes, actually only possible for nonlinear as for Code-Aster: âSurface heat fluxâ with table data depending on temperature
Surface radiation (using the Steffan-Boltzmann fourth power model) (RAYONNEMENT)
-> not directly as Code-Aster forces you to use °C as temperature when using this BC, but you can easily model this with the nonlinear heat flux from above on SimScale
Heat exchange (according to some heat exchange constant) (ECHANGE)
-> yes: âConvective heat fluxâ
Initial temperature gradient (do not ask me about this one, I do not know its application)(PRE_GRAD_TEMP)
-> no - there is no use for it as far as I know, let me know if you find one
Convection (taking into account relative velocity to fluid)(CONVECTION)
-> no, as not requested and relatively large effort
Temperature-dependent volumetric heat source (for linear simulations)(SOUR_NL)
-> no, actually in nonlinear analysis only in Code-Aster. There have not been to many requests yet where this feature would have been needed, but probably the candidate to be implemented as next thermal BC.
Various connection models (LIAISON_âŚ)
-> they are mainly used for structural element connections or simplified surface-surface radiation which itself has several important limitations (no view factor taken into account, node count needs to be exactly the same on both surfaces, surface pairs need to be explicitly defined) which make it impracticable to use
I hope this helps to find the options you might be looking for and cleared some doubts.
Also let m know if you have a particular project where the current feature set is not sufficient and any of the above not yet implemented boundary conditions would be essential, so I can at least make a good point for increasing its priority on our road map.
Open foam, which simscale is built on, has much more advanced capabilities and so does simflow which is basically just a GUI which uses openfoam âas isâ.
The way I see it, simscale have traded the advanced capabilities for ease of use as simscale does not map all of the options from open foam one to one but is easier to use and provides helpful error messages about the mesh and boundary conditions.
Hello @roy_g,
just as a side-note: the post here is I think related specifically to the âHeat transferâ analysis type on SimScale, which deals with heat transfer within solids and is based on the Finite Element solver Code-Aster - but in general the same analogy applies of course to the analysis types based on OpenFOAM or other solvers.
Thanks for your comments on the topic, they are indeed very valuable.
The case we are discussing here pertains to the thermal analysis of solids, aiming to calculate stress and deformations. This is why we mention the Code_Aster solver, as opposed to the fluid focused OpenFOAM modules.
It is true that SimScale has a focus on easy usability, but here is hoping that in the future complete solver capabilities are implemented, in order for more involved analysis to be feasible.
Ah ok, I did not know that the heat transfer solver was not from Openfoam. I think that the temperature dependent surface heat flux, which is only available for non-linear simulations, would be very helpful in conjugate heat transfer, where from what I have seen it is not available at all.
An advantage of using a convection coefficient and not modelling convection flow is the fast computation time. The coefficient can be determined both numerically and analytically (for simple cases). If simscale included functionality to determine the coefficient, it would increase the usefulness of this approach as without knowing what the coefficient is itâs a case of garbage in garbage out.
