[Guille1811]

Yeah, thing is i checked, double checked and triple checked all the geometry and meshing and it is all perfect. No weird hidden faces, overlapping, holes, nothing. Besides the geometry of the simulation is extremely simple so it makes sense that it is indeed fine.

With regard to the rotating domain, i set it up exactly as i said earlier, the vertical axis is well positioned as well as the rotational speed. Besides, the rotation of the domain works perfectly, it is just the initial position where the problem is.

What other kind of analisis could i do in order to spot the problem? since my geometry and setup is very very simple i run out of ideas...

[ghorrocks]

Try halving the time step, then see if the thing shoots off into space at half the velocity or not. This will tell you if it is related to your motion or time discretisation; or if it a numerical instability.

Also try doing a very small time step and see if it follows the same motion, but just spread over more time steps.

If that does not work then post an image of what you are doing and your output file and let us have a look at it.

[Guille1811]

Try halving the time step, then see if the thing shoots off into space at half the velocity or not. This will tell you if it is related to your motion or time discretisation; or if it a numerical instability.

Im using adaptive timestepping, so what i did was reduce 1 order of magnitude on the initial timestep (from 1E-4 s to 1E-5 s) but sadly the problem wasnt solved.

Also try doing a very small time step and see if it follows the same motion, but just spread over more time steps.

Well 1E-5 s is a very small timestep and since the adaptive timestepping algorithm is kinda slow to amp it up it stayed pretty low for a quite a bit, and as i said nothing realley changed.

If that does not work then post an image of what you are doing and your output file and let us have a look at it.


Ive posted a lot of images along this thread, do you want to see some specific image i havent posted yet?

Finally, here i attach the output file (all the iterations were cut off due to file size limit)

[ghorrocks]

I think you missed the point of my comment of halving the time step. It was not suggested as a fix for the problem. It was intended to see if that changed the motion of the body. It is only to help you debug the problem to try to identify where in your setup the problem lies.

If the halved time step means the body does the same motion but half as fast then you know the problem is in the definition of the motion. If the halved time step still looks the same (or does something completely different) then the problem is numeric instability or numeric resolution. As you can see it does not fix the problem, it is just a clue as to where the problem might lie.

You should note the warning at the top of the output file. It looks like your user name is too long and therefore CFX parallel might not work.

The definition of the motion in your model is very simple, just rotation about axis 0.2. Is the motion you are seeing actually motion around this axis or something else?

Other points which are not really related to the motion issue:
* You are defining a reference density for the buoyancy model. You also use it in your initial pressure field calculation. Is that density correctly matching the actual density of the air in your simulation?
* Your mesh is quite fine. This makes debugging mesh motion very slow - I see this run took 14 hours. I would recommend you either:
** Do a coarse mesh version for debugging the motion, then return to the fine mesh version when the mesh motion is correct, OR
** Use expert parameters to turn solution of the fluids, heat and turbulence equations off and just solve the mesh motion.
* I cannot understand all the boundaries in your output/CCL file as you have not shown an image which defines them all.
* You define a coordinate system (Coord 1) and then do not use it.

[Guille1811]

You should note the warning at the top of the output file. It looks like your user name is too long and therefore CFX parallel might not work.

No problem with that, it works despite that message. Ive run 3 other typer of simulations under that user name and they all came out perfect.

The definition of the motion in your model is very simple, just rotation about axis 0.2. Is the motion you are seeing actually motion around this axis or something else?

Yes, the motion im seeing is exactly around that axis.

* You are defining a reference density for the buoyancy model. You also use it in your initial pressure field calculation. Is that density correctly matching the actual density of the air in your simulation?

Yes, i carefully used the formula that relates absolute pressure, reference pressure, relative pressure, and buoyancy effect to asign those configurations. On top of that, the absolute pressure countours in cfx post look perfect to me.

Do a coarse mesh version for debugging the motion, then return to the fine mesh version when the mesh motion is correct,

By this you refer to only change the mesh option from "fine" to "coarse", or also making the different sizings bigger?

* I cannot understand all the boundaries in your output/CCL file as you have not shown an image which defines them all.

The boundaries are just adiabatic walls except for the floor that has a fixed temperatura and and inlet and outlet. The inlet has air velocity of 1E-4 m/s and and temperature profile, and the outlet has a static pressure condition of a pressure profile that matches that temperature profile.

By the way, in solver manager i keep gettin the message of "fluid ix entering in the outlet so we will put a wall in X% of the area" despite the fact that the outlet is FAR away from all the simlation influenced area (like really far away). What can i do about this?

You define a coordinate system (Coord 1) and then do not use it.


Yes, that system what used is a previous version of the simulation but is not needed anymore and i forgot to delete it.

[ghorrocks]

The definition of the motion in your model is very simple, just rotation about axis 0.2. Is the motion you are seeing actually motion around this axis or something else?

Yes, the motion im seeing is exactly around that axis.

So then what is the problem? Then isn't the motion what you defined?

Do a coarse mesh version for debugging the motion, then return to the fine mesh version when the mesh motion is correct,

By this you refer to only change the mesh option from "fine" to "coarse", or also making the different sizings bigger?

For debugging anything which gives you a mesh with much less elements will do. You don't need inflation and big elements - but the elements need to be small enough to resolve GGIs and curvature.

By the way, in solver manager i keep gettin the message of "fluid ix entering in the outlet so we will put a wall in X% of the area" despite the fact that the outlet is FAR away from all the simlation influenced area (like really far away). What can i do about this?

Have a close look at the output file in the post processor. Try to work out if the back flow is real or not. If not then you may need to fix the setup to resolve it. If real then you might need to change the boundaries to handle it. Alternately, it might be far enough away from anything interesting that it does not matter.

[Guille1811]

So then what is the problem? Then isn't the motion what you defined?


The problem is that the STARTING position of the cilindrical domain is random. As i said, the motion of the rotation works perfectly fine, the only problem is that the starting position of the domain is at an arbitrary angle and therefore its position along the entire simulation is flawed.

[ghorrocks]

Sorry, forgot about the starting position bit. That is the problem with holding several conversations at once I guess.

By random do you mean it starts at a different location every run, or is it always the same position?

One way I can think of where the initial condition can be wrong is that when CFX is run in workbench it uses the previous simulation as the initial condition by default. This can lead to the effect you are seeing where the flow does not initialise properly. You should turn this option off (if you have not already done so), or even better run CFX outside of workbench where you have more control over what it is doing (this is how I run it most of the time).

Another thing - I notice you are homing in on 8-10 coeff loops per iteration. The recommended amount is 3-5. It should run better like that.

[Guille1811]

By random do you mean it starts at a different location every run, or is it always the same position?


Different location every run.

One way I can think of where the initial condition can be wrong is that when CFX is run in workbench it uses the previous simulation as the initial condition by default. This can lead to the effect you are seeing where the flow does not initialise properly. You should turn this option off (if you have not already done so)

I already turned it off and it doesn´t solve the problem.

or even better run CFX outside of workbench where you have more control over what it is doing (this is how I run it most of the time).

How can i do that?

Another thing - I notice you are homing in on 8-10 coeff loops per iteration. The recommended amount is 3-5. It should run better like that.

The first trials i had 3-5 coeff loops indeed, but the problem was the the timestep size converged to 1E-6 sec after a few iterations and then stayed there forever. I then changed it to 8-10 coeff loops and the problem was gone, with a time step size between 0,01 sec and 1 sec, averaging 0,1 sec aprox, and a very reasonable total run time.

[ghorrocks]

or even better run CFX outside of workbench where you have more control over what it is doing (this is how I run it most of the time).

How can i do that?

If you are on windows, from the start menu start the CFX Launcher. You can then launch CFX-Pre, solver manager and CFD-Post stand-alone from there. You will need to get your simulation out of the workbench file structure as well. This can take a bit of hunting.

The first trials i had 3-5 coeff loops indeed, but the problem was the the timestep size converged to 1E-6 sec after a few iterations and then stayed there forever. I then changed it to 8-10 coeff loops and the problem was gone, with a time step size between 0,01 sec and 1 sec, averaging 0,1 sec aprox, and a very reasonable total run time.

A very reasonable run time and an inaccurate answer. I guess if all you want are some pretty pictures that is fine, but if you actually want accurate answers you better put it back to 3-5 coeff loops. If the solver reckons it needs small time steps then you better let it do so.

But you should do a sensitivity check on your convergence criteria. It might be too tight and that causes the time step to go very small.

[Guille1811]

What is the proof that 8-10 coeff loops = inaccurate results?

I ask you because the simulations results are according to the expected and specifically the particular result im interested (it has to do with the temperature field at 1.5 mts high) has a 6,2% error in relation to the technical specifications of the machine.

By the way, the criteria im using is MAX residual 1E-3

[ghorrocks]

It is a general recommendation. I have done work years ago and convinced myself, and likewise the CFX developers did so as well. But the best test is to try it yourself on your case. If you have checked and it works for your case then go for it.

Have you done a sensitivity check of your convergence criteria? When you use adaptive time stepping the convergence criteria sets both the tightness of the convergence and the time step size so it is a critical parameter.

But back you your original question why the starting position is different each time - I cannot say why you seem to get different starting positions each run. This is very strange and I have never seen this (or even heard of it) before. Something is very weird in your simulation.

[Guille1811]

Ok, will see what i do about it. Thanks for your help Glenn!

[Guille1811]

There is another problem with this simulation that i didn´t solve it before but now i have to:

As mentioned before, the cilindrical domain is rotating around a nearby vertical axis with a time dependent momentum source described as follows:



X component: -1E4[kg m^-3 s^-1]*((Velocity u)+15*cos(pi/180*7)*cos(phi) [m s^-1])

Y component: -1E4[kg m^-3 s^-1]*((Velocity v)+15*sin(pi/180*7) [m s^-1])

Z component: -1E4[kg m^-3 s^-1]*((Velocity w)-15*cos(pi/180*7)*sin(phi) [m s^-1])



Where pi/180*7 is the outflow angle with respect to the floor (see first image attached, Y is the vertical axis) and phi is the azimuth angle (see second image attached). The angle phi is a time dependent expression defined as:

phi=2*pi/300[s]*(t+37.5[s])

Where 300 seconds (5 minutes) is the total time of 1 rotation. As you can see from the expression, at t=0 s, phi= pi/4 and the velocity vectors indeed have that outlet angle (see second image). The problem is that after that initial time, the momentum source never aligns again with the rotation of the cilinder. For example, in the 3rd image attached the simulation time is t=37,5 s so the cilinder must have a pi/2 angle as well as the momentum source (if you evaluate that time in the phi expression gives pi/2. The cilinder indeed has a 90°angle as you can see in the picture, but the momentum source is totally dissaligned, despite the fact that the value of phi is right (i checked in cfx post for the value of the expression in that moment).

That is just an example, as this missalignment happens througout the entire simulation.

Yes, i triple checked all the momentum source equations and they are perfect.

Yes, i tried different values for the momentum source coefficient and it made no difference.

How can i fix this?

[ghorrocks]

I cannot see the problem in what you have done so far. It is tricky to debug these sort of things in CFX as you only have very basic debugging options for the CEL.

While the equations you show appear to be correct according to the 2D rotation transformation matrix (https://en.wikipedia.org/wiki/Transformation_matrix) that is assuming many things, such as the rotation is about the origin, that the frame of reference is stationary, that velocities u,v and w are constant and many other things.

The only thing I can recommend is you check the motion one component at a time, that is check the domain rotation and source term rotation separately to try to debug it.