Ansys Assistant will be unavailable on the Learning Forum starting January 30. An upgraded version is coming soon. We apologize for any inconvenience and appreciate your patience. Stay tuned for updates.
Fluids

Fluids

Topics related to Fluent, CFX, Turbogrid and more.

Variable time stepping with VOF method

    • nlnlOuO
      Subscriber

      Hi, everyone. I'm now running a 3D transient simulation about the kerosene filling process of a fuel tank.I used VOF method for multi-phase flow and k-w SST for turbulence model. The inlet condition was set to be 3.5m/s velocity inlet and the outlet condition was 0 gauge pressure outlet.

      I created my mesh via fluent T-Grid meshing. Poly-hexacore was adopted to create the volume mesh. The mesh layout contained 7 boundary layers, and the minimum first layer height was estimated to be 5e-05m. The minimum surface meshing size is about 1e-03m.

      I'm now facing a big problem regarding the time step size. Normally, we can use fixed time step, and the fixed time step size can be estimated by Courant number, where C = dt*[(Vx/dx)+(Vy/dy)+(Vz/dz)]. And C is suggested to be less than 1 (Although I used first order Implicit time advancement scheme). In my case, since the velocity normal to the boundary reaches zero in the boundary layer, dt is calculated as,

      dt = 1/[(3.5/0.001)+(3.5/0.001)] = 1.4e-04s

      Besides all about, I tried to use variable time stepping with "multi-phase specific time advancement algorithm." Here are my settings :

      Global Courant number = 2

      Max time step size = 1.5e-04

      Min time step size = 1e-06

      Max changing factor = 1.1

      Min changing factor = 0.5

      The solution diverged at 8200 iterations, which corresponds to physical time = 0.1s, at 2950 time steps. The console shows : "Global Courant number is greater than 250."

      Here's the strange thing, the solution seemed to run very well just one time step before it diverged. At one time step before the solution diverged, the console showed: "Global Courant number [Variable Time Step Criteria] : 1.16" and "physical-dt 7.36e-06." Also, the solution iterates "once" in one time step, lasting for three time steps before the one that diverged. So I suspect the time step was too fine.

      Here's my question, would it be better if I use fixed time step? If so, How should I determine my time step? Or should I keep using variable time stepping? Then what parameter should I change?

      Second, the time step size at the diverging instance (7.36e-06) was far under the calculated time step (1.4e-04). I know that the velocity field varies everywhere every instance. But how can the solution diverge so suddenly?

    • DrAmine
      Ansys Employee
      If running in 21R1 and later, turn on VOF Stabilization and use "Settings Optimization". Second try first implicit VOF instead of Explicit VOF. Afterwards if still having issues you might turn on Advanced Stabilization.
      You can debug you problem by having a report of max velocity, and the time step used over the time steps: Perhaps you will find a correlation between both, that at the moment you max velocity is going crazy at hat Fluent wants to reduce the time step but It cannot do that so quick . All this I am supposing that your mesh is of good quality and the boundary conditions are correctly setup.
    • nlnlOuO
      Subscriber
      Hi, Amine.
      Thanks for your reply.
      There are some license problems in using 2021R1, So I haven't tried using stabilization yet. I've contacted the local supplier to figure out the problems.
      Actually, the change I tried is to use implicit VOF. The solution is stable until 0.17s, much longer than before(0.1s). However, it still diverged. Here's the phenomenon:
      The solver started to try to reduce the time step at about 10 time steps before it goes crazy, it probably had detected that the velocity in some location was too high. So the "high, probably wrong" velocity might occur few more steps even further (I guess).
      So, I have the following suspicion:
      Maybe what's wrong was not about whether I used implicit or explicit VOF, but the "Global Courant number?" Furthermore, I've learned that implicit VOF may cause numerical diffusion. So, I turned my focus to the global courant number.
      Although I'm using implicit time stepping, which can tolerate higher Courant number. But, I guess, very tiny error may stem from the start (since the max Courant number >2), and then grows until large error occurred, causing tragedy to the solution.
      I want to ask : do you have any experience trying the global Courant number larger than 1 for multi-phase specific variable time stepping? Did it successfully converge? Or do you have any suggestion on setting the Global Courant number. Though the stability is different case by case.
      Also, will the stabilization acting causing any side effects on the correctness? For example, will it suppress the answer crudely.
    • Rob
      Forum Moderator
      I've not had as much luck with poly-hexcore as with a poly mesh: hanging nodes in the wrong place can cause some issues. If the model is running well, then failing, have a look at the flow a bit before it fails. What is going on, and is anything about to change? Stability controls do just that, stabilise the model.and I did some of the testing of these on a range of cases and I don't recall seeing anything different in the results, other than having a result in several cases!
    • DrAmine
      Ansys Employee
      I ran a couple of cases with Global CFL larger than 20, or even 30 using implicit VOF. I usually leverage velocity limiting and some VOF stabilization features which are available in the recent versions.
      Again look into the evolution of your reports, max velocity max CFL number, interrupt right away and review the contour plots.

      Implicit VOF with compressive scheme + Bounded Time is the way to go for almost all industrial applications.
Viewing 4 reply threads
  • The topic ‘Variable time stepping with VOF method’ is closed to new replies.
[bingo_chatbox]