[Dreoasteh]

Hi,

I'm trying to run a conjugate heat transfer case with the chtMultiRegionSimpleFoam solver in OpenFOAM 4.1.

The geometry of the problem can be seen in the attached image. The red region corresponds to the solid (named schwarzP) and the blue region is the fluid (named boolean). The solid is hot and cold fluid flows through it, heating up in the process.

After doing checkMesh, there appears too be no errors in the geometry.

However, after running the solver, the output is the following:

Time = 1

Solving for fluid region boolean
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
#4  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#5  Foam::fluidThermo::nu() const at ??:?
#6  Foam::laminar<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > >::nuEff() const at ??:?
#7  Foam::linearViscousStress<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > >::divDevRhoReff(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>&) const at ??:?
#8  ? at ??:?
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10  ? at ??:?
Floating point exception (core dumped)

I don't really know where the error might be so any help would be greatly appreciated.

In case any CFD/OpenFOAM hero would like to lend a hand, I have uploaded my case here (it is only 0.8Mb and runs in a minute by executing the runCase file).

Thank you!

[ali.ikhsanul]

I've tested the folder case, and I think the error comes from boundary or initial condition.

In my computer, I'm using OpenFOAM dev, it said:

Time = 1


Solving for fluid region boolean


--> FOAM FATAL ERROR:
PBiCG has failed to converge within the maximum number of iterations 1000
    Please try the more robust PBiCGStab solver.

    From function virtual Foam::solverPerformance Foam::PBiCG::solve(Foam::scalarField&, const scalarField&, Foam::direction) const
    in file matrices/lduMatrix/solvers/PBiCG/PBiCG.C at line 214.

FOAM exiting

And after changing the fvSolution as suggested, I got:

Time = 1


Solving for fluid region boolean
DILUPBiCGStab:  Solving for Ux, Initial residual = nan, Final residual = nan, No Iterations 1001

Or, you can consult on this tutorial for chtMultiRegionSimpleFoam:
http://openfoamwiki.net/index.php/Ge..._-_planeWall2D

[Dreoasteh]

It looks like the error in OpenFOAM dev gives more insight towards the source of the problem than the error output I posted.

I will check all my BC's specially for the velocity field and lower the tolerances to see if the solver starts running. Thank you for your advice, I will report back soon.

On the other hand, I did try the planeWall2D (and many other cht tutorials I found) and used it as a template to build my case. However, this particular one did not run for me. I actually started a thread on this here but I got no replies as of yet.

[Tobi]

Hi all,
the error messages you both get should be related to a non-sense setups. The iteration amount of 1001 (or crash - segmentation fault) is normally the sign of non-physical boundary conditions and/or sometimes a bad mesh. Changing the matrix solver should not solve your problem. Only and only if, it is related to a very bad initial guess but I would bet that this is not the case and the solver will crash too ... however, I have the experience with the cht-Solver, that this one was sill buggy in the previous versions (even in Dev). I made a case 4 days ago and run it @home - no problem. Then I sent it to my office to let it run on the cluster with the outcome of segmentation fault error. Unfortunately, I had no time to compare the Dev versions but the local on my home computer was one pulled 1 week ago while the one at my office was 2 month old. After updating foam the error was gone too.

Therefore, keep in mind that the dev Repo always includes the latest bug-fixes and features. It can happen that dev solves the equations differently or some model works differently and thus some problem you focus on does not exist anymore and the solver runs.

[ali.ikhsanul]

Here I attach sample case for chtMultiRegionSimpleFoam:
https://www.dropbox.com/s/mrw8c7ll96...dOnly.rar?dl=0

I've tested it in OpenFOAM dev and it works well.

The simulation run heat conduction between two bodies with fixed temperature at two faces (hot and cold).

I set the same thermophysical properties of the bodies, so can compare the result with laplacianFoam for further validation.

Hope this help you troubleshooting the problem.

[Tobi]

Hi all,

I changed my reply a bit and want to refer to this bug report:

https://bugs.openfoam.org/view.php?id=2663

and the related commit:

https://github.com/OpenFOAM/OpenFOAM...9a73241ba3a832

which caused my problem.

[Dreoasteh]

Thank you Ali and Tobias,

The problem was indeed an initial condition issue: I changed the velocity at fluid-solid interphase to noSlip and pressure conditions' fixed values to no-zero constants (for instance 1 atm) and now the case runs smoothly.

Nevertheless, I would like to ask you about the latter. It was my understanding that pressure was non-physical (i.e. only pressure differences matter) and therefore I could define any constant value for the initial condition. However, in testing this problem I found that changing the initial condition from say p=1 to p=100000 changed the solution completely.

How can I go about understanding this? Thank you

[Tobi]

Hi,

you have to distinguish between incompressible and compressible solvers. In incompressible solvers, the density is a constant value. Thus we can put it out of the derivatives and the pressure becomes the units p/rho. However, you see that we do not evaluate the density in that case (we do not need e.g. the ideal gas law or something similar). For compressible treatments, rho is not a constant and we have to calculate it (e.g. using the ideal gas law). The pressure in the compressible solvers have the normal units [Pa].

If you now model the compressible case by your assumption that only the pressure gradient is of interest and you set your pressure to 1 Pa, you can imagine how the density of your fluid is evaluated. If the setup is too unphysical, the solver cannot handle it and blow up; I guess in your case the density should get very large.

Further information of the mathematical point of view is given here: https://www.cfd-online.com/Forums/op...-openfoam.html

I hope I explained it in an appropriate way. Otherwise just let me know.

An additional hint: you are using chtMultiRegionSimpleFoam which is a compressible solver. You can check it out if you have a transportProperties file (in general for incompressible solvers) or a thermodynamicProperties file (for compressible solvers).

[Dreoasteh]

Thanks for the quick reply!

I was so used to working with incompressible solvers that I didn't think about it, now it is really obvious.

But, if the solver computes the density, how can I extract it for postprocessing?

By the way I used your book a couple of times and it is pretty amazing, you did a great contribution to the OpenFOAM community.

[Tobi]

The density field is calculated in the thermodynamic library. E.g. rhoThermo.C. However, the write option in the thermodynamic classes are in general set toIOobject::NO_WRITE and thus the field is not written. Maybe there is a function library you can use with the program postProcess. The way I would do it out of the box is to build a new field in the solver and save it. E.g. buoyantPimpleFoam:

//- CreateFields.H
volScalarField myRho
(
    IOobject
    (
        "rho"
        .
        .
        IOobject::NO_READ,
        IOobject::AUTO_WRITE
    ),
    mesh
);
.
.
.
//- After updating the thermodynamic (pEqn.H)
myRho = thermo->rho();

I did not check this peace of code, so it could be that it is not correct. However, the idea is simple. We make a new volScalarField and set it to AUTO_WRITE. The values of the field are taken from the thermodynamic library, namly the field rho. The AUTO_WRITE takes care that this field will be written.

I guess there are easier ways e.g. functionObjects but out of the box I cannot give you an example.

Another solution could be:

volScalarField& myRho = thermo->rho()

//- Changing the write option of the object somehow
myRho.foobar

//- Or write the object manuelly
if (runTime.write())
{
    myRho.write();
}

The possible ways we can implement and get access to the rho field is not limited to one approach You can decide. However, I guess other people might now a better solution without hard coding, cf. functionObjects.

[WUYing]

Hi Tobias, I have the same error "PBiCG has failed to converge within the maximum number of iterations 1000. Please try the more robust PBiCGStab solver." when using pisoFoam to solve an unsteady and incompressible case (3D flow over cylinder). The question is that the case can run smoothly when using icoFoam, but it crashed after running 180000 steps when using pisoFoam with same settings except for adding the standard k-epsilon turbulence model. So I suppose the initial condition, the boundary condition and also the mesh are Ok because it can run with icoFoam. But I don't know why pisoFocam failed to solve it. I would be very appreciated if you can give me some help!