Torque calculations.
 

Hi,

I am having a problem calcuating the torque on my impeller in CFX. I can caculate the torque on the blade (excluding the hub) an I get a value of, say, x. I then calculate the torque on the hub (excluding the blade) and I get a value of torque on the hub or 6x. This is clearly a crazy result! I believe the flow field is reasonably well converged, and even if it was not, I would not expect such a discrepency. I am convinced I have defined the rotational axis correctly and also that the regions are correct. I am running a Frozen rotor simulaiton of a single bladed centrifugal waste water pump moving at 305 rad/s. Does anyone have any ideas? I am using the macro for torque and the macro for turbo_perform in CFX. I know the macros tell you to understand them before you use them, but I am convinced that the problem lies elsewhere. Has anyone any experience with such a problem as I have?

thanks for any help,

John.

Re: Torque calculations.
 

(1). Again, my theory says that 99% of the time we are getting the wrong answers in CFD. (2). Try the other way: the angular momentum change between the inlet and the exit of the flow comes from the work done by the torque, assuming that other frictional effects are not included. (3). So, find the angular momentum balance first.

Re: Torque calculations.
 

We get the wrong answer many times. The right one only once.

Re: Torque calculations.
 

Thank you!!!!!! I like that, but I'm afraid I would not mind getting a wrong answer, but I am getting a ridiculous answer!! 99% pespiration.... 1% inspiration :Edison...I think!.

Re: Torque calculations.
 

(1). Well, the 99% is derived based on my hands on experience. (2). In most cases, it is larger than that. (3). It is more or less similar to the research of the cancer cure drug. (4). But if you like it (doing CFD research), then it is something fun to do. (5). Sometimes, it is easier than taking a picture of lotus. In early 90's, I took some 2000 pictures of lotus flowers in three summers (almost every Saturday and Sunday). (6). It is very important to realize this when doing CFD research. The failure of a company, in most cases is the failure to understand this nature of work. (7). In other words, if your working environment allows you to fail 99 times, then you are next to finding the right answer. Most companies can't wait that long though.

Re: Torque calculations.
 

I wouldn't agree that you get wrong answers 99% of the time. If we have good physical insight as to what results one should anticipate then we have a good chance in CFD. But most of the times the students are in the learning process and they just do blindly sometimes without putting an extra effort to understand the physics of the problems. Research is a phase,one phase being good and the next phase being depressing. But that's where the challenge lies. Nobody has seen great success without a failure. But in companies,one would be expected to produce timely accurate results. The future of CFD lies in the hands of people who are good in numerics and those who are good in physics and there should be a good balance between the two since we use numerical techniques to solve our physical problems.

Re: Torque calculations.
 

I have to ask this. Which code? CFX-5, 4, TASCflow?

Re: Torque calculations.
 

TASCflow 2.10. I have no idea why it giving such an incorrect answer.

Re: Torque calculations.
 

How exactly are you calculating the torque? Maybe your torque calculation is in error or inconsistent with your problem setup. I'm not a TASCflow expert but there is probably a way to do this in TASCbob.

Re: Torque calculations.
 

Jim,

Did you use Build-case to set up your model, or TurboGrid to build your grid? If not, you will have to ensure that you have correctly assigned your regions for the macro to work correctly.

Robin

Re: Torque calculations.
 

I used Build-case to setup the problem. I am convinced that the problem lies with something I am doing in Tascflow. I use the turbo_perform macro to calculate my torque. I oculd live with the result if the torque on the hub wasn't six times greater than that on the blade! A ridiculous result.

Re: Torque calculations.
 

(1). I must assume that your "hub" is a cylindrical surface. Therefore, the pressure on the hub surface is not going to give you the torque. (2). If that is the case, the only force left is the skin friction on the hub surface. (3). Skin friction is hard to predict correctly. So, why not take a look at the hub skin friction first, to see whether the result is reasonable. (it is hard to know) (4). My suggestion is: for the MACRO function part, you will have to talk to the vendor's support engineer. for the skin friction on the hub, try to refine the mesh near the wall (put more mesh points there), run the case, and check the result again. (5). Remember my theory, if you have already tried 99 cases, the next one will be a good one.

Re: Torque calculations.
 

Good suggestion.

There are two things you may want to do; look at the shear stress field on your surfaces, check that your Y+ values are reasonable for the turbulence model you have chosen.

To look at the shear stresses, go to the Vector Field Manager and replace the velocity vector components (U,V,W) with the shear stress components (TAU_WALL_X, TAU_WALL_Y, TAU_WALL_Z I think). If you then generate a vector plot on your hub surface, you will see the direction of your shear components. Note: these will point in the direction of the reacting force on the wall, opposite the flow direction.

Check your Y+ values by plotting YPLUS on your surfaces. You may also want to go to tasctool and calculate the min, max and average values of YPLUS for all your surfaces.

For k-epsilon with the default wall model, you should have YPLUS between 20 and 100, preferably closer to 20. If your YPLUS values are too far off, the wall function will miscalculate your wall shear. If you cannot ensure good YPLUS values, you may want to try the SCALABLE wall function, which makes the assumption that the node at the wall is actually on the edge of the viscous sub-layer, thus correcting for bad YPLUS.

If you are running k-omega then you are trying to model the boundary layer directly, thus you will need YPLUS less than 2. If you are using k-omega, you should also use Menter's SST model. SST uses k-omega in the near-wall region (where it is best suited) and k-epsilon in the free-stream (where it is best suited), a blending factor applied in-between based on the near wall distance.

If these are off, you should fix your grid and run again. Remember, you are building a simulation with TASCflow (or any code for that matter) and the results are only as good as the grid and BC's you provide.

Robin

Scalable wall functions.
 

Hi,

I have a related question. You say to consider the refinment of my boundary layer. I am usgin the scalable wall functions in Tascflow and I have been told by a CFX Engineer that I do not need to worry about the y* and y+ values. He told me that the model will take care of the wall region (perhaps by creating cells itself) when it encounters various flow situations (recirculation, highly sheared, rotating, curvature etc.). Has anyone any opinions on this? Can anyone further explain this "scalable wall function" to me. thanks. J.

Re: Scalable wall functions.
 

(1). If what you are saying is true, then why not reduce the number of mesh points near the wall to speed up the calculation. And I guess, they will tell you that the results will be the same? (2). Anything which is related to the use of the wall function requires further investigation.

Re: Scalable wall functions.
 

I agree John. I am very reticient to accept that the scalable wall function is capable of taking care of itself. It seems like a drea come true, but I'd imagine its a dream with a nightmareish twist!

Re: Scalable wall functions.
 

The scalable wall function makes the assumption that the node on the surface of the blade is actually on the edge of your viscous sub-layer, rather than the surface. The implied geometry change usually results in less error than a bad y+ would. Because it is still using k-e and a wall function, it will not accurately predict separation.

The intent is not to let the user be lazy and put less nodes near the wall. More so, it is to allow the user to do grid refinement studies without worrying about y+ being too small.

You should still have plenty of nodes near the wall, if anything this is a way for you not to worry that your y+ is too small when using scalable wall functions.

If you are concerned with separation, use k-omega SST and make an appropriate grid.

<font color="#0066ff"> ALL of this is well documented in the TASCflow Theory documentation, including guidelines on grid generation.</font color="#0066ff">

Robin

Re: Scalable wall functions.
 

(1). It seems to me that there is no direct connection between a collection of codes and the solution of the user's problem. (2). This is upmost important to know, when the user attempt to solve his problem using a collection of codes. (3). In other words, the user of a collection of codes must realize that the codes contain only formula and concept which in most cases were not tested out to obtain a solution to the user's problem. (4). Based on my experience, a low Reynolds number turbulence model is a minimum requirement to handle 3-D flow with flow separation,(you can't find attached flow in turbomachinery)

Re: Scalable wall functions.
 

(1). Your e-mail has been received. (2). My comments here was based on my hands-on experience of CFX-TASCflow. (3). I also must say that the code has been used by a world leading turbomachinery company to make a claim on their high efficiency design, which could not be validated by my extensive and systematic study using the same code. (4). So, it is important to know that wrong claim can be made based on the results of this code, unless the results are systematically validated. (5). IT IS GOOD FOR THE CODE VENDOR BECAUSE WHEN THE WRONG RESULTS ARE USED BY THE USER, IT CAN DESTROY THE REPUTATION OF THE USER'S COMPANY AND THE CODE VENDOR. (6). If the code can produce only good results, then I guess, we don't need this forum at all. The need to have the forum is becuase the code tends to create the wrong result when used by a user.

Re: Torque calculations.
 

Problem solved thanks to an excellent CFX support engineer!!! It was a problewm in my definition of Torque calculation. Thank for all your help. J.

Re: Torque calculations.
 

(1). Congratulation! (2). Could you reveal the secret of your definition of the Torque calculation? This could help eliminating the same trip to the support engineer by our readers. (it is just a thought. it is not required if you prefer to keep it a secret.)

Re: Torque calculations.
 

Hi J Keays,

When one uses Turo Perform macro, it asks for inflow and outflow regions, and blade region, amongh other things. If the grid is generated using TurboGrid, the blade region is named BLADE and if we use BuildCase, it puts a suffix such as _R1 to indicate that it's the blade of a rotating part and _S1 to indicate stationary part etc. So, the macro asks for blade region also. What do you input? I input BLADE_R1. As far as I understand, BLADE doesn't include hub. So how do you manage to calculate torque at hub?

If it's not a secret(as indicated by John), please enlighten me. :)

Thanks

Drona