[maddalena]

Hi Nicolas,

Originally Posted by NicolasB

Hi,
I've set up a case with both a solid and a fluid.
...
I join an archive with these cases (just use the "Allrun" scripts).

can you attach the solver as well? Otherwise I cannot run your cases...

Originally Posted by NicolasB

What I don't understand is why we have to run this solver on transient mode for fluids while it works on steady for solids...

What have you done to make the solver steady? I guess you should reproduces the same changes there are between chtMultiRegionFoam and chtMultiRegionSimpleFoam. You cannot declare the case as steadyState on fvSchemes only, something weird may appear. Please correct me if I am wrong...


mad

[NicolasB]

Hi Maddalena,

I've just use the chtIcoMultiRegionFoam solver from the first post in this thread, with no modification.
As it was run steady for solids, I thought I only had to change the fvSchemes and the controlDict. Seems that was too easy
I hope you can enlighten me since I'm pretty new on CFD and OF.

Nicolas

[maddalena]

Originally Posted by NicolasB

Seems that was too easy
I hope you can enlighten me since I'm pretty new on CFD and OF.

Well, I do not know if you can make steady state the solver changing fvSchemes and controlDict simply... I guess you have problem with simple and piso loop, see here, so on fvSolution as well.
As the name says, chtIcoMultiRegionFoam is based on icoFoam. It means that the fluid part is solved in the same way of icoFoam. Thus one thing you can try is to take a icoFoam tutorial (cavity should be ok) and compare the unsteady and steady solution, the latter obtained changing fvSchemes, fvSolution and controlDict only, and adjusting BC if necessary. I guess the solver will complain...
In that case, you have to modify chtIcoMultiRegionFoam throwing away all the ddt terms and changing the loops accordingly. A good point where to start is to reproduce the same changes there are between chtMultiRegionFoam and chtMultiRegionSimpleFoam, as I said before.

mad



PS: of course, I am not saying you have to do it for me: I need a steadyState version of this solver as well. I hope we can work together on it!

[NicolasB]

+1 for your PS
Can you check the solver in the attachment?
I made a copy of chtIcoMultiRegionFoam;
changed the names;
commented the "ddt" terms in the equations;
commented the "#include" with time, Pimple and piso;
added the "readSIMPLEcontrols" from chtMultiRegionSimpleFoam;
changed the PISO loop to a SIMPLE one.

I hope I've forgotten nothing.
Waiting for your feedback
Regards

[maddalena]

Just give a fast look at it. I think you commented too much, especially on the fluid part. But give me some more time to go deeper.

mad

[mirko]

Originally Posted by maddalena

Hello,
nicolasB, Mirco, have you succeeded in creating a steady state version of chtIcoMultiRegionFoam?

mad

Sorry, Maddalena, no progress here.

Mirko

[Canesin]

Hi all,

You will not have success in creating a steady version in it definition.

The energy exchange at the interface is done in an boundary update methodology.. segregated.

The only thing could be done in an segregated approach is to use an fake transient with large time step (like the pimpleFoam solver).

To create an trully steady state version of the solver one needs to make it fully coupled, like in an block coupling for velocity-pressure.

[mirko]

Originally Posted by Canesin

Hi all,

You will not have success in creating a steady version in it definition.

The energy exchange at the interface is done in an boundary update methodology.. segregated.

The only thing could be done in an segregated approach is to use an fake transient with large time step (like the pimpleFoam solver).

To create an trully steady state version of the solver one needs to make it fully coupled, like in an block coupling for velocity-pressure.

Nice thinking :-)

[NicolasB]

Hi Fábio,

As I'm preparing the oral following my training period, I'd like some pieces of information not to be trapped by easy questions...
Just to be sure, can you confirm the next equations are solved in your chtIcoMultiRegionFoam?

Solid:
d(rho*Cp*T)/dt - grad.(K*grad(T)) = 0

Fluid:
dU/dt + grad.(phi*U) - grad.(nu*grad(U)) + (source) = - grad(p)
dT/dt + grad.(phi*T) - grad.(Kappaeff*grad(T)) = 0
grad.(rUA*grad(p)) = grad.(phi)

I'm not very skilled in C++, nor in Of: I've got difficulties in converting the code in mathematical language.

Moreover, I haven't understood what is the central coefficient rUA. Could you enlighten me?

Thanks in advance,

Nicolas

[Canesin]

Nicolas,

You are almost right .. .just the last equation:

grad(rAU*grad(p))= grad(phi)


rAU = 1.0/UEqn().A()

Look at doxygen what the .A() is:

//- Return the central coefficient
00403 tmp<volScalarField> A() const;

It is related with the PISO algorithm in OpenFOAM:
refer to: http://openfoamwiki.net/index.php/Th...hm_in_OpenFOAM

[NicolasB]

There's something I don't understand.
Are they really gradients and not divergences, in the p-equation? Because in the file pEqn.H we have:

fvScalarMatrix pEqn
        (
            fvm::laplacian(rUA, p) == fvc::div(phi)
        );

I thought that for gradients we'd had

fvScalarMatrix pEqn
        (
            volVectorField temp = rUA*fvc::grad(p);
            fvm::grad(temp) == fvc::grad(phi)
        );

or something like that...

I'd seen the definition of rUA, but I've no idea of what the 'central coefficient' returned by the A() function is. I'm going to dig deeper in the PISO algorithm.

Many thanks for your help,

Nicolas

[Mojtaba.a]

Hello,
Dear Fabio, Thank you for your contribution.

Fabio and mad I wonder if you have been able to develop a code for incompressible steady turbulent flows, as it is the base characteristics for most of the heat transfer cases.

Is this new solver (chtIcoMultiRegionFoam) appropriate for using turbulence models?

All these aside, I can not understand one thing.
Is it OK to use the compressible chtMultiRegionSimpleFoam solver for an incompressible case? as it has been used in here: planeWall2D ?

Best wishes,
Mojtaba

[mxylondon]

I am thinking about this as well...

[mxylondon]

Hi, I am trying to compile the application in Version 2.2.0, a fatal error occured as:
'directMappedPatchBase.H: No such file or directory'.
Actually, I can't find this in this version.

[lhcamilo]

Originally Posted by mxylondon

Hi, I am trying to compile the application in Version 2.2.0, a fatal error occured as:
'directMappedPatchBase.H: No such file or directory'.
Actually, I can't find this in this version.

This is due to the fact that the directMapped patch was renamed in OF>=2.1 to just mapped.

This patch is used by the conjugate boundary conditions so you should go to the following folder inside your solver:

derivedFvPatchFields/solidWallMixedTemperatureCoupled


search for every instance of directMapped* and change it to mapped* , you should do that for both the .C and .H file.

PS: The * is just there to indicate that the patch name above may be part of a longer word.

[mxylondon]

Hi, Camilo, thank you very much for your reply.
Now, my solver is compiled well.
However, an error "hanging pointer, cannot dereference" occurs when 'adding to turbulence' for a very simple case.
Still struggling for that....

[lhcamilo]

I have had those problems... they are more fun than a barrel full of monkeys.

In any case,my guess is that your problem is probably somewhere inside the fluid/createFluidFields.H folder or solid/createSolidFields.H , some variable is probably not properly declared , usually the type of field or information is wrong.

These may be tricky to find and I had to spend more time than I care to admit understanding the purpose of each of these lines and variables in these folders (and the entire solver) to the point that I could re-write them from scratch (which I eventually did) for the particular set of cases I have been working on).

I wish I could be more help but this is a very hands on type of problem, you can also add the following bit of code to check where exactly the breaking happens

Info << "\n Check 1... \n"<<endl;

Make several of those lines inside one of those files with different numbers, so you can see how far the code goes before it breaks, that way you can narrow down where the problem may be.

GL

[mxylondon]

Thank you!
I got it, the problem is my definition of transportModel.
Thanks again!!!

[Haryo]

tmp<fvVectorMatrix> UEqn
(
fvm::ddt(U)
+ fvm::div(phi, U)
- fvm::laplacian(nu, U)
+ turb.divDevReff(U)
);

If you look the UEqn in the chtIcoMultiRegionFoam posted by Mr. Canesin (shown above), the viscous term appears twice.
So the - fvm::laplacian(nu, U) or + turb.divDevReff(U) should be deleted ( I deleted the - fvm::laplacian(nu, U)).
I compared the calculation results with the reference results shown below.
http://www.sciencedirect.com/science...17931086900177
Both of them show good agreement

[cyril.trp]

Hello everyone!

I installed chtIcoMultiRegionFoam on the 2.3 version of OpenFoam. Because of the new version, I replaced ddtPhiCorr with ddtCorr in pEqn.H compile and ran the previous case but I got this error:

Solving for fluid region fluid
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 0.02009576, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.98533956, Final residual = 0.011378115, No Iterations 1
DILUPBiCG: Solving for T, Initial residual = 1, Final residual = 4.4231395e-09, No Iterations 5
max(T) [0 0 0 1 0 0 0] 400


--> FOAM FATAL ERROR:
dimensions of phi are not correct

From function EulerDdtScheme<Type>::fvcDdtPhiCorr
in file finiteVolume/ddtSchemes/EulerDdtScheme/EulerDdtScheme.C at line 602.

It seems that something goes wrong with phi . What can I do to fix this error?

Thank you

Regards Cyril