Learning Forum

[Milne Ando]

G'day,

I want to make the solid geometry swing as a pendulum (rotating about the x-axis), and the magnitude of its moment of inertia is needed. Then I checked the user guide, and it says:

"Note that the inertia tensor components are defined relative to the Center of Gravity and Rigid Body Orientation settings defined in the Dynamic Mesh Zones Dialog Box (p. 3687)."

I don't understand what it means by "relative to the Centre of Gravity". Does it mean "parallel axis theorem"? Does it need the moment of inertia about the axis passing through its centre of mass? Or it needs the moment of inertia about the rotating axis (here indicating the x-axis)?

Hope someone can help me out, please. Thanks a lot.

[Federico Alzamora Previtali]

Hello Milne, 

since your pendulum undergoes 1DOF rotation about the X-axis, you will need to enter the Ixx moment of inertia passing through the center of mass. Specifying the center of rotation and axis in the 6-DOF Properties dialog box, and the center of gravity location in the Dynamic Mesh Zones dialog box, Fluent will compute the correct moment of inertia during calculation.

I hope this helps.

[Milne Ando]

Hello sir,

Well I've done sevaral tests and it always turned out to be strange; if I entered the moment of inertia passing through its CM, the console window would keep showing "6DOF angular solver has not converged ". But if I entered the moment of inertia about the x-axis (of global coordinates system), it wouldn't diverge in the beginning and could calculate through about 16 seconds (then negative cell volume occured). I just can't figure out what's wrong with my settings...

[Federico Alzamora Previtali]

The message "6DOF angular solver has not converged" means that you should either correct the "Implicit Update" settings or time step size and number of iterations per time step.
In the "Implicit Update" panel, enter the convergence criterion for the 6DOF solver (default 1e-3). If this is not achieved within a time step, reduce the update interval, calculate more iterations per time step, or reduce the time step size.

 

I hope this helps

[Milne Ando]

Yes, thank you so much.

I'll follow your hints and keep troubleshooting until it can work correctly; here the pic is my estimation of time step. But 0.48s is obviously large, so I ran the simulations with time step of 0.075s. Hmm it's small enough, right?

Looking forward to your reply. Thank you.

[Federico Alzamora Previtali]

Hello Milne, 

your approach is correct, but are the units right? It seems to me that the LHS is in meters and RHS is in mm. Otherwise, your smallest cell is larger than the length of the cylinder.

If that's correct, than your time step would need to be reduced by a factor of 1000.

Federico

[Milne Ando]

Yes!

I didn't notice that unit was wrong. Thank you so much!

After correcting time step size, it's now around 0.00048 second. That's really small! So I need to turn to supercomputer' aid. I'll update the result in the near future.

Milne

[Milne Ando]

Hello sir,

I found that once 6DOF solver can't converge (always), the cylinder would rotate almost 180º(as the pic shows:Theta(deg)) within the first time step, which is unreasonable. Plus, the circular cylinder deformed to a elliptic cylinder although it's assigned to Rigid body. Is that possible we misunderstand the statement in user guide? I've checked the theory guide, I'm sure that in six DOF properties panel, that 6 inertia tensor values are defined relative to its CM/CG. But when one DOF rotation box is checked, maybe moment of inertia isn't relative to its CM/CG? Implicit update interval is always set to 1. I've tried hard but failed to find out the bug...

[Federico Alzamora Previtali]

I would correct the time step first, as per my last reply. Once that is fixed, if your motion still shows errors, perhaps you are right and you might want to try what you are suggesting, with moment of inertia relative to rotation axis. If you do, please update me on this forum, I'm curious to see what you find!

Bests,

Federico

[Milne Ando]

Hi,

I think I've figured out the reason. I cheked the codes and found the value of Izz was filled in my solid body's moment of inertia. So yes, that field should be filled in the moment of inertia relative to its CG. But!! This field seems only set for Izz, so if I want to assign a value to Ixx or Iyy (my axis of rotation), I need to make the z-axis of the global coordinate system lie along the axis of rotation. In other words, I initially set a value for Ixx, but the programme gave this value to Izz, 'cause I didn't know it worked in that way. I think this was the main problem that caused the calculation diverged at early iterations and strange phenomenon.