Althea,

Since seeing this message on CFD On-line last November I have undertaken a little research into this problem. I contacted the company involved and asked for the Pro/Engineer geometry of the valve that they were simulating. We then ran a CFdesign model of the valve for six different shaft positions. For each position CFdesign produced a summation of the forces on the shaft and the flow-rate through the valve for a given pressure drop.

After running this test "blind" I went down to see the company and compared our results to their experimental results. CFdesign's force predictions were within 15% of the experiment over the entire range and predicted the trends well. The flow rates were up to 20 % out but we would put this down to some slight misunderstandings about how the valve body was connected to the test rig. Assumptions were made about this geometry which turned out to be incorrect.

It turned out that the company involved had tried to simulate this valve with two of the best-known commercial finite volume based CFD codes. One had predicted a force on the shaft of 300 Newton's, at a position where the experiment gave them around 50 Newton's, while the other had given them a value of under 1 Newton. Some of the trend graphs looked like a random number generator produced them. Both of these codes produced very reasonable results for the flow rate.

Unfortunately I cannot give you a simple answer to why these Finite Volume codes are so poor at predicting forces in valves. I would guess that it is something to do with solving for the pressure at the cell centres and then having to interpolate the pressure forces to the walls. You could imagine that this could lead to problems when you have a flow through a small gap where there is only one cell through the width of the feature. CFDesign uses an equal order finite-element technique. That means we are actually solving for pressures on the nodes, some of which are on the walls. Therefore we do not need to do any interpolation to get the forces out.

If anyone else is encountering similar problems with valve forces, or just wants to find a quicker and easier way to run fluid flow problems, please take a look at www.cfdesign.com.

Regards

Mike Clapp

Valve forces Posted By: Althea <adesouza@talk21.com> Date: Fri, 3 Nov 2000, 3:36 a.m. Hello everyone, I am interested in using Fluent to simulate a valve under steady state conditions to predict the forces. The valves are fairly small (approx. 9mm diameter inner shaft). This is a problem which has been tackled previously by people who are no longer available (and unfortunately nor are their simulations). All I know is that their results did not tie up with the experimental data. Actually I think they got close with pressure drop but the forces were way off. What I want to know is this - is it reasonable to expect to be able to use Fluent to predict the forces accurately (within 10%) or would I just be wasting my time? And what complications would I be likely to encounter? Regards Althea

(1). Thank you for the invitation. I have just visited the website. (2). Thank you for the information. I think, the Colorful cfd is nice to have for PR, but the bottom line is even the NASA X- series will be cut if it is not working. (3). We used to think that money is all we need to invent something new. The reality is, you have to be very smart to find the answer. Even the X-series with nearly one billion dollars and five years of time is now dead. (4). And those who think that the answer is buried in the code, must make sure that they have the right code in the first place. (5). CFD is not about the code, CFD is about finding the smart person with the smart answer.

Mike,

Firstly, I hope you have been successful at winning contracts from the company as reward for your enterprise. It is good to see upfront investment in solid work rather than b******t. Which, unfortunately, leads on to your last two paragraphs.

I would strongly suggest the failure of the previous predictions had almost nothing to do with the adopted CFD software. It was simply that the people using it were not competent. In order to successfully apply a mathematical model (produce reliable results) the user must understand the basis of the model. This does not mean obtaining a Ph.D. in some field of CFD but it does mean investing some time and effort in learning how to control numerical errors with the grid generation and how the assumptions in the model show up in the predictions. This is unglamourous and difficult to measure in terms of money/time spent and useful knowledge gained but is almost certainly a far better investment for the company concerned than alternative CFD software.

Again, I would suggest that most competent CFD users would recognise a pretty likely contributory reason for the previous poor predictions (apart from grid resolution) the solutions were not converged. Mass conservation is a poor measure of convergence: you can get a "converged" mass flow on the first iteration with pretty much any initial flow field you like by heavily solving the mass conservation equations and/or heavy underrelaxation/small time step. It also doesn't take long to discover that the default convergence criteria from commercial suppliers can be daft. A recent prediction of the flow in/around a probe like device in tunnel hit the suppliers convergence criteria while still blowing out the initial transient. The flow was actually going the wrong way through the device at this point in the convergence history (negative force so that beats your too small and too big! - integrated mass flow across duct was fine). Now is this the suppliers fault?, is it the fault of pressure interpolation? is it the fault of the finite volume scheme? or is it the fault of the user if they do not recognise what has happened and simply run on past the initial transient to get to the converged solution?

I do not want to be seen to be promoting the codes you are disparaging (I am currently writing a report that is fairly critical of one of these codes) and I am unfamiliar with your code and so cannot comment on whether it is superior/inferior in any significant way. But please, if you wish to attack the leading commercial codes (and I would agree that there is some scope for this) do so for the right reasons (technical reasons that is not marketing reasons). It is quite unreasonable to introduce speculative nonsense on FEM vs FV based on (a) the predictions (possibly unconverged) from a less than competent user who has "resolved" a flow passage with one cell (is this the gap between a poppet valve and it's seat? The multi-moded separation off the leading/trailing edge of the valve and valve seat "resolved" with one cell?) and (b) apparently competently performed predictions using your own code. Surely, a fair comparison would require you to screw up your predictions in the same way?

(1). I have studied some commercial CFD codes extensively for the last several years. And my conclusion is:a commercial code is a commercial code. That's all. (2). To run a code, it takes a couple of weeks to learn how to use it. (3). To solve a problem, even with nearly one billion dollars and five years of time, the end result is sometimes like NASA X-series spaceplane. (4). In the commercial world, the customer's satisfication is the source of business. The user is definitely a customer. If the customer is a PhD, then it is very hard to make a deal. (5). So, the ideal market for commercial CFD codes is the persons who know nothing about CFD but are interested in becoming an expert. (6). But for companies interested in getting real solutions, using commercial cfd codes blindly will guarantee that the company will die several times. (the same reason for the dot com failure. Simulation is not always real. And real life is sometimes very hard.)