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

Cht tutorial in 15

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

Like Tree4Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   December 15, 2010, 06:31
Default
  #161
Senior Member
 
Pawel Sosnowski
Join Date: Mar 2009
Location: Trieste, Italy
Posts: 105
Rep Power: 9
psosnows is on a distinguished road
Hello Sebastian,

I am happy that you found my prev post useful

Now, about the thing:
Quote:
Originally Posted by sebonator View Post
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 View Post
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 View Post
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
psosnows is offline   Reply With Quote

Old   December 20, 2010, 05:10
Default
  #162
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
Hi Pawel,

thanks again for your reply! I modified my boundary and initial conditions a bit and by now I got a converging calculation! Unfortunately the acquired solution does not seem to make much physical sense, as the velocity field does not look like the one I expected. So I think I have to return to setting better initial conditions than uniform (0 0 0) for the velocity field ;-)

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. I also thought about this possibility, but I don't know an easy way to use a solver like icoFoam only for the fluid regions! How do you setup such a case? My mesh is pretty complex (I am calculating a whole pump!) and I don't think its a good way to crate a second mesh with only the fluid region and map this solution to my fluid region in the chtMRSimpleFoam case afterwards.

Can you give some details about your procedure? Is it maybe possible do deactivate the calculation of the solids and the temperature without changing the solver-code? It would be ideal if I could start the simpler calculation with icoFoam from within my case folder and start the chtMRSimpleFoam-solver from within the same folder afterwards.

Thanks in advance! Hope I can help other ones in the future, too!
Greetings Sebastian
sebonator is offline   Reply With Quote

Old   January 7, 2011, 09:52
Default Setting initial solutions with custom function
  #163
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
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
sebonator is offline   Reply With Quote

Old   February 2, 2011, 11:18
Post Converging?
  #164
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 7
marval is on a distinguished road
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 View Post

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 View Post
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 View Post

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

Old   February 2, 2011, 17:40
Default
  #165
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
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
sebonator is offline   Reply With Quote

Old   February 3, 2011, 00:06
Default
  #166
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 7
marval is on a distinguished road
Hi Sebonator!

Quote:
Originally Posted by sebonator View Post

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 View Post
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 View Post

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

Old   February 3, 2011, 05:01
Default
  #167
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
Hi marval,

allright, I had a look at my case and will describe you, which boundary conditions I used. First of all, I am simulating an impeller side gap (is that the correct english word for the german 'Radseitenraum'???) where the one side is the rotating impeller and the other side is a fixed wall. There is a cold mass flow of water entering in axial direction from a gap between the fixed wall and the shaft. There is a hole in the impeller where the water can leave the impeller side gap and of course at the outer impeller diameter there is the gap to the main stream flowing through the pump. Hope this is enough for you to imagine it ;-)

A general aspect is, as I stated in a former post, that a rotationally symmetric simulation of such a configuration, where a lot of fluid flows in circumferential direction, requires cyclic boundary conditions and not wedge boundary conditions!!!! But maybe you don't want to simulate it rotationally symmetric.

My boundary and initial conditions:
  • temperature
    • fixedValue at all fluid inlets
    • zeroGradient anywhere else
    • initial conditions as a mean value of the maximum and minimum value of the temperatures you applied in the fixedValues
  • k and omega (I used SST-turbulence-model)
    • fixedValue at all fluid inlets (consider the circumferential fluid movement, too, when you estimate these values!)
    • zeroGradient anywhere else
    • initial conditions are not that important from my experience. I chose 0 for most simulations
  • p_rgh
    • buoyantPressure at all walls (rotating and fixed)
    • zeroGradient at all fluid inlets (<=> opposite to velocity field)
    • fixedValue at all fluid outlets (<=> opposite to velocity field)
    • initial conditions is 1/2 of the pressure difference the pump creates in the main stream
  • p
    • calculated everywhere, as it is derived from p_rgh
    • I set the same initial conditions as for p_rgh, but I don't think that it makes any difference, because p is never calculated for solution, just for postprocessing
  • U
    • rotatingWallVelocity at rotating wall (impeller)
    • fixedValue (0 0 0) at standing walls
    • fixedValue at fluid inlets. If your incoming fluid is expected to have a circumferential velocity, then apply this in your fixedValue, too!!! An example in my case is the gap where the cold mass flow enters the domain through the gap between shaft and standing wall, because the shaft rotates and I expect that the incoming flow rotates therefore, too.
    • zeroGradient or inletOutlet at fluid outlets. inletOutlet behaves like zeroGradient if the patch really is an outlet. that means that the fluid leaves the domain through that patch. in case of incoming fluid through that patch, the boundary condition switches automatically to fixedValue. This fixedValue can be used to force the fluid to leave the domain at that patch. I can't give a general advise here, because my simulation had two outlets and one worked fine with simply applying zeroGradient, while the other needed the inletOutlet. There were unrealistic circulations when I applied only zeroGradient to that outlet and the inletOutlet provided the solution for a realistic stream. Of course, such unrealistic circulations might be the course for other unrealistic behaviours.
    • Last and pretty tricky thing to apply are the initial solutions. The best would be to map some good initial solution, but if you don't have one, then you can only use this general way: Never apply velocity uniform (0 0 0) when you have a fluid inlet with fixedValue anywhere! That made my calculations diverge in less than 10 iterations! Apply at least a small velocity, 0.01 m/s for example. I think this behaviour is mainly caused by numerical problems because of the zeros you apply. And don't forget: If you expect your stream to have a circumferential velocity in the correct solution (in my case this is clearly expected because of the rotationg impeller!) then apply some circumferential velocity in your initial solution, too!!!!!
All right, that's all I can tell! Hope it helps!!! If you still got questions or you can't solve your problem with these information, feel free to ask again!

Good luck, Greetings Sebastian
gimmetwofingers likes this.
sebonator is offline   Reply With Quote

Old   February 17, 2011, 10:52
Question Coupling problem between solid and fluid (water).
  #168
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 7
marval is on a distinguished road
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 View Post

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]
        gradient     uniform 0;			// Initial gradient [K/m]
        
    }
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
marval is offline   Reply With Quote

Old   February 17, 2011, 16:16
Default
  #169
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
Hi marval,

cool that I was able to help you!

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
-your mesh is wrong

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

Old   February 18, 2011, 05:49
Default
  #170
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
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.
sebonator is offline   Reply With Quote

Old   February 20, 2011, 18:19
Default Boundary conditions
  #171
Member
 
Join Date: Dec 2009
Posts: 39
Rep Power: 7
marval is on a distinguished road
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 View Post
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!
I read your other post

Quote:
Originally Posted by sebonator View Post
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
File Type: gz heatedChannel.tar.gz (4.7 KB, 33 views)
marval is offline   Reply With Quote

Old   February 21, 2011, 05:34
Default
  #172
Member
 
Sebastian Lang
Join Date: Aug 2009
Posts: 46
Rep Power: 8
sebonator is on a distinguished road
Hi marco,

thanks for the uploaded files. The values you posted (0.6 W/mK for fluid and 16 W/mK for solid) are not the specific heat of the materials! Those are the thermal conductivities K! The specific heat usually has the symbol cp and is expressed in the unit J/(kg K). But this value is OK in your files. In contrast to that, the thermal conductivity of your water is not 0.6 W/mK as you said in your former post, in your files it is 6.62 W/mK!

Maybe the problem is located in your turbulence-modelling! I have no experience with low-Re models, so you have to get informations to them from someone else. But I saw that you did not set any wall-functions in your k- and epsilon-field! As far as I know, low-Re models need wall functions, too! You use zeroGradient at the wall for those fields, but this surely isn't correct, because turbulence usually happens at the wall, so the values of k and epsilon should change dramatically in the near wall region!

In general, the presence of turbulence influences the heat transfer coefficient between the wall and the fluid dramatically. Maybe you remember the calculation of heat transfer coefficients via Nusselt-relations from the lectures? One of the first steps in those calculations always is to decide if turbulence is present or not. This affect of turbulence can be found in the calculated value alphat in OpenFOAM, too: I think alpha represents the heat transfer coefficient and alphat is something like a an heat transfer coefficient, which is corrected to the extend of the additional convection caused by turbulence.

My guess is: if you don't model turbulence correctly at the wall, then the heat transfer coefficients will be much too low and therefore your fluid doesn't heat up as you expect! Check carefully how the boundary conditions for your turbulence model have to be set. I can't imagine that zeroGradient is the correct wall-treatment for a low-Re model!

Could you please make your question about time steps a bit more specific?

Good luck!
Greetings Sebastian
sebonator is offline   Reply With Quote

Old   March 4, 2011, 05:31
Default
  #173
Member
 
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Wolle is on a distinguished road
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
    {
        type            zeroGradient;
    }

    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
File Type: jpg FLUID_AMB-Domain.jpg (20.6 KB, 23 views)
__________________
CAELinux 2010 -- OpenFOAM 1.7

Last edited by Wolle; March 4, 2011 at 05:47.
Wolle is offline   Reply With Quote

Old   March 4, 2011, 05:45
Default
  #174
Member
 
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Wolle is on a distinguished road
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
Wolle is offline   Reply With Quote

Old   March 8, 2011, 06:27
Default
  #175
Member
 
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Wolle is on a distinguished road
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
Wolle is offline   Reply With Quote

Old   March 8, 2011, 13:48
Default
  #176
Senior Member
 
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 186
Rep Power: 8
mabinty is on a distinguished road
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
mabinty is offline   Reply With Quote

Old   March 9, 2011, 08:36
Default
  #177
Member
 
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Wolle is on a distinguished road
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 View Post
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
Wolle is offline   Reply With Quote

Old   March 10, 2011, 04:36
Default
  #178
Member
 
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Wolle is on a distinguished road
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
Wolle is offline   Reply With Quote

Old   March 10, 2011, 04:54
Default
  #179
Senior Member
 
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 186
Rep Power: 8
mabinty is on a distinguished road
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
File Type: c chtMultiRegionFoamMF.C (3.9 KB, 7 views)
mabinty is offline   Reply With Quote

Old   March 10, 2011, 05:09
Default
  #180
Member
 
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 7
Wolle is on a distinguished road
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.
Wolle is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
---------Tutorial help mech FLUENT 4 May 16, 2007 02:43
tutorial 6 in Fluent 6.2 tutorial and Mesh pilli4u FLUENT 2 April 2, 2007 05:09
3D Tutorial MJ FLUENT 0 January 16, 2007 09:45
tutorial masood yooceframandi FLUENT 1 January 25, 2005 13:28
tutorial adil FLUENT 0 March 8, 2004 04:48


All times are GMT -4. The time now is 07:36.