[jp_]

Hi, I am new to these forums

I want to simulate flow of water in cavity to see how well it cools it. Regardless of how low I bring the timestep (tried down to 1e-10, with 1e-2 residuals) it yields
"ERROR #001100279 has occurred in subroutine ErrAction. |
| Message: |
| Floating point exception: Zero divide"

The mesh works fine for the steady-state simulation, and it works fine with initial conditions until I turn mesh motion on. Even ramping up rotation speeds (not ideal, but given circumstances...) produces this error. It always happens not at the first event of mesh move (which works fine, somehow), but the second one. And it also works fine if initialized with 0 velocity everywhere instead of steady-state results.

Since it works pretty well otherwise, I believe it is not diverging, especially with the stupid low timestep, and RMS are below target residual. I understand if it were in the expressions, it would appear. This brings me to believe mesh move does that. The mesh does not appear to blow apart. Is this typical? Any idea?
Is there a way to set it such that the error catch could tell us what it is computing when it fails?

Some more details:
-2 rotating domains, and 1 in stationary frame using mesh move (hence 3 total)
-transient rotor interfaces (all at unspecified mesh motion)
-double precision, upwind and first order k-e turbulence
-multiphase water and air, constant property for both
-steady-state solution devised with acceleration fields, works fine, uses same exact mesh

Probably related:

When using the Initial Mesh option, convergence problems may occur in cases where there are large mesh displacements, large changes in control volumes, or moving GGI interfaces.

Mesh displacement is quite very small thanks to timestep; the mesh just moves, the equations don't make it deform; but YES, I have GGI interfaces on that moving mesh domain. Is there a way around this?

Any help is appreciated,
jp

[ghorrocks]

Have you done a run where you save an output file on every time step (including the mesh) and checked that the mesh is not doing some weird movement?

Can you post a picture of what you are modelling and your CCL file (or your output file).

[jp_]

Hi ghorrocks, thank you for the quick reply. To answer your questions:

Before the initial post I did output mesh at each step, and it looks ok at first glance, no crazy jump-arounds. Then again I could always only get 1 non-zero mesh move step to work with this set of initial conditions (everything including mesh move works fine otherwise for any X number timesteps if not using these ICs). This is what I simply cannot wrap my head around.

Since I can get it to work with other initial conditions, I have re-launched another steady-state set with tweaked values, to see if the data was perhaps just corrupted/on a bad spot/etc.


Now, that brings me to:
1 - Mesh "diffusion stiffness" options. After reading the documentation on it, how could the mesh "diffuse" through stiffness coefficients instead of its expression-provided position values through "specified location" & "displacement relative to initial mesh", through a subdomain spanning the complete domain? (and of course, all boundaries/interfaces set to unspecified so as not to make stuff explode) Could the "diffusion" be distorting some elements to zero-length sides? What is it actually doing?

2 - I looked but haven't come across; is there no "debug level" to CFX? An option where it outputs more info about what it is doing with each level (of course reduces performance, but helps the user learn and understand without bugging people on forums... )

3 - Could there be any interaction with adaptive timestep and mesh-moving? - From experience, do you even recommend using adaptive instead of fixed-value?

4 - Thinking about this, since the mesh wasn't moving in steady-state (obviously), how well, from experience, does the flow react to sudden mesh-moving?

Will re-post an update as I unravel this thing/find more stuff.

[ghorrocks]

1: Yes, mesh diffusion can and does create inside out elements. When you get these it is reported as negative volume elements. But before you get to this stage you have very poor quality elements which are numerically unstable and therefore more liable to divergence.

2: No debug levels are available with CFX. You can turn on some diagnostic stuff like the output file with a mesh every time step and lots of monitor points but no true debug modes.

3: Yes, I recommend using adaptive time steps. But mesh motion simulations often require small time steps so make sure your upper time step size limit is sensible. Even better, use adaptive time stepping homing in to 3-5 coeff loops per iteration and that will take this all into account.

4: This depends on the physics. In compressible flow a pressure wave will be created which radiates outwards. In incompressible flow the boundary conditions need to account for the increase or decrease of stuff in the domain.

[jp_]

1-2: Sad to hear of no debug mode. Alternatively, is it possible (even if unlikely) to make it output the pre-solution, or even just the mesh after being solved for, but before coefficient loop #1 crashes?

3: Ok perfect, I will probably decrease from the standard 10 max coeff loops that I was using so far. Timestep values tend to hover at around 1e-9 at the start (same behaviour regardless of initial conditions, wether it fails or not), then ramp back up to 1e-7. Horribly small, 100 tstep per deg of rotation of the domains...

4: Ok, so this won't likely be a problem. No trapped fluids are without access to an opening-type boundary. (through some domain interfaces, but yeah)

[jp_]

After discussing results with some other CFD users, we came to the conclusion that the solution was in fact diverging at one node near a wall, which happened only when both phases were present (~0.5 v_water/v), works fine if it is dominantly only 1 phases though (~1 v_water/v or ~0 v_water/v)

Although it could be interesting to figure out why it does that, the primary workaround is to eliminate mesh move entirely and input that part's moving reference frame as stationary, and of course, generate the matching acceleration field/wall velocities/etc.

I feel I did not understand properly your last answer on question 4.

4: This depends on the physics. In compressible flow a pressure wave will be created which radiates outwards. In incompressible flow the boundary conditions need to account for the increase or decrease of stuff in the domain.

So by moving the mesh we add or remove stuff in the domain?

[ghorrocks]

1) You can use expert parameters to turn the solvers off, then the simulation will run quickly as the mesh motion is the only thing happening. This FAQ has some tips on doing this: http://www.cfd-online.com/Wiki/Ansys..._went_wrong.3F

4) When the mesh moves it usually results in a change of volume of the domain. In compressible fluids that means fluid has to enter or leave the domain to maintain conservation of mass.

[jp_]

Originally Posted by ghorrocks

1) You can use expert parameters to turn the solvers off, then the simulation will run quickly as the mesh motion is the only thing happening. This FAQ has some tips on doing this: http://www.cfd-online.com/Wiki/Ansys..._went_wrong.3F

Interesting, I should run through these parameters more often.

4) When the mesh moves it usually results in a change of volume of the domain. In INcompressible fluids that means fluid has to enter or leave the domain to maintain conservation of mass.

Ok, yes, that relationship is obvious; it just seems backwards that with specified node positions (in pure rotation-translation), the volume will change more than absolutely minimal amount, unless these node positions provided through expressions are treated as suggestions, and that would be where mesh stiffness options come into account.

Thanks alot for all the help!

[ghorrocks]

Yes - if the mesh motion is rotation or translation then the volume should not change. But it will change a tiny bit due to numerical noise, and the solver marches to convergence with the potential of the mesh motion changing the volume anyway.