[hsieh]

HI,

Can OpenFOAM handles this type of problem:

Solid elements and fluid elements. Heat Conduction within solid elements and natural/force convection within fluid elements.

Thanks!

Pei

[henry]

We have done some work in this area particularly for catalytic-converters. We could produce some nice wrapping to make this easier to do and the coupling between the regions can be done in several ways some of which we have done and other we have the scaffolding for. One of the biggest remaining problems is the mesh generation and conversion process because we would need fluid and solid meshes which match at the interface.

We would be happy to work in this field if we can find sponsors.

[hsieh]

Hi, Henry,

We do quite a few thermal analysis of a refrigerate chamber with heat sink on the outside to take away heat. In this case, we need to model solid elements for conduction and fluid elements for natural convection.

I think it will good for OpenFOAM to have this capability. We do not have any money left in the budget this year, but, I will try my best to find some money for this development next year. Thanks!

Pei

[helmut]

Hi Henry,

We're also interested in this kind of problem, but from what I read I get the impression I can't have material boundaries in the mesh. Do I have to have separate meshes for the solid and fluid regions? Could you elaborate on the several ways you have tried coupling the regions?

Regards,
Helmut

[henry]

What do you mean by having material boundaries in the mesh? How do you envisage distinguishing the fluid and solid region and formulating the equations for them if you have a single mesh?

[hsieh]

Hi,

My experience with another software is the following:

Solid mesh and fluid mesh are generated separately. After that, a layer of zero thickness elements need to be generated between solid elements and fluid elements (these elements serve as coupling between solid elements and fluid elements).

It is not necessary for the solid elements and fluid elements at the common face to match.

pei

[helmut]

What I mean by material boundaries is having different material properties in different volume regions of the mesh, and two adjoining regions would have an interface defined by a face patch. Boundary conditions on the face patches would be used for solving fluid flow within the fluid regions. Heat transfer would be calculated over the whole mesh, albeit with a jump discontinuity in conductivity at the material interfaces.

[henry]

What you are proposing here can be done in the current version of OpenFOAM by introducing a phase-fraction into the fluid equations which is 1 in the fluid zone and zero in the solid zone and adjusting physical properties appropriately. You will also need a face-zone for the solid interface to apply the correct drag onto the fluid. All this is possible and has been done but is not very elegant or efficient.

An alternative is to have two meshes one for the solid and one for the fluid and transfer the boundary conditions explicitly between the two. This is also possible and has been done in OpenFOAM and is even easier in in the 1.1 release now that multiple meshes can be handled by the same time class. However the explicit BC update can produce slow convergence.

Another two-mesh approach would be to have one mesh for the fluid and one mesh for the thermal equation, i.e. a mesh of everything, and transfer fields between the two. This gives implicit coupling between the regions for the thermal equation but sufferes from a modest storage overhead and the need for quite a bit of mapping code but is also possible in OpenFOAM but has not yet been tried.

The fourth approach is to have two meshes as for the second approach but to introduce implicit coupling by combining the thermal equation matrices of the two regions which could be done in several ways. This is my prefered approach for the future but we haven't written all the scaffolding for it yet.

[almanstoetter]

Henry,

you said (in section two of your answer), using two meshes one for the solid and one for the fluid and transfer the boundary conditions explicitly between the two has already been done and is also easier with 1.1 version of OpenFOAM. Where do I find this exisiting implementation for OpenFOAM ?

[henry]

Sorry my mistake, I mean it has been done in FOAM a very long time ago but that work has not been upgraded to OpenFOAM. With the new mutli-mesh handling in OpenFOAM it can be done better so I wouldn't coose to upgrade what I did before.

[almanstoetter]

Henry,

you said (in section two of your answer), using two meshes one for the solid and one for the fluid and transfer the boundary conditions explicitly between the two has already been done and is also easier with 1.1 version of OpenFOAM. Where do I find this exisiting implementation for OpenFOAM ?

[henry]

Sorry my mistake, I mean it has been done in FOAM a very long time ago but that work has not been upgraded to OpenFOAM. With the new mutli-mesh handling in OpenFOAM it can be done better so I wouldn't coose to upgrade what I did before.

[sergei]

Hi Henry,
I am new to FOAM, and only starting to look at the code. First impression (after a few simulations) - it is a great tool, even compared to STAR (joking).
I am not quite sure about the FOAM data structure yet, but is it not convenient to have also cell tables? In this way, (solid) cells may have a certain additional information (inherently build-in scalar, like you suggest) and one can use certain equations (solvers) on a given cell table. Patches between cell types is also very convenient. In this way the multi-physics coupling will be much easy.
I have also a question related to the volumetric sources (may be not completely for this topic, so). Is there a relatively simple way of defining a source term on a given volume? (For instance, if I would like to fix velocity to a constant value, let say, to zero making cells "solid").

Well I have some more questions, but will look for an appropriate topic.

Thank in advance
Sergei

[mattijs]

As said above we would prefer to do this with multiple meshes (or rather regions) with implicit coupling.

single mesh with cell regions:
+ can have addressing across cell regions

multiple meshes with implicit coupling:
+ regions are automatically topologically separate
+ adheres to the OpenFoam way of having 'normal' internal faces and patch faces requiring special handling
+ allows different fields and properties in different regions
- requires special ordering across coupling patch

On the meshing side there should be no difference. We can already split a mesh into pieces (subsetMesh, splitMesh) and add together meshes (mergeMeshes, stitchMesh)

[liu]

This reminds me Flow3D (which is excellent in modeling free surface^_^). Which I also like very much is the way it deal with meshes. It uses a so called "FAVOR" method which essentially blockes the solid object and boundary on a struectured grid. I believe there is some indicator variable like gamma we have in the interFoam solver to indicate fluid region and blockage. The fluid boundary is like the free surface. The only problem is how to reconstruct this "surface" every time step.

I am wondering if this can be uesed in FOAM.

Just a thought.

[sergei]

Mattijs,
Thank you for your answer. Probably, you are right, because I don't have much experience writing solvers for CFD. I have been looking at this from the point of view of a user. Cell tables are very handy to have when pre- and post-processing (you can add easily sources, define properties of materials, etc.)

But here, Liu is right, if you indeed are planning to introduce in the future chimera-like meshes, the approach of FOAM is then will be superior.

Mattijs, do you have a "higher" layer, which would allow to introduce source terms (for scalar, momentum, etc.) into equations, like user sub-routines in fortran (I am a fortran programmer)?
Or the user has to modify standard solvers to include these.
I am looking for something, like user functions in Fluent.

[hsieh]

Hi, Sergei,

I was a Fluent user for many years and thought that the UDF was great. But, that is because you do not have the source code of Fluent.

With OpenFOAM, you can easily modify the source code, recompile and you have the solver you want.

pei

[sergei]

Pei,
Thanks for the answer. So, there is no such an "upper layer". I understand now a bit better how FOAM works.

My example with Fluent was probably not very nice one (I have only marginal experience with it). However, in codes using Fortran (90), user coding with dynamic linking is quite convenient.

Sergei

[panara]

I would like to simulate a conjugate heat transfer problem using the option formulated by Henry Weller in this discussion that I report below:

'An alternative is to have two meshes one for the solid and one for the fluid and transfer the boundary conditions explicitly between the two. This is also possible and has been done in OpenFOAM and is even easier in in the 1.1 release now that multiple meshes can be handled by the same time class'

can I have some hints on how to do that?
At the moment I am quite lost in the time, polymesh, and IO classes =(

regards,

Daniele

[mattijs]

Read in your two meshes.

Get the correct fvPatch and the corresponging field on it on both sides. Find out the correspondence between the faces on both sides (using the face centres) and use this to transfer your boundary field. Use these transferred values as fixedValue boundary values.

// Select face centres of patch (see fvMesh.H)
mesh.Cf().boundaryField()[patchI];

// Select patch field (see GeometricField.H)
p.boundaryField()[patchI];

// Assign to fixedValue boundary condition
p.boundaryField()[patchI] == ...