CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > FloEFD, FloWorks & FloTHERM

FloEFD rotating region

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   August 27, 2019, 12:05
Default FloEFD rotating region
  #1
New Member
 
Adam
Join Date: Dec 2018
Posts: 15
Rep Power: 7
310toumad is on a distinguished road
I am trying to run a simulation modeling airflow over the body of an AC motor from a fan attached at the rear. The fan is encased in a shroud as shown. On the inside of the shroud along the periphery there exists several fins to help direct the flow in the axial direction.

My question is, where exactly should the boundary of the rotating region end? Should it extend just beyond the tips of the fan blades, but not intersect the fins? Originally I had the rotating region extending halfway into the wall thickness of the shroud so the fins and shroud wall were encased inside the rotation zone (boundary shown by blue sketch line in picture), and then I defined them as stator walls.

Which method is correct? If the rotating zone only extends just past the blades, but there still exists a sizeable gap with the shroud wall, then I assume what will happen is you have a distinct region of rotating air, and then an abrupt change to a region with zero rotation (the region which the fins exist within). The physical interpretation of this would be the radial velocity of air abruptly decreasing to near zero across this interface, so essentially that fluid/fluid interface acts almost like another "wall."

The problem though is when I originally had the rotating zone encompassing the fins and shroud wall (with these surfaces defined as stator walls), when I did an animation of the velocity vectors in the rotating zone, they were shown to be accelerating radially outward which is what I anticipated, but it appeared as though they were passing right "through" the stationary fins and continuing on a circumferential path. When I took a look at streamlines going into the slots located at the inlet, the flow correctly "contracted" and moves around these narrow openings, so I know the streamline plots should show the behavior of the flow field as it "re-arranges" around solid objects, so why does the simulation appear to not recognize the fins? It seems all the examples I can find with a fan, they are encased in a perfectly round shroud with no protrusions. How are protrusions that aren't perfectly revolved around the rotating zone handled in FloEFD? Currently I am used the averaging method for rotating region, should I switch to sliding mesh method?

My second question for this set up is, for my flow domain I have bell-shaped inlet and outlets modeled. The type of simulation is designated as internal, and I have a total pressure defined at the inlet and static pressure defined as the outlet with atmospheric values (14.7 psi). When I run it, I get a warning "vortex crosses the pressure opening (outlet)" which I know to mean there is a recirculation zone intersecting the outlet. When the simulation finishes, the velocity flow field appears to show a lot of reversed flow at the outlet. How can this be? Are my BC's incorrect for this model? I do not know mass flow, only RPM of the fan and both inlet and outlet are open to atmospheric conditions. When I run the same simulation as an external problem, the flow field behaves as one would expect, so I'm curious why the internal one seems to give results which do not make sense.

Also, the simulation only ran 250 iterations before stopping, perhaps I should run it longer although I'm not sure if it matters because I did a test run at 150 iterations and the solution did not appear to change much from 150 to 250. My suspicion is that because the flow is not being directed by the fins, the air loses all momentum prior to reaching the inlet. Note: the picture is not from the actual CFD sim but a rough sketch of what the flow domain looks like. Thanks for any help or advice.
Attached Images
File Type: jpg Fan.jpg (71.3 KB, 61 views)
File Type: jpg Domain.jpg (64.2 KB, 60 views)
File Type: jpg RotatingZone.jpg (122.5 KB, 54 views)
File Type: jpg FlowDomain.jpg (50.6 KB, 49 views)

Last edited by 310toumad; September 6, 2019 at 13:12.
310toumad is offline   Reply With Quote

Old   September 10, 2019, 10:14
Default
  #2
Disabled
 
Join Date: Jul 2009
Posts: 616
Rep Power: 23
Boris_M will become famous soon enough
Hi Adam,

No, do not extend the rotating region into the fins as they are stator protrusions into the rotating regions. A rotational symmetric (cylindrical) wall is not a problem as the stator boundary condition is only a surface boundary condition and forces the have 0 absolute velocity of the wall and therefore forcing the boundary layer to come to 0 at the wall. It doesn't say that the wall as a geometry is not moving. You would see that easily if you use the sliding mesh option when the fins get cut off by the rotating region and actually move. For a cylinder, this is not a problem as it doesn't have any blockage to the flow which it will drive like a fin. If the cylinder has a stator condition the wall is frozen with its boundary layer. A fin will still rotate but the velocity at the wall will kind of be zero. So that doesn't make sense.

No, the fluid/fluid interface is not acting as a wall, then the whole approach wouldn't work no matter where the rotating region is. There is a "hidden" boundary condition between rotating and non-rotating region where the values are exchanged. With the averaging plane method, the rotating region cylinder will be cut into slices and at the circumference, the velocity will be averaged. This can cause a small error as the velocities are usually not the same over the full circumference. But that is a valid approach and should work just fine in your type of fan. For crossflow fans, the sliding mesh is required, but not for axial or radial fans.
So when the flow comes out of the rotating region it still has its tangential velocity, it just changes the perspective.
The perspective view is just like you are "standing" in a driving train and see people passing by, you could say they are moving because you are standing, but the other way around they will say you are moving because they are standing. This is what happens when the flow crosses that fluid/fluid interface, it changes the reference system. Wehn you would jump out of the driving train, you don't hit a wall either (unless you jump against an actual wall :-)).
You will just experience a sudden deceleration when you hit the ground (running or not). This is what will happen do the flow as well when it hits the fins or the shroud walls.

The reason you saw the vectors passing through the wall is because of the reference system. You can switch that with the option "Relative to rotating frame" in the flow trajectories or with the parameter for the vectors in the cut plot from velocity to velocity RRF. This is then switching the reference as well for the visualization. Otherwise the trajectories look similar to what you mentioned, they suddenly have a kink when they switch between the regions from a rotation to no rotation, depending on which setting you use. That is completely normal.

I cannot tell what the flow looks like regarding those recirculations you mentioned. But I would run it as external the the same length and width you used for your inlet and outlet if there is no other reason to have it internal. This avoids the BC issue and question. In reality the fan is sucking in the flow through the grid as well and some flow from further away doesn't make it in through the grid and will be pulled along at the outlet from the exiting flow which will make it pass by as if the motor is flying through the air. The shroud is so short, the flow will get the pull from the inlet and if it doesn't make it in, it will get the second pull from the outlet and get sucked along the outside of the shroud. The boundary conditions just simplify the flow in a way it is not 100% natural and then this can change results a bit. Depending on how you defined the BCs at the inlet and outlet, it might result in such flows you see.
If you want to keep the two inlet and outlet regions, then I would suggest to build them more dome wise for both sides and not starting directly at the edge of the inlet and outlet but more in the middle of the shroud, giving the flow a more natural flow path as if it is passing along the shroud before meeting the flow that gets sucked in or blown out. So more like two half soccer balls for the outlet and inlet one which meet in a thin separating sheet that cuts the shroud on the outside by half. So sometwhat similar to what you will see in the images when you search for "jet engine danger zone" on google. They have this half dome at the inlet that starts a little behind the intake and you simply mirror that also for the outlet if you really need to have an internal flow model. If these domes are big enough the effects of the circulation get smaller and will not influence the fan itself anymore.

I am not sure what the flow looks like that you suspect the flow doesn't get directed by the fins. It is best to check the most useful parameters as goals such as force and torque on the fan surfaces, the inlet and outlet flow rates (mass or volume flow) and if it is external then use some lids at the outlet and deactivate them with the component controls and check the goals at that lid for the flow.
With rotation it can happen that initially the flow will go the wrong direction and will turn around after some iterations. It is important that the flow does not change anymore in magnitude or direction. It can happen that it has a sinusoidal swing to the value but with an offset from zero, so not changing directions.
Sometimes the solver might stop earlier than the results are converged which is then usually the case in rotation, that it reached the maximum travels settings in the calculation control options. You can deactivate it so that the only stopping criteria is the goal convergence.

I hope this helps,
Boris
Boris_M is offline   Reply With Quote

Old   September 10, 2019, 10:59
Default
  #3
New Member
 
Adam
Join Date: Dec 2018
Posts: 15
Rep Power: 7
310toumad is on a distinguished road
Hello Boris,

Thank you for the detailed reply. So just to clarify, the reason why the velocity vectors appeared to "pass through" the fins when I had them enclosed within the rotating region was because they were actually rotating with the reference frame, and so thus were not being recognized as stationary objects within the flow domain?

I did experiment a little and changed the rotating region to only enclose the fan, and when I did that the flow field seemed to interact with the fins and move around them rather than passing straight through as before, so I can understand the logic you are describing.

Another question I have: for the fan, I created a cylinder that totally encloses it for the rotating region. I don't know if you can tell, but from the pictures the fan has straight blades mounted to a solid, circular surface. Now, from my understanding objects that are protrusions which cannot be fully revolved around the axis of rotation (such as blades) need to lie within the rotating region, however any surfaces that are fully revolved that are either partially included or outside of the rotating zone should be defined as moving walls with rotation. My question is, if one of these revolved surfaces (such as the backing of the fan which the blades are mounted on) is already fully enclosed within the rotating region, does it then become pointless to also apply a moving wall condition to it as well?

Secondly, for the problem of reversed flow I tried to run longer iterations (500-1000) to see if convergence was the issue. This did not appear to help. I also tried refining the mesh and this did not help either. I did not yet try what you suggested with modifying the inlet/outlet geometry.

Something I thought of: because the fan is used with an AC motor, it requires straight blades such that it can produce flow if the motor is run in both clockwise and counter-clockwise directions. When I ran my simulation, I noticed that while some of the flow did move axially as it "hit" the fins and exited the shroud, the straight-bladed fan created a lot of re-circulation zones within the shroud. Is it possible that, by defining the simulation as 'internal' and creating walls around the inlet/outlet, this is worsening/amplifying the negative pressure gradient caused by these recirculation zones around the fan, and thus actually contributes to "pulling" the flow back into the domain because now the fixed outlet pressure is higher?

Perhaps this is why the external simulation did not see as much reversed flow, because the domain is much more open around the geometry so the effect of a negative pressure gradient is diminished?

Last edited by 310toumad; September 10, 2019 at 16:02.
310toumad is offline   Reply With Quote

Old   September 11, 2019, 03:44
Default
  #4
Disabled
 
Join Date: Jul 2009
Posts: 616
Rep Power: 23
Boris_M will become famous soon enough
Hello Adam,

Yes, that is correct. You will see the trajectories also cross the fan blades if not looking at it in the right reference system. It is the reference setting that makes them pass through fan blades.

Yes, your understanding is correct with regards to the protrusions. But other surfaces like the base of the fan don't necessarily have to be outside the rotating region. This is usually done to save mesh as it is good to have at least 3 cells between the solid geometry inside the rotating region and the rotating region walls and then between the rotating region walls and the solid geometry outside the rotating region. This will cause at least 6 cells between the fan walls closest to the rotating region and the shroud walls also closest to the region. For the base of the fan this can be then avoided if the rotating region cuts into the base and the backside of it is defined as rotating walls. Then there only need to be 3 cells between that wall and some stator walls that might behind it and hold the bearing or so. It could also extend into the stator walls if they are rotationally symmetric and you could apply stator walls to them. Then it also only needs 3 cells for good results.
The 3 cells are numerically better as you can imagine if there is only one cell between the rotating region wall and the geometry, the flow would get in or out of the rotating region and the hidden BC that is applied by the software and directly has to change direction as it would suddenly hit a wall. With 3 cells it has more time to gradually change direction.
Now 3 cells are just a rough rule of thumb, of course more are better (6-8) for high accuracy, but sometimes that's not really possible without causing a massive mesh. The flow won't be resolved very well maybe but often the results of the key values are still quite accurate as the influence might be only small.

And yes, if the wall is already fully inside the rotating region, it is already rotating. Even walls that are partially inside like a shaft, are rotating from the point they are inside. So it then makes sense to define the shaft that that is not inside or partially inside as rotating wall for the rest of the surfaces that are not inside. Again, this is only working well if the shaft is a revolved surface and doesn't have any protrusions like slots etc. as it is just a boundary layer that is applied as moving, the geometry itself is actually not moving.

No, the error message of vortex crossing pressure opening will not disappear unless the vortex is not crossing it and such reveresed flows can be naturally but can also be caused by the close proximity of the outlet BC. This is why usually the dome is made somewhat bigger to allow flow to develop and not force a pressure condition to close the the major flow happenings when these usually don't have such ideal conditions as a pressure opening.
In external simulations such error warnings don't exist as they are considered naturally and simply can appear. But also here the domain walls often should not be too close to the model.

Yes, indeed. This is what such forces ideal BC too close to more chaotic flow can force unnatural behavior onto the flow as the flow cannot develop freely.
Exactly, regarding the external simulation.

You always have to consider that simulation definitions are forced and don't necessarily represent the natural occurrence of the conditions. The less it is like the reality, the more deviations you will get. In reality there is no tight outlet and inlet region around it, the motor would sit in a room which is multiple times bigger and you don't force a constant pressure just a centimeter away from the outlet, the flow can expand to the environment pressure the next few meters until into the room, at least that's the space it has. So making things a bit bigger and less forced will reduce such unnatural behaviors. Sometimes it can be neglected if the influence is little but here I wouldn't.


Regards,
Boris
Boris_M is offline   Reply With Quote

Old   September 11, 2019, 09:28
Default
  #5
New Member
 
Adam
Join Date: Dec 2018
Posts: 15
Rep Power: 7
310toumad is on a distinguished road
Thanks for the information, it is very helpful
310toumad is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fluent: Flow won't interact with rotating region TOlsen FLUENT 0 September 26, 2016 11:30
Car external aerodynamic with wheel spinning issue hokhay FloEFD, FloWorks & FloTHERM 2 August 18, 2016 04:23
Rotating Impeller Naith FloEFD, FloWorks & FloTHERM 22 November 5, 2012 08:53
Rotating region of a centr. pump - Counter R wall Emre CFX 0 September 20, 2007 09:58
[Gmsh] Import gmsh msh to Foam adorean OpenFOAM Meshing & Mesh Conversion 24 April 27, 2005 08:19


All times are GMT -4. The time now is 10:58.