[Talaat]

Hello everyone,

I am new to OpenFOAM. I am trying to model a simple case with three regions: top reflector, bottom reflector, and core. It's assumed that the external walls are all insulated. The core generates heat. I am looking at how the temperatures change.

I set up the case and defined an fvOptions file under the constant/core. However, I am getting this warning and the temperatures are not changing:

Source core defined for field e but never used

Clearly, the program is not applying the heat source to the core but I am not sure why. I'd appreciate if someone looks at the case. The entire case with the log file could be accessed from here: https://www.dropbox.com/s/8tk27ygba0...yCase.zip?dl=0

Thank you.

[peterhess]

Replacing the parameter e with h solves the problem.

fvOptions should looks like this:


heatSource
{
type scalarSemiImplicitSource;
active true;

scalarSemiImplicitSourceCoeffs
{
selectionMode cellZone;
cellZone core;
volumeMode specific;//absolute;
injectionRateSuSp
{
h (20000 0);
}
}
}

[Talaat]

Originally Posted by peterhess

Replacing the parameter e with h solves the problem.

fvOptions should looks like this:


heatSource
{
type scalarSemiImplicitSource;
active true;

scalarSemiImplicitSourceCoeffs
{
selectionMode cellZone;
cellZone core;
volumeMode specific;//absolute;
injectionRateSuSp
{
h (20000 0);
}
}
}

I appreciate your help. But I still have a few questions: what are the units for h? does it stand for enthalpy? And what does the second term mean? Thanks.

[peterhess]

Howto use scalarCodedSource in fvOptions

See the answer 24!


https://upcommons.upc.edu/bitstream/...=2&isAllowed=y

See page 115!

[aero.rajat1]

Hi !
I am also dealing with similar kind of problem. A hot rectangular block (solid) placed inside the stream of cool air (fluid) so that the block's temperature decreases with time.
So far i know that i will need to define 2 regions- solid and fluid I am not good with multi-region meshing.
Can you tell me what to do in multi region meshing which we dont do in a normal snappyHexMesh? Suppose i have already made a snappyHexMesh for my geometry (pic attached), now what changes should i make so that it becomes a multi region mesh??
I may sound confused to you but i request you to please elaborate this thing. It is kind of a roadblock right now.

[peterhess]

Hello!

The topoSet is just sets the topology of the mesh. That means to define which part of the mesh belongs to which region.

topoSet is followed by splitMeshRegions to devide the mesh has been defined by topoSet!

If you are using snappyHexMesh, then no need to use topoSet cause snappyHexMesh do the job for you!

If you take a look to those two tutorials and compare them then you will understand more:

/tutorials/heatTransfer/chtMultiRegionSimpleFoam/multiRegionHeaterRadiation/

and

/tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/

The topologies are identical.

The difference is that the first one is made with topoSet and the second with snappyHexMesh.

Both are using:

splitMeshRegions -cellZones -overwrite

to separate the mesh to the regions.

In the case I uploaded here:

Conjugate Heat transfer- Heat generating cylinder & natural convection

I uploaded an example for the combination of snappy and simple.

Take a look to the Test case!

regards

Peter

[aero.rajat1]

Hi !
I tried using snappyHexMesh. But i am getting unusual results near the surface of my block. Everywhere else the mesh is perfectly fine.

Please have a look.

[peterhess]

Hello!

Post the case please.

Regards

Peter

[aero.rajat1]

i have attached the case here.
I made a fresh geometry, a fresh mesh also. This time the mesh looks good.
as i am noob for multi region heat transfer, I am taking snappyMultiRegionHeater case as a reference.

When mesh got finished, I used splitMeshregions and now I am confused by the outcome.

1) i defined my patch as in/out/side/block/air in the snappyhexMeshDict file in the geometry section. So the polymesh->boundary folder created should have these patches, right?
But they contain the patches which i defined in blockMeshDict file, minX/maxX./../maxZ.

2) The chanfeDictionaryDict file. Present in system->air->changeDictionaryDict. This file wasnt created automatically (after splitmeshRegions) but it was present in the reference tutorial so i copy/pasted it into this location. I dont know how to modify it. How to show inlet/outlet of my case here? the patches are named in the form of minX/maxX...


The test case which you will download wont have polymesh folder, coz of size constraints. But you can generate it using ./Allrun_pre.


I might not have conveyed myself to you in a coherent manner but there are like thousand kind of confusions going on in my head for this case.

I have attached my original problem as a screenshot here. I hope it gives you a better idea of what i am trying to do.

[peterhess]

Hello!

1) i defined my patch as in/out/side/block/air in the snappyhexMeshDict file in the geometry section. So the polymesh->boundary folder created should have these patches, right?
But they contain the patches which i defined in blockMeshDict file, minX/maxX./../maxZ.

Well, the boundaries type is defined by default as in blockMeshDict!

snappyHexMesh does not change the type.

splitMeshRegions does not change the type also. It splits the mesh generated by the snappyHexMesh with the default boundaries type defined in blockmeshDict.

Changing the type of the boundaries habens when you use changeDictionary.

In your case if you look to changeDictionaryDict for air --> line 19 to 26 here you are manipulating the boundaries type of the air.

The main cht_case/constant/polyMesh/boundary stay unchanged. Just the specific region (air) is changs after changeDictionaryDict of the air is used. i.e. cht_case/constant/air/polyMesh/boundary.


2) The changeDictionaryDict file. Present in system->air->changeDictionaryDict. This file wasn’t created automatically (after splitMeshRegions) but it was present in the reference tutorial so i copy/pasted it into this location. I don’t know how to modify it. How to show inlet/outlet of my case here? the patches are named in the form of minX/maxX...

Well, here you are able to change the type and initial conditions of the specific mesh region.

splitMeshRegions is splitting the mesh into the regions.

It also generates the initial conditions folder in the folder 0 for every region by copying the files from 0 to 0/(regions).

The files are manipulated after using changeDictionary.

You define the changes to be made in changeDictionaryDict. And you execute the changes by using changeDictionary.

It has been made this way to make the process automatic. You don’t need to change the conditions every time manually!

I added an Allrun_CD to execute the changes in changeDictionaryDict.

You can see that I changed the type of the boundaries minZ and maxZ to symmetryPlane, minY and maxY to wall and minX and maxX to patch.

You need to modify the changeDictionaryDict for both regions to setup the initial conditions.

I changed them and here is the result (see file).

Try it and post if you need help.

Regards

Peter

[aero.rajat1]

You are a real Saviour.

Right now the case runs good. But the initial conditions are not showing up in paraFoam as i want them to be(see attached picture) The temperature is the same throughout, instead the block temperature should be shown higher as defined in the problem.


In ./cht_case/0/block/T, I initialized the temperature value to be 350K. Also i did the same at ./cht_case/system/block/changeDictionaryDict.

But i cant see these changes getting reflect back in paraFoam. I dont know why?
I have a few other doubts as well:



Does the temperature values in air_to_block and block_to_air have to match?



While defining the velocity for the block, all i get access to is minZ, maxZ and block_to_air. What if i want to define each face of the block separately? top-bottom, left-right, front-back all separately?

[peterhess]

I am not sure to understand your questions right way.


Well, z diraction is defined to be symmetrical.

Your case is 2D!


The initial temperature you define will be updated during the simulation. This value is the value for the time step 0!

Yes you are able to define different temperatures for the interface between block and air. Anyway it does not make a sence since those will be equal later as the calculation progress.


To define different values for each face of the block, you need to place patches on those faces using createPatch utility!

https://www.openfoam.com/documentati...ePatch_8C.html


Yes, the sector in the middle is red. See attached files!


Regards

Peter

[aero.rajat1]

You are correct. I did some stupid things thats why it was not running at my end. Openfoam is so confusing to me sometimes, and i dont understand like 90% of it.

For now, i have my case running so i will change some variables (like material/inlet velocity etc), post process the results and see what happens.

will need your help if i get stuck somewhere.



Without you it couldn't be possible. Thanks again

[aero.rajat1]

Hello Peter!

There is a problem in the case right now. I have made slight modification to the geometry, so that there is a solid block 3*21.5*13.5 mm. It is places in an air column of 400*150*13.5 mm.

The heat source placed inside the box is absolute 7 W.

In the log file attached(compressed folder), you can see that the temperature of the solid block are shooting up to values as high as 800K ! Given that the initial block temperature was just 310K and the air temperature 300K.

Ideally the block should start cooling after sometime, since the air is flowing continuously. But here the opposite is happening.

Please have a look at this case.



Regards.
Rajat

[peterhess]

Hello!

The discussion you lead here has nothing to do with the main thread subject.

That makes the other forum user confused. Please open a new thread!

Anyway, in the last case you shared, you need to do the following changes to make the simulation running right way!

Those changes has less to do with the thread you discuss!

- snappyHexMesh --> line 20 --> snap false;

There is no need for snapping cause your geometry does not need it!

See: fig 26 – page 69 – compare B and C

https://upcommons.upc.edu/bitstream/...=2&isAllowed=y

The mesh quality for the block will become better!


- If there is no free convection (as I suppose), then the gravity need to be 0 in y direction.

You need to do that cause the velocity at the inlet is very low and the effect of the free convection is even stronger than the forced convection in X direction!


- There is no need for 14 elements in z direction in blockMeshDict, cause there is no effect in z direction. Reducing it to 1 will reduce the calculation time and does not affect the solution. Just the skewness will become worth a bit!


- In system --> air --> changeDictionaryDict --> line 93 you need to change the pressure for maxX from fixedValue to calculated! This change has no effect on the simulation


- In system --> air --> fvSolution --> line 58 you need to change the

rhoMin 1;

to

rhoMin 0.1;

This will allow the density to go down, cause the temperature in the simulation is very high and the density needs to go down!


Applying those changes is necessary to have a “good” simulation in a low calculation time.
Then the results will be “right”.

Changes has been applied. See attached file!


The temperature will still be high cause your Re is very low, block very small and 7 w is much!

The initial temperature is just initial and will be updated during the calculation.

The results does not affected via the initial temperature in the regions. The nearest the initial temperature (or any varianle) to the final result, the "faster" you get the results i.e. less itterations needed to reach convergence!

Regards

Peter

[aero.rajat1]

Dear Peter,


I have started a new thread posting my problem {
https://www.cfd-online.com/Forums/openfoam-verification-validation/204072-temperature-values-still-blowing-up.html#post699133}




Whatever changes you suggested are correct, but still my temperature values are coming in the range of 900 K!



It shouldn't go beyond 350 K ideally.
Please have a look.