# Torque calculations.

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

 June 16, 2001, 09:39 Torque calculations. #1 J. Keays Guest   Posts: n/a 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.

 June 16, 2001, 11:43 Re: Torque calculations. #2 John C. Chien Guest   Posts: n/a (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.

 June 16, 2001, 16:52 Re: Torque calculations. #3 B Malone Guest   Posts: n/a We get the wrong answer many times. The right one only once.

 June 18, 2001, 06:19 Re: Torque calculations. #4 Syaek Guest   Posts: n/a 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!.

 June 18, 2001, 07:17 Re: Torque calculations. #5 John C. Chien Guest   Posts: n/a (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.

 June 18, 2001, 13:17 Re: Torque calculations. #6 Geethakamal,Nallan Chakravarthy Guest   Posts: n/a 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. pugovka9085 likes this.

 June 19, 2001, 02:15 Re: Torque calculations. #7 Dan Williams Guest   Posts: n/a I have to ask this. Which code? CFX-5, 4, TASCflow?

 June 19, 2001, 05:25 Re: Torque calculations. #8 J. Keays Guest   Posts: n/a TASCflow 2.10. I have no idea why it giving such an incorrect answer.

 June 19, 2001, 23:19 Re: Torque calculations. #9 Dan Williams Guest   Posts: n/a 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.

 June 20, 2001, 20:24 Re: Torque calculations. #10 Robin Steed Guest   Posts: n/a 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

 June 21, 2001, 06:24 Re: Torque calculations. #11 J. Keays Guest   Posts: n/a 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.

 June 21, 2001, 13:22 Re: Torque calculations. #12 John C. Chien Guest   Posts: n/a (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.

 June 23, 2001, 16:24 Scalable wall functions. #14 J. Keays. Guest   Posts: n/a 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.

 June 23, 2001, 17:01 Re: Scalable wall functions. #15 John C. Chien Guest   Posts: n/a (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.

 June 24, 2001, 07:29 Re: Scalable wall functions. #16 J. Keays Guest   Posts: n/a 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!

 June 24, 2001, 11:03 Re: Scalable wall functions. #17 Robin Steed Guest   Posts: n/a 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. ALL of this is well documented in the TASCflow Theory documentation, including guidelines on grid generation. Robin

 June 24, 2001, 17:40 Re: Scalable wall functions. #18 John C. Chien Guest   Posts: n/a (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)

 June 25, 2001, 00:10 Re: Scalable wall functions. #19 John C. Chien Guest   Posts: n/a (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.

 June 28, 2001, 09:40 Re: Torque calculations. #20 J. Keays Guest   Posts: n/a 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.

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Anonymized_JL1 FLUENT 14 September 26, 2013 03:35 SAH2006 FLUENT 0 September 3, 2010 16:59 Yali CFX 2 January 7, 2008 04:13 Mechstud CFX 4 June 26, 2007 08:53 lancy CFX 0 June 10, 2003 06:19

All times are GMT -4. The time now is 13:08.