[psosnows]

Hello Michael,

as you pointed out, with the geometry that you have shown, it will be veeery hard (or even impossible) to acquire constant heat flux on the solidBottom-fluid interface. Its just the matter of geometry and heat transfer properties. The "hole" is closer to the heating surface, so it will faster start giving heat to the fluid, ergo it will have different heat flux from the rest of the interface. And it will change further in time... With your proposed setup it is unavoidable.

In my opinion what you should do is simply... drop the bottomSolid
Then at the fluidBottom-patch you just impose solidWallHeatFlux and voilà.

Best,
Pawel

ps
In the 4th post in this thread Maddalena cited my talk regarding general idea of temperature coupled systems. I am sure you already read it, but just want to point it out once again

[marval]

Hi everyone!

It turns out that I didn't fully understand the changeDictionaryDict files since I get the following:

--> FOAM FATAL ERROR:
Not Implemented
Trying to construct an genericFvPatchField on patch fluid_to_heater of field h

As I undestand it, the problem lies in the coupling between fluid and solid for the temperature. I post my two changeDictionaryDict-files and a picture of the geometry.

This is for the fluid:
************************************************** ************
dictionaryReplacement
{
U
{
internalField uniform (0.001 0 0);

boundaryField
{
".*"
{
type fixedValue;
value uniform (0 0 0);
}
inlet
{
type fixedValue;
value uniform ( 0.145 0 0 );
}
outlet
{
type zeroGradient;
}

}
}

T
{
internalField uniform 293;

boundaryField
{
".*"
{
type zeroGradient;
}

inlet
{
type fixedValue;
value uniform 293;
}
outlet
{
type zeroGradient;
}

"fluid_to_.*"
{
type solidWallMixedTemperatureCoupled;
neighbourFieldName T;
K K;
value uniform 293;
}
}
}

epsilon
{
internalField uniform 1.33e-7;

boundaryField
{
".*"
{
type epsilonWallFunction;
value uniform 1.33e-7;
}

inlet
{
type fixedValue;
value uniform 1.33e-7;
}
outlet
{
type zeroGradient;
}
}
}

k
{
internalField uniform 1.08e-4;

boundaryField
{
".*"
{
type kqRWallFunction;
value uniform 1.08e-4;
}

inlet
{
type fixedValue;
value uniform 1.08e-4;
}
maxX
{
type zeroGradient;
}
}
}

p
{
internalField uniform 1e-9;

boundaryField
{
".*"
{
type zeroGradient;
}

outlet
{
type fixedValue;
value uniform 0;
}
}
}
}
************************************************** ************

And this is for the solid, I do not really understand how it works at the beginning under "boundary". I think there might be errors there as well:
************************************************** ************
dictionaryReplacement
{
boundary
{
minX
{
type patch;
}
maxX
{
type patch;
}
minY
{
type patch;
}
minZ
{
type patch;
}
maxZ
{
type patch;
}
}

T
{
internalField uniform 293;

boundaryField
{
".*"
{
type zeroGradient;
value uniform 293;
}
"heater_to_.*"
{
type solidWallHeatFluxTemperatureCoupled;
neighbourFieldName T;
K K;
value uniform 293;
}
cellWall
{
type fixedGradient;
value uniform 4860;
}
}
}

rho
{
internalField uniform 8000;

boundaryField
{
".*"
{
type calculated;
value uniform 8000;
}
}
}

K
{
internalField uniform 16;

boundaryField
{
".*"
{
type zeroGradient;
value uniform 16;
}
}
}

cp
{
internalField uniform 450;

boundaryField
{
".*"
{
type zeroGradient;
value uniform 450;
}
}
}
}
************************************************** ************

Since the heater splits the fluid, do I have a similar scenario as Michael with the dimple?
Should I maybe do a separate region that splits the fluid in the middle?

Regards
Marco

[psosnows]

Hi Marco,

regarding splitting solid region into "heater part" and "fluid wall" part. This is only a good idea if you want to drop the bottom heater part, leaving only the fluid and the wall, and imposing constant heat flux from the bottom.
If you want on the other hand to have the temperature distribution also in the bottom solid part, I would strongly recommend to leave the solid as one, single region (of course if the solid has constant heat transport properties).

I do not know whether you read some of my earlier post, but I have some doubts regarding the coupling condition- that is why I think the less solidWallMixedtemperautreCoupled conditions in the simulation- the better.

And also, I do not want to discourage you, for sure learning how changeDictionaryDict works is a nice thing, but... don't you think it would be much easier and faster to write your boundaries manually? And then, when your simulation is running, you can try to dig through changeDictionaryDict on a dummy case.

Best,
Pawel

[marval]

Hi Pawel and thank you for the quick reply!

Originally Posted by psosnows

regarding splitting solid region into "heater part" and "fluid wall" part. This is only a good idea if you want to drop the bottom heater part, leaving only the fluid and the wall, and imposing constant heat flux from the bottom.
If you want on the other hand to have the temperature distribution also in the bottom solid part, I would strongly recommend to leave the solid as one, single region (of course if the solid has constant heat transport properties).

Yes, I want to have the distribution in the bottom part of the "heater"(it's just a solid part and I didn't mind changing the names of the tutorial case ). Fortunately, I created the solid region as one to start with so there is no problem.

Originally Posted by psosnows

I do not know whether you read some of my earlier post, but I have some doubts regarding the coupling condition- that is why I think the less solidWallMixedtemperautreCoupled conditions in the simulation- the better.

I read through them, I just think that I confused them (similar names). I still get the same error when I change to solidWallMixedtemperautreCoupled though. Maybe related to the following:

Originally Posted by psosnows

And also, I do not want to discourage you, for sure learning how changeDictionaryDict works is a nice thing, but... don't you think it would be much easier and faster to write your boundaries manually? And then, when your simulation is running, you can try to dig through changeDictionaryDict on a dummy case.

Hehe, it's ok. But I don't really understand what you mean by writing my own boundaries, didn't I do it in a way by (trying to) modify the tutorial case?

Regards
Marco

[maddalena]

Hi,
as Pawel told you, you can leave changeDictionary out... In any case, I noticed the following:

Originally Posted by marval

"heater_to_.*"
{
type solidWallHeatFluxTemperatureCoupled;
neighbourFieldName T;
K K;
value uniform 293;
}

This has absolutely no meaning! There are two BC: solidWallMixedTemperatureCoupled and solidWallHeatFluxTemperature. I think you are going to use the latter, so the right syntax is, for example:

        "heater_to_.*"
        {
            type            solidWallHeatFluxTemperature;
            K               K;                  // Name of K field
            q               uniform 1000;       // Heat flux / [W/m2]
            value           uniform 300.0;      // Initial temperature / [K]
            gradient        uniform 0.0;        // Initial gradient / [K/m]
        }

Originally Posted by marval

I do not really understand how it works at the beginning under "boundary".

At the beginning it works on constant/polyMesh/boundary file, applying a "patch" type boundary on all the minX, maxX, minY, minZ and maxZ boundaries.
This may be not the solution to your problem, but hope it helps.

Originally Posted by psosnows

I do not know whether you read some of my earlier post, but I have some doubts regarding the coupling condition- that is why I think the less solidWallMixedtemperautreCoupled conditions in the simulation- the better.

I agree with Pawel about the solidWallMixedTemperatureCoupled precision. I experienced some difficulties on making chtMultiRegionFoam works if applying a volume heat source, and I doubt of its precision on other kind of applications. And Pawel for sure has more experience on that than me...
Regards,

mad

[psosnows]

Hi Marco,

by writing BC by yourself, I mean setting up the case from scratch, without using changeDictionary utility.

Lets look at it from the top-
what does chengeDict do? It is an utility which allows to prepare the case automatically. It helps to create p, rho, T, U, K (all necessary fields) in "0" folder.

My point is that you can do it manually, just writing those files by yourself.
And that way changeDict becomes unimportant, and can not generate errors because you know what are the boundaries (in the end you wrote them).

Best,
Pawel

[marval]

Hi!

That sounds like a good idea actually, I will try to create the files in the 0-directory myself. I did never realize that you could get around it in that way since I thought the cht-solver worked that way (with changeDict) and it was the whole point using them.
Should I create two folders inside named "fluid" and "heater" for the respective region?

Now my question is how to define the coupling between fluid and solid in the 0-directory since it will have some "internal faces" (fluid to solid-coupling inside the geometry). Don't know if it can be defined in blockMeshDict, if it's ever needed to.

I suppose the makeCellSets is still needed to split the geometry.

Regards
Marco

[psosnows]

Hi Marco,

if you want to have a quite clear understanding how to couple two regions, I strongly recommend to read this thread. It is very long, true, but has all the info you need. If you do not want to read all of it, start from the end

best,
Pawel

[marval]

Thank you Pawel!

I read through the entire thread and it was very informative.
This was not clear to me though:

...I always created "tmp" case for decomposition, and "runCase" for the simulation, which had the mesh in "const" folder (copied from 0.001 tmp folder), and no meshes in 0 starting folder.

Did you create two folders with those names ("tmp" and "runCase"), what for?
And what do you mean with decomposition?

Regards
Marco

[psosnows]

Hi Marco,

next time please give me some link to the post that you are mentioning- it was half a year ago

This post was about preparing a "case" for work. The idea in cht-tutorial was: create one big mesh, then use splitMesh tool to decompose it into regions.

splitMesh writes the decomposed big mesh in "constant" folders in newly created time folder 0.001. I did not like this way, so I proposed to create a tmp case, where one plays with the mesh, and when everything is ready- copies the tmp to runCase folder and runs the simulation.

Thats it.

Best,
Pawel

[marval]

Originally Posted by psosnows

next time please give me some link to the post that you are mentioning- it was half a year ago
l

Ooops, sorry! Didn't pay attention to that.

Originally Posted by psosnows

splitMesh writes the decomposed big mesh in "constant" folders in newly created time folder 0.001. I did not like this way, so I proposed to create a tmp case, where one plays with the mesh, and when everything is ready- copies the tmp to runCase folder and runs the simulation.

That part I don't get, about the creation of folder 0.001. It doesn't do that in the tutorial case.
I suppose I create the mesh with blockMeshDict as ususal but how do I define which parts that are solid/fluid?

Originally Posted by psosnows

This is how I do it in the approach I propose:

0-folder: contains domain folders with their respective data fields without polyMesh folders.

constant-folder: regionProperties file and domain folders. Each domain has properties files, AND polyMeshes folder.

system: in main folder controlDict and individual domain folders. In domain subfolers: fv-files.

(no changeDictionaryDict is required, it is used for automatic decomposition)

I also note, that the polyMesh folders require only standard files in them: boundary, owner, neighbour, points, faces. All other may be thrown out (repeating after Einstein: "make everything as simple as possible, but not simpler" )

I attach a picture showing "general idea" of multi region structure I use.

Hope it helps a bit

The picture you attached:
http://www.cfd-online.com/Forums/att...iregfolder.jpg

About the different regions:

Originally Posted by psosnows

I also note, that the polyMesh folders require only standard files in them: boundary, owner, neighbour, points, faces. All other may be thrown out (repeating after Einstein: "make everything as simple as possible, but not simpler" )

Do I only need one blockMeshDict in polyMesh-directory and just copy the above mentioned files to their resective region-directories?

Thanks for your patience and your replies!

Regards
Marco

[psosnows]

OK, lets do it from the top.

First thing to know is how OF stores data. It requires folders: system, constant, <time>. Data are stored in time folders and do not contain any mesh information. Mesh is stored in polyMesh folder. It can be put in two places. First, most common is inside constant folder. Second place is the time folder. The 2nd approach is usually used for time-varying mesh. In one of previous chtMRFoam tutorials one also used this approach while running splitMesh.

In multi region case, in each of folders: system, constant, <time>, one requires to put "domain" folders. Each of those folders contains data which correspond to a specific region. The regions themselves are defied in constant/regionProperties file.

Going back to case organization regarding mesh. I do not like the 2nd approach, that is why I recommended the pre-processing procedure "tmp- run_case". First we create mesh in "tmp" which is saved using the 1st approach, and then manually we move it to constant/domainNames/polyMesh folders to acquire 2nd way of organizing files. After that we create "run_case" and use it to run the case.

Regarding "blockMeshDict"- this file is used only during pre-processing to create the mesh. After that, when you want to run the solver it is no longer needed (and even can be deleted).

I really do not know how to put this topic in other way


For the last words, I want to show completely different way of pre-processing.

Create empty multi-region case "runCASE" (without files, just right folder structure). Create a "TMP" case. In it, create a blockMeshDict for only one region. Run blockMesh. Copy acquired mesh from TMP to respective "runCASE" constant/region/polyMesh. Repeat procedure for all reigons.
After mesh is created, one has to organize "boundary" files in the right way, create initial fields, etc. This procedure is slower, requires more work but it works. And after one succeeds, he finally knows how it all works.

Best,
Pawel

[marval]

It's clear to me now, thank you!

Now I know exactly what the boundaries are by defining everything myself (like you proposed) and editing the files for example:

...

fluid_to_solid
{
type               directMappedWall;      // Changed from wall to directMappedWall
nFaces           10300;                      // Leave as it is
startFace        600000;                    // Leave as it is

// Added for coupling
sampleMode    nearestPatchFace; 
sampleRegion  solid;
samplePatch    solid_to_fluid;
offset             (0 0 0);
}

...

Had to figure out that you also needed the following in TMP-folder to be able to run blockMesh:

* controlDict file in TMP/system
* blockMeshDict had to be in TMP/constant/polyMesh

I guess these are basic and obvious things you need to know in OpenFOAM that I didn't know, but now anyone that didn't know can read this and learn .

Anyhow, I still get the following error when I try to run chtMRSimpleFoam:

--> FOAM FATAL ERROR: 
Not Implemented
    Trying to construct an genericFvPatchField on patch fluid_to_solid of field h

Don't understand what the error means (I got the same error in an earlier post in this thread). Probably coupling problem(s).

If anyone wan't to look at the files your welcome to do so (only the more relevant files are included).

The reason I have two solid regions are for visualization purpose mostly since the channel -region will be a more complex geometry later on (running some testcase now to get it working). Just in case someone was wondering.

Regards
Marco

[maddalena]

Hi Marco,
usually that error means that you mispelled the boundary definition (in constant\polyMesh\boundary) or the BC assignation (in 0\...). Indeed:

Originally Posted by marval

fluid_to_solid
{
type directMappedWall; // Changed from wall to directMappedWall
nFaces 10300; // Leave as it is
startFace 600000; // Leave as it is

// Added for coupling
sampleMode nearestPatchFace;
sampleRegion solid;
samplePatch solid_to_fluid;
offset (0 0 0);
}

is not right. You should use type directMapped and not directMappedWall. Try to correct this and let me know if it worked. You got the same error some posta ago because you used a non existant BC, as I pointed out here.

Have fun!

mad

[marval]

Originally Posted by maddalena

is not right. You should use type directMapped and not directMappedWall. Try to correct this and let me know if it worked. You got the same error some posta ago because you used a non existant BC, as I pointed out here.

Thank you Maddalena, but I still get the same error.
When I check the boundary- file in the tutorial case (which runs changeDictionary) the created type is directMappedWall. Why the difference?

As I carefully read through some earlier posts, you guys didn't actually recommend solidWallMixedTemperatureCoupled (swMtc).
For instance:

Originally Posted by psosnows

I do not know whether you read some of my earlier post, but I have some doubts regarding the coupling condition- that is why I think the less solidWallMixedtemperautreCoupled conditions in the simulation- the better.

Should I instead use solidWallTemperatureCoupled (swtc) for coupling the temperature?

Btw, is solidWallHeatFluxTemperature (swHFt) a suitable boundary condition for a system? Since the others (swtc, swMtc, swHFtc) are more like coupling conditions inside the system.

I will continue to look for misspelling errors for the moment, could be more more of them (if you have time I posted the relevant files in my earlier post so you can look at them ).

Regards
Marco

[maddalena]

Originally Posted by marval

Thank you Maddalena, but I still get the same error.
When I check the boundary- file in the tutorial case (which runs changeDictionary) the created type is directMappedWall.

Ops... My fault. directMappedWall is ok indeed...

Originally Posted by marval

As I carefully read through some earlier posts, you guys didn't actually recommend solidWallMixedTemperatureCoupled (swMtc).

Well... let us say that Pawel, I and some other guys worked a bit on the subject, and discovered that the coupling condition is not so fine for some kind of applications. You can find a discussion on the subject in this post. But maybe this is not your case...
Regards,

mad

[marval]

Hmm, swMtc maybe don't work so well then.
I looked at the other alternatives, but the question is:

Do these even exist in OF-1.6.x?
* swtc (solidWallTemperatureCoupled)
* swHFtc (solidWallHeatFluxTemperatureCoupled)

I did try anyway to do as proposed by Pawel in another post by using swHFtc and swtc:

Originally Posted by psosnows

The conclusion is: if you want swHFtc to work, you will need swtc on the neighbour patch. You can have two swtc on bot regions, but this way you will set both boundaries as the value of the second filed (in fact they will not be coupled).

But with no sucess, also not sure which side should be swtc or swHFtc.

Could it be something with the thermophysical properties in fluid region? Wondering since the error is displayed in the following way.

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>


--> FOAM FATAL ERROR: 
Not Implemented
    Trying to construct an genericFvPatchField on patch fluid_to_solid of field h

    From function genericFvPatchField<Type>::genericFvPatchField(const fvPatch& p, const DimensionedField<Type, volMesh>& iF)
    in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 45.

I have changed from air to H2O in that file anyway (I attach it too), don't know if you're allowed to do that.

Regards
Marco

[miael]

Hello everybody,

i did some cht-simulation but i´m still confused about the mixing BC. I use solidWallMixedTemperatureCoupled as it was mentioned in this thread. But how does this BC works?

That I found out is, that the valueFraction decides whether it is fixedValue ( valueFraction=0) or zeroGradient (valueFraction=1) or it could be something in between. The valueFraction is calulated by:

valueFraction()=nbrKDelta/(nbrKDelta+myKDelta)

with:

nbrKDelta = nbr.Field.K()*nbrPatch.deltaCoeffs();
myKDelta = K()*patch.deltaCoeffs();

so the valueFraction depends on the Kfield of the coupeld regions. What I don´t know is the meaning of the "deltaCoeffs()" and how does the BC work, when the valueFraction is between 0 and 1???

Thanks a lot!!

Michael

[psosnows]

Hello Michael,

I suppose that you are working on OF-1.7.1 (please state if otherwise- there were some major changes in this BC).

You got quite deep into C++ jungle of boundary condition implementation.
As I mentioned, there were big changes since OF-1.6 and this BC became very abstract (this means- good knowledge of C++ is needed).

Regarding deltaCoeffs().
It is a member function called for "patch" object which is of "fvPatch" type.
Here is where the deltaCoeffs are calculated: makeDeltaCoeffs()
In general, they are distances from the face to the centre of the cell.

Regarding valueFraction(), etc.
In the newest swMixedTempCoupled one just sets valueFraction, rfValue and refGradient, then calls "mixedFvPatchScalarField::updateCoeffs();" and lets OF magic do the rest. In fact, during solving process, OF calls member functions of mixedFvPatchField, which define values, gradients and all the other needed stuff. And those functions take as parameters the ref-Data set by us in the updateCoeffs() of swMixedTempCoupled function. If you want to see exactly how the values are calculated- go to mixedFvPatchField above.

All above is just about the "mechanics" of the BC (and requires only jumping from tree to tree in the C++ jungle). I can not help with the theoretical background of this mechanics: I am simply not aware of it- my bad. Can anyone give some references please?

Hope it helps a bit,
best,
Pawel

[miael]

Hello Pawel,

Thank you and yes it helps a lot! So this BC decides due to the K-value and the cellsize whether it is fixedGradient, fixedvalue or something in between. So this BC is the implementation of the third type of BC (other names I found for that are Robin-BC or Newton-BC). Am I right??

Thanks

Michael