[panara]

I found the error.. it was a stupid mistake in the evaluation of the heat conductivity ratio..

I attach the modified version for people interested..

Daniele

conjugateFoam7.tar.gz

[otsuki]

Hi, Daniele,

Thank you for uploading interesting solver and case.
In my OpenFoam-1.2 distribution, your solver cannot
be built by wmake.
In your Make/options,

EXE_INC = \
-I$(LIB_SRC)/cfdTools/compressible \
-I$(LIB_SRC)/cfdTools/lnInclude \
...

But my system, there is no lnInclude/
in cfdTools/ directry but exist in
cfdTools/general/

The version of OpenFOAM is different with yours ?


Masato Otsuki

[panara]

You are right, I should have mentioned that I am using the 1.1 version of OpenFoam...

If you change cfdTools with cfdTools/general it should work.

You have also to change the Peqn.H file according to the 2.2 rhoTurbFoam version.

I managed to compile the application in 2.2 but I didn't test it, I get also a lot of suspicious warning...

If you are going to test it with OpenFoam 2.2 please keep me posted

Daniele

[hsieh]

Hi, Daniele,

I downloaded your solver and compiled under OpenFOAM 1.2. The followings are the warnings and errors I got (I will try to see if I can adapt the solver to OpenFOAM 1.2, but, if any one is successfully in adapting the solver to 1.2 first, it will be appreciated if you can post the fix):

SOURCE_DIR=.
SOURCE=conjugateFoam7.C ; g++ -m64 -DlinuxAMD64 -Wall -W -Wno-unused-parameter -Wold-style-cast -march=opteron -O3 -ffast-math -DNoRepository -ftemplate-depth-30 -I/home/phsieh/OpenFOAM/OpenFOAM-1.2/src/cfdTools/compressible -I/home/phsieh/OpenFOAM/OpenFOAM-1.2/src/cfdTools/general/lnInclude -I/home/phsieh/OpenFOAM/OpenFOAM-1.2/src/thermophysicalModels/specie/lnInclude -I/home/phsieh/OpenFOAM/OpenFOAM-1.2/src/thermophysicalModels/basic/lnInclude -I/home/phsieh/OpenFOAM/OpenFOAM-1.2/src/turbulenceModels -I/home/phsieh/OpenFOAM/OpenFOAM-1.2/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -c $SOURCE -o Make/linuxAMD64Gcc4Opt/conjugateFoam7.o
readPISOControls.H: In function 'int main(int, char**)':
readPISOControls.H:53: warning: use of old-style cast
readPISOControls.H:54: warning: use of old-style cast
pEqn.H:12: error: 'ddt0' is not a member of 'Foam::fvc'
pEqn.H:15: error: 'ddt0' is not a member of 'Foam::fvc'
pEqn.H:40: error: 'ddt0' is not a member of 'Foam::fvc'
pEqn.H:42: error: 'ddt0' is not a member of 'Foam::fvc'
make: *** [Make/linuxAMD64Gcc4Opt/conjugateFoam7.o] Error 1

Pei

[otsuki]

Hi, Pei-Ying,

1. modify Make/options:
EXE_INC = \
-I$(LIB_SRC)/cfdTools/compressible \
-I$(LIB_SRC)/cfdTools/general/lnInclude \
...
2. replace pEqn.H by rhoTurbFoam/pEqn.H
and modify mesh. --> mesh1.
Then you can compile conjugateFoam7 with
OpenFoam-1.2.

You must modify ConjugatePipe/system/fvSchemes
to run the case. I can't run the case yet.

Masato

[lillberg]

Hi Daniele

I converted your code to OF1.2 (happy to provide it if someone is interested) but ran into problems when trying it on your case. First iteration is fine, obviously, but in the second timestep the temperature gradient gradT1 is 10e+06, have you seen that before? Consequently the thermodynamics goes ballistic and stop with an error.

//Eric

[lillberg]

Works like a charm... awaiting the results...

//E

[lillberg]

Daniele,

The results looks fine, a very neat case to show the ability of OF to solve coupled problems. Is there any validation case with analytical/experimental values to compare with?

//Eric

[hsieh]

Hi, Eric,

I ran the case. Used foamToVTK to export two regions, then, read both regions using paraview. The liquid phase has temperature gradient, however, the temperature of the pipe region looked strange (grey color). Did you get the same results? Or how did you post process your results?

Thanks!

Pei

[hsieh]

Hi, Eric,

Never mind! I got it. I am just not use to multi-regions in paraview yet. The results seem reasonable.

Hi, Daniele,

Great job!

Pei

[panara]

Dear all,

I am trying to validate the solver for unsteady conjugate flows but I get strange results.

The test case is and hydrodynamically fully developed pipe flow with a wall suddenly set at a different temperature Tw at time t=0. The flow and The wall are at same temperature Ti at time t<0.

here you can see what I get, in the picture there are two different time steps.



It seems that at the solid fluid interface something is wrong... I am not sure if I have imposed the right thermal diffusivity for the solid..

The test case is with alpha_fluid = alpha_solid
(alpha = thermal diffusivity)

and k_solid=10 * k_fluid ( k = thermal conductivity)

I imposed the thermal conductivity ratio and I calculated the thermal diffusivity for the solid as:

alpha_solid=alpha_fluid= mu/(Pr * rho )

mu = 1.84e-5
Pr = 0.7
rho = 0.5 (T = 700 K)

I didn't use mu(T) since I am using constant thermal properties.. is it ok?

Anybody has any suggestion?

Daniele

[ankgupta8um]

Hi Mattijs,

I was trying to give a parallel run (using LAM-MPI) to the solver "simpleFoam-twoMeshes" posted by you on Friday, July 01, 2005 in this thread. I came across the following error:
----------------------------------------------
n-1<24686> ssi:boot:base:linear: booting n0 (lionxm150)
n-1<24686> ssi:boot:base:linear: booting n1 (lionxm151)
n-1<24686> ssi:boot:base:linear: finished

LAM 7.1.1 - Indiana University

mpirun: cannot start simpleFoam-TwoMeshes on n0: No such file or directory
-------------------------------------------
I would appreciate any comments on the possible reasons behind the above error.

Thanks!
Regards,
Ankur

[ankgupta8um]

Hi,

The problem I had as mentioned in the last posting is due to the fact that the executable (simpleFoam-TwoMeshes) was getting placed in $Foam_User_Appbin. Once I changed it to $Foam_Appbin, it was working fine.

-Ankur

[panara]

I forgot to mention just for records that the code has been validated. There was just a wrong sign of the heat flux at the interface. It is important to pay attention at the wall normals...!! =)

Daniele

[dmoroian]

Hi Daniele,
Is the latest code running with OpenFOAM 1.3?
I have troubles to compile conjugateFoam7 with this version. For instance there is no "findRefCell" defined anywere, or at least I coud not find it in the documentation (only findRefCell.H exists as a source file).
It would be very nice if you could post again the solver and the case files on the forum.

Dragos

[panara]

Sorry Dragos but I am using OpenFOAM 1.2 and with it I do not have any troubles...

what kind of error message do you get?

Daniele

[helmut]

Hi,

I'm trying to solve flow and temperature on a three region domain consisting of two fluid ducts with square cross section separated by a solid slab of the same size. I'd like to do this by solving fluid flow in the fluid regions, and temperature on the entire domain, but I'm getting some nonphysical values.

I have a mesh of the entire domain and submeshes of the two fluid domains. The latter were generated by the submesh utility using cellSets of the fluid regions. For simplicity, the fluid flow and the material properties are independent of temperature. The velocity fields computed on the fluid region submeshes are transferred to their respective regions of the velocity field U_ALL on the full mesh prior to the temperature calculation, which is coded as

RhoUCp = ( fvc::interpolate(rho_All*U_All*Cp_All) & meshAll.Sf() );
solve ( fvm::div(RhoUCp, T_All) - fvm::laplacian(DT_All, T_All) );

U_All is zero within the slab. The fields rho_ALL, Cp_All, and DT_All are region-wise constant with, respectively, the densities, heat capacities, and thermal conductivities of the three materials/regions. The fluid inlet temperatures are set at 300K, the exterior fluid duct walls are set at 300K, the initial interior fluid duct temperatures are 300K, and the fluid outlet conditions are zero-gradient. The slab exterior boundaries are set at 400K and the slab interior is initialised to 400K. The velocity solutions in the ducts are identical to solutions obtained from simpleFoam, and I've checked the transfer of the velocity fields. Nonphysical temperature values are occurring at the inlets and outlets. Temperatures at the inlets drop below 300K to 291K, while at the outlets there are temperatures in excess of 44500K. (See the attached figures).



Thanks for any ideas,
Helmut

[dmoroian]

Well that is bad news for me. I have to check the changes in 1.3 release. Anyway, the error is the following:

dragosm@tirian01:~/OpenFOAM/dragosm-1.3/run/conjugateHeat/conjugateFoam7> wmake
make: Inget behöver göras för "allFiles".
make: "Make/linuxAMD64Gcc4DPOpt/dependencies" är färsk.

SOURCE_DIR=.
SOURCE=conjugateFoam7.C ; g++ -m64 -DlinuxAMD64 -DDP -Wall -W -Wno-unused-parameter -Wold-style-cast -march=opteron -O3 -DNoRepository -ftemplate-depth-30 -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/cfdTools/compressible -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/cfdTools/lnInclude -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/cfdTools/general/lnInclude -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/thermophysicalModels/specie/lnIncl ude -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/thermophysicalModels/basic/lnInclu de -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/turbulenceModels -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/finiteVolume/lnInclude -I/fsd/home/dragosm/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -c $SOURCE -o Make/linuxAMD64Gcc4DPOpt/conjugateFoam7.o
readPISOControls.H:
readPISOControls.H:47: error: findRefCell was not declared in this scope
readPISOControls.H:53: warning: use of old-style cast
readPISOControls.H:54: warning: use of old-style cast
make: *** [Make/linuxAMD64Gcc4DPOpt/conjugateFoam7.o] Fel 1

Thank you for considering my question.
Dragos

[panara]

Something seems to be wrong in the file readPISOControls.H

Try to start from scratch, you have to copy together rhoTurbFoam and LaplacianFoam the ones that work with OF1.3 (that means also the readPISOControls.H version 1.3).
Then add the additional command like in conjugateFoam7.C and the file createFields.H.
Then you change mesh in mesh1 or mesh2 wherever is needed.
Control also the path in Make/options, they should be more or less a combination of the path in rhoTurbFoam and LaplacianFoam 1.3.
when you compile you can get some error from files that are not in your compiling directory and that use mesh insted of mesh1 or mesh2.
Find them e copy them in your compiling directory
changing mesh in mesh1 or mesh2 and recompile..

Good Luck,

Daniele

[lillberg]

Here's a fixed version of cunjugateFoam7 compiling under OF 1.3.

conjugateFoam7_of13.tgz

findRefCell is not used anymore, so setRefCell will use the cellnumber given in the PISO dict.

Regards

//Eric