|
[Sponsors] |
Frozen Rotor (Moving reference frame) validity |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
December 1, 2021, 08:04 |
Frozen Rotor (Moving reference frame) validity
|
#1 |
New Member
Join Date: Oct 2021
Posts: 8
Rep Power: 4 |
Hello! I'm simulating more or less an impeller inside a casing much similar to a pipe. Since my computational resources are low I've chosen a moving reference frame approach, that is I've defined a region that contains the whole impeller, and created a frame of reference for this region that has a prescribed rotational rate. The rest of the domain (the casing walls and remaining fluid volume) has the default stationary frame of reference. Then I run this as a steady RANS simulation and obtain a converged solution that looks somewhat how I would expect it.
As I've understood, this is a valid approach. I'm using STAR-CCM+ but I don't think it is only used there. That's why I put my thread here. I think it's also called the frozen-rotor approach in general. However, I have some questions regarding the validity of this approach. They are mainly regarding how the rotational region is defined. How does the size of the rotational region affect the results? I.e, what would the effect be of defining the rotational region to extend almost up to the casing wall, as compared to say only half way? In both cases it is assumed that the impeller is fully inside the rotational region. Thank you on beforehand for any answers. |
|
December 2, 2021, 04:54 |
|
#2 |
Senior Member
|
With multiple reference frames, the flow in each single zone (moving reference or not) will be described correctly, no matter what. The problem is in the information that they exchange.
When you look to the rotating frame zone from the fixed frame one you won't see anything moving, just some strange flow field that doesn't respect the basic NS equations unless some additional terms are added. The same is true the other way around, looking at the fixed frame from the rotating one. Also, there is no doubt that, if you need multiple frames to describe some motion without actually moving the grid, then the case is genuinely unsteady in all the coupled frames. In my opinion, unless the impeller is relatively far from the interface with the non rotating frame zone, the frozen rotor approach should no be used if what you are interested in is actually in the rotating frame zone (i.e., the impeller). In contrast, it could be used instead, even when the impeller is relatively close to the interface, when the rotating frame zone is relatively small with respect to the whole domain and it is not your main interest. Like, say, some fans distributed in a larger space. In your case, however, it is fundamental to know if the case is indeed a round pipe or not. In the former case you could indeed push the interface farther away. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Setting the height of the stream in the free channel | kevinmccartin | CFX | 12 | October 13, 2022 21:43 |
It would be wonderful if a tool for FoamToTecplot is available | luckyluke | OpenFOAM Post-Processing | 165 | November 27, 2012 06:54 |
Error with Wmake | skabilan | OpenFOAM Installation | 3 | July 28, 2009 00:35 |
OpenFOAM on MinGW crosscompiler hosted on Linux | allenzhao | OpenFOAM Installation | 127 | January 30, 2009 19:08 |
Windows Installation BugsComments on Petrbs patch | brooksmoses | OpenFOAM Installation | 48 | April 16, 2006 00:20 |