I brought up the idea of developing a watercooling system simulator in
this thread and rather than continue threadjacking there, I'm hoping to continue the discussion here.
Quoting a post from gmat in the earlier thread:
Quote:
Originally posted by gmat
That's the problem. If you count on only one person to fill the data, the DB won't be nearly useful before 1 or 2 years, and i'm optimistic.
One needs the curves (actually, the data behind them) for every pump, piece of tubing, rad, fan, and waterblock around. The software can interpolate between curve points, using linear or more elaborate techniques, but too many missing points and you'll get inconsistent results.
That said, many curves show a nice inverse exponential look, which can be neatly approximated. But one needs to consider each case (pump, rad, etc) and each subcase to match the math functions as exactly as possible. Not a short work either.
Also, some parameters are very hard to code, like turbulence behaviour for example. This is the domain of finite elements calculus, and out of reach for a small java applet...
We need to define exactly what to expect from that piece of software.
|
I think a very useful simulator could be developed without modeling every conceivable detail down to the part per million.
For example, modeling a pump as crudely as shown below, appears unlikely to result in a final temperature error greater than 0.1C. (The simulation is a simple parabolic curve.)
Of course if you stack up enough 0.1C errors, the total error becomes significant. More accurate models would certainly be desireable, but even crude models would allow people to make vastly better informed decisions than is common now. Even if such a simulator is not very accurate at predicting actual die temperature achieved, it could still be very useful in doing comparisons between different sets of components.
I certainly don't see a need for finite element analysis in order to produce a useful simulator. The relevant effects of turbulence in the water are, for the most part, already contained in BillA's dP vs flowrate and "C/W" vs flowrate curves.
In terms of the components, I envision something like this:
1) Fans - skip em, just allow a CFM input. Maybe report the pressure drop required to get that air flow rate with the selected rad. (There are a bazillion different fans. Their PQ curves are ugly. Actual performance depends greatly on shrouding, pushing vs pulling, etc.)
2) Pumps - simulated PQ curve are fairly easy to generate. I could set up a spreadsheet in an evening or two that would allow me to quickly come up with simulator equations for pumps that are substantially better than the one shown above. Power put into the water is another issue. Would have to be guesstimated for inline setups unless testing was done. Probably 80% of manufacturers spec'd max power could be used for submerged. A couple dozen pumps ranging from Eheim 1046 to Iwaki MD20-RZ and RX would be a worthwhile starting point IMO.
3) Waterblocks - List all of the commercial blocks known. If Bill hasn't tested it, report something like, "The manufacturers of this block are losers and have not provided the data necessary to simulate the block."
Of the blocks Bill has reported data for, it appears that simulating the relevant curves is usually easy. MCW462 types are the only ones which deviate substantially from simple exponential curve.
4) Rads - Biggest problem area. Curves can be very ugly. No data for most popular models - Chevette and Camaro heatercores, BIX, BIM? Perhaps an algorithm for determining the relevant data for Fedco heatercores, based on the commonly listed dimensions, could be determined. (Maybe Fedco could provide such?)
5) Tubing etc. - Allow four selections:
Typical 1/4"
Typical 3/8"
Typical 1/2"
Typical 5/8"
Eventually add a section allowing a person to detail his tubing/fitting setup? (More detail than I'd likely bother with, but if someone was motivated to generate that level of modeling...)
6) Heatpath through CPU pins to MOBO - use a guesstimated C/W.
Aside from the gaping hole, (data for popular rads) I think something fairly useful could be put together in a reasonable period. Ideally it would be a work in progress; components could be added as data became available, and errors in the results tracked down and corrected.
Seems worth consideration to me, but I'm not much interested in arguing about it. I can do the simulations I'm interested in, easily enough in Excel. Considering the generally dismissive response I've seen to the idea so far, I only posted this, because I said I would. I'm not much interested in pushing string.