Heat Transfer possibility with DnsFoam ?
Hi Foamers !
I am trying to simulate a very simple case : a turbulent flow into a duct.
I have to "see" the turbulent structures in the boundary layer (maybe not the hairpins, but ideally it would be nice) and to analyze heat transfer at this boundary layer.
I am running a case with DnsFoam : 1024*1024*2 mesh for a duct with 10 millimeter high. Inlet is initialized with a LES model for turbulences.
Normally I should have good results with that (still running at present) ^^
But now I wonder if there is a possibility, with DnsFoam, to run the same case and to "see" the heat transfer at the walls. I mean : is someone has already run a heat transfer case with DnsFoam, and how ?
Any kind of help would be greatly appreciated !
Actually I got another problem with dnsFoam : it seems to be impossible to run a parallel computing case.
Kmesh always outputs a fatal error about the number of cells (I use a regular grid, but while running dnsFoam after decomposePar it gives me that error). I think I understand that error, but since the "-parallel" option is available for dnsFoam I wonder if there is a way to avoid that error.
Thank you in advance
Just a remark, it seems that you are using a 2D grid, well, with 2cells depth. I does not make sense to do DNS or LES in 2D because all the turbulent energy cascade is wrong in 2d as turbulence structures are fundamentally 3D.
For the heat transfer, you can have a look at this boundary conditions :
You may have made a mistake in the decomposeparDict file.
I know a pure 2D DNS is impossible, because the physics is all wrong, but I thought using 2 cells in the z direction would be enough since I am not interested in the behavior in that direction. Am I wrong ?
Thank you for the link, I will check this out.
Does anyone have an experience with a parallel DNS case and could help me ?
My decomposePar file is the same as in the UserGuide, but I use a 15mm*10mm*1mm (1024*1024*2) box and not a cube, could it put any problem for decomposePar or Kmesh ?
Thank you in advance
Having in mind that turbulence is the presence in the flow chaotic eddies, existing on a wide range of length scales, and all these scales exchanging energy via the stretching and viscous phenomena, the conclusion is that the mesh must be able to hold (I didn't find a better word for that) all this range of spacial wave length. But with only 2 points in the z direction, you can't discretize any signal. Basically, it is the same thing as discretizing a sinus function with 2 points. The signal is completely destroyed. You would need around 10 points per period to discretize correctly the signal.
As a wide range of eddies exist, typically, when you have a look at the Kolmogorov spectrum you will see that often more than one decade of eddies exist in frequency. So a fast conclusion would be that you need at least 100 points in all directions, whatever your problem is. Of course it is more complicated than that. Actually, in papers, we most often see DNS meshes with the same number of cells in all directions (people, tell me if I am wrong), because of that completely 3D structure of the turbulence.
I suggest you to read these pages :
The solver that you use should not be linked with parallelization issues (again, tell me if I am wrong), because in OF solvers source codes, you will notice that there is no parallelization instruction as this is completely in charge of the OF low level classes. And this is a strength of OF because parallelization is not easy to program.
Indeed most cases in papers have the same number of cells in all directions, you may be right about that : I will enlarge my number of cells in the z direction.
However I red on this forum (do not find out the link ...) that a parallelization is not possible at present with dnsFoam.
Is there any expert who could come here and give us a definitive answer plz :)
Thanks for your time
You seem to be right, I get the same error when I launched the tutorial after decomposition of the domain. This is very surprising to me ! Also doing DNS without parallelism is a bit restrictive...
Cheers and good luck,
|All times are GMT -4. The time now is 16:48.|