[maddalena]

Originally Posted by psosnows

I set things up just as you asked. Zero velocities everywhere. The simulation runs without any problems.
In OF-1.6 before main loop there is:

    if (fluidRegions.size())
    {
        #include "compressibleMultiRegionCourantNo.H"
        #include "setInitialDeltaT.H"
    }

And this does the trick. setInitialDeltaT.H is standard file. Here is a link to documentation:
http://foam.sourceforge.net/doc/Doxy...8H_source.html
I believe the if() part (CoNum > SMALL) prevents the crash.

And here is setInitialMultiRegionFoam.H: as you can see, the CoNum > SMALL is there, but the system crashes. I am going to write in the bug section (link here)

Thanks for the detailed answer to my second question. This will be useful for sure on a following step investigation.

mad

[maddalena]

Hi Pawel,
I need your help one more time...
Some posts ago you suggested to Michea to change her cylindrical geometry:

Originally Posted by psosnows

It would greatly speed up your work if you would simplify the geometry to 2D.

So, you are suggesting to investigate her cylindrical surface with a slice of the overall geometry, using wedge or cyclic, I guess.
At the moment I have some difficulties to run cyclic in chtMultiRegionFoam: the geometry and patches are managed correctly, but the simulation always blows up when using cyclic. However, I could run the same case using symmetry in place of cyclic, without changing geometry, mesh or settings.
Are there, in your experience, some incompatibilities between cht and cyclic? Have you ever run a case using that?
Some more details on what I am running are posted here.

Thanks for your helpfulness!

mad

[psosnows]

Hello Maddalena,

unfortunately I have not yet run a chtMRFoam case with cyclic BC. But I looked at your geometry and after first glance I had the following thought.

You have a very sharp, thin edge in the center of your problem. At the same time, we are expecting some radial-direction movements of the fluid due to presence of heat. In my opinion, the fluid simply does not have enough "space" to develop proper flow near that corner.

I would try to widen the case to quarter of a circle and then apply cyclic BC. If this does not work, then you probably will be forced to work on full circle (which works and gives acceptable results- I did a case like that).

Best,
Pawel

[maddalena]

Hi Pawel,

Originally Posted by psosnows

You have a very sharp, thin edge in the center of your problem. At the same time, we are expecting some radial-direction movements of the fluid due to presence of heat. In my opinion, the fluid simply does not have enough "space" to develop proper flow near that corner. I would try to widen the case to quarter of a circle and then apply cyclic BC.

Actually, this is something that I also think. I can try to wide the domain with this simple case, but in the end this is not a solution for me, since my final geometry is more and more complex.
I am going to test another solution: cut the tip of the slice and apply a waveTransmissive bc on the cutting. And see what happens... I'll keep you informed.
thanks

mad

NB: the uniform (0 0 0) velocity was indeed a bug. It has been fixed in 1.7.x.

[benk]

Hi all, I'm trying to use the chtMultiRegionFoam solver in OF1.6.

At the moment I'm just trying a very very simple test case: 1D steady state diffusion between two regions with fixedValue boundary conditions at both ends. This is just to make sure I understand how everything works.

I've basically set up my solver in a standard way and then used the solidWallMizedTemperatureCoupled boundary condition to handle the coupling between the two regions.

My problem is that my model just isn't solving correctly when I try to couple the boundaries of the two regions using the solidWallMixedTemperatureCoupled boundary condition. Everything compiles and runs fine but for the results I'm getting values over 10E15 when they should be bounded between 100 and 0 (which are the fixedValue boundary conditions that I'm applying).

If I replace the solidWallMixedTemperatureCoupled BC with fixedValue in my changeDictionaryDict file, the solver works (except this isn't making use of the coupled boundary condition which I need).


Can anybody help me troubleshoot this?

My entire model can be found right here: http://dl.dropbox.com/u/12812/OF/tes...ultiRegion.tgz and all you need to do to get it running is:

cd solver;wmake;cd ../case;./Allrun

[maddalena]

Hi Pawel,
some update before one more question: cutting the tip of the slice and apply a waveTransmissive BC for pressure did not worked, neither simulating a 90° slice + cyclic. The problem is always the same: h or U on the fluid region gets high suddenly, and the simulation crashes. Using a symmetry bc did not raise the problem, so I think I will lay on this solution. Since the slice is thin, the introduced error should be low.
With these results, I simulated my real geometry finally. The set up was fine, and I could manage the coupling of 16 different regions. However, as you did,

Originally Posted by psosnows

I also had a problem with acquiring steady state

The temperature in my case raise only by heat generation, and I know that the final temperature of the reference point is around 400K, with a time constant of 20000 s. However, after 10000 simulated seconds, that temperature is already 450K, and the steady state is not reached (thus it is going to get higher...)
I am thinking to your example of some post ago: may this be due to a time step that is too high? In my case, I have U (0 0 0) and the time step is driven by the solid part (maxDi) mainly. In order to speed up the calculation and have a first insight if everything is fine or not, I set maxDi = 1E-3, while the diffusivity of my solid materials is included between 1E-4 and 1E-8. If I want to see a proper transitory of the solid, I should set maxDi = 1E-8, I guess. However, using 1E-3 should affect only the transitory and have no effect on the final steady state temperature. What you think? Am I right?
Thanks for any suggestions,
cheers,

mad

[psosnows]

Hello Ben, Maddalena!

regarding Ben's case-
I compiled the solver, unpacked the case.
You modified it quite a bit (fields names c1, D1, S1 do not tell me much, sorry). And the test case does not have any field connected with solidWallMixedTemperatureCoupled.
If you support the solver, a final test case and some readme file with description what is what (plus maybe with a log of what went wrong), then I maybe will be able to help you

regarding Maddalena's post-
you say that you support energy by a heat generation. I understand that you added a source term to solved energy equations and additional source field to the problem- am I right? (if not- how do you supply energy?)

If you do support energy by a source term, consider the ways the energy is transported in a real case- you have advection (in fluids), diffusion (both solids and fluids) plus radiation (in transparent solids and fluids). Take to account that the chtMRFoam does not consider radiation. This may result in reduced energy transport.

The other possible answer to your problem is a bit more devastating- maybe the coupling does not work the way it should... I mentioned it several times earlier, that I do not fully trust the coupling method used in chtMRFoam (I found no literature that would confirm its credibility, and the ones that I found show different approaches!). If this is the case- then the only way would be to improve the coupling BC condition...

And as the final word- I still hold my statements regarding time step control. If chtMRFoam has some built-in mechanisms that control the time step- do NOT give any boundaries to it (as by setting minimum time step). And always make your own calculations (on paper) to determine the smallest possbile time step: dTime=size_of_smallest_cell^2 / diffusion_coeff.

Hope it helps a bit. Best,
Pawel

[maddalena]

Hi Pawel,

Originally Posted by psosnows

you say that you support energy by a heat generation. I understand that you added a source term to solved energy equations and additional source field to the problem- am I right? (if not- how do you supply energy?)

Yes, I added a field variable H that is solved by solveSolid.H. That's all.

Originally Posted by psosnows

If you do support energy by a source term, consider the ways the energy is transported in a real case- you have advection (in fluids), diffusion (both solids and fluids) plus radiation (in transparent solids and fluids). Take to account that the chtMRFoam does not consider radiation. This may result in reduced energy transport.

I have no transparent solids, and only air as fluid. Since the air is still (at the moment), diffusion is the main means of transport in my system, so I think chtMRFoam is ok.

Originally Posted by psosnows

The other possible answer to your problem is a bit more devastating- maybe the coupling does not work the way it should... (...) If this is the case- then the only way would be to improve the coupling BC condition...

Yes, this is devastating! However, let us say that OF is working the way it should...

Originally Posted by psosnows

If chtMRFoam has some built-in mechanisms that control the time step- do NOT give any boundaries to it (as by setting minimum time step). And always make your own calculations (on paper) to determine the smallest possbile time step: dTime=size_of_smallest_cell^2 / diffusion_coeff.

Ok, checked. The OF time step is 0.003 s. The minimum time step calculated on paper is 0.01s so I could use a higher maxDi ideally. That is nice.

... In any case, you forget one more possible answer to my problem: temperatures are higher than I thought. In that case, CFD can help me to understand what is wrong on my experimental setup...

Originally Posted by psosnows

Hope it helps a bit.

Yes, as usual!

thanks,

mad

[benk]

Originally Posted by psosnows

Hello Ben, Maddalena!

regarding Ben's case-
I compiled the solver, unpacked the case.
You modified it quite a bit (fields names c1, D1, S1 do not tell me much, sorry). And the test case does not have any field connected with solidWallMixedTemperatureCoupled.
If you support the solver, a final test case and some readme file with description what is what (plus maybe with a log of what went wrong), then I maybe will be able to help you

Hi Pawel, thanks for taking a look! Basically I want to solve:

laplacian(D1,c1) = 0 with boundary conditions c1=100 on the left and c1=0 on the right. D1 is the diffusivity.

I included a field S1 because later on I'll be adding a source term but that's just equal to 0 for the moment.

In the dictionary file for c1 in left and right regions, you'll find:

 c1
    {
        internalField   uniform 100;
        boundaryField
        {

            left_to_right
            {
                type            solidWallMixedTemperatureCoupled;
                neighbourFieldName c1;
                K               D1;
                value           uniform 0;

            }
     
        }
    }

So instead of coupling T I'm just trying to couple c1 instead.


The problem with the solver is that when I run it, I get the following output:

...
DICPCG:  Solving for c1, Initial residual = 0.97919, Final residual = 7.327857e-29, No Iterations 2
DICPCG:  Solving for c1, Initial residual = 0.333287, Final residual = 1.480727e-29, No Iterations 2
Time = 9

DICPCG:  Solving for c1, Initial residual = 0.333287, Final residual = 5.874262e-31, No Iterations 2
DICPCG:  Solving for c1, Initial residual = 0.97919, Final residual = 6.189845e-28, No Iterations 2
Time = 10

DICPCG:  Solving for c1, Initial residual = 0.97919, Final residual = 5.618467e-28, No Iterations 2
DICPCG:  Solving for c1, Initial residual = 0.333287, Final residual = 1.147113e-29, No Iterations 2
Time = 11

DICPCG:  Solving for c1, Initial residual = 0.333287, Final residual = 5.0275e-30, No Iterations 2
DICPCG:  Solving for c1, Initial residual = 0.97919, Final residual = 3.03365e-28, No Iterations 2

ExecutionTime = 0.03 s  ClockTime = 0 s

So if you look at the initial residuals (one for the left region and one for the right region), they're just oscillating between 0.33 and 0.979. And the final c1 field has values 10e15 instead of being bound between 100 and 0.

[psosnows]

Hello Ben,

I took another glance at your case, here are some thoughts.

I would still include

fvm::ddt(c1_left_or_right)

term in the equations. Then set in fvSchemes

ddtSchemes
{
    default steadyState;
}

But this is just my habit...

Most important result is if you decouple the cases and set the left_to_right and right_to_left as fixedValue. Run the solver, and... obtain nice gradient results after first iteration... This simply means that there has to be some major problem in the coupling condition. At least in your case (with changed equations and dimensions of the problem from temperature to quantity) it does not work.
The only way will be to get "into" the coupling condition, and try to understand what is not ticking well for your simulation. In the end it may be necessary to modify or write your own coupling BC.

Best,
Pawel

[maddalena]

Hi Pawel, hi everyone,
in order to find an explanation to the hard time I am getting to reach steady state for my simulation, I performed some tests on a simple case: a flat plane, with or without insulation, heated by an external heat source (fixedValue temperature in one side), or by inner heat generation. I compared these results with the analytical solution, that is known in these cases.
Meshes and setting are equal in all the cases. In detail, I declared every coupling as:

    cube1_to_cube2
    {
        type            directMappedWall;
        nFaces          10;
        startFace       390;
        sampleMode      nearestPatchFace;
        sampleRegion    cube2;
        samplePatch     cube2_to_cube1;
        offset          (0 0 0);
   }

and the 0/cube1/T file says that:

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

while I have:

    cube1_to_cube2
    {
        type            zeroGradient;
    }

for K, cp and heat source. Cht performed as expected in three cases out of four:

• flat plane without insulation without heat source;
• flat plane with insulation without heat source;
• flat plane without insulation with heat source.

The most interesting case, flat plane with insulation with heat source, shows the same behaviour I had for the simulation said above: temperature increases without control, and time vs temperature changes linearly (see the attachment).
What I can conclude is that:

Originally Posted by psosnows

(...)maybe the coupling does not work the way it should... I mentioned it several times earlier, that I do not fully trust the coupling method used in chtMRFoam (I found no literature that would confirm its credibility, and the ones that I found show different approaches!). If this is the case- then the only way would be to improve the coupling BC condition...

Indeed, at the interface it seems like the coupling is working as a zeroGradient BC for T as well and the heat flux does not flow in the preferred direction.
Has anyone experienced similar problems? If you have already found a solution to the problem, I would be grateful if you can share the code, or at least point out where I can look for a coupling improvement. Suggestions are really welcome.
Regards,

mad

[Chrisi1984]

Hi all,

I would like to simulate conjugate Heattransfer.

My treated geometry is a pipe with a porous zone inside. But the porous zone is only one part of the pipe. So I need a combination of chtMultiRegionSimpleFoam and rhoPorousSimpleFoam, in which the darcy law is only uitlized in one part of the fluid region.
Therefor I think it would be good to handle the interior pipe flux through two different fluid zones. But if I know correctly there is no possibility to directly couple two fluid regions in chtMultiRegionSimpleFoam.

Has anyone an idea how to combine the two solvers chtMultiRegionSimpleFoam and rhoPorousSimpleFoam for my problem.

Best ragards Chrisi

[maddalena]

... just to say that I moved the conversation here. A new thread seems more appropriate for the problem I am getting.

cheers

mad

[psosnows]

Hello Chrisi,

I would say, that you simply need 3 region types instead of 2 in classical chtMultiRegionFoam.
In that case, you would have solid, fluid and porous (in addition).

In the end, for solid and fluid, you copy the methodology from chtMultiRegionFoam, and for porous you copy the algorithm from rhoPorousSimpleFoam.

Of course there will be a problem with a coupling boundary condition. It is obvious that not only you will have to couple temperature, but also velocity, pressure and mass. Try looking at some solvers which deal with mixing of fluids (I have no experience with them, but directory "OpenFoam-1.6/applications/solvers/multiphase" has several solvers, maybe they can be of some use).

Good luck!
Pawel

[Chrisi1984]

Hi,

thank you for your hint!

I have now added the new region porous in my chtMutltiRegionSimpleFoam solver. Until now this region is treated like the fluid region, bescause for me it seems more difficult to combine the two different synthax of rhoPorousSimpleFoam and chtMultiRegionSimpleFoam in compare adding the darcy-law to the fluid equations.

But my problem now is in this file
turbulentTemperatureCoupledBaffleFvPatchScalarFiel d.C

How can I deal with the two fluid regions to get the neighbouring management in this file work?

I also checked the other solvers you told me for coupling the other variables like pressure, velocity etc. , but I did not get an idea. Has anyone dealed with the same problem before?

Best regards

Chrisi

P.S: I am using OF 1.7.0

[Chrisi1984]

Hi again,

I think I solved the problem with the file
turbulentTemperatureCoupledBaffleFvPatchScalarFiel d.C

by creating an analogical file for my porous zone.

But there is still the problem how to couple the variables of the different meshes fluid and porous.

Can the coupling be done only in the boundaries of the files in the 0 folders?

I discovered thinks like directMappedPatch, directMappedVelocityFixedValueFVPatch or directMappedFixedValue.
But I do not know how to use them and if they realy do what I want to, because they should couple patches of different meshes.

Or do I have to prepare the coupling in an other way in my solver?

Thanks in advance and best regards

Chrisi

[psosnows]

Hi Chris,

from what I remember, the directMappedPatch (and possibly other directMapped(...)) require that the neighbour meshes match on the boundary.
This is the only restriction (so one mesh can be triangular, other square). But the boundaries have to match.

If you want to connect not-matching boundaries, you will have to work on your own implementation of the coupling.

I remember that somewhere earlier in this thread I explained how to use the directMappedPatch coupling method. Dig up a bit and for sure you will find it

Best,
Pawel

[Chrisi1984]

Hi,

Thank you!

I tryed directMapped like it is described here http://www.cfd-online.com/Forums/openfoam-solving/59741-boundarycondition_mappring-inlet-les.html. But I changed set average to false.

I set in one region directMapped as patch at the connection with x_to_y . The BC off the other end y_to_x I think I have to take a standard BC. But so there is no really coupling between the two regions. I only map the calculated field of one region to the other. But the other region is independant of the flow in the neighbour region.
How can I really couple the two regions (with back coupling)?

Best regards

Chrisi

[benk]

Is there any way to specify the number of nodes in each region?

For example, in the model that I'm developing, I have 2 regions that have the same dimensions but I want a higher grid density in one of my regions compared to the other.

Is this possible in chtMultiRegionFoam?

[mabinty]

hi benk,

this can be done e.g. by defining two hex-blocks in the blockMeshDict corresponding to your regions.

cheers,
aram