Hi Mike, you wrote, you had a
 

Hi Mike,
you wrote, you had an error, like

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

Can you say, how do you solved it?

When I run blockMesh over the case from Hrv, this error come. Without it, I can run the case with conjugateHeatFoam without problems.

Jens

Ups. I haven't read the messa
 

Ups.
I haven't read the messages on Jan 08 carefully. I have to change the boundary file per hand.
Sorry!

Jens

Hrv, I was poking around a
 

Hrv,
I was poking around at the insides of the solver trying to understand it, and I was looking at its accuracy. I had noticed what looked like a temperature discontinuity at the boundary of the two meshes so I was investigating.

Here's what I came up with:
The easiest way I could think of to test things was to check that the two boundary conditions, heat flux and temperature, were satisfied. I altered the heatedBlock initial conditions such that the DT internal field is now 4e-3. In steady state, this should correspond to a conductivity 4 times greater should be reflected in the solution.

I had some issues with using sample with the given meshing, so I refined it to a (50 50 1) mesh for both liquid and solid regions and reduced the Courant number in the solver by a factor 5 to keep the solver happy. The simulation is run to 10 seconds. The solid has a thermal time constant of 2.5s with DT=4e-3 and 0.1m side length, so we should have reached steady state by then (the fluid is mixed and should likewise hit steady state by then).

The result is that there is a mismatch in the boundary conditions, as near as I can tell.

https://netfiles.uiuc.edu/mjaworsk/s...M/two-mesh.png
shows the two regions plotted in paraview. The refined mesh which looks much better compared to the (10 10 1) mesh provided.

Looking closely at the actual temperature profile through the y=0.05 point gives the following:
https://netfiles.uiuc.edu/mjaworsk/s...two-region.png
with linear least squares applied on the last 5-10 data points next to the boundary. The slopes are shown on the plot.

One would expect, by conservation of heat flux, that the slopes would be proportional to the ratio in conductivities. However the ratio doesn't reflect 0.25 as expected, rather yields something like 0.3 (depending on which points you use to do the curve fit.

In addition, the boundary doesn't quite match the expected location based on where the temperatures actually line up.

Could you comment on the accuracy of the coupledfvScalarMatrix methods you used for the solver? And, based on that method, does the boundary get moved a little or such that would explain the results I have?

Thanks and mostly thank you for your patience as I'm learning quite a bit at the moment.

Regards,
Mike Jaworski

Yes I can: there's nothing wro
 

Yes I can: there's nothing wrong with the code, you are just not using it appropriately. I have, of course, checked the flux balance etc. and it is perfectly conserved.

What is required (are you using a tutorial and the code I wrote?) is to have a diffusivity FIELD and not just two dimensioned scalars. If you form the matrices with the diffusivity field (which also has the coupled boundary condition) all will be well.

If, on the other hand, you do it with two scalars, you will have two different values of diffusivity on the two sides, leading precisely to the problem you describe. I have seen it in early days of development and solved it about 5 mins later.

In any case, have a look at the patch values for T on the two sides and you'll see if the value is identical or not. Regarding the discretisation, it is identically the same as other coupled b.c.-s, eg. cyclic or processor, and I'm 100% sure I didn't mess those up.

Comments?

Hrv

Oh, some more things, regardin
 

Oh, some more things, regarding the accuracy. The boundary operates in both coupled and decoupled modes and the code needs to recalculate the weighting factors correctly. There is a functionality in the coupled version of the fvPatch which will allow you to decouple and re-couple the boundary, re-calculating the weghts (e.g. coupled w = 0.5 on a uniform mesh and 1 when decoupled). Maybe that's your problem...

Hrv

Hrv, Thanks much for the q
 

Hrv,
Thanks much for the quick response.

I was using the solver provided and the tutorial files as provided with only modification being mesh refinement. This could also be some artifact, maybe, of how the sample utility works?

I did the above analysis on the provided tutorial files (original mesh) and here's the graph:
https://netfiles.uiuc.edu/mjaworsk/s...OAM/course.png

I also sampled the DT field to check that one as well.

The discontinuity is more obvious which is why I went to mesh-refinement before posting anything.

However, when I checked the patch values using sampleSurface, they line up exactly. This is very confusing.

I've also uploaded the sample dictionary used to pull the data points out:
https://netfiles.uiuc.edu/mjaworsk/s...OAM/sampleDict

I'm, of course, open to every possibility that I'm using sample or the solver wrong, since I'm new to FOAM, it's about all I can do to try and keep up with much of this.

Also, I constructed a very simple case to look at pure conduction by setting the moving wall boundary condition to (0 0 0) velocity. Keeping all other constants from the original tutorial files the same, in theory, this should just be a straightline across the screen and there's some funny business, it seems, at the interface.

https://netfiles.uiuc.edu/mjaworsk/s...AM/conduct.png
Here's the paraFoam view of it and you can see the change in slope at the beginning and end of the paraview probes:
https://netfiles.uiuc.edu/mjaworsk/s...conduction.png

At the same time, however, if I fit a single line at the start of one region, it runs right through and provides the correct solution.

Thanks for the help,
Regards,
Mike J.

Hrv, In another question r
 

Hrv,
In another question regarding the initial/boundary conditions set in the <case>/0 file:

the internel field is specified as <x> and then the same value is assigned to the right patch. This is mirrored in the heatedBlock/0 file as well. If I want to test with two different diffusivities, <x> and <y>, should that patch value be anything other than the internel value, or does the subordinate region (heatedBlock in this case) need to match the conjugateCavity patch value or is there anything I should be aware of in there?

Thanks again,

Mike J.

Hi again! I think I've
 

Hi again!

I think I've determined that it is a problem with the sample utility. or, not so much a problem, but maybe I'm not setting the interpolation scheme correctly.

https://netfiles.uiuc.edu/mjaworsk/s...FOAM/2-mat.png
that figure shows a pure conduction test with 2 dissimilar materials (one 3x as diffusive).

I changed the sampleDict to use interpolationScheme cell and sampling type midPointandFace to obtain the data. This obtained the x-direction data. The y-direction data was obtained using sampleSurface looking at the left and right patches themselves.

The patches' temperatures perfectly match but there is some disconnect between what sample says the face temperature is at the interface. It appears, though, that the solver is working fine and this is some artifact with sample. I tried setting the interpolationScheme to cellPointFace but it generates an error.

I'm sure I'm missing a lot of the finer details here, but thank you for your patience.

Regards,
Mike J.

hi, I am very new to openfo
 

hi,

I am very new to openfoam, 2days experience.
Can anyone post or direct me on a "how to" use this code? I have been looking arround, hoping to find my way out from the tutorials.

Thank you.

Hi Florante, Did you go th
 

Hi Florante,
Did you go through the tutorials in the user manual and programming manual (there are three more examples in that). Also, the "how to" use the code is not very clear. Are you wanting to run new cases with conjugateHeatFoam or some other solver or build new solvers?

Regards,
Mike J.

Michael, Thank you very muc
 

Michael,

Thank you very much for the quick reply. I am currently working on my way on understanding the tutorials. I got a little grasp on them now, but still a lost.

What I mean with "How To" is to use it with other cases. Honestly, I havnt done any case of my own yet. I have just started with the tutorials.

I was hoping that there is a visual tutorial on using openfoam with a lot of comments as what I have seen in the CAElinux.com wiki. There was a flash tutorial in using openfoam.

http://www.caelinux.org/wiki/index.php/Doc:CAETutorials

Can you recomend more tutorial like these?

Thank you very much for helping me find my way in this jungle.

Thank you.

Florante, The tutorials in
 

Florante,
The tutorials in the User Guide are about as visual as I've seen so far. You might also go through this "getting started with OpenFOAM" paper which is on Hrv's website.

http://powerlab.fsb.hr/ped/kturbo/OpenFOAM/docs/gettingStartedWithOpenFOAMLeroux _Sep2007.pdf

That document has some graphics in it as well, as I recall.

Regards,
Mike J.

What solver would be the best/
 

What solver would be the best/easiest to try and use conjugateHeatFoam with to simulate convection boussinesqBuoyantFoam, buoyantFoam, or buoyantSimpleFoam ?

Hi to All, first of all, th
 

Hi to All,

first of all, thank You Dr.Jasak for developing this solver!!

My Problem: How is it possible to change the patch-type of the solid-region called patch "right" from fixedValue to fixedGradient. If I change it in ../solid/0/T form fixedValue to fixedGradient the solver works fine, but if I want to do postprocessing, paraFoam and foamToVTK mentioned about the fixedGradientPatch. The exact error-Message is :
Time constant

Internal : "/home/studium/OpenFOAM/OpenFOAM-1.4.1-dev/tutorials/conjugateHeatFoam//heatedBl ock/VTK/heatedBlock_0.vtk"
Original cells:100 points:242 Additional cells:0 additional points:0

Patch : "/home/studium/OpenFOAM/OpenFOAM-1.4.1-dev/tutorials/conjugateHeatFoam//heatedBl ock/VTK/topAndBottom/topAndBottom_0.vtk"
Patch : "/home/studium/OpenFOAM/OpenFOAM-1.4.1-dev/tutorials/conjugateHeatFoam//heatedBl ock/VTK/left/left_0.vtk"
Patch : "/home/studium/OpenFOAM/OpenFOAM-1.4.1-dev/tutorials/conjugateHeatFoam//heatedBl ock/VTK/right/right_0.vtk"
Patch : "/home/studium/OpenFOAM/OpenFOAM-1.4.1-dev/tutorials/conjugateHeatFoam//heatedBl ock/VTK/frontAndBack/frontAndBack_0.vtk"
Time 0


--> FOAM FATAL ERROR : Shadow of regionCouple patch left named right is not a regionCouple.
This is not allowed. Please check yuor mesh definition.

From function void regionCouplePolyPatch::calcInterpolation() const
in file meshes/polyMesh/polyPatches/constraint/regionCouple/regionCouplePolyPatch.C at line 81.

FOAM aborting

Where is my mistake?
I've only edited the ../solid/0/T-file and only changed the bc-type from fixedValue to fixedGradient.

Any hint will be welcome!

No, you also changed the bound
 

No, you also changed the boundary file. Have a look at the constant/polyMesh/boundary and constant/solid/polyMesh/boundary. There I define two patches that are coupled to each other and BOTH have to be of type regionCouple:


left
{
type regionCouple;
nFaces 10;
startFace 200;

shadowRegion region0;
shadowPatch right;
attached on;

}


right
{
type regionCouple;
nFaces 10;
startFace 200;

shadowRegion solid;
shadowPatch left;
attached on;


}

The error message tells me you've messed one of them up and that one called right is not of type regionCouple.

How did this happen?

Also, I cannot figure out what the message should say so that you find this without my help - please let me know how I should change it.

Hrv

Hi Hrvoje, hi Jens, I´ve so
 

Hi Hrvoje, hi Jens,

I´ve solved the Problem for me by doing the following steps :

1.) I changed the patch "right" in .../conjugateCavity/0/solid/T from fixedValue to fixedGradient

2.) run the solver without problems

3.) for postprocessing I changed in the ../constant/solid/polymesh/boundary file :


left
{
type regionCouple;
nFaces 10;
startFace 200;

shadowRegion region0;
shadowPatch right; // -->changed to "left", but only for converting to *.VTK
attached on;
}

4.) now I can use foamToVTK/paraview for visualisation

I'm not sure, if I made a mistake while setting up the case. But if my understanding of the "regionCouple"-bc is right, it points to the correspondenting patch of the other mesh and has nothing to do with the patches in the same mesh.

Example :
in ../constant/solid/polymesh/boundary

left
{
type regionCouple;
nFaces 10;
startFace 200;

shadowRegion region0;
shadowPatch right;
attached on;
}

shadowPatch "right" points to the patch "right" in the region0-domain and has nothing to do with the patch "right" in the solid-mesh?

My Problem was, that if I wanted to postprocess only the heatedBlock-files with
foamToVTK ../conjugateHeatFoam/ heatedBlock
foamToVtk gave me the error-message.
So it seemed to me, that foamToVTK mentioned about the patch "right" in the solid-domain, which is, at my understanding of the regionCouple-BC, not involved in the conjunction between the two regions.

As a conclusion, in general I'm very happy about this solver, and with the workaround of changing the constant/solid/polymesh/boundary-file after running the solver I'm also able to postprocess the case.

I hope I described the problem I had well.

Thank you all again for your suggestions,

Johannes

OK, so what happened here is t
 

OK, so what happened here is that the region couple has tried to find its neighbour in order to perform face interpolation. If you haven't requested face interpolation, this would not have happened - I do not see any need for it in foamToVTK.

The hack you did is perfectly fine and will do no damage... but is not very practical (you need to change this every time you want to see the results. There's not much I can do in regionCouple itself, but I can change foamToVTK not to call surface interpolation. Could you please produce and post a complete track-back and we can take it from there.

Incidentally, I have been visualing this using paraFoam without any problem.

Hrv

Hi Hrv, you´re right. I've
 

Hi Hrv,

you´re right. I've refined the mesh of the fluid region, so the faces don´t fit and interpolation was needed. So my question:
What do you mean by a "complete track-back"? Uploading the case or the complete output of foamToVTK? I'll support a solution as I can.

I´ve reproduced the problem with a second case with a hex-mesh for the fluid-region and a tet-mesh for the solid region.

Johannes

Dear All, maybe it is a stu
 

Dear All,

maybe it is a stupid question, but I have to confess that I cannot see the solution right now...

how should I set the initial fields and BCs to simulate a case with two solids with the same heat diffusivity but different heat conductivity??

Regards

Daniele

Hrv, I have a question reg
 

Hrv,
I have a question regarding the machinery of the region coupling code. For my own purposes, I modified the solver in a similar way that Daniele did to include two new fields, k and rhoCp (thermal conductivity and capacity) so that at a later time, I could make these temperature dependent variables. I made suitable alterations to the energy transport equations to take this spatial variation into account. I am wondering, however, which fields *must* be coupled.

Specifically:
what does it mean in the "createSolidFields.H" file the comment:
//on creation of both diffusivities, couple the sides
k.correctBoundaryConditions();
kSolid.correctBoundaryConditions();

This is after my own alterations to the code, of course. They originally read DT instead of k.

Do I need to couple rhoCp in the two regions as well? I would think not since this term is not present in the standard heat transfer boundary conditions so I left it out in mine. What does this function do?

Finally, in the matter of solving the energy transport equation: I read in the manual that all the time discretization schemes are implicit. There is a stability problem with heat conduction problems related to the cell Fourier number, but as I recall, this only applies to explicit schemes. Does this mean I don't have to worry about the Fourier number in OpenFOAM and just set things according to the Courant number?
Thanks for your time.

Regards,
Mike