I am relatively new to CFX. Please help to resolve this issue.

In CFX 5.5, I have a model of an internal cooling passage in a turbine blade. The whole domain is obviously rotating at some 10000rpm or more. Now the trouble is getting any difference at all between solutions for a stationary and rotating passage. Otherwise predictions of flow and heat transfer have reasonable values.

Initially I have set up 2 cases - a stationary domain exported from Build, and a rotating domain exported from Build, but initially with 0rpm. No surprise to me there when I got two identical solutions.

Then when I changed the rot.speed to the real value in the definition file, and restarted the run, there was no effect on the solution whatsoever! Even the residuals did not move a bit. What is going on?

Your ideas will be appreciated!

Cheers,

Martin.

Martin,

Did you change the rotational speed in the .def file or the .res file?

Robin

Robin, in the def file prior to the run restart. I used the res file with 0rpm to restart from. Martin.

Hi Martin,

So you started from the .def file and specified the .res file as an initial values file?

(ie "cfx5solve -def myRun.def -ini myRun_001.res")

Regards, Robin

Robin,

yes, that's the way, and after this run, I checked both def file and the new res file, they both included the specified angular speed, but no change to the solution.

I am a former FLUENT user and I modelled flow in a rotating machinery with it. In FLUENT, when I displayed the velocity of the walls in the stationary reference frame, it would be logically corresponding to (angular speed)*radius. I presume it should be the same in CFX, right? What I get in CFX is the same for wall velocity and wall velocity in a stationary frame(=0 with hybrid values, or some wall-adjacent conservative values), so no sign of rotation.

Regards,

Martin

Hi Martin,

No, it's not the same. When you look at the velocities, they are in the relative frame. So vectors on the wall (hybrid) do not show up, as per the no-slip condition.

If you want to see the vectors relative to the stationary frame, select Velocity in the Stn Frame instead.

Regards, Robin

Hi Robin

What you say is what I'd like to achieve!

Unfortunately, in my solution with rotational speed specified, there is no difference between the values of Velocity and Velocity in the Stn Frame. This is most puzzling.

In fact, today I was looking in more detail at what actually happened to the source terms at the moment when I specified the rotation (around 1000 rad/s, and average radius 0.3m, just for your appreciation of the problem). There was a very tiny step from zero value for V and W momentum sources, and remained 0 for U momentum, as it's rotating around X axis. So the solver added some sources, as it was supposed to do. Perhaps the effects of corriolis force and centrifugal force are so small. And I would be prepared to believe that in case the solver solves everything in the rotating reference frame, the very tiny momentum sources made no impact on the convergence.

Until I can see the actual absolute velocity vectors or contours plotted on the wall, I cannot trust these results.

Hi Martin,

I suspect there is something else wrong with your setup. Without seeing your model, I can't say what the problem is.

I suggest you send your model to your support representative for a look.

Robin

Hi,

after some time of exhausting investigations I found what the reason for my problem was.

I became suspicious when I was evaluating the effect of increasing the speed from 1000 rad/s up, to some unrealistic values and found that to actually obtain the domain velocity of around 1000 rad/s in the results, I had to specify the angular velocity of 1000000 rad/s in the definition file. This multiple of a 1000 immediately triggered investigation into the way the model was exported from Build into the definition file.

My geometry was imported as a parasolid with values corresponding to milimetres, so I used milimetres for geometry units, because scaling down a complex imported solid is a hassle. (Unless somebody can advice me how to scale it down without breaking it into surfaces). I used metres as the solution units. I did so in the hope that the options for using various geometry units are there to help the user deal with units he prefers.

And since the model appeared in the correct dimensions in CFX post and also the stationary solution was as expected, it would not cross my mind that Build puts a multiplication factor of 0.001 or 1000 for momentum sources somewhere where it should not, if you are using milimetres instead of metres as geometry units.

The most worrying thing is that the two definition files, one written from database with geometry in milimetres, and the other from database with geometry in metres, and both written for the same solution units, do come out exactly the same!!! But ruin two apparently same definiton files and get two different results. I know there there must be a difference somewhere in the two files, but not where you can edit it.

The absolute velocity in results varied by three orders. During the solution I monitored the momentum sources and they varied by the multiple of 1000.

I personally regard this as an annoying bug, from now on I will be forced to scale my geometry to bring the values to metres in Build. (one more alternative may perhaps be to use milimetres as both the geometry and solution units - I have to try it tomorrow.)

I am happy to send the two definition files to anybody to replicate the problem. To make sure it was not caused by my geometry I created a very simple model of a long rotating duct to confirm my explanation.

Martin

Robin,

thanks for reading my posts and contributing. Please have a look at the message in the other thread, and perhaps give me your view.

Regards, Martin.

Hi Martin,

Geometry unit handling in Build is simple; tell it what units your geometry is created in and the mesher will scale your mesh to the appropriate solver units. Did you check any lengths in your parasolid model after import to make sure you have the right units?

And since the model appeared in the correct dimensions in CFX post and also the stationary solution was as expected, it would not cross my mind that Build puts a multiplication factor of 0.001 or 1000 for momentum sources somewhere where it should not, if you are using milimetres instead of metres as geometry units.

Build does no such thing! When you enter a momentum source, you include the appropriate units. These are given to the solver exactly as is.

Lastly, if you want to scale an entire model, put it into a group and scale the group.

Best regards, Robin

Robin,

with all respect, this is what CFX5 documentation says:

"For flows in a rotating frame of reference, ..., additional sources of mometum are required to account for the effects of the Coriolis force and the centrifugal force" Another section: "When a domain with a Rotating Frame is specified, the CFX solver computes the appropriate Coriolis and centrifugal momentum terms, and solves a rotating frame Total Energy equation."

So, clearly, the only way I am supposed to enter input for this is specifying the rotational speed.

Making sure I have got the right units associated with my dimensions is the first thing I do. I am happy to send you the two definition files for yourself if you want to see it for yourself.

Or, have a geometry in mm, use m as solution units, specify angular speed in rad/s and just watch.

I will try the thing with scaling down the group, thanks for that.

Martin

Robin,

Just a brief note regarding your advice on scaling the group in Build:

Both scaling the geometry and scaling the group come out with the same following message: "The transformation of solid geometry accessed by the Parasolid method is not supported in this version. Solid 1 as well all finite elements and LBCs in this group will not be transformed. To successfully transform the FEs and LBCs, UNDO the previous operation, remove this solid from the group and then re-apply the transformation operation".

Not much of a help then. Any other idea?

For the time being I ended up with re-importing the parasolid again, specifying the scale factor during import. I guess that will do me for the future as I know now I can only trust metres as the geometry units.

Martin.

Martin,

Yes, a momentum source accounts for the effect of rotation. By your previous posts, it sounded like you were putting in one of your own.

The coriolis force is a function of radius, so you would expect it to vary with your model size.

Robin