[menorka]

Hmm, I see. I was waaay off!

I think I'll take your approach and define it all myself. I don't mid it taking a little extra time. It's confusing enough without running scripts that I know nothing about.

The fluid domain is indeed a little tricky in blockMesh so my plan now is to make two meshes in gmsh - one for the fluid domain, one for the solid and gmshToFoam them.

I need some clarifications though as to what goes where?

0-folder: contains domain folders with their respective data fields and polyMesh folders?
constant-folder: regionProperties file and domain folders. Each domain has properties files, no polyMeshes here?
system: fv-files and a controlDict. The individual domain folders has fv-files but no changeDictionaryDict's?

[psosnows]

This is how I do it in the approach I propose:

0-folder: contains domain folders with their respective data fields without polyMesh folders.

constant-folder: regionProperties file and domain folders. Each domain has properties files, AND polyMeshes folder.

system: in main folder controlDict and individual domain folders. In domain subfolers: fv-files.

(no changeDictionaryDict is required, it is used for automatic decomposition)

I also note, that the polyMesh folders require only standard files in them: boundary, owner, neighbour, points, faces. All other may be thrown out (repeating after Einstein: "make everything as simple as possible, but not simpler" )

I attach a picture showing "general idea" of multi region structure I use.

Hope it helps a bit

[menorka]

Thanks a bunch for all your help, I really appreciate it! So polyMesh goes in the constant directory, makes sense. I've made a new case based on your layout, simplified it to one fluid and one solid domain, changed the files accordingly but I get an error trying to run the solver.

--> FOAM FATAL ERROR:

    patch type 'patch' not type 'directMappedPatchBase'
    for patch fluidToSolid of field T in file "~/run/0/fluid/T"

    From function solidWallMixedTemperatureCoupledFvPatchScalarField::solidWallMixedTemperatureCoupledFvPatchScalarField
(
    const fvPatch& p,
    const DimensionedField<scalar, volMesh>& iF,
    const dictionary& dict
)

I defined the patch fluidToSolid as follows in 0/fluid/T. I also got the corresponding solidToFluid patch defined in the same way in 0/solid/T.

            fluidToSolid
            {
                type            solidWallMixedTemperatureCoupled;
                neighbourFieldName T;
                K               K;
                value           uniform 300;
            }

How does the solver know what patches are coupled? Does it work it out by itself using faces or do I have to define it somewhere? I'll check all the boundary and data field files one more time and report back.

The case can be found here for those interested.

[psosnows]

When you use solidWallMixedTemperatureCoupled the coupling is not only done in the data file (in T) but also at the mesh level, that is in boundary file.
I explained the needed modifications in the boundary file in the post at 15.05.10. In the end- you set things in T files exaclty as you did, and modify the boundaries as in the cited post.

Good luck

[menorka]

OK, I added the coupling to my boundary files. I had also forgot to scale the mesh (it was 3000m instead of 3000mm ) before converting it.

Also, the number nFaces in fluidToSolid and solidToFluid differ (279 vs 234). That would indicate that the two meshes do not line up properly and I'm guessing that is a big no-no? *

*scratch that I just checked and they fit perfectly.

[psosnows]

Exactly- mesh at the coupled patches should be 1:1
In fact I never tried to run a case with non-matching patches, maybe it would work. But I would strongly doubt in the acquired results...

[menorka]

When I check the meshes in gmsh they fit perfectly. Should nFaces be the same number? Could it be gmshToFoam that skews them? Might have to start a new thread in the meshing subforum.

[psosnows]

I looked up the the case you attached. Do the following:
run in console:

paraFoam -touch -region fluid
paraFoam -touch -region solid
paraview

and in paraview show only the solidToFluid and fluidToSolid (no fields, only those patches). I am sure you will get what is the problem

The next problem that you will encounter after you repair wrong face grouping will be in data files. You did not specify dimensions of some data (for example solid cp).

Best,
Paweł

[Chrisi1984]

Hi,

This thread is really good.

But there is still a problem that I can not solve.

I habe imported a mesh from Fluent with fluent3dMeshToFoam -writeSets -writeZones
than I made setsToZones -noFlipMap
and splitMeshRegions -cellZones
and finally I moved all folders to their correct positions and corredted the boundarc conditions (I am thinking at least).
and now I am getting this error message:

Create time

Create fluid mesh for region f-in for time = 0

Create fluid mesh for region f-vr for time = 0

Create fluid mesh for region f-et for time = 0

Create fluid mesh for region f-m-1 for time = 0

Create fluid mesh for region f-at for time = 0

Create fluid mesh for region f-out for time = 0

*** Reading fluid mesh thermophysical properties for region f-in

Adding to thermoFluid

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>
Adding to rhoFluid

Adding to KFluid

Adding to UFluid

Adding to phiFluid

Adding to gFluid

Adding to turbulence

Selecting turbulence model type laminar
Adding to DpDtFluid

#0 Foam::error:rintStack(Foam::Ostream&) in "/root/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/root/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted:
#3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/root/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPOpt/libOpenFOAM.so"
#4 void Foam::divide<Foam::fvsPatchField, Foam::surfaceMesh>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/root/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linuxGccDPOpt/chtMultiRegionFoam"
#5 Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > Foam:perator/<Foam::fvsPatchField, Foam::surfaceMesh>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > const&) in "/root/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linuxGccDPOpt/chtMultiRegionFoam"
#6 main in "/root/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linuxGccDPOpt/chtMultiRegionFoam"
#7 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"
#8 _start at /build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:122
Floating point exception


It would be really great, if someone can tell me what can be the Problem in "Adding to DpDtFluid"?

Thanks in advance!

Regards Chrisi

[psosnows]

Hello Chrisi,

it seems to me we have a typical "division by zero" problem.
Your error is definitely at line 133 of createFluidFields.H. In there you have:

132:  Info<< "    Adding to DpDtFluid\n" << endl;
133:  DpDtFluid.set
        (
            i,
            new volScalarField
            (
                "DpDt",
                fvc::DDt
                (
                    surfaceScalarField
                    (
                        "phiU",
                        phiFluid[i]/fvc::interpolate(rhoFluid[i])
                    ),
                    thermoFluid[i].p()
                )
            )
        );

the field DpDt is created by dividing phiFluid by interpolation of rho. It seems to me, you did not set rho properly, and its interpolation is zero. Check you data files in initial folder. Good luck!

Best,
Paweł

[Chrisi1984]

Hi,

thank you very much.

The problem was that the initial value of the pressure was set to zero at the cut surface.

Best Regards
Chrisi

[menorka]

Originally Posted by psosnows

I am sure you will get what is the problem

Hehe. Doh! The simulation runs but now there's something wrong with the time step. Thanks for putting up with all my stupid questions!

[r08n]

Hi *,

I'm trying to simulate a turbulent air flow over a solid heater with kEpsilon model. The question is -- how to set up the turbulent BC between the solid and fluid regions for the respective coefficients: k, epsilon, alphat. For domain boundary walls, the BCs can be set to compressible::alphatWallFunction, etc., but not for the boundaries between the fluid and solid regions. Are the BCs like "type calculated; value uniform 0;" or "type zeroGradient" acceptable?

[psosnows]

Hi r08n,

consider that the coupling between regions is done only on "T". All the rest of the fields exist somewhat "separately". You should be allowed to set any "standard" BC.

Thats how I understand it. The practical applications may vary

Best,
Pawel

[mik]

Hi Pawel, hi all,

I have a question related to the usage of the heat flux.

I have my cell (always the one I have already show you, see images attached at my previous posts) and therefore the interface between the two regions (FLUID and SOLID (cylinder)) is the lateral surface of the cylinder.
I want to insert an heat flux at the bottom of each region (FLUID_BOTTOM) and (CYLINDER_BOTTOM) using:

    FLUID_BOTTOM
    {
        type            solidWallHeatFluxTemperature;
        K               K;
        q               uniform 25e04; // [W m⁻2]
    value           uniform 293; // initial Temp [K]
    }

and

    CYLINDER_BOTTOM
    {
        type            solidWallHeatFluxTemperature;
        K               K;
        q               uniform 25e04; // [W m⁻2]
    value           uniform 293; // initial Temp [K]
    }

My problem is what I have to insert for the interface (FLUIT_to_SOLID in the T dictionary in the FLUID folder) and (SOLID_to_FLUID in the T dictionary in the SOLID folder).

I have tried with:

    FLUID_to_SOLID
    {   
    type                solidWallMixedTemperatureCoupled;
    value               uniform 293;
    neighbourFieldName     T;
    K                   K;
    }

and

    SOLID_to_FLUID
    {   
    type                solidWallMixedTemperatureCoupled;
    value               uniform 293;
    neighbourFieldName     T;
    K                   K;
    }

but I am not sure about the result... It seems that if I use the entry: "solidWallMixedTemperatureCoupled" the heat flux is not considered!

So I have tried to use:

    type            zeroGradient;

instead of:

    type                solidWallMixedTemperatureCoupled;
    value               uniform 293;
    neighbourFieldName     T;
    K                   K;

bur it seems that there is no "continuity" in the heat flux at the interface, like if the region are not coupled!
The internal field of the temperature (in the T dictionary) is for the two cases: uniform 293 in the whole domain.

Can you please help me?

Many Thanks

Best Regards

Michea

[maddalena]

Hi Michea...
what version are you using? If you have 1.6, there may be a bug: http://www.cfd-online.com/Forums/ope...n-problem.html
Hope it helps,
mad

[mik]

Hi Maddalena,

thanks for your hint, I have modified the solver!

However what I asked was a bit different (or maybe I have wrong understood ), I do not know what entries I have to add in the interface between the two regions (solid and fluid) because the heat flux is set at the bottom of the fluid as well as the solid region. The the heat flux (due to convection and conduction) between the cylinder mantel (lateral surface, the interface between the two regions) and the surrounding fluid is not know and therefore I do not know what entries I have to use.

Maybe can you help me...

Many thanks

[psosnows]

Hello,

first, thank you Maddalena for pointing the bug-topic out. The general idea shown there seems very important.

regarding Michea's question.

Remember that the only way to couple regions using chtMultiReigionFoam is to use solidWallMixedTemperatureCoupled. If you do not use this type of BC for both patches of coupled regions, then they are simply not coupled. We can not therefore discuss about proper heat flux, etc.

If in addition you add constant heat flux on other patches (like you did), it should simply work. Coupling is one thing, behavior of a system due to constant heat flux from one side is another.

And last "food-for-thought". I could not find much (if any) literature about "proper" way of decoupling system and solving it in an iterative method like in chtMultiRegionFoam. Even though the OF-Team made a great effort by creating the code, they did not support us with a lot of documentation I have some doubts if the proposed method is the right one. But maybe this is just me

Best,
Pawel

[maddalena]

Hello,
well, happy to be useful, but these are really my first steps inside cht!

Originally Posted by psosnows

Remember that the only way to couple regions using chtMultiReigionFoam is to use solidWallMixedTemperatureCoupled. If you do not use this type of BC for both patches of coupled regions, then they are simply not coupled. We can not therefore discuss about proper heat flux, etc.
If in addition you add constant heat flux on other patches (like you did), it should simply work. Coupling is one thing, behavior of a system due to constant heat flux from one side is another.

What does "add constant heat flux on other patches" mean? Does it mean that I cannot put two solid regions, both of them that are heat source, closed? I opened a new thread on the subject: http://www.cfd-online.com/Forums/ope...implefoam.html but maybe you can help me to sort the things out...
Cheers,
mad

[psosnows]

Hi,

Originally Posted by maddalena

What does "add constant heat flux on other patches" mean?

I just ment using solidWallHeatFluxTemperature of course you should be able to get similar results, if you impose fixedGratient such that:
FG = Qtot / Area
where FG is the FixedGradient value, Qtot is the constant total Heat flux, and Area is the area of the patch that we apply the HF to.
It all goes to using Neumann boundary condition types (fixed gradients).

And once again I state- the coupling patches do not have anything to do with other boundaries.

It also does not matter if you have solid-solid or solid-fluid connection.

In fact, I would not even use the term "boundary condition" but "coupling condition", since they are inside the whole system.

Maybe I am talking the thing a bit over, but consider an example: two connected square solid boxes. We create a system by coupling the connection face for each of the boxes (by using "special BC" called solidWallMixedTemperatureCoupled). From that moment, this connection becomes part of the "temperature interior" of the system. All the other patches that are pointing "outside" of the system should be considered as "boundary patches". We can apply any possible and allowed boundary condition types to them. So fixedGradient, fixedValue, solidWallHeatFlux, zeroGradient, bulkBody, you name it (I am not sure about "calculated" type).

Hope I did not shade the general idea too much and that this helps you a bit

Best,
Pawel