[emba]

Dear all,

This is my first post in the CFD Online forum. I've spent some time in this StarCCM+ section to check if my issue was already covered by previous threads, but I couldn't find anything that could help.

My issue is the following. In StarCCM+ (version 2020.2) I'm stimulating the "Moving Reference Frames: Marine Propeller in Open Water" tutorial. For my personal interest, I was further post-processing the results to have a look at the properties of the fluid flow. In the images attached, I'm plotting an isosurface of the Q-criterion colored by velocity magnitude. The vortices trailed by the propeller blades correctly rotate in the rotating region where the MRF is applied, while in the stationary region they are rectified after crossing the interface between the two regions and move downstream as straight blobs.

I'have followed precisely the indications in the user guide to set up the simulation. Besides, I have also successfully validated my results as shown in the tutorial. Is it possible that the issue above is a limitation of the solver or of its post-processing capabilities? I was told by some colleagues using Fluent that this issue does not occur in Fluent when simulating similar types of problems.

Thank you for your help!

[bluebase]

Hi emba,


your results are from a steady-state simulation right? If that is the case, i believe, this is an artifact of the MRF modelling and how the postprocessing is computed - and to be expected...

Lets individually imagine the static down stream region. In a steady-state simulation the boundary conditions have to be steady as well, don't they?
This consequently means at the boundary (the interface) the wing tip vertices are also not moving on that plane - do you follow?
Since the downstream region effectively has a fixed "inlet" boundary condition you'll get a straight stream down - the way you show in your screenshots.

In the tutorial there is a field function floor($Iteration/501) which introduces some transition mechanics. But this is only a convenience feature to simulate multiple sets of boundary conditions in one go. This is still a steady solution, though.

If you want nice pictures, you could transplant the geometry in in a cylindrical domain and let the whole domain rotate in the MRF.
You'd need to add a counter-rotation (with the same rpm as the MRF domain) on the shaft to effectively have a steady wall.
But this is computationally a bit more expensive, since it takes more time to reach a converged solution.


And further down you'd consider transient solution approaches, i guess.

[emba]

Hi Sebastian

Thank you very much for your explanation and also for your tips to improve the visualization of the vortex structures. Indeed, the steady-state simulation from the tutorial (although the five operating conditions considered) was the first step. After modifying the setup to allow for mesh rotation, I've simulated only one of these five conditions by a transient simulation. In this case, the blade vortices were correctly rotating also in the stationary region as one would expect.

I just have a final question/curiosity. Can you confirm if in Fluent a similar setup with the MRF in the "rotating" region and stationary mesh in both regions would provide a solution with the blade vortices rotating also in the stationary region? If so, is it a capability of the solver or of the post-processor?

[bluebase]

Originally Posted by emba

Can you confirm if in Fluent a similar setup with the MRF in the "rotating" region and stationary mesh in both regions would provide a solution with the blade vortices rotating also in the stationary region? If so, is it a capability of the solver or of the post-processor?

Sorry, i am not able to answer this question with certainty. I haven't used Fluent for many years.

Though, I would assume, for equivalent boundary conditions as the StarCCM tutorial, you would also receive the same weird looking down stream - since it's consequence of the physics/mathematical modeling of the problem. I would not see this outcome to be much related with either the solver nor post-processor.

[Rinia]

Originally Posted by bluebase

Hi emba,


your results are from a steady-state simulation right? If that is the case, i believe, this is an artifact of the MRF modelling and how the postprocessing is computed - and to be expected...

Lets individually imagine the static down stream region. In a steady-state simulation the boundary conditions have to be steady as well, don't they?
This consequently means at the boundary (the interface) the wing tip vertices are also not moving on that plane - do you follow?
Since the downstream region effectively has a fixed "inlet" boundary condition you'll get a straight stream down - the way you show in your screenshots.

In the tutorial there is a field function floor($Iteration/501) which introduces some transition mechanics. But this is only a convenience feature to simulate multiple sets of boundary conditions in one go. This is still a steady solution, though.

If you want nice pictures, you could transplant the geometry in in a cylindrical domain and let the whole domain rotate in the MRF.
You'd need to add a counter-rotation (with the same rpm as the MRF domain) on the shaft to effectively have a steady wall.
But this is computationally a bit more expensive, since it takes more time to reach a converged solution.


And further down you'd consider transient solution approaches, i guess.

Hi Sebastian

I find some researchers simulate only one blade in CFD to obtain the flow field of the turbomachinery. They used the rotating frame of reference modelling, but still set the time step in simuation.

The use of rotating frame of reference is thought to be steady in simulation. Is the time step set reasonable in their simulation? And if the one blade simulation method is available in STAR CCM+?

I have been confused by this problem. Hope you can give me some advice.

[bluebase]

Consider MRF as an approach to model motion of walls and this motion's impact on the flow. Other approaches to do the same would be Moving-mesh/sliding-mesh, or Chimera-grid - there are different names for theses depending what source you read (StarCCM's manual in this case).
An advantage of MRF is that the mesh does not need to be changed/translated/transformed during the simulation in contrast to the other two.

The question of a steady or transient solution can actually be independent from how to model MRF. With other words, you can run MRF simulations steady, and transient (with time step).

The tutorial chose a steady simulation so that people could run them on small machines. You don't get to run heavy simulation on a large machine as novice, or did we? =)

A one-blade simulation in more general terms is a simulation which makes use of the rotational symmetry of your rotor.
Although there are simulation assistants, I don't know whether there is one ready to do such simulations. If you do these simulations day-in-day-out it might make sense to program such an assistant.

Anyway, defining rotational periodicity manually is very simple (You want periodicity here, and not just symmetry). All you need to do is create a wedge-shaped domain from your geometry. The wedge needs to have an angle of 360 degree divided by number of blades, of course.
The symmetry faces need to be used to create an interface. In that interface you can define rotational periodicity.

[Rinia]

Originally Posted by bluebase

Consider MRF as an approach to model motion of walls and this motion's impact on the flow. Other approaches to do the same would be Moving-mesh/sliding-mesh, or Chimera-grid - there are different names for theses depending what source you read (StarCCM's manual in this case).
An advantage of MRF is that the mesh does not need to be changed/translated/transformed during the simulation in contrast to the other two.

The question of a steady or transient solution can actually be independent from how to model MRF. With other words, you can run MRF simulations steady, and transient (with time step).

The tutorial chose a steady simulation so that people could run them on small machines. You don't get to run heavy simulation on a large machine as novice, or did we? =)

A one-blade simulation in more general terms is a simulation which makes use of the rotational symmetry of your rotor.
Although there are simulation assistants, I don't know whether there is one ready to do such simulations. If you do these simulations day-in-day-out it might make sense to program such an assistant.

Anyway, defining rotational periodicity manually is very simple (You want periodicity here, and not just symmetry). All you need to do is create a wedge-shaped domain from your geometry. The wedge needs to have an angle of 360 degree divided by number of blades, of course.
The symmetry faces need to be used to create an interface. In that interface you can define rotational periodicity.

Hi Sebastian，

Thanks for your reply. I found there was a tutorial case about the periodic modelling in the STAR CCM+2020.

I simulated a three blade propeller with the periodic modelling method according to the method you provided. The thrust on the propeller is not smooth, a leap occurs when the blade return to the starting position, i.e. 'snap back'. I don't know if the phenomenon is the result of incorrect modelling. Have you ever simulated the propeller with the periodic modelling method?