CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

solidWallHeatFluxTemperature at the solid solid interface in chtMultiRegionSimpleFoam

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 23, 2010, 05:31
Default
  #21
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   September 24, 2010, 06:50
Default Heat flux
  #22
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
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
Attached Images
File Type: jpg forumChannel.jpg (61.9 KB, 59 views)
marval is offline   Reply With Quote

Old   September 24, 2010, 07:12
Default
  #23
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   September 24, 2010, 07:35
Default
  #24
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
Hi Pawel and thank you for the quick reply!

Quote:
Originally Posted by psosnows View Post
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.

Quote:
Originally Posted by psosnows View Post
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:

Quote:
Originally Posted by psosnows View Post
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
marval is offline   Reply With Quote

Old   September 24, 2010, 08:49
Default
  #25
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 23
maddalena will become famous soon enough
Hi,
as Pawel told you, you can leave changeDictionary out... In any case, I noticed the following:
Quote:
Originally Posted by marval View Post
"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:
Code:
        "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]
        }
Quote:
Originally Posted by marval View Post
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.
Quote:
Originally Posted by psosnows View Post
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
maddalena is offline   Reply With Quote

Old   September 24, 2010, 08:52
Default
  #26
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   September 24, 2010, 14:17
Default
  #27
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
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
marval is offline   Reply With Quote

Old   September 24, 2010, 15:33
Default
  #28
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   October 1, 2010, 11:24
Default
  #29
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
Thank you Pawel!

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

Quote:
...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
marval is offline   Reply With Quote

Old   October 2, 2010, 04:59
Default
  #30
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   October 13, 2010, 15:28
Default
  #31
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
Quote:
Originally Posted by psosnows View Post
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.

Quote:
Originally Posted by psosnows View Post
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?

Quote:
Originally Posted by psosnows View Post
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:

Quote:
Originally Posted by psosnows View Post
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
marval is offline   Reply With Quote

Old   October 14, 2010, 06:32
Default
  #32
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   October 19, 2010, 16:30
Default
  #33
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
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:

Code:
...

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:

Code:
--> 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
Attached Files
File Type: gz runCase.tar.gz (3.9 KB, 13 views)
marval is offline   Reply With Quote

Old   October 19, 2010, 17:02
Default
  #34
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 23
maddalena will become famous soon enough
Hi Marco,
usually that error means that you mispelled the boundary definition (in constant\polyMesh\boundary) or the BC assignation (in 0\...). Indeed:
Quote:
Originally Posted by marval View Post
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
maddalena is offline   Reply With Quote

Old   October 20, 2010, 09:42
Default
  #35
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
Quote:
Originally Posted by maddalena View Post

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:

Quote:
Originally Posted by psosnows View Post

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
marval is offline   Reply With Quote

Old   October 20, 2010, 09:56
Default
  #36
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 23
maddalena will become famous soon enough
Quote:
Originally Posted by marval View Post
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...
Quote:
Originally Posted by marval View Post
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
maddalena is offline   Reply With Quote

Old   October 20, 2010, 12:12
Default
  #37
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 16
marval is on a distinguished road
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:

Quote:
Originally Posted by psosnows View Post

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.

Code:
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
Attached Files
File Type: gz thermophysicalProperties.tar.gz (474 Bytes, 10 views)
marval is offline   Reply With Quote

Old   November 4, 2010, 09:32
Default
  #38
New Member
 
Michael Stiehm
Join Date: Sep 2010
Posts: 13
Rep Power: 15
miael is on a distinguished road
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
miael is offline   Reply With Quote

Old   November 4, 2010, 10:42
Default
  #39
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18
psosnows is on a distinguished road
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
psosnows is offline   Reply With Quote

Old   November 10, 2010, 13:07
Default
  #40
New Member
 
Michael Stiehm
Join Date: Sep 2010
Posts: 13
Rep Power: 15
miael is on a distinguished road
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
miael is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wind turbine simulation Saturn CFX 58 July 3, 2020 02:13
RPM in Wind Turbine Pankaj CFX 9 November 23, 2009 05:05
Convective Heat Transfer - Heat Exchanger Mark CFX 6 November 15, 2004 16:55
Replace periodic by inlet-outlet pair lego CFX 3 November 5, 2002 21:09
CFX4.3 -build analysis form Chie Min CFX 5 July 13, 2001 00:19


All times are GMT -4. The time now is 09:11.