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 |
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: |
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. |
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 |
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] |
Quote:
Code:
T+T |
Quote:
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 |
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 |
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. |
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 19:58. |