[Dehyp]

Hello everyone.

I'm currently trying to simulate a defrosting windscreen of a VW Beetle CAD model using the DeIcing module in Star-CCM+.
However, the simulation diverges and does not lead to a solution.

As my Bachelor Thesis, it is the goal to have a simulation, which tells me how the air is spreading inside of the passenger compartment in terms of velocity and temperature.
I also want see how fast the whole windscreen defrosts with a view from the inside of the car and from outside.

I am using the implicit unsteady solver with a time step of 5 sec with 360 iterations. After a little more than 5 iterations the simulation starts to diverge heavily (up to 1e+21 residuals) and eventually leads to a floating point exception after 15 iterations.
The CAD model itself could be a problem since I had to convert .vrml files to .stl in order to make it usable in Star-CCM+ but I do not have another option.

I run the whole model in a single fluid region as a polyhedral mesh with 5 prism layers, surface remesher and surface wrapper. I use all walls as convection thermal specifications with a certain heat transfer coefficient except inlet and outlet boundaries. For that I use mass flow inlets and pressure outlets with a value of 0 Pa.
My windscreen has an ice layer of 0.5 mm.

I tried different things to make it run. I changed flwo types from segregated to coupled flow and used convergence accelerators for instance. With that I achieved a maximum of 76 iterations until a floating point exception. I also tried different mesh sizes with different amounts of prism layers, etc. The results look okay until iteration 6. In either way, the scalar scenes start to display unlogical results (Temperatures inside of the cabin of 4000 °C ofr instance). I also set different maximum and minimum temperatures, changed time steps, etc., but I've never been able to run all 360 iterations and hence obviously never achieved usable results.

I am using Star-CCM+ 11.04.010-R8 on Windows 7 64bit with Intel(R) CPU W3540 @ 2.93 GHz and 12 GB RAM.

Here you can find a link to my simulation file.
https://www.dropbox.com/s/ri04vmdrwf...eetle.zip?dl=0

I hope someone of you can help me with that. I am desperately trying to make it work for a week now working on it 7 hours every day.

I am looking forward to hearing from you and thanks in advance.

[Fiedde1887]

Did you ran the solution with energy and flow solver? The TimeStep should be to high for the Flow Solver.
There is an interesting Presentation by LandRover at the StevePortal. I think you can find that presantation on the Internet, if you don´t have Access to Steve.

[Dehyp]

I know this webinar. I watched it a couple of times actually and from the information that they give I used most of them. And as stated. I used the same solvers and same time step as JLR is doing. I use the following solvers
Implicit Unsteady
Partitioning
Wall Distance
Segregated Flow
Segregated Energy
K-Epsilon-Turbulence
K-Epsilon Turbulent Viscosity
DeIcing

And I tried time steps between the default 0.001 and my own value of 5. It all leads to the same


Sent from my iPhone using CFD Online Forum mobile app

[Fiedde1887]

Have you solved the flow and the energy simultaneously? If yes, hav a look at page 17 of the presentation by Jaguar and landrover. A TimeStep of 5s is far to high for the flow!

Edit: I mean the presentation from the 2011 conference at europe. http://mdx2.plm.automation.siemens.c...st-performance

[me3840]

Can you post pictures of your mesh?

If you are getting divergence that easily with the Deicing model (which is just an empirical model) then the problem is likely elsewhere.

A timestep of 5s is achievable if you freeze the flow solvers and only let energy solve. For the most part you should get the same results as running regular unsteady.

[Dehyp]

Originally Posted by me3840

Can you post pictures of your mesh?

If you are getting divergence that easily with the Deicing model (which is just an empirical model) then the problem is likely elsewhere.

A timestep of 5s is achievable if you freeze the flow solvers and only let energy solve. For the most part you should get the same results as running regular unsteady.

Here are pictures of the mesh. I haven't tried to freeze the flow solver yet. I am going to try it. Thanks already.

[Dehyp]

I tried to simulate it with a frozen flow solver now. The simulation does not diverge any longer. However, the ice layer thickness value remains constant at 0.5 mm in the whole duration of the simulation.

I also tried to run it steady state without ice. Then again I have the problem of divergence again. After about 10 iterations I get the same floating point exception as I had before.
Please help if it is possible.

[me3840]

If you froze the energy solver then the ice layer value wouldn't change, you only wanted to freeze the flow solver.

Anyway, your problem is more fundamental. If the steady solver blows up without deicing then you have a mesh or boundary condition issue.

It's hard to tell what all your pictures mean, but it looks like you have a really coarse surface mesh and your prism transition ratio is astronomically large. Your last prism should be on the order of the size of your regular poly cell. You took pictures of several poor quality spots, you should clean them up.

You have a picture of a door handle, which implies there is mesh outside the car...why is this? You're doing an in-cabin simulation, you don't need mesh outside the car.

[Dehyp]

Originally Posted by me3840

If you froze the energy solver then the ice layer value wouldn't change, you only wanted to freeze the flow solver.

Anyway, your problem is more fundamental. If the steady solver blows up without deicing then you have a mesh or boundary condition issue.

It's hard to tell what all your pictures mean, but it looks like you have a really coarse surface mesh and your prism transition ratio is astronomically large. Your last prism should be on the order of the size of your regular poly cell. You took pictures of several poor quality spots, you should clean them up.

You have a picture of a door handle, which implies there is mesh outside the car...why is this? You're doing an in-cabin simulation, you don't need mesh outside the car.

I also had the feeling that my problem is due to my mesh. Due to the vague explanations of the mesh, I put a link to the overall simulation because it is definitely a lot easier to find problems that way. Also the forum rules do not allow me to upload more pictures.

The door handle can be explained. As mentioned earlier, the initial file format of the car was .vrml. That's a file only used for graphics and VR models. I had to convert it to a file type that Star-CCM+ can work with. The only file type that was possible to create without a complete distraction of the geometry was .stl. And when importing this type of file, you are not able to use the "split-by-patch" feature. Star ccm detects it as a single surface. So deleting some faces such as the door handle was not possible. But as explained in my post I do not have another option.


Sent from my iPhone using CFD Online Forum mobile app

[me3840]

Deleting faces is certainly possible without split by patch. You can use the surface repair utility to eliminate anything you don't want. If this is a very labor-intensive task you can also use the surface wrapper to get rid of geometry outside the car.