CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Bugs (https://www.cfd-online.com/Forums/openfoam-bugs/)
-   -   conjugateHeatFoam error in new commits of 1.6-ext (https://www.cfd-online.com/Forums/openfoam-bugs/89207-conjugateheatfoam-error-new-commits-1-6-ext.html)

benk June 7, 2011 16:28

conjugateHeatFoam error in new commits of 1.6-ext
 
When I try to run the conjugateHeatFoam tutorial in 1.6-ext, I get the following error message in log.conjugateHeatFoam:

Quote:

--> FOAM FATAL IO ERROR:
keyword attachedWalls is undefined in dictionary "::right"

file: ::right from line 35 to line 41.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 396.

FOAM exiting
I don't get this error when using the binary mac version of 1.6-ext but I do when I use a newer commit of 1.6-ext. For the version that gives me a problem, git log gives:

commit 2f89ab8b718f44bda09af0ed421ec6751d7c52fa
Date: Fri May 27 20:53:20 2011 +0100

For the version that doesn't give me a problem, git log gives:

commit 3b1cb74951fe1630a2b3f39fc8d267622421f54d
Date: Fri Nov 26 11:08:01 2010 + 0000

benk June 8, 2011 12:34

Just for everybody's info, to solve this problem, you need to add

Code:

.
.
.
attached on
attachedWalls off

in the boundaries file.

kamkari June 9, 2011 07:45

p { margin-bottom: 0.08in; } Hi Ben
I am also using OF 1.6.ext. There is something wrong with conjugteHeatFoam solver. If you select different transport properties for solid and liquid regions ( for example DTsolid=1e-2 & DTcavity=1e-5) you will find that the temperature calculated for adjacent node to the coupled boundary in cavity region is not correct. The temperature of adjacent node is almost the same as the value of interface (coupled boundary)!!!!! when I investigate the temperature distribution through the solid and cavity region, I found that the solver use the solid value of DT (DTsolid=1e-2) for calculation of temperature for adjacent node to the interface. Or it seems as if the boundary has moved through the cavity region when the solver wants to solve energy equation I also should mention that this does not happen for calculation of velocity and it is OK. I think there must be something wrong in the solver when it attach the patches for solving energy equation!!
I also applied your changes (attachedWalls off) but I didn't get any changes.
This defect shows its importance when someone wants to calculate the gradient of transport properties on the interface which will faces to wrong results.

benk June 9, 2011 10:02

kamkari: I don't think there's a problem. I've been using this solver successfully for a while.

If you can make a simple 1D model and send me the results, I'll compare your results against the same model in Comsol.

Make the following model using the coupledFvScalarMatrix functionality, then send me the results (concentrations and the gradient of the concentration):

Region 1 (x=0 to 0.5):
laplacian(Dleft,c) + 0.1 = 0 BC: at x=0 c=100
Dleft=10^-5

Region 2 (x=0.5 to 1.0):
laplacian(Dright,c) + 0.1 = 0 BC at x=1 c=0
Dright=10^-3

kamkari June 9, 2011 17:31

3 Attachment(s)
Hi Ben
Thank you for your kind offer.
I solved the diffusion equation with the mentioned boundary conditions (as the first step without source term).



Region 1 (x=0 to 0.5):
laplacian(Dleft,c) = 0 BC: at x=0 c=100
Dleft=10^-5

Region 2 (x=0.5 to 1.0):
laplacian(Dright,c) = 0 BC at x=1 c=0
Dright=10^-3

As I expected the value of adjacent node to the interface (left region) has been calculated wrong. It follows the same slope as the right region!!! As I said before the solver seems to use the right region-DT value for calculation of the first node of left region!!!
I also emailed you the solved case (limitation for upload). Please have a look and let me know if I have made any mistake. I used the conjugateheatFoam solver OF1.6 ext without any manipulation.

Thank you in advance

benk June 9, 2011 19:41

1 Attachment(s)
Ok, I see what you mean. I'm getting a similar result as you and the comsol solution is right.

Here's a link to the solver that I'm working with:
http://dl.dropbox.com/u/12812/OF/multiRegion2.tgz

I've been burned before using silly settings in fvSchemes...I wonder if that's the problem.

benk June 9, 2011 23:57

1 Attachment(s)
kamkari: I've been playing around with the laplacianSchemes and I've found 2 that seem to work better (but not perfectly) for this 1D example (but I have no idea what these schemes are doing).

Try using:

Quote:

laplacianSchemes
{
default Gauss localMax corrected; // or localMin corrected
}
This is where cfd gets dangerous though, when you start playing around with schemes. There must be some other scheme that works better though.

kamkari June 10, 2011 09:59

1 Attachment(s)
Hi Ben
I solved the same problem using Gauss localMax corrected scheme for laplacian. I calculated concentration gradient on the interface (for left side):
linear: 4.28
localMax: 159.04
The correct value: 206.23
Although it seems using localMax scheme leads to better results in this case, there is still about 20% deviation from correct value which is a considerable error!!!! In addition the value of interface will change using this scheme.
The final goal of any heat or mass transfer analysis is usually calculation of nusselt or Sherwood number on the interface. But this solver cannot provide good results:(. I really can’t understand where the problem is. Is it from detaching or attaching the mesh or fvSchemes!!??
Regards,

hjasak June 10, 2011 13:58

Easy: you are doing something wrong. The solver works, it is validated and the results are correct.

My guess is that you messed up the diffusivity update or boundary conditions.

Hrv

kamkari June 12, 2011 01:39

2 Attachment(s)
I checked boundary conditions for coupled patches again and again. They are the same as the tutorial case (heated cavity) with different DT for left and right regions:
right
{
type regionCouple;
nFaces 1;
startFace 60;
shadowRegion solid;
shadowPatch left;
attached on;
}
left
{
type regionCouple;
nFaces 1;
startFace 59;
shadowRegion region0;
shadowPatch right;
attached on;
}
And the same for T boundary condition.
So this couldn’t be because of boundary condition.
I don’t understand what you mean with diffusity update. As I mentioned before I didn’t changed anything in the solver (OF1.6 ext) And I think the conjugateHeatfoam included in the OF1.6 ext is the last version of the solver.

benk June 12, 2011 10:46

2 Attachment(s)
Quote:

Originally Posted by kamkari (Post 311630)
I don’t understand what you mean with diffusity update.

Hrv means the part where you have to do a: diffusivity.correctBoundaryConditions(); I've tested all of this and it's not the problem. I invite anybody who has 15 minutes to please look at my very simple test case that I posted above and let me know what I'm doing wrong. I've even included instructions for how to run/compile the solver:
http://dl.dropbox.com/u/12812/OF/multiRegion2.tgz

In my opinion, the problem is in the fvSchemes.

The conjugateHeatFoam tutorial is mostly meant as an example of how to use the coupledMatrix functionality. Whenever there's a sharp change in the diffusivity at an interface, harmonic schemes should probably be used. That being said, I haven't had any luck using harmonic schemes in 1.6-ext (see below).

I did some more comparisons, this time between OF1.5-dev and OF1.6-ext.

These are my findings:

1. I still can't get exactly the right answer at the interface.

2. As can be seen in the attached figures, something has changed in the harmonic scheme between OF1.5-dev and OF1.6-ext. To get these results, I used the following fvSchemes:

Code:

divSchemes { default        Gauss linear; }
laplacianSchemes { default        Gauss harmonic corrected; }
interpolationSchemes { default        linear; }

3. Using localMin/localMax in laplacianSchemes in 1.6-ext gives exactly the same results as using harmonic and localMin/localMax in 1.5-dev.

4. Using 1000 grid points of course gives a better solution than 100 grid points as long as you use localMin scheme.

So far, the only suggestion I can give is to refine the mesh close to the interface and if you're using 1.6-ext use the localMin scheme. This shouldn't be necessary, but it's the best I've been able to do so far.


One more comment: I admit that I could be doing something wrong, but it seems to me that the gradient is being conserved at the interface, not the flux. When I do a print out of fvc::snGrad(cLeft) and fvc::snGrad(cRight), I get -99.96 and +99.96 at the interface. Clearly if the diffusivity is changing at the interface, the gradients at the interface should not be the same. The condition at the interface should be: cLeft = cRight AND -Dleft*grad(cLeft) = -Dright*grad(cRight)

benk June 13, 2011 16:44

Quote:

Originally Posted by benk (Post 311674)
2. As can be seen in the attached figures, something has changed in the harmonic scheme between OF1.5-dev and OF1.6-ext.

For the record, using the harmonic scheme seems to be an issue with earlier builds of 1.6-ext, but not newer ones. With a build date of Feb 4 I have issues (this is the build date of the mac binary) but not with the latest build of 1.6-ext.

kamkari June 16, 2011 08:09

1 Attachment(s)
Hi Ben
As you suggested I started playing with fvScheme to achieve better results than localMax/Localmin on the interface for the previous case with 40 nodes. I faced something strange when using snGrad with localMax scheme and linear scheme.
As far as I know snGrad uses the following formula for calculating the gradient of variable normal to the surface:
(Concentration of the interface – Concentration of the neighbor cell center) /dx (1)
I implemented the following line in the code for snGrad calculation on the both side of interface:
****** Right side ***************
label patchi = mesh.boundaryMesh().findPatchID("right");
gradT.boundaryField()[patchi]=T.boundaryField()[patchi].snGrad();
****** Left side ***************
label patchj = solidMesh.boundaryMesh().findPatchID("left");
gradTsolid.boundaryField()[patchj]=T.boundaryField()[patchj].snGrad();

Here is the comparison between the result of snGrad with formula (1):
****** linear scheme***************
Left Side
snGrad : -40.8
formula (1): -42.8
Right Side
snGrad : 2016
formula (1): 38.9
****** localMax scheme***************
»Left Side
snGrad : -1016
formula (1): -1590
Right Side
snGrad : 1970
formula (1): 443
I expected that the snGard and formula (1) results to the same answer.
To check the implementation of snGrad I added the snGrad as above to the boussinesqBuoyantFoam solver (solving natural convection in a single domain) and the results of snGard and formula (1) were the same.
Would you please check it and let me know if I am doing something wrong.
Tank you in advance

kamkari June 20, 2011 11:58

p { margin-bottom: 0.08in; } I think that I made a mistake for calculating the sngrad on the right region. The correct code for right region is:
label patchj = solidMesh.boundaryMesh().findPatchID("left");
gradTsolid.boundaryField()[patchj]=Tsolid.boundaryField()[patchj].snGrad();


now the results are as the following:
Left Side
snGrad : -40.8
formula (1): -42.8
Right Side
snGrad : 40.8
formula (1): 38.9
****** localMax scheme***************
»Left Side
snGrad : -1016
formula (1): -1590
Right Side
snGrad : 1016
formula (1): 443


There is still difference between formula (1) and snGrad. I found something interesting. SnGrad unexpectedly uses two point on the right and left side the interface for calculation of the surface normal gradient!!!!! This couldn't be right, because it should use the value of interface and its adjacent node value.

kamkari June 20, 2011 17:46

Hi Ben

I think that the snGrads you found for right and left regions in your last post are not correct, since the sngrad surprisingly is using two nodes located in right and left of the interface (you can check it by hand calculation)!!! Obviously if you use snGrad for linearMax /linearMin it shouldn’t leads to the same value for right and left regions but snGrad gives the same values.
I tried to solve it by detaching the patches:
# include "detachPatches.H"
label patchi = mesh.boundaryMesh().findPatchID("right");
gradT.boundaryField()[patchi]=T.boundaryField()[patchi].snGrad();
label patchj = solidMesh.boundaryMesh().findPatchID("left");
gradTsolid.boundaryField()[patchj]=Tsolid.boundaryField()[patchj].snGrad();
But I get the following error:
--> FOAM FATAL ERROR:
Requesting patchToPatchInterpolation in detached state
From function const patchToPatchInterpolation& regionCouplePolyPatch::patchToPatch() const
In file meshes/polyMesh/polyPatches/constraint/regionCouple/regionCouplePolyPatch.C at line 118.
FOAM aborting

Regards

hjasak June 20, 2011 21:30

Hahaha, you really made me laugh: so the gradients are correct, just like the doctor says.

As for your formula, you are wrong:

- in the detached state, the gradient is face centre minus cell centre divided by the distance, just like on any normal patch

- in the attached state, the snGrad is right CELL value minus the left CELL value divided by the distance, just like on any coupled patch.

So, as I said all along, the code is exactly right, conservative and consistent. Any other behaviour would be inconsistent.

Hrv

niaz June 21, 2011 16:17

Dear kamkari
You mean that snGrad() uses central difference scheme(but the openfoam site says different definition). So, is it really normal to surface?
The second problem is there are two regions having different conductivity. Can the snGrad() understand it?
I think the source of the problem is the solver. It shouldn`t really differ between two region. It is a really childish bug.:p

kamkari June 21, 2011 17:26

Dear Prof. Jasak

First I have to thank for your time and participation in this discussion. You still insist that the code is exactly right but I think it worth putting a little time for modification of code for the next extended version (1.7-ext). There are some notes:
1- Although your solver (conjugateHeatFoam) is easier for handling and may be faster than chtmultiregionFoam but without the capability of right prediction of gradients at the interface it can’t be much useful for heat or mass transfer problems.
2- I have used snGrad() in attached state and resulted to the same value for both regions. It means noting for a heat transfer problem with different DT for regions.
3- I am sure that what Doctor Ben has calculated for Right & Left gradients was in attached state which obviously leaded to the same problem and it is not what we are looking for.
4- If someone could calculate the snGrad() on the interface in detached state and get reasonable values for interface gradients, I mean that DTleft/DTright=snGrad()right/snGrad()left, you could be confidently sure that the code is exactly right.
5- I have calculated the gradient on the interface for both regions for the simple 1D case suggested by Ben like this with a calculator:D:
Gradient of the variable on the interface for Right/Left region = (face center value – cell center value)/dx
The results were far from the result of other software of analytical solution
!!!
6- Whatever happens in the solver is related to the interpolation on the interface because as the Ben said by selecting localMax or Loacl Min for laplacian scheme the results get better but still not acceptable (60%-100% deviation from the right value of interface gradient). The attached pics of previous posts show this clearly.

Regards

hadi1982 June 22, 2011 01:25

Dear Babak,
I have recently installed OpenFOAM 1.6-ext and faced with the same problem as you mentioned.
I think that your evaluation about the code is true. More investigation about this bug is required by the developers.

Good luck

hjasak June 22, 2011 05:35

This is starting to annoy me - make sure you don't show up for an exam at my class because you're going to fail.

1 in the attached state, the gradient across the Coupledinterface equals right minus left CELL value and includes the non-orthogonal correction and all other goodies

2 in the detached state the face minus cell gradient applies. I have state this in the snGrad message above

3 the flux is calculated AT THE INTERFACE, and is a product of the snGrad and the diffusivity at the face. The diffusivity at the face is calculated to be consistent on both sides

4 how to calculate diffusivity: in case of jump in diffusivity in two materials, the FACE diffusivity is calculated based on serial resistances of each material. This implies harmonic averaging at the interface, achieved by the regionCoupling b.c. ON THE DIFFUSIVITY VARIABLE. if your FACE diffusivity is. Not identical on both sides, you are doing something wrong - probably not correcting the diffusivity b.c. correctly.

5 in case of ADDITIONAL RESISTANCES AT THE INTERFACE, such as wall functions from turbulence model, insulation or similar, further serial resistances are added AT THE INTERFACE ITSELF. Note that cell values of diffusivity are still material properties of each material, including any jump states that may occur. This is handled specially, by manipulation of surface diffusivity in the laplacian.

6 in case of radiation or similar surface effects, further treatment is needed - but I told you enough already.

Is that now clear? The code is correct, it has been validated and it works properly.

To conclude with a personal note: I am a University professor and a professional CFD developer who wrote a million lines of quality CFD code that you can look at and check yourself. I DO KNOW how to implement a region coupled boundary condition (and you don't). So the next time you get into this situation ask yourself are you really certain enough in what you are saying to tell Hrv he does not know how todo his job. If you are, and you happen to be wrong, I will come down upon you like a ton of bricks!

So let's hear it now: go to your diffusivity fields on both sides of the interface, look at the face values and tell me if they are the same. If not, why didn't you update them correctly with a correct boundary condition?

Hrv

cosimobianchini June 22, 2011 05:41

I incurred in an analogous problem some time ago (same problem but in my own conjugate heat transfer solver: attached and detached modes are managed changing the specified boundary condition at the interface).
I solved it modifying the interface boundary condition in order to maintain a constant heat flux instead of a constant temperature gradient also in case of non-continuous conductivity.
Basically for the coupled interface both the internal and boundary coefficients were modified to guarantee continuity of heat flux and temperature on the interface itself.
1D conduction case was conformal to analytic solution to machine precision. Some more details of the implemented boundary condition may be find in the following paper presented at the open source CFD international conference 2008 http://brun.de.unifi.it/docpub/OF_Co..._C3X_final.doc

niaz June 22, 2011 07:11

new test
 
1 Attachment(s)
Dear Hrvoje
1-I checked Benk test case. My left diffusivity is 10-5 and right is 10-3: on the interface has diffusivity 1.9802*10-5 for both sides. It shows that DT in boundary has updated.
2- For second test, I have used fixedGradient as BC. So, I should give the same Gradient value on the interface. But when I solved it, I faced to new problem. The value for flux on the interface is not similar!!!!:confused:

benk June 22, 2011 13:32

For the simple model that I made with a jump in diffusivity from 1e-5 to 1e-3, I calculated the fluxes by hand:
https://spreadsheets.google.com/spre...thkey=CMCd18IP

The fluxes match exactly if you use harmonic (or localMin/localMax) in laplaceSchemes but from my calculations, it looks like using Gauss linear corrected does have a problem with the fluxes through the interface.

It's also a good idea to refine the mesh close to the interface for large jumps in diffusivity like this though. I haven't tried this.

kamkari: To calc gradients in detatched state, you could just try creating another submesh which spans all regions and map the solution to this new submesh, then you can call snGrad on fields within this new mesh without needing to attachpatches.

kamkari June 23, 2011 04:38

Dear Professor Jasak

Thank you for your explanation and sorry for annoying you. As you recommended I went to diffusivity filled. the values of updated diffusivities were the same on the both side of the interface as it was expected. Here the main problem is that the gradient of concentration (or temperature) on the sides of the interface are not correct using both linerMax and linear scheme for laplacian interpolation. I am working on your comments and Dr. Kenney results.
I also should add, it is my great honor to take part in your classes and you fail me because I will find another opportunity for learn more.

Thank for your time and patience

albem July 11, 2011 22:11

Hello

I am trying to run conjugateHeatFoam solver for the conjugateCavity problem, the program starts running but, after the first time calculation it crashed, I am using OpenFOAM 1.6-ext mounted in MacOSX 10.6.7

I followed the useful link from Hrv to instal OpenFoam

http://www.cfd-online.com/Forums/ope...-mac-os-x.html

Any help is welcome

thanks in advance


Starting time loop

Time = 0.01

Courant Number mean: 0 max: 0 velocity magnitude: 0
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 1.36284e-06, No Iterations 6
DILUPBiCG: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for p, Initial residual = 1, Final residual = 7.95294e-07, No Iterations 18
time step continuity errors : sum local = 1.41709e-08, global = -6.77626e-19, cumulative = -6.77626e-19
DICPCG: Solving for p, Initial residual = 0.431067, Final residual = 1.96388e-07, No Iterations 18
time step continuity errors : sum local = 6.11905e-09, global = 6.77626e-19, cumulative = 0


--> FOAM FATAL IO ERROR:
keyword preconditioner is undefined in dictionary "::preconditioner"

file: ::preconditioner from line 39 to line 39.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 396.

FOAM exiting




I don't get this error when using the binary mac version of 1.6-ext but I do when I use a newer commit of 1.6-ext. For the version that gives me a problem, git log gives:

commit 2f89ab8b718f44bda09af0ed421ec6751d7c52fa
Date: Fri May 27 20:53:20 2011 +0100

For the version that doesn't give me a problem, git log gives:

commit 3b1cb74951fe1630a2b3f39fc8d267622421f54d
Date: Fri Nov 26 11:08:01 2010 + 0000[/QUOTE]

benk July 11, 2011 23:00

Quote:

Originally Posted by albem (Post 315775)
--> FOAM FATAL IO ERROR:
keyword preconditioner is undefined in dictionary "::preconditioner"

file: ::preconditioner from line 39 to line 39.

It sounds like a problem with your fvSolution file. I specify the preconditioner like this:

Code:

    T+T
    {
        solver          BiCGStab;
        preconditioner Cholesky;
        minIter      0;
        maxIter      1000;
        tolerance    1e-20;
        relTol      0.0;
    };


albem September 20, 2011 19:26

Quote:

Originally Posted by benk (Post 310923)
When I try to run the conjugateHeatFoam tutorial in 1.6-ext, I get the following error message in log.conjugateHeatFoam:



I don't get this error when using the binary mac version of 1.6-ext but I do when I use a newer commit of 1.6-ext. For the version that gives me a problem, git log gives:

commit 2f89ab8b718f44bda09af0ed421ec6751d7c52fa
Date: Fri May 27 20:53:20 2011 +0100

For the version that doesn't give me a problem, git log gives:

commit 3b1cb74951fe1630a2b3f39fc8d267622421f54d
Date: Fri Nov 26 11:08:01 2010 + 0000


Hi

I have installed OpenFOAM-1.6-ext on my Mac, I could compile conjugateHeatFoam solver but when I ran it I got

--> FOAM FATAL ERROR:
Attempt to cast type wall to type lduInterface

From function refCast<To>(From&)
in file /Users/hjasak/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/typeInfo.H at line 115.


It is strange to me because the directory /Users/hjasak/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude

does not exist in my Mac

Any help is welcome

Alberto

Rakenta May 29, 2012 06:51

Hi to all!
I am new to OpenFOAM and I try to run the conjugateHeatFoam tutorial in 1.6-ext according to the tutorial of Johan Magnusson (1.5-dev).
Running the blockMesh for conjugateCavity and heatedBlock works fine, but whenever I try to run conjugateHeatFoam I get the following error message:

--> FOAM FATAL ERROR:
Cannot find file "points" in directory "constant/solid/polyMesh"

From function Time::findInstance(const fileName&, const word&, const IOobject::readOption)
in file db/Time/findInstance.C at line 148.


As I tried it for a long time to fix the problem without any success, I really would appreciate if you can give me any hints what I am doing wrong.
Thanks in advance

Rakenta June 6, 2012 07:09

Well, I solved it. Stupid mistake.
You have to create the links of the folders 0, constant and system in the heated block, rename them to solid and shift them into the folders 0, constant and system of conjugateCavity.

mm.abdollahzadeh June 18, 2013 15:24

Hi all

I want to modify the regioncouplying .

my boundary conditions is somehow"

k1grad(T)=k2grad(T)+sigma.

for this case I am already reading the the sigma field in regioncoupling. I think I need to access delta() of the coupled patch.

Any idea how to do it?

best
mahdi


All times are GMT -4. The time now is 13:38.