[LorenzoVonMT]

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

[me3840]

This is often mesh related. Please post pictures of your mesh.

[LorenzoVonMT]

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?

[me3840]

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?

[LorenzoVonMT]

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?

[me3840]

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.

[LorenzoVonMT]

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]

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.

[me3840]

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?

[LorenzoVonMT]

Originally Posted by me3840

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?

Originally Posted by me3840

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?

Originally Posted by me3840

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.

Originally Posted by me3840

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.

[me3840]

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.

[LorenzoVonMT]

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.