CHT: Calculation of HeatFlux for meshes which use wall functions

[ykhedar]

Hi, I just looked at the HeatFlux.C implementation and observed that it uses gradient of the temperature to calculate the heatflux. This would be accurate only if one uses very fine mesh near the wall, say with y+ < 1. Does that mean at the moment use of wall function meshes (y+> 30) is not possible for CHT analysis? Or I am missing something. :)

[uekerman]

@arusch

[MakisH]

Thank you very much for the feedback, ykhedar!

You are right, the adapter uses the temperature gradient to calculate the heat flux and this means that the mesh should be fine on the direction normal to the wall.

I have not rigorously tested or validated turbulent flow scenarios yet, even less using wall functions, although turbulent flow with resolving the boundary layer is technically supported.

This is an interesting enhancement we could develop. Do you maybe have any suggestions on a different way to calculate the heat flux? Maybe we could also model the Temperature with wall functions, although I am not aware of any literature. The main question is if there is already an implementation of this in OpenFOAM, which we could reuse.

[ykhedar]

I required the calculation of Heat Flux on Wall Function meshes for my Studienarbeit last year and found none already implemented in OF. So I wrote one using the formulation from Ansys CFX called Automatic Wall Treatment for heat flux. You can find my implementation in my repository OF-dev, the directory named "wallHeatFluxAWTcfx4.1" contains the implementation. I have found it to be reasonably accurate for the test cases which I simulated. Theoretical details could be found in the CFX solver guide. Feel free to ask if you need further help. I wish to test CHT case for my thesis using precice also(but with wall function and only if I have some time left), so if I have time and this is not implemented till then, I would try to do it.

[arusch]

Hi ykhedar,

you are right. Let me explain the issue in a little more detail so that other readers may follow as well. On the one hand, with the current adapter implementation it is necessary to sufficiently resolve the turbulent boundary layer. The computational expense of this strongly depends on the characteristics of the turbulent flow (transitional, turbulent, fully turbulent, very high Re, compressibility, attached/detached flow, …). On the other hand, using a standard wall function „out of the box“ (with the current adapter implementation) would yield inaccurate results in most cases since the (very) near wall behaviour is simply neglected and exactly that region determines the heat transfer at the coupling boundary.

Using a thermal wall function approach would, indeed, reduce computational costs in the boundary layer as it needs not be fully resolved. But this idea needs to be treated with care. The thermal boundary layer varies greatly for different kinds of flows and the formulation used in CFX assumes fully turbulent flows under a few additional assumptions (such as e.g. that flow dynamics are not affected by heat addition/extraction). Moreover, even when using a thermal wall function the heat transfer coefficient (at the CHT-interface) would still be determined from a (wall-function corrected) temperature difference between the wall surface and the closest fluid cells. So even though the boundary layer does not have to be fully resolved, it is still important to choose a turbulence model suitable for the specific kind of turbulent flow under inspection in order to make sure that the temperature at the fluid nodes is realistic. The correction factor determined by making use of the thermal wall function then takes care of the lack of near wall grid resolution. Its fundamental characteristic is the blending between the model for the linear viscous sublayer and the one for the log-law region. Therefore, the user does not need to explicitly know in which region the cells closest to the wall actually lie.

So in conclusion, if you deal with cases that exhibit fully turbulent flow at the CHT-interface, you can use such a blending thermal wall function for determining the heat flux coefficient. But be aware of the limitations of the thermal boundary layer theory/assumptions that underlie this modeling approach and validate your results when possible.

Best regards Alexander

[uekerman]

Thanks, @arusch and @MakisH for the answers here. What is the conclusion? Is this something, we could easily implement or would it be more work? Of course, validation would be another issue then, but maybe @ykhedar could help us with this.

If anyway, @ykhedar, you would implement such a feature in the OpenFOAM adapter, we would, of course, be interested in feeding this back to the main branch.

[MakisH]

I just now looked at your code, @ykhedar (I fixed the link in your comment). It looks very clean and I think we can integrate it in the adapter, at least for the (full-featured) compressible solvers. What do you think?

The main file we need from your tool is the correctHeatFlux.H. Most of the changes would go to our CHT/HeatFlux.C file.

Are you maybe going to the GOFUN2 in Braunschweig (or to the Dutch OpenFOAM Workshop in Delft)? If yes, we can try it together! Do you maybe have any relevant publication or orther text that I could read in the meanwhile?

[ykhedar]

Thanks for the link for GOFUN2, I am already in Braunschweig so will definitely attend :) and have registered just now. We can try to do it during the Meeting then.

The original paper by B.A.Kader is I believe Heat and mass transfer in pressure-gradient boundary layers.

Some more details which I used for the implementation can be found in the CFX Theory Manual 2.8.1.5. Heat Flux in the Near-Wall Region

[ykhedar]

I have one doubt regarding the writing of the coupling data (Heat Flux/ HTC/ Sink Temp etc.) from the function object to the disk every time step. If I am not mistaken the function

Foam::functionObjects::preciceAdapterFunctionObject::write()

in the source file preciceAdaptorFunctionObject.C

must implement the writing code similar to the OpenFoam function objects do but at the moment it is not implemented.

I require the values for debugging and was wondering if I am thinking in the right direction. Really appreciate the help. :)

EDIT: Or is there an easier option, a switch may be, which I can turn on/off to write the coupling data to the disk.

[MakisH]

You mean the actual data on the interface, at every coupling time, separately from the result files the solver writes? Such a feature is not implemented and is not currently planned. If I understand correctly what you need, you can get it by setting the write time to 1 timestep and then observe the values of the interface in ParaView.

The Foam::functionObjects::preciceAdapterFunctionObject::write() is not implemented as it is not needed. All the writing is handled by the solver. In some cases we need to re-write the results, something that is handled by these lines.

EDIT: I see now that you want e.g. the Heat Flux, not the Temperature. No, something like this is not supported at the moment.

[ykhedar]

You mean the actual data on the interface, at every coupling time, separately from the result files the solver writes?

Yes, I meant this.

Paraview would also work fine for normal field variables. But If I want to check the values of Sink Temperature or Heat Transfer Coefficients, I cannot see in Paraview.

One other option would be to use the default OpenFoam Function objects to write these values but it only writes the averaged values to the log file and not the Field values to the disk, if I am right.

[uekerman]

There is a feature in preCICE that allows you to directly output all coupling data, even at every coupling iteration. Check the export tag in the xml reference https://github.com/precice/precice/wiki/XML-Reference

On Jan 31, 2018 12:43 AM, "ykhedar" [email protected] wrote:

You mean the actual data on the interface, at every coupling time, separately from the result files the solver writes?

Yes, I meant this.

Paraview would also work fine for normal field variables. But If I want to check the values of Sink Temperature or Heat Transfer Coefficients, I cannot see in Paraview.

One other option would be to use the default OpenFoam Function objects to write these values but it only writes the averaged values to the log file and not the Field values to the disk, if I am right.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/precice/openfoam-adapter/issues/10#issuecomment-361773183, or mute the thread https://github.com/notifications/unsubscribe-auth/ACxFiHBAQXkMpDTccxC96ePYY3uyYxLwks5tP6kdgaJpZM4RrWzp .

[ykhedar]

The export tag works just fine. :) One has to include the 'export:vtk' tags within the 'participant' tags to enable exporting for the given participant.

[ykhedar]

Hi Team,

I have one observation to make. I was looking into the implementation of the Wall Function based heat flux into the adaptor and I realised that we have some kind of duplication of code between the adaptor and OpenFOAM w.r.t the boundary calculation. Take for example wallHeatFlux for which there is already a function object which does the exact same thing as the write() function of HeatFlux.C class. Why not call this functionObject directly when the boundary information needs to be exchanged instead of getting the field variables and re-calculating it in the adaptor.

I agree not all boundary condition types exist at the moment e.g. SinkTemperature etc. My point being it makes more sense to have only read/write functionality in the adaptor (e.g. Temperature class) and calculation based things should be accessed directly from the OpenFOAM functionObjects. In case the functionObjects does not exist, it can be created and provided along with the adaptor until the time it becomes available in OpenFOAM. This has following advantages:

1. A new developer wishing to implement a new boundary condition and familiar with OpenFOAM functionObjects can simply create one depending on his needs without requiring her to change anything in the adaptor
2. One could write a single class which takes the name of the variable as input (e.g. "T" ) and gets this from the runtime database.
3. De-coupling of adaptor and functionObject maintainance.
4. The created functionOjects can also be used directly with OpenFOAM so dual purpose would be served.
5. Easier to extend to general FSI adaptor.

Would love to know your thoughts. :)

P.S. I forked the repo for implementing the wall function Heat Transfer, did some changes, will work on it more during the weekend.

[MakisH]

I see that ypu are already doing a great job in integrating your work into the adapter!

The wallHeatFlux is at the moment a stand-alone application, not exactly a function object, but for sure I am open in reusing as much OpenFOAM functionality as possible, provided that we do not get restricted to a very small spectrum of OpenFOAM versions/variants and solvers. Also outsourcing some calculations to our own, separate function objects would be an interesting idea. I am very much in favor of reducing the complexity of the adapter itself.

Let's also discuss in person on the side of GOFUN (I will make sure to write the most important observations also here). Please write me at gerasimos.chourdakis at tum.de to find each other more easily.