Thank you Niklas!

It gives the same answer but now I have the correct unit.

Somehow i get a really cool section in the end of my channel (170 K). This is strange because my temperatures are defined as follows:

inlet (280 K) fixed value
internal (300 K) initial
heating wall (330 K) fixed value

I think this could have something tot do with the relaxationfactor for T but Ill look further into that.

Thanks again!
Erik

Hi all,

I want to add a source term to the temperature calculation for the cells that are in contact with one of the patches. So that it looks something like:

solve

(
fvm::div(phi, T)
- fvm::laplacian(alphaEff, T)
q*Aw/(rho*Cp*V)
);

where:
Aw=area of cell in contact with wall
rho=density
Cp=specific heat
V=volume of cell

for the cells that arent in contact with this patch I want to do the ordinary temperature calculation without a source i.e.:


solve
(
fvm::div(phi, T)
- fvm::laplacian(alphaEff, T)
);

Can anyone please give me an idea of how to do this?

Thank you
/Erik

[gschaider]

In other words: you want to have a patch with a constant heat flux. Like it says in the bible: "Give the emporer what belongs to the emporer and the boundary condition what belongs to the boundary condition"

What you want to do (if I remember it correctly, it can be found somewhere else on the board) is apply a fixedGradient boundary condition on that patch and leave the equation as it is (no source term).

Thanks for your answer!

I have been experimenting with the fixedboundary condition for temperature and got a few results. The problem is that TempGrad=HeatFlux/heatTransfCoeff where the heat TransfCoeff is very difficult to calculate because of the high turbulance. The heat flux is on the otherhand well determend in the experiment that im trying to reconstruct.

/Erik

[gschaider]

Then there are two ways to do it:

1. Program a new boundary condition (derive from fixedGradient etc). This is the recommended way, I guess

2. create at the start of the program a volScalarField qSrc that is 0 everywhere and q*Aw/(rho*Cp*V) in the cells near the patch. Then simply add the field as a source-Term to the equation. The fun part is setting that field at the start of he simulation:
a) find the patch
b) loop over the faces in the patch
c) set the value in the cell near the patch

Solution 1 is more elegant but harder if you never programmed a BC before, Solution 2 is mesier

Thank you very much. I guess method 2 is for me then. Time to get craking code.

are the a,b,c steps for finding the cell volumes and face areas?

I have now constructed a volScalarFild containing the constant q value. I thought I could make the q*Aw/(rho*Cp*V) calculation on an other line outside the volScalarFild implementation with the a,b,c steps.

Thanks
/Erik

Is the boundary field (patch) the outermost cell layer or is it just the surrounding of the mesh?

[gschaider]

Hi Erik!

I'm having second thoughts about solution 2: you'll have to choose a boundary condition for the patch anyway (fixedValue is out of the question and with zeroGradient I see a chance that with the source-term in the "boundary cells" I see a chance that the solution blows up, but I might be wrong).

Anyway:
@find the patch:
label patchIndex=mesh.boundaryMesh().findPatchID(patchNa me);
const fvPatch &thePatchItself=mesh.boundary()[patchIndex];

@loop over the patch:
forAll(thePatchItself,faceI) {
label cellI=thePatchItself.faceCells()[faceI];

// @set the value (just an example Aw/V):
qSrc[cellI]=mesh.Sf().boundaryField()[patchIndex][faceI]/mesh.V()[cellI];
}

Ok, thanks for your help I will try to implement this and se if it works anyway.

When calculating Aw/V as above I get the following error message:

createFields.H:54: error: cannot convert 'Foam::Vector<foam::scalar>' to 'double' in assignment

I guess that Aw is the wrong type because i can set qSrc[celli]=mesh.V()[cellI];

do you or anyone else hava a sugestion of how to make Aw the right format?

Thanks
/Erik

[gschaider]

Sorry. I forgot. Sf is a vector normal to the face whose length is the area of the surface. simply put a mag() around the vector and everything will be well.

Thank you very much Bernhard. The calculations seems to work fine. I get 60 itterations at the most for the energy calculation. Its worse with the pressure calculation which reaches 1000 iterations and causes time step continuity errors. I guess thats caused by bad intitial values.

Thank you again
/Erik

aha,..

the pressure with 1000 iterations is calculated with OpenFOAMs BCs taken from simpleFoam. My temperature calculations are done with 5 -50 iterations which may still be too much.

Anyway I need to do something about the pressure.

Thanks for your help so far anyway! It gave me better understanding.

/Erik

Hi,
I'm not getting reasonable results from my source term mentioned above which is implemented in the following way:


//find the patch:
label patchIndex=mesh.boundaryMesh().findPatchID("hole") ;
const fvPatch &thePatchItself=mesh.boundary()[patchIndex];

//loop over the patch:
forAll(thePatchItself,faceI) {
label cellI=thePatchItself.faceCells()[faceI];

//set the value (just an example Aw/V):
Aw[cellI]=mag(mesh.Sf().boundaryField()[patchIndex][faceI]);
V[cellI]=mesh.V()[cellI];
S[cellI]=Aw[cellI]/V[cellI];
}

//With the energy equation as the following:

solve
(
fvm::div(phi, T)
- fvm::laplacian(alphaEff, T)
- S*q/(rho*Cp)
);


(Aw=cell area faceing heated wall; are the seme for all heated cells)
(V=volume of cell; gets biger along heated patch)

The problem is that I need a large cell structure in order to gett more heat to the smaler cell volumes as the code above implies. When I want to make the cell structure smaller to improve the resolution It switches so that more heat is transfered to the larger cell volumes instead of the smaler ones which is expected.

Do you Bernhard or maybe someone else know what I can do to always get most heat to the smaler cellvolumes.

I would like to attach describing graphes from paraFoam but I dont know how.

Thanks
/Erik

does a finer mesh always lead to greater reselotion or could it cause computational errors as my problem stated above. Because I really expect the source to give a higher temperature in a more narrow channel.

Thanks
/Erik

[gschaider]

Hi Erik!

Problems like that is why a boundary condition should be implemented with a boundary condition (and not a source-term).

Instead of a solution I have some questions:
- are the V and Aw fields necessary? (I think temporary scalars inside the loop are sufficient)
- with higher resolution you mean: a) the faces on the patch have a higher resolution b) the third dimension pointing away from the patch has a higher resolution c) both?

Pictures would be helpful. See in the tab on the left of the Window under Documentation->Formatting how to append these

test

Hi again Bernhard

Thanks again for helping me. I choose the source term method just because it should be easier and its probably still too advanced for me to implement my own BC. Anyhow here are three pictures of my channel. the three strait patches are symmetry sides and the curved one should be a heat source. The pictures show that the temperature is higher in the more narrow part of the channel for the rough grading and vice versa for the finer grading. According to experimental data the rough grading describes the temperature most correctly.

10x10x30

15x15x30

30x30x30


kind regards
/Erik

I have made Aw and V temporary scalars once again like you sugested. I just tried makeing volscalarfields of them to se if it resolved any computational errors if there where any but I got the exact same result.

With resolution I ment a) i.e. more measuring points and better physical representation caused by better correspondance with continuity.

Thanks
/Erik

[gschaider]

Hi Erik!

The last number of subdivisions (30) which is fixed is in the direction pointing "away" from the viewer? (With resolution I meant "grid"-reolution, so I guess of the three choices given above it is c.) )

Questions about the pictures:
- in the second picture I see a discontinuity of the temperature on the curved surface. Where is that from?
- funny thing is that I can believe that the pictures with the coarsest and the finest grid (first and third) were calculated with the same conditions, but not for the second. Have you checked that?
- were all simulations done to the same level of convergence?