Fluids

Fluids

Inlet Velocity Perturbation stability issues

    • JamesWright
      Subscriber

      I'm having issues getting Fluent to use the inlet velocity perturbation algorithms. All three (vortex method, spectral synthesis, and synthetic turbulence generator) crash my simulation (with vortex method able to get to time step in the 20s).


      Background on the actual simulation setup:


      I'm using a SBES turbulence model on an internal flow simulation of swirling flow going into a conical diffuser going that empties to the atmosphere (which I have modeled as a plenum who's walls are outlets). The mesh was generated in ICEM CFD and is a structured O-grid mesh. There is a mesh interface between the outlet of the diffuser and the inlet of the plenum. The core of the O-grid mesh matches exactly, but the "ring" block mesh is less refined on the plenum face (as there's no BL in the free stream). The inlet velocity conditions are a csv-based boundary profile from experimental results that I'm attempting to match. The inlet turbulence settings are .05 intensity and 100 eddy viscosity ratio. The flow is compressible and the energy equation is turned on. All the suggested numerical settings for SBES method are used. Relaxation parameters are at their default values


      The SBES simulation is initialized with a k-ω SST based RANS simulation that is converged on continuity to 1e-6 and the three velocity components to 1e-9.


      The actual problem:


      Using the above simulation settings and no velocity perturbation methods, the simulation runs perfectly fine. There is reversed flow on a lot of the outlet faces, but this is physically real (since the outlet faces are on all sides of the plenum).


      When running any of the inlet velocity perturbation methods, the simulation crashes with


      Divergence detected in AMG solver: temperature

      repeated a few dozen times (possibly one for every core I'm using?). Note that 


       


      Using vortex method as an example (as it actually made it to more than 1 time step), the simulation starts fairly normally for the first couple iterations (Note that the RANS simulation took 610 iteration to converge):


       614  1.9650e+01  6.5770e-03  6.6863e-03  3.3963e-03  2.5920e-05  8.5096e-03  8.7117e-01  0:00:07   16

       reversed flow in 2759 faces on pressure-outlet 15.

       reversed flow in 13077 faces on pressure-outlet 16.

      Then the turbulence viscosity starts to get out of hand apparently:


      616  9.6360e+00  2.8885e-03  2.9301e-03  1.3704e-03  1.1293e-05  6.5866e-03  8.6227e-01  0:00:05   14

       turbulent viscosity limited to viscosity ratio of 1.000000e+05 in 1 cells

       reversed flow in 2761 faces on pressure-outlet 15.

       reversed flow in 13061 faces on pressure-outlet 16.

      By the end of the first time-step as well, we see very large CFL numbers: Note that in the original simulation, this max_cfl number function was reporting 2e-1.


       630  1.7689e-01  1.9806e-03  4.4073e-04  1.2954e-03  9.5547e-07  2.0293e-01  2.3937e-01  0:00:00    0
      step flow-time max_cfl massflow_imb
      1 5.0000e-06 1.2640e+02 -1.0466e+00
      Flow time = 5e-06s, time step = 1
      39999 more time steps

      The number of cells that have their turbulent viscosity limited continues to grow until eventually we get temperature warnings:


         769  4.2402e-01  3.4345e-03  1.0568e-03  1.3095e-04  1.4698e-06  8.1409e-02  1.3289e-01  0:00:00    1
      temperature limited to 1.000000e+00 in 5 cells on zone 2 in domain 1

      turbulent viscosity limited to viscosity ratio of 1.000000e+05 in 7 cells

      reversed flow in 3425 faces on pressure-outlet 15.

      reversed flow in 13063 faces on pressure-outlet 16.
      770 4.1524e-01 3.8029e-03 1.1382e-03 1.6574e-04 1.0026e-06 5.8571e-02 2.8554e-01 0:00:00 0
      step flow-time max_cfl massflow_imb
      8 4.0000e-05 1.4684e+02 -2.4502e-01


      The number of temperature limited cells continues to grow until eventually, we get the divergence issue described above.


       


      How should I go about fixing this? Is it normal to run into these issues when going to a velocity perturbation method?

      I think the issue probably lies in the CFL number, but do I really need to decrease the time-step by 2 orders of magnitude to make the simulation run? Or would this just be an condition where the initial "start-up" settings needs to be very fine, and then they can be ramped up later on?


       


      Thanks for anyone's help!

    • Rob
      Ansys Employee

      Some images would be useful, especially around the mesh interface and main geometry.


      If you are looking at a fundamentally transient model look at the cell size & velocity; divide size by speed to get a timestep and divide that number by 10. Then see if the model is stable. If yes continue to run, if not decrease the time step. You're aiming to converge after about 10-15 iterations per step.

    • seeta gunti
      Ansys Employee

      I can give you another suggestion. As Rwoolhou suggested, you need to calculate the time step size as per the formula. You can start your run with variable time step size so that fluent will calculate the appropriate time step size. You can continue the run with variable time stepping, once the flow is stabilized, you can change to fixed time step and slowly ramp up the time step size. It will work for many transient simulations and hope it will work for you as well.

    • JamesWright
      Subscriber

      Just to give y'all a better idea as to the BC setup, here it is:


      Domain BC setup


      The second dotted line (the one between the "diffuser" and "plenum extension") is the split between the two meshes.


      Here is an overall picture of the actual mesh in Fluent:


      Overall Domain View


      I've posted detailed pictures of the rest of the grid to imgur here


       


      I'm about to try out the time-step solution changes. I'll let y'all know how it goes!


       

    • JamesWright
      Subscriber

      I can give you another suggestion. As Rwoolhou suggested, you need to calculate the time step size as per the formula. You can start your run with variable time step size so that fluent will calculate the appropriate time step size. You can continue the run with variable time stepping, once the flow is stabilized, you can change to fixed time step and slowly ramp up the time step size. It will work for many transient simulations and hope it will work for you as well.



      For whatever reason, under the "Time Step Method" drop down box in Solution>Run Calculation, there isn't a "Variable TimeStep option" available. Only Fixed is allowed. I ran into this issue when I was first working on this problem, otherwise I would've been using it already. Any ideas why this is happening?

    • JamesWright
      Subscriber

      Going off your suggestion, I was getting the same divergence errors as before.

      However, I've had to drop to 100 times less for my time step unfortunately. Good news is that it's stable now. Bad news is it now takes 100x longer to solve because of the time step drop.


      I'm seeing my CFL number drop fairly steadily (started at 6e-1, after 150 timesteps it's down to 5e-2). Is it possible to raise the CFL number after a few iterations?


      Going off that idea, any reason you can see that the variable time step method isn't available for my simulation right now? Because that would help out a lot for this.


       


      Thanks for your help!

    • JamesWright
      Subscriber

      I think I've figured out the reason why I don't have the variable/adaptive timestep method available. Per ANSYS suggestions, I'm using a Bounded Second-Order Implicit transient scheme. From what I can tell with ANSYS documentation, this scheme doesn't allow for the use of adaptive time stepping.


       


      Should I look at switching over to first-order to use the adaptive timestep method? Or at least use that for the "initialization" and then switch to Bounded Second-Order Implicit with a constant time step once the domain has "settled down"?

    • Rob
      Ansys Employee

      If you're perturbing the velocity the solution won't settle down, unless you're only doing it once. In which case you'll need the transient solver (with it's associated increase in time) until the flow stabilises (ie when the perturbation leaves the domain).


      As you've not actually explained what you're trying to do we can't comment on which schemes to use. As the model is fairly small, I'd just run it: shouldn't take too long.

    • JamesWright
      Subscriber

      The simulation is swirling air flow going through a conical diffuser. Axial inlet speed of 40 m/s, solid body swirl of around 900 rad/s. I'm trying to get time averaged static pressure recovery of the diffuser.


      And by "settle down", I was referring more numerically than physically. As in the max CFL for the domain has "settled down" to around certain value. I interpreted that as some part of the domain is changing to a more "steady state" value. In a similar vein to allowing several flow through times to allow the turbulence to "converge" onto a "steady state" time period.


      And I think "shouldn't take too long" is a relative term". If I keep it at the same timestep, the simulation is going to take over a week on the cluster system I'm running it on. Compare that to ~12 hours without the velocity perturbations. 

    • Rob
      Ansys Employee

      Right, so it's not perturbed, you're running a swirling flow.  If the original case didn't have swirl check the cell zone settings to ensure you're actually swirling about the correct axis. Why do you need to include temperature, looking through you've not mentioned any heat transfer: 40m/s is well below 0.3M so the solution may not be overly compressible. I'd also look at the back flow conditions, and extend the domain so the back flow isn't influencing the system.

    • JamesWright
      Subscriber

      So full overview of what I'm doing. Hopefully this will make everything come together.


      The end goal of my thesis (which is what I'm doing this for) is to computationally determine the relationship between swirl, diffuser geometry, and static pressure recovery at high flow speeds (around 0.5M).


      The first step to do that is to create a simulation model that can match the results of experimental results. This is the stage I'm at right now.



      Right, so it's not perturbed, you're running a swirling flow.



      In the experiment I'm trying to model right now, the swirl generator does create turbulence that has been measured. Would this not mean that the mean velocity is perturbed? If not, how would the turbulence at the inlet be taken into account for the LES domain?



       If the original case didn't have swirl check the cell zone settings to ensure you're actually swirling about the correct axis.



      Just doubled checked and it's rotating about the correct axis.



      Why do you need to include temperature, looking through you've not mentioned any heat transfer: 40m/s is well below 0.3M so the solution may not be overly compressible.



      Because the simulations after the validation step are going to be high velocity, high temperature flows. Ideally, I'd like to maintain the exact same settings from the validation stage to the actual computation stage. That said, I could probably ignore thermal effects, I just figured I'd keep them in there.



      I'd also look at the back flow conditions, and extend the domain so the back flow isn't influencing the system.



      What specifically should I be looking at the back flow conditions for? They're currently set to the same levels of turbulence and temperature as the inlet. 

Viewing 10 reply threads
  • You must be logged in to reply to this topic.