CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > Siemens > STAR-CCM+

Maximum Temperature limited to xx in cells error

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

Like Tree1Likes
  • 1 Post By me3840

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 15, 2019, 18:01
Default Maximum Temperature limited to xx in cells error
  #1
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
Good day, I'm running a DFBI simulation on a quadcopter using virtual disk's as the propellers, I'm using the implicit unsteady model and k-omega turbulence. After every iteration, I get this in the output window:

Minimum Temperature limited to 100 on 29 cells in Fluid Volume
corrections limited on 19438 cells in Fluid Volume
minimum absolute pressure limited to 1000 on 2391 cells in Fluid Volume
Maximum Temperature limited to 5000 on 12 faces on Surface Wrapper.Assembly.Default
Maximum Temperature limited to 5000 on 40 faces on Surface Wrapper.Assembly.Default 2
Maximum Temperature limited to 5000 on 56 faces on Surface Wrapper.Assembly.Default 6
Maximum Temperature limited to 5000 on 7 faces on Surface Wrapper.Assembly.Default 8
Maximum Temperature limited to 5000 on 69 faces on Surface Wrapper.Assembly.Default 9
Turbulent viscosity limited on 19 cells in Fluid Volume


The quadcopter is about 2x2x1 ft and I used a surface control with a target surface size of 0.5mm on the body of the quad. I checked my mesh and no bad cells were found and I didn't change any temperature or pressure values so I'm not sure what's causing this problem

Last edited by LorenzoVonMT; February 15, 2019 at 21:04.
LorenzoVonMT is offline   Reply With Quote

Old   February 16, 2019, 11:25
Default
  #2
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,190
Rep Power: 18
me3840 is on a distinguished road
This is often mesh related. Please post pictures of your mesh.
me3840 is offline   Reply With Quote

Old   February 18, 2019, 16:30
Default
  #3
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
I inspected the mesh a bit more and there are some areas that need refinement, posted below. However, the surface control on the drone is already at a target surface size of 0.5mm, any smaller and it takes ages to mesh. Would a volumetric control on the trouble areas consume fewer resources than reducing the surface size on the entire drone?
Attached Images
File Type: png 1.PNG (36.7 KB, 22 views)
File Type: png 2.PNG (97.8 KB, 19 views)
File Type: png 3.PNG (92.7 KB, 17 views)
File Type: png 4.PNG (124.0 KB, 16 views)
LorenzoVonMT is offline   Reply With Quote

Old   February 18, 2019, 20:21
Default
  #4
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,190
Rep Power: 18
me3840 is on a distinguished road
You can probably make this mesh coarser by raising the target size and lowering the minimum size.

Mesh isn't all about the surface, what does the volume look like? Are your prisms good quality?


Also, why do you have temperature on at all, is this thing fast enough to be compressible?
me3840 is offline   Reply With Quote

Old   February 18, 2019, 23:32
Default
  #5
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
These are the volume mesh pics:

I have the number of prism layers set to 10. For my fluid domain, I have the target surface size set to 108 mm and the minimum set to 84 mm

And no, its definitely not compressible. I didn't turn temperature on, it was on by default. How do I turn it off correctly?
Attached Images
File Type: png 1.PNG (80.0 KB, 23 views)
File Type: png 2.PNG (66.4 KB, 23 views)
File Type: png 3.PNG (74.7 KB, 21 views)
File Type: png 4.PNG (70.1 KB, 16 views)
LorenzoVonMT is offline   Reply With Quote

Old   February 18, 2019, 23:41
Default
  #6
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,190
Rep Power: 18
me3840 is on a distinguished road
You should probably take a step back and learn about how different meshes can affect your solution, your mesh is far from good quality. Remember that the mesh's purpose is to resolve flow gradients. Can you draw on some paper what you expect the gradients to look like? Are your cells sized to appropriately resolve those gradients? Your sizes jump by a factor of 8 to 16 very close to the surface. There are several meshing tutorials which will teach you the tools STAR-CCM+ has to refine and coarsen in certain places.

If you notice your prisms are also zigzagging up and down, which is the mesher telling you it cannot produce them as thick as you demand without damaging the mesh quality. You have to reduce their thickness or coarsen the surface mesh to have them grow larger, if that's what you want.

STAR-CCM+ doesn't turn on energy by default, it must be user-chosen. I would suggest you go through a few tutorials first, they will help immensely in your understanding of the process.
ashokac7 likes this.
me3840 is offline   Reply With Quote

Old   February 19, 2019, 00:54
Default
  #7
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
I've actually done all the meshing tutorials but I'll go through them again because it seems that I missed a lot. I'll work on improving the mesh to see if it'll fix the diverging solution.
LorenzoVonMT is offline   Reply With Quote

Old   March 8, 2019, 20:49
Default
  #8
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
Ok so I've improved the mesh by increasing the target surface size on the drone from 0.5mm to 2mm and lowering the minimum surface size to 0.008mm.

Under Prism Layer Mesher settings, I also reduced the minimum thickness percentage from 10 to 1 and I increased the Layer Reduction Percentage from 50 to 95. I also turned on mesh alignment.

The only initial condition I changed was the changing the velocity from 0 to 13m/s in the x direction. I have a velocity inlet and a pressure outlet and I changed the velocity at the inlet to 13 m/s.

I then followed an article on steve portal that talked about getting rid of the temperature correction messages. The article said to turn on grid sequencing initialization and under coupled solver. It also said to reduce the courant number. So I reduced it from 50 to 25 to 2.5 to 0.2 to 0.02 to 0.002. Each time I reduced the courant number the residuals converged a bit better until I reduced it to 0.002, then the residuals started diverging, so I switched back to 0.02. However, I no longer get the temperature correction messages but my residuals are bad for some reason. I attached a picture of the residuals below.
Attached Images
File Type: png 1.PNG (32.3 KB, 18 views)
File Type: png 2.PNG (48.7 KB, 17 views)
File Type: jpg 3.jpg (178.4 KB, 14 views)
File Type: jpg 4.jpg (77.7 KB, 18 views)
File Type: png 5.PNG (112.0 KB, 15 views)

Last edited by LorenzoVonMT; March 9, 2019 at 22:12.
LorenzoVonMT is offline   Reply With Quote

Old   March 11, 2019, 21:34
Default
  #9
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,190
Rep Power: 18
me3840 is on a distinguished road
0.008 mm? That is incredibly fine, are you sure you don't mean 0.008m?


Your mesh is much improved. Still has some work to do, but from those images it will probably run in some fashion.


Why did you choose the coupled solver for this problem, I thought you stated compressibility is not an issue? Why are you still solving with temperature on?

As a future note, dropping the CFL (or URFs for segregated methods) to values far below 1 (or 0.1 for URFs) for simple physics like this is not an effective strategy. For these kinds of physics if you can't run with the default settings, something is wrong with the mesh or problem specification in 9/10 cases. Dropping the CFL/URFs just makes your case take longer to blow up.

The residuals make it look like you're running unsteady. Have you chosen your timestep appropriately?
me3840 is offline   Reply With Quote

Old   March 11, 2019, 22:35
Default
  #10
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
Quote:
Originally Posted by me3840 View Post
0.008 mm? That is incredibly fine, are you sure you don't mean 0.008m?
Yes, the minimum surface size is currently 0.008mm. The mesh size is 38 million. Should I coarsen the mesh?

Quote:
Originally Posted by me3840 View Post
Your mesh is much improved. Still has some work to do, but from those images it will probably run in some fashion.
How would you improve on it?

Quote:
Originally Posted by me3840 View Post
Why did you choose the coupled solver for this problem, I thought you stated compressibility is not an issue? Why are you still solving with temperature on?
I see what you mean when you first asked why did I turn temperature on. I was following the "Body Force Propeller Method: Marine Self-Propulsion" tutorial and they used the coupled solver so I followed it blindly. Now that I've done more research, I see the segregated solver is more appropriate for this simulation.

Quote:
Originally Posted by me3840 View Post
As a future note, dropping the CFL (or URFs for segregated methods) to values far below 1 (or 0.1 for URFs) for simple physics like this is not an effective strategy. For these kinds of physics if you can't run with the default settings, something is wrong with the mesh or problem specification in 9/10 cases. Dropping the CFL/URFs just makes your case take longer to blow up.

The residuals make it look like you're running unsteady. Have you chosen your timestep appropriately?
I see. So to isolate the problem, I ran a completely new simulation without the virtual disks, without the DFBI model but I kept the same mesh and the same initial and boundary conditions, using a steady time step and the segregated solver. However, the residuals were still hovering around E-1. So you're right, there's a problem with the mesh but I've done all I could think of. Also the DFBI Rotation and Translation model requires an unsteady time step, that's why I'm using it.

https://drive.google.com/file/d/1f-j...ew?usp=sharing

That's a link to the sim in question.
LorenzoVonMT is offline   Reply With Quote

Old   March 11, 2019, 23:08
Default
  #11
Senior Member
 
Join Date: Nov 2010
Location: USA
Posts: 1,190
Rep Power: 18
me3840 is on a distinguished road
38M is extremely fine for a geometry like this, I would think. For troubleshooting purposes I would aim for a ~2M cell mesh or so. If you have to throw out some of the geometry detail do it, it will save an enormous amount of time letting you learn. You can move back to the detailed model when you are confident that your inputs are built on a good foundation. The small model lets you make far more mistakes (read: learned lessons) in the same amount of time.

I have a hard time believing something that small is 38M, but you can coarsen the target size and perhaps drop a prism layer to save a lot of cells. As far as improvement, you have a lot of narrow gaps you can probably throw away for now, but you may wish to break the internal faces of the gaps into a separate surface to lower the prism size on them. This will reduce the skewness in a lot of the corners, some of which you can see in your mesh quality thresholds you made. You might also question if a lot of those gaps are even aerodynamically important.

Turning off extra physics (DFBI/virtual disk/etc) is an excellent approach. You ran it steady-state (is that what you meant?) and it did not converge residual-wise that well. You have a pretty fine mesh, which may factor in. How did your engineering quantities converge? Do they make some sense?

Don't feel discouraged/patronized/fearful of simplifying the model. I always keep a simplified version of cases I run on hand, they're very useful to check that a physics model makes sense or a script will work without spending hours or days running a big case. The little model gives you confidence your approach is correct and you will spend fewer man hours and computer hours in total than trying to fight the big model into working.
me3840 is offline   Reply With Quote

Old   March 12, 2019, 00:06
Default
  #12
New Member
 
Join Date: Nov 2018
Posts: 7
Rep Power: 2
LorenzoVonMT is on a distinguished road
Alright, I'll work on simplifying the geometry. You're right, a lot of those gaps aren't important so I'll take them out. On the simplified simulation I ran, it was reporting a drag force of about 4 N, which is lower than I expected. But I'll let you know how the simplified model goes.
LorenzoVonMT 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
[OpenFOAM.org] Compile OF 2.3 on Mac OS X .... the patch gschaider OpenFOAM Installation 225 August 25, 2015 20:43
Compile problem ivanyao OpenFOAM Running, Solving & CFD 1 October 12, 2012 10:31
ParaView for OF-1.6-ext Chrisi1984 OpenFOAM Installation 0 December 31, 2010 07:42
Problem with compile the setParabolicInlet ivanyao OpenFOAM Running, Solving & CFD 6 September 5, 2008 21:50
Compiling problems with hello worldC fw407 OpenFOAM Installation 21 January 6, 2008 18:38


All times are GMT -4. The time now is 14:56.