# Cht tutorial in 15

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

December 15, 2010, 06:31
#161
Senior Member

Pawel Sosnowski
Join Date: Mar 2009
Location: Trieste, Italy
Posts: 105
Rep Power: 9
Hello Sebastian,

I am happy that you found my prev post useful

Quote:
 Originally Posted by sebonator MODchtMultiRegionSimpleFoam run for about 180 steps. After that the solver stops because it exceeds the maximum number of iterations. It seems as if my temperature field diverges... I get temperatures ranging from -1000 to 770 K but i don't know why...(The 'physical' temperature range is 300 to 600 K)
The solution clearly diverges. Supposing that you do not have any explicit heat sources (like heat generation in some filament), suppose that the temperature "only" conducts and diverges, and suppose that the "input temperature" is set only on the boundaries, then temperature has to stay between the max and min temperature on the boundaries (there is a pretty nice mathematical theorem proving that).
This means that there is something not working in the solver and/or the case is not "set up" properly.

Another possibility is that you do not provide enough corrections for solving the equations within single time step (but I am not sure about that, since I did not study deeply this algorithm).

Quote:
 Originally Posted by sebonator I think my initial conditions are not inside the convergence radius, but as the setFields-utility for example doesn't accept the -region option, I don't know an easy way to set up proper initial conditions...
Sometime earlier in this thread I explained a way of creating a multi region case "from scratch". It is not the easiest one, true, but it works and I found it quite reliable. Maybe you can give it a try.

Quote:
 Originally Posted by sebonator You advised me to check the internal boundaries. What could be done wrong on the internal boundaries?
The mixed boundaries are coupled in two points- in the file inside the time folders, and in the constant/REGION/polyMesh/boundary file. Both are crucial
for this BC to work. Check them at least three times! Some explanation about the constant/.../boundary coupling is also to be found earlier in this thread.

Hope you will also find this post useful

Best,
Pawel

 January 7, 2011, 09:52 Setting initial solutions with custom function #163 Member   Sebastian Lang Join Date: Aug 2009 Posts: 46 Rep Power: 8 Hi Pawel, Pretty much time passed since my last post and was able to make my calculations run well. My mistake was that I used the wedge boundary types for my axisymmetric simulation of the pump instead of the cyclic ones, so the momentum was not able to be transported from the impeller to the inner part of the fluid. Stupid mistake, I know, but I think thats the reason why students have to do internships ;-) Thanks you for your help! I am pretty sure I will return and post another question sometime ;-) Greetings Sebastian

February 2, 2011, 11:18
Converging?
#164
Member

Join Date: Dec 2009
Posts: 39
Rep Power: 7
Hi there Sebastian!

I also have diverging temperatures and was always suspecting that it had something to do with the initail/booundary conditions.
I see you managed to solve it:

Quote:
 Originally Posted by sebonator thanks again for your reply! I modified my boundary and initial conditions a bit and by now I got a converging calculation!
What changes did you do? How was it setup before and after? I'd really like to know how you could get it working. Are you able/allowed to post your case so I can have a look?

Quote:
 Originally Posted by sebonator Pawel, I guess you were talking about the post where you describe to use a laminar solver for the fluid regions only and use this solution as an initial solution for the chtMultiRegionSimpleFoam solver.
Speaking of that, I can just link you to the post that describes the procedure

Quote:
 Originally Posted by psosnows If I were you, I would do this case like this (it works for my problems fine): - treat the case that you have as a scrapyard from which you will build up a work case (I will call it TMP); - create "raw" work case: standard 0, constant, system folders (call RUN); - in each of standard folders in RUN create "region" subfolders; Now we build up our case. Copy: - controlDict to system; - fvS* files to each subfolder in system; - regionProperties to constant; - any files in TMP's constant subfolders to corresponding subfolders in RUN's constant; - polyMesh from TMP's 0.001 subfolders to corresponding subfolders in RUN's constant; - all data files from TMP's 0.001 subfolders to corresponding subfolders in RUN's 0; - worst part, check each boundary file in RUN if the names are different for coupled patches, and if they are the right type (directMappedPatch, explained earlier in the thread) - check all data files if all boundaries are mentioned. If not, fix it After doing that, you get a nice OF case: all constant things (like mesh, props) are in constant folder, all initial data are in 0, all simulation control are in system. It should run smoothly like a summer breeze For post processing use the "paraFoam -touch -region " trick. Hope it helps you a bit Best, Pawel ps Of course you can do things like in tutorial. In my case, after some time I simply got fed up and thought that it is better to do something slower and less automatic, but with understanding of everything, than to go with a ready code... But probably I am just strange
As stated, it takes longer time but it can really be worth it since it's you yourself who defines every single thing and knows exactly what you're doing. I used those steps with great success (except for the diverging of the temperature part of course ).

Anyway, I hope you find the time to answer my qustions and thanks in advance!

Best regards
Marco

 February 2, 2011, 17:40 #165 Member   Sebastian Lang Join Date: Aug 2009 Posts: 46 Rep Power: 8 Hi marval! First of all, at the moment I am at home, so I can't reach my data and therefore can't tell you what I exactly changed to make it converge. Hopefully I can find it out tomorrow when I am back at office. Unfortunately I can't post my cases in a complete way, as I signed a privacy policy. Maybe I am able to post some "abstract" things like my boundary files, I'll see what I can do for you tomorrow! But one thing I can tell from here is that the diverging temperature most likely is a result and not the cause of a diverging calculation. Be sure that you use fixedValue boundary conditions only at the fluid inlets and your conditions for temperature will exactly be as mine. For the turbulent variables it is the same: Inlets with a fixedValue and outlets with zeroGradient. at the walls I used the standard wall functions, of course. My advisor told me, that bad initial conditions for temperature are unlikely to be the cause for diverging calculations. As the energy equation is a linear equation, it's solution is relatively easy compared to Navier-Stokes and the pressure-equation, so I think you should look for your mistake in the velocity- and pressure-field. The initial solutions you should take care of are those for pressure and velocity, too. I realized a relative big sensitivity to the initial solutions of those "navier-stokes-fields" compared to those for temperature. That's what I can tell you by heart, as I said, I will look for the rest tomorrow. I don't know if I can tell you the exact changes I made in my boundary conditions, but at least I can tell you which boundary conditions I used in the final simulation. I'll post something for you tomorrow, Greetings Sebastian

February 3, 2011, 00:06
#166
Member

Join Date: Dec 2009
Posts: 39
Rep Power: 7
Hi Sebonator!

Quote:
 Originally Posted by sebonator Unfortunately I can't post my cases in a complete way, as I signed a privacy policy. Maybe I am able to post some "abstract" things like my boundary files, I'll see what I can do for you tomorrow!
I understand since I'm in a similar situation.

Quote:
 Originally Posted by sebonator My advisor told me, that bad initial conditions for temperature are unlikely to be the cause for diverging calculations. As the energy equation is a linear equation, it's solution is relatively easy compared to Navier-Stokes and the pressure-equation, so I think you should look for your mistake in the velocity- and pressure-field. The initial solutions you should take care of are those for pressure and velocity, too. I realized a relative big sensitivity to the initial solutions of those "navier-stokes-fields" compared to those for temperature.
Aah, right. I'm trying to mess around a little with that and also noticed big diference in the results.

Quote:
 Originally Posted by sebonator That's what I can tell you by heart, as I said, I will look for the rest tomorrow. I don't know if I can tell you the exact changes I made in my boundary conditions, but at least I can tell you which boundary conditions I used in the final simulation. I'll post something for you tomorrow,
Yes, thank you very much! It would be highly appreciated!

Regards
Marco

February 17, 2011, 10:52
Coupling problem between solid and fluid (water).
#168
Member

Join Date: Dec 2009
Posts: 39
Rep Power: 7
Greetings sebonator!

I am really thankful for your help in applying correct boundary conditions, I can now run my simulations without them blowing up.

Quote:
 Originally Posted by sebonator First of all, I am simulating an impeller side gap (is that the correct english word for the german 'Radseitenraum'???)
I have no idea of the german name. Do you both have solid and fluid regions in your case?

However, my problem now is that the fluid and solid regions doesn't couple correctly. After 10 000 iterations the fluid temperature rises just slightly over 1 degree while the solid regions seem to rise as it should.
Is there any explanation to the slow rise of the temperature?

I apply a heat flux to the top of the solid with using solidWallHeatFluxTemperature

Code:
```    cellWall
{
type 		solidWallHeatFluxTemperature;
K		K;				// Name of K-field
q		uniform 19985.49;	// Heat flux [W/m²]
value		uniform 300.15;		// initial Temp [K]

}```
I read something about the timesteps being different for the solid and fluid regions and that could be the problem, more of that in these threads

Slow convergence of chtMultiRegionSimpleFoam

and

(Heattransfer) Temperature boundary condition problem.

The coupling between the two solids is OK though,

Code:
```    solid_to_channel
{
type				solidWallMixedTemperatureCoupled;
neighbourFieldName	T;
K				K;
value				uniform 300.15;
}```
So it seems that the fluid just can't take the temperature values from the solid for the calculations, but the solid seem to "know" that there is a fluid adjacent to it because the temperature is lower in that region.

One of the big difference from the tutorial is that I use a turbulence model instead of a laminar flow, could that be a reason for the coupling problem? Would be strange if that's the case.

Regards
Marco

February 17, 2011, 16:16
#169
Member

Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
Hi marval,

Yes, I simulated the temperature distribution in a whole pump. The pump is heated up from the fluid that flows inside the impeller side gap and there are several solid regions through which the heat is transported by conduction.

Mhm, I can only guess on the reason of your problem... But what I can tell is that there should not be a problem with turbulence, because I did a turbulent simulation with the SST-model, too.

Check these things in your setup:
-Is the code you posted the correct input to the solidWallMixedTemperatureCoupled? I think there is an extra entry like 'neighbourPatch' or something like that needed which tells the boundary condition, with which other patch it should exchange the temperatures! Unfortunately I am not at office, so I can't check that now... But have a look at that, I think this keyword is missing, at least in the code you posted!
-Is the solidWallMixedTemeperatureCoupled applied for both the solid and the fluid region? Both regions need the definition of such a corresponding couple in order to work correctly!
-Make sure you don't have something like fixedValue applied to the interface on the fluid-side!
-Other possibility can be wrong material properties... for example a huge specific heat of the fluid could be a problem. But as you said
Quote:
 After 10 000 iterations the fluid temperature rises just slightly over 1 degree while the solid regions seem to rise as it should.
I think that you do a steady-state simulation, don't you? Specific heat should not play a role then.
-What might play a role is: Is it possible, that you did not scale your mesh correctly? If you built up your mesh in mm in your mesh generator (blockMEsh or gambit or whatever) and you don't scale it with 0.001 during import, openfoam will think that the mesh is generated in m! My guess is: a solid area in dimensions of 100m or so might warm up by conduction in a steady-state simulation, especially if you impose a heat flux, but maybe a 100m huge reservoir of fluid does not heat up, because its thermal conductivity might be much smaller!

A general word in the end: If you really do a steady-state simulation, you can not talk about
Quote:
 slow rise of the temperature
at all. A steady-state simulation basically does the same as an transient simulation, except: In a transient simulation the timestep is carefully controlled while in a steady-state simulation you can have different timesteps over your domain. So talking about slow or fast is not really correct in steady-state simulations.

In a case of a steady-state simulation you can only seperate between converged and not converged. Did your simulations converge? It is important to monitor the residuals of a steady-state simulation. Have a look through the forum, I found a nice script for gnuplot that reads the residuals of the fluid-region from a logfile and plots them. In this way you can easily monitor the convergence and for example stop your simulation when the residuals don't change anymore. As I said in a former post, the energy equation is a linear equation and almost always converges therefore. Because of that, you only have to care about the fluid field, because you can say that the solid regions converge before the fluid regions.

If a steady-state simulation converges and does not give the expected result, then
-your initial conditions are wrong (velocity often is critical) or
-your boundary conditions are wrong (simulation converged to a correct result, but this result belongs to incorrect boundary conditions => the computer is stupid, he can only solve what you told him!) or
-your material properties are wrong or

You see,all I can do is guess. If it doesn't help you, maybe you can post a list with all your boundary conditions for all regions like I did in my former post?

Hope that helps!
Greetings Sebastian

 February 18, 2011, 05:49 #170 Member   Sebastian Lang Join Date: Aug 2009 Posts: 46 Rep Power: 8 Hi marval, it's me again ;-) I just had a look at my cases and realized that I told you something wrong again: You don't have to indicate something like a "neighbourPatch" in your time directories. What I meant are the keywords "samplePatch" and "sampleRegion" which have to be set inside the constant/Region/polyMesh/boundary-files. Make sure these entries are correct to ensure that your fluid patches sample with the correct solid patches! Goog luck! Greetings Sebastian mirko likes this.

February 20, 2011, 18:19
Boundary conditions
#171
Member

Join Date: Dec 2009
Posts: 39
Rep Power: 7
Hi sebonator!

Brief description of my case: a steel-channel with water flow contained in a steel box that is heated up by concentrated sunlight (thus I know the heat flux, need a temperature distribution of the steel-surface, or at least very close to it). The inlet and outlet are very close to each other, this means that the fluid flows in many U-turns as it heats up along the way inside the box. This makes for a quite complicated heat transfer inside since it will be by convection and conduction in all directions.

The three parts consists of:
• fluid: The water that will be heated up.
• channel: The channel walls (decides where the water flows).
• solid: Steel plate where the concentrated sunlight hits, here I apply a heat flux boundary condition.

I have two solid parts for visualization purpose only.

Quote:
 Originally Posted by sebonator Mhm, I can only guess on the reason of your problem... But what I can tell is that there should not be a problem with turbulence, because I did a turbulent simulation with the SST-model, too.
Ok, I'm using the Launder-Sharma low-Re k − ε model (launderSharmaKE in RASProperties as RASModel). I first used simpleFoam with that same turbulence model to get an initial condition for velocity, k and epsilon. These where patched to chtMultiRegionSimpleFoam as initial conditions.

I tried to use laminar flow just to see if something happens and the temperature of the fluid rose to around 700K which of course is not possible.
That tells me at least that the fluid and solid regions are coupled and the problem is somewhere else.

Quote:
 Check these things in your setup: -Is the code you posted the correct input to the solidWallMixedTemperatureCoupled? I think there is an extra entry like 'neighbourPatch' or something like that needed which tells the boundary condition, with which other patch it should exchange the temperatures! Unfortunately I am not at office, so I can't check that now... But have a look at that, I think this keyword is missing, at least in the code you posted!

Quote:
 Originally Posted by sebonator Hi marval, it's me again ;-) I just had a look at my cases and realized that I told you something wrong again: You don't have to indicate something like a "neighbourPatch" in your time directories. What I meant are the keywords "samplePatch" and "sampleRegion" which have to be set inside the constant/Region/polyMesh/boundary-files. Make sure these entries are correct to ensure that your fluid patches sample with the correct solid patches! Goog luck! Greetings Sebastian
I checked them and they are correct, for instance:

Code:
```...
fluid_to_solid
{
type            directMappedWall;
nFaces          37021;
startFace       3025435;
sampleMode      nearestPatchFace;
sampleRegion    solid;
samplePatch     solid_to_fluid;
offset          ( 0 0 0 );
}
...```
So they do couple (verified by the divergence of the temperature with laminar flow).

Quote:
 -Is the solidWallMixedTemeperatureCoupled applied for both the solid and the fluid region? Both regions need the definition of such a corresponding couple in order to work correctly! -Make sure you don't have something like fixedValue applied to the interface on the fluid-side!
Yes, I have applied those correctly and the only fixed value for the temperature is the inlet.

Quote:
 -Other possibility can be wrong material properties... for example a huge specific heat of the fluid could be a problem. But as you said I think that you do a steady-state simulation, don't you? Specific heat should not play a role then.
I took a value of 0,6 W/(m,K) for the water and 16 W/(m,K) for the steel.

Quote:
 -What might play a role is: Is it possible, that you did not scale your mesh correctly? If you built up your mesh in mm in your mesh generator (blockMEsh or gambit or whatever) and you don't scale it with 0.001 during import, openfoam will think that the mesh is generated in m! My guess is: a solid area in dimensions of 100m or so might warm up by conduction in a steady-state simulation, especially if you impose a heat flux, but maybe a 100m huge reservoir of fluid does not heat up, because its thermal conductivity might be much smaller!
I use the scaling in meters but the points are correctly defined (e.g. [x y z] = [100mm 20mm 50mm] = [0,100m 0,020m 0,050m] ).

Quote:
 A general word in the end: If you really do a steady-state simulation, you can not talk about at all. A steady-state simulation basically does the same as an transient simulation, except: In a transient simulation the timestep is carefully controlled while in a steady-state simulation you can have different timesteps over your domain. So talking about slow or fast is not really correct in steady-state simulations.
Ok, thank you for that information. Yes indeed, I'm running a steady state simulation. Do you know more precisely how time steps affects in the solver? I always get confused when the word "time" is used in a steady state scenario.

Quote:
 In a case of a steady-state simulation you can only seperate between converged and not converged. Did your simulations converge? It is important to monitor the residuals of a steady-state simulation. Have a look through the forum, I found a nice script for gnuplot that reads the residuals of the fluid-region from a logfile and plots them. In this way you can easily monitor the convergence and for example stop your simulation when the residuals don't change anymore. As I said in a former post, the energy equation is a linear equation and almost always converges therefore. Because of that, you only have to care about the fluid field, because you can say that the solid regions converge before the fluid regions.
Yeah, I think I found the Residuals in another thread
Plotting Residuals

I can upload my boundary conditions so you can see if there are some errors in them. Please note that I did not use the "changeDictionary-approach" instead I used the approach which I mentioned in a former post.

Best regards
Marco
Attached Files
 heatedChannel.tar.gz (4.7 KB, 33 views)

March 4, 2011, 05:31
#173
Member

Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Hi all!

After a long time of absence, I'm again trying to use OpenFOAM. I'm using CAELinux which comes with OpenFOAM 1.7.

For a start, I adapted some parts of the chtMultiRegionHeater tutorial case. I've managed to set up my chtMultiRegionFoam case by hand, according to the rules that Pawel suggested in this thread. Temperature coupling works very well. In my case, I've got a solid heater (region named "GAL") completely surrounded by a fluid mesh (region named "FLUID_AMB"). The case is 2D. See also the attached picture, especially for coordinates...

As a first attempt, I adapted the tutorial case and therefore specified a velocity inlet and an outlet (left resp. right), while top and bottom were set up as walls, same as in the tutorial case. That seemed to work fine.

What I would like to set up (for now) is: The bottom of the fluid mesh is considered to be a wall, while the left, right and top boundaries should be "open atmosphere". The starting velocity should be zero on all boundaries, while all open boundaries shall work as inlet or outlet, depending on pressure and velocity.

For fluid T field, I set:
Code:
```dimensions      [0 0 0 1 0 0 0];

internalField   uniform 300;

boundaryField
{
FLUID_AMB_to_GAL
{
type            solidWallMixedTemperatureCoupled;
neighbourFieldName T;
K               K;
value           uniform 300;
}

FLUID_AMB_down
{
}

FLUID_AMB_up
{
type        inletOutlet;
inletValue    uniform 300;
value        uniform 300;
}

FLUID_AMB_left
{
type        inletOutlet;
inletValue    uniform 300;
value        uniform 300;
}

FLUID_AMB_right
{
type        inletOutlet;
inletValue    uniform 300;
value        uniform 300;

}
}```
My interpretation of that setting is, that temperatures at the boundaries are either zeroGradient (when boundary is outlet and outflow has temperature calculated) or fixedValue 300 (ambient temperature for inward flow). Is that correct so far?

The fluid p field is all set to "type calculated" and "value uniform 1e5", same as in the tutorial case. Can this p field in this context be described as something like "ambient pressure without buoyancy effects"? The total pressure would then be p+p_rgh, is that right?

For the fluid p_rgh field, I set the following:
Code:
```dimensions      [1 -1 -2 0 0 0 0];

internalField   uniform 100000;

boundaryField
{
FLUID_AMB_to_GAL
{
type            buoyantPressure;
value           uniform 100000;
}

FLUID_AMB_down
{
type            buoyantPressure;
value           uniform 100000;
}

FLUID_AMB_up
{
type        fixedValue;
value        uniform 100000-34.1388; // rho*g*h with h=3
}

FLUID_AMB_left
{
type        uniformDensityHydrostaticPressure;
rho        1.16;
pRefValue    100000;
pRefPoint    (-1.49 -1.49 0); //lower left corner location
value        uniform 100000;
}

FLUID_AMB_right
{
type        uniformDensityHydrostaticPressure;
rho        1.16;
pRefValue    100000;
pRefPoint    ( 1.49 -1.49 0); //lower right corner location
value        uniform 100000;
}
}```
Is the fixedValue for top correct? I took a height of 3m, as I set the pRefPoint with value 100000 at the lower corners. I found the general idea of those boundaries in the thread Temperature inlet/outlet boundary conditions .

Next comes fluid U field:
Code:
```dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0.01 0 0);

boundaryField
{
FLUID_AMB_to_GAL
{
type            fixedValue;
value           uniform ( 0 0 0 );
}

FLUID_AMB_down
{
type            fixedValue;
value           uniform ( 0 0 0 );
}

FLUID_AMB_up
{
type        pressureInletOutletVelocity;
value        uniform (0 0 0);
}

FLUID_AMB_left
{
type        pressureInletOutletVelocity;
value        uniform (0 0 0);
}

FLUID_AMB_right
{
type        pressureInletOutletVelocity;
value        uniform (0 0 0);
}
}```
Did I get it right, that the "value uniform (0 0 0);" directive is only needed for initialization? I set internalField NOT to zero, according to information from this post - although I would like to do so. For the walls (FLUID_AMB_to_GAL and FLUID_AMB_down) everything is fine. My interpretation of the pressureInletOutletVelocity is, that it's zeroGradient for outflow and velocity (magnitude and direction) calculated from pressure at the cells next to the boundary for inflow. Is that correct so far?

Currently, the simulation is running, gives small residuals and the numbers of iterations is between 0 and 2 for all calculated stuff. What I'm worried about, is that automatic time step adjustment produced very small time steps... therefore the simulation takes a lot of time and I don't know, whether it's a good signal or not...

In former attempts, I tried inletOutlet for velocity at the open boundaries, but this is obviously not a good choice. zeroGradient in case of outflow is nice, but what to specify for possible inflow? fixedValue uniform (0 0 0) would cause the case not to suck any fluid into the domain, while just outflow is permitted. Did I get that right? So, I switched to zeroGradient... which did the same.

Other possible choices maybe might be "directMappedFixedValue" and "fixedInternalValue", e.g. for mapping the velocity field for the cells next to the boundary to the boundary itself? Could this work or would it be likely to force instability?

Cheers
Wolle

P.S.: In the fluids mesh boundary file, I set FLUID_AMB_to_GAL to directMappedWall according to the suggestions in this thread. FLUID_AMB_down is wall, all others are simply patch type.
Attached Images
 FLUID_AMB-Domain.jpg (20.6 KB, 23 views)
__________________
CAELinux 2010 -- OpenFOAM 1.7

Last edited by Wolle; March 4, 2011 at 05:47.

 March 4, 2011, 05:45 #174 Member   Wolfram Kretzschmar Join Date: Dec 2009 Posts: 71 Rep Power: 7 After reviewing my post and having another look on the solver output, I noticed that temperature falls below ambient level. I'm going to let it run though, I'm just curious, what the results will look like... __________________ CAELinux 2010 -- OpenFOAM 1.7

 March 8, 2011, 06:27 #175 Member   Wolfram Kretzschmar Join Date: Dec 2009 Posts: 71 Rep Power: 7 Hi all! Seems like I can't make it from the tutorials boundary conditons to some "open to atmosphere" boundary conditions... First of all... is this boundary condition for fluid U fields on "open to atmosphere" patches right, if I don't have any ventilaton but velocity driven only by heating up some air inside the domain? Code: ```SOMEPATCH { type pressureInletOutletVelocity; value uniform (0 0 0); }``` As there will be fluid inflow and outflow, how do I specifiy inflow fluid temperature to be 300K? Should this work: Code: ```SOMEPATCH { type inletOutlet; inletValue uniform 300; value uniform 300; }``` Although I think, this should be correct, I always get falling temperatures... Finally, we have pressure... Code: ``` SOMEPATCH { type uniformDensityHydrostaticPressure; rho 1.16; pRefValue 100000; pRefPoint (0 -1.5 0); //lower middle value uniform 100000; }``` Is this right for the sidewalls? As far as I understood, this bc produces a gradient of p_rgh at the sidewalls from 100000 to 100000-(3*9.81*1.16)=99965,8612 at the top of the domain (domain is from y=-1.5 to y=1.5). g is defined in the constant/fluidregion/g file to (0 -9.81 0). Regarding this... would a fixedValue 99965,8612 at the top of the domain be appropriate or would buoyantPressure be better? Ciao Wolle __________________ CAELinux 2010 -- OpenFOAM 1.7

 March 8, 2011, 13:48 #176 Senior Member   Aram Amouzandeh Join Date: Mar 2009 Location: Vienna, Vienna, Austria Posts: 186 Rep Power: 8 hey wolle, i ve been working with open boundaries since a while and its not that easy (at least for me) to obtain a satisfiable solution with the first set of bcs, but its most of the time the bcs causing the problems. at the first look your bc seem to be ok, inletOutlet for T at the open boundaries is also ok. i experienced that the most crucial bcs for this type of set-up are those for p and U; its very important to apply bouyantPressure for p at all walls and inlets(!). for the open bcs i sometimes play with zeroGradient for p/U as uniformDensityHhydrostaticPressure/pressureInletOutletVelocity not always produced good results for me. I d try to apply fixedValue 99965,8612 for p and zeroGradient or inletOutlet for U at the top of the domain. in my case of a simple heated plate it helped to use a small value of U as initial conditions in the direction you expect the flow to move. What about turbulence? Do you apply a turbulence model? In case of standard k-eps i made the experience that its sometimes helpful to set the initial value for epsilon 2 to 3 magnitudes higher than the standard value. i use k = 1e-6 m2/s2 and epsilon = 1e-9 m2/s3 for the inletValue at the open boundary (atmosphere). It can also help to play a bit with the domain size. Furthermore, i always check the mass balance! as well as continuity errors. Search the wiki page for a description how to add calculation of mass flux to your code ( http://openfoamwiki.net/index.php/Sn...ting_mass_flow). Thats what came to my mind so far. hope that helps and looking forward to your results! cheers, aram

March 9, 2011, 08:36
#177
Member

Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Hi Aram,

I totally agree with you, that p and U bcs seem to be most essential. At the moment I tried to adapt the damBreak tutorial (multiphase/interfoam/laminar), which would mean: only walls, except the top boundary. In the damBreak tutorial, they use pressureInletOutletVelocity (uniform 000) for U and totalPressure for p:
Code:
```   atmosphere
{
type            totalPressure;
p0              uniform 0;
U               U;
phi             phi;
rho             rho;
psi             none;
gamma           1;
value           uniform 0;
}```
I tried to adapt this and it seems to work as far as temperature doesn't fall below 300K as I specified. What doesn't work, is to obtain a flux of fluid through the top boundary. When I use the steamline tracer or the glyph filter in Paraview, I can see, that the fluid rather circulates in the domain, than to exit (in the middle) and enter (left and right end of the top boundary) it as I would have wanted/expected. To me it seems, that also totalPressure is not correct and I don't know, whether fixedValue would be better or not. Maybe pressure at the top boundary should also be something like inletOutlet? I'm going to have a look at the different bcs source codes... maybe I can find something that fits better...

Having a look at the mass flow is a very good idea indeed!

Quote:
 Originally Posted by mabinty What about turbulence? Do you apply a turbulence model? In case of standard k-eps i made the experience that its sometimes helpful to set the initial value for epsilon 2 to 3 magnitudes higher than the standard value. i use k = 1e-6 m2/s2 and epsilon = 1e-9 m2/s3 for the inletValue at the open boundary (atmosphere).
Good point. I started of with the values and settings of the chtMultiRegionFoam tutorial, which means laminar simulation type, standard k-epsilon model. I used inital values and settings as in the tutorial, as I wanted to get it up and runnig first, adapting it to my needs later.

Thanks for your hints! As my case is rather abstract (although indeed with a practical background), I think I can post it, when it's nice and clean...

Ciao
Wolle
__________________
CAELinux 2010 -- OpenFOAM 1.7

 March 10, 2011, 04:36 #178 Member   Wolfram Kretzschmar Join Date: Dec 2009 Posts: 71 Rep Power: 7 Hi Aram! Meanwhile I tried the waveTransmissive bc and it looks good as far as the fluid now leaves the domain as expected. Temperature and velocity seem to be good although pressure raises... Therefore I tried to add mass flux calculation according to the hint you gave me. I first copied/renamed the solver, recompiled an tested: worked like the original. Then I took the files from the wiki and did, what it says there. (BTW: There's an error in the wiki. It says ' #include "computeMassFlux.H" ' but later on, the file is called calculateMassFlux.H). Sadly, I can't compile the modified solver. I tried to add the #include "buildGlobalBoundaryList.H" in various places... no luck. Here's the error message: Code: ```In file included from my_chtMultiRegionFoam.C:55: buildGlobalBoundaryList.H: In function 'int main(int, char**)': buildGlobalBoundaryList.H:4: error: a function-definition is not allowed here before '{' token my_chtMultiRegionFoam.C:130: error: expected '}' at end of input make: *** [Make/linux64GccDPOpt/my_chtMultiRegionFoam.o] Error 1``` I copied buildGlobalBoundaryList.H exactly like in the wiki... here's the modified solver code (beginning till main loop): Code: ```\*---------------------------------------------------------------------------*/ #include "fvCFD.H" #include "basicPsiThermo.H" #include "turbulenceModel.H" #include "fixedGradientFvPatchFields.H" #include "regionProperties.H" #include "compressibleCourantNo.H" #include "solidRegionDiffNo.H" #include "SortableList.H" // added for flux calculation // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // int main(int argc, char *argv[]) { #include "setRootCase.H" #include "createTime.H" regionProperties rp(runTime); #include "createFluidMeshes.H" #include "createSolidMeshes.H" #include "buildGlobalBoundaryList.H" // added for flux calculation #include "createFluidFields.H" #include "createSolidFields.H" #include "initContinuityErrs.H" #include "readTimeControls.H" #include "readSolidTimeControls.H" #include "compressibleMultiRegionCourantNo.H" #include "solidRegionDiffusionNo.H" #include "setInitialMultiRegionDeltaT.H"``` What's wrong? Ciao Wolle EDIT: Looks like I can't put the variable/function definition in main()? Well, here they call the function seperately in the code (but where exactly?): Calculation of integral boundary values __________________ CAELinux 2010 -- OpenFOAM 1.7

March 10, 2011, 04:54
#179
Senior Member

Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 186
Rep Power: 8
hey wolle!

i m using OF-1.6.x, but that shouldn t matter here. for me it works like this: buildGlobalBoundaryList.H and SortableList.H have to be include before the main in applications/chtMultiRegionFoamMF/chtMultiRegionFoamMF.C. buildGlobalBoundaryList.H is stored in applications/chtMultiRegionFoamMF. wordList globalBoundaryList and calculateMassFlux.H are then added in the fluidRegions loop. calculateMassFlux.H is stored in applications/chtMultiRegionFoamMF/fluid.

I attached you the main code chtMultiRegionFoamMF.C.

cheers,
aram
Attached Files
 chtMultiRegionFoamMF.C (3.9 KB, 7 views)

March 10, 2011, 05:09
#180
Member

Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Ah, there it is...
Calculation of integral boundary values

Here it says:
Quote:
 buildGlobalBoundaryList.H This should be included outside the main function after top level includes like "fvCFD.H". It can then be called inside the main function like so, wordList globalBoundaryList; globalBoundaryList = buildGlobalBoundaryList(mesh); Then, mass fluxes can be calculated via the following include (similar to the previous example). computeMassFlux.H
Now, I get the following error:
Code:
```my_chtMultiRegionFoam.C: In function 'int main(int, char**)':
my_chtMultiRegionFoam.C:71: error: 'mesh' was not declared in this scope```
Where line 71 is "globalBoundaryList = buildGlobalBoundaryList(mesh); " as described above. I suppose, that "mesh" is only used to describe what has to be done in something like a meta language rather than the correct syntax. What should be used there instead?

Ciao
Wolle

EDIT: Maybe one has to refer to the respective meshes of the several regions? Calculation (using the provided code) would then only be possible for the regions seperately, wouldn't it? In chtMultiRegionFoam... is there something like an "overall mesh"?
__________________
CAELinux 2010 -- OpenFOAM 1.7

Last edited by Wolle; March 10, 2011 at 05:49.

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post mech FLUENT 4 May 16, 2007 02:43 pilli4u FLUENT 2 April 2, 2007 05:09 MJ FLUENT 0 January 16, 2007 09:45 masood yooceframandi FLUENT 1 January 25, 2005 13:28 adil FLUENT 0 March 8, 2004 04:48

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