WC simulator discussion.

[BillA]

jeez, are you listening ?

Crane, Technical Publication #410; Flow of Fluids Through Valves and Fittings
- the fitting data is known (Crane sells a software program for $450)

this was also cited as a reference in pHaestus' flow article

a quick datum:
a wb mfgr sent me a prototype for testing with 90° swivel push-in fittings for 1/2" OD tubing

at 1gpm the wb's head loss was 0.35psi vs. 0.04psi using copper NPTm x 3/8CTS adaptors and 3/8" pipe (still with the 1/2" OD)

that represents a substantial flow difference

shitcan all fittings, use copper pipe and hose clamps (no barbs)

[gmat]

Originally posted by unregistered

shitcan all fittings, use copper pipe and hose clamps (no barbs)

Well, there are those who don't care about maximum performance (and flow), like in Germany. All they need is *some* flow (aka the pump doesnt stall) and silence.

Anyway, the software will model fittings and tubing. The accuracy of data provided will be yours, since you'll be able to add your own elements (="plugins").

[BillA]

is it about maximizing the flow/performance ?

or about minimizing the flow resistance so that the (smaller ??) pump can operate at a higher point on its efficiency curve ?

I do believe these 'issues' are quite the same

[gmat]

Yep.

I'm currently designing 'plugins' dataset interpolation. I'm currently writing a Lagrange interpolation as it's easy, but odd points on the dataset can produce 'wavelets' on both ends.
Anyone has a good algorithm for cubic spline interpolation ? I think i have one somewhere but it needs a lot of retooling...
(oh and any good polynomial fitting algorithm, other than Lagrange, is welcome)

[Blackeagle]

Gmat,


Well I don't know anything about doing code, so that is going to limit my taking part.

But I'd still gladly work on taking down the info on rads as far as the number of plate/tubes total & per pass, and total length of all the tubes in a rad to firgure area. Any thing of this sort to help out.

[gmat]

The software will not know about surface area and so on. Every element will be known as a data set of flow/backpressure or heat/flow, or both (for rads and waterblocks).
So for a rad you'll need at least 2 data sets:
backpressure vs flow
total heat transfer vs flow
Of course a problem arises there, air flow.
We can solve this by adding, for example, a heat transfer coefficient vs air flow, then (after fixing air flow) applying the resulting coefficient to the heat transfer vs water flow data.
That means for rads -> we need at least 3 data sets.
Heat up your Excel sheets

[BillA]

I have been waiting for the other shoe to drop

a rad's specific dissipation is a huge chore experimentally

[gmat]

That's why i'm doing the programming part
You guys do the data feeding part. The 'simulator' ("pro/sim ?") will be ready before actual rad data - and *good* data - is available... or I hope so...
Already got a 2nd polynomial fitting algorithm up and running. Currently testing it against Lagrange's.

[Joe]

So as you can see, you guys now have your own forum!

Enjoy!

[Alchemy]

Originally posted by unregistered
is it about maximizing the flow/performance ?

or about minimizing the flow resistance so that the (smaller ??) pump can operate at a higher point on its efficiency curve ?

I do believe these 'issues' are quite the same

They're not. The centrifugal pump efficiency curve maximizes at a particular flow rate, usually around 2/3 the max (not scientific, just guessing from the charts I remember). Maximum pump efficiency is not maximum or minimum of either flow resistance or flow rate.

As far as just the water part is concerned, the aim should be to maximize flow for a particular arrangement of blocks and radiators. The efficiency of the pump should make no difference unless you have a pump drawing close to an amp and dumping almost as much heat into the fluid as the CPU.

The end goal, I imagine, is to find the particular arrangement of pump, block, and rad with the lowest delta-T.

Alchemy

[gmat]

(Thumbs up, Joe.)

Well that would be an "optimizer", built on top of the simulator.
The goal of the simulator is to tell you the heat resistance of a particular setup.
With a heat input you can infer the actual temp of your heat source.
Once the sim is built and running, we'll be able to consider running it in iterative runs to find optimal setups. Until then, finding the best setup will be up to the user.

I've been running a few tests with real datasets (two pumps and one waterblock), with Lagrange polynomial interpolation the curve fits real well. I'm polishing a little tool that displays the characteristics of an element in a window, with a graph. If i'm motivated enough it can be ready next weekend.

[Alchemy]

Originally posted by gmat
I've been running a few tests with real datasets (two pumps and one waterblock), with Lagrange polynomial interpolation the curve fits real well. I'm polishing a little tool that displays the characteristics of an element in a window, with a graph. If i'm motivated enough it can be ready next weekend.

I was wondering if you (we?) were going to arrange the data as tables for each component or as functions. I guess functions would save a lot of time, and given most things should be well-correlated by polynomials.

I think this could work very well.

Alchemy

[BillA]

Alchemy

yes, sloppy terminology on my part

most (dare I say all) WCing pumps are operating FAR below (to the left of) their peak efficiency
so any reduction in the system flow resistance will have the effect of increasing the flow rate
AND
shifting the pump's operating point to (the right to) a higher point on its efficiency curve

still a bit sloppy, but a little clearer
the issue is not the same, but the effect is

[Since87]

Originally posted by Alchemy
I was wondering if you (we?) were going to arrange the data as tables for each component or as functions. I guess functions would save a lot of time, and given most things should be well-correlated by polynomials.

I think this could work very well.

Alchemy

My impression is that gmat is intending his simulator to interpolate based on a set of data points. (See his XML model example above.) This is certainly the easiest for people generating models.

We need to pick some units that all models will be in:

Water Flowrate -> lpm
Air Flowrate -> ??? CFM? metric convention? (Haven't googled this.)
Pressure drop -> mH2O
Thermal resistance -> C/W

Models would, in some cases, require conversion from a manufacturer's spec to these standard units.

(I've got a lot of issues to bring up, but little time for the next few days.)

[Alchemy]

Originally posted by unregistered
Alchemy

yes, sloppy terminology on my part

most (dare I say all) WCing pumps are operating FAR below (to the left of) their peak efficiency
so any reduction in the system flow resistance will have the effect of increasing the flow rate
AND
shifting the pump's operating point to (the right to) a higher point on its efficiency curve

still a bit sloppy, but a little clearer
the issue is not the same, but the effect is

I see. You're quite right.

Alchemy

[Skulemate]

Originally posted by Since87
Air Flowrate -> ??? CFM? metric convention? (Haven't googled this.)

How about m^3/min (CMM)?

[futRtrubL]

Is there any reason to change airflow to metric? a 100 CFM fan becomes a 2.83 CMM fan. If that's going to be changed then why not metricize the lot. So pressure change would be in Pascals (1cmH2O=98Pascals).


I have a request for another step in the sim. TECs. Granted the user of the sim could add CPU and TEC loads to get hotside temp through the "Pro/sim" and then use a TEC sim to get cold side temps. TECs would of course only be on the CPU and not elsewhere in the loop.

Edward

[Alchemy]

For airflow, might as well keep the pressure drops and airflow in inches water and cfm, which is how most data is given. [edit- sentence fragment removed - meant to cut&paste into next paragraph, sorry]

Since all this data will be given in terms of empirical equations, it makes no difference what units things are in so long as they're consistent - it's not like any unit conversion need be done so we can run semitheoretical methods or anything like that.

I'd say go for whatever units the experimental data is given in. BillA would probably be best in deciding what units those are.

BillA, on your site, how do you measure C/W? My indication is that it is the same as 1/hA, the inverse of the heat transfer coefficient mutiplied by the area of transfer.

For a waterblock, then, the C/W would be the difference in temperature between the CPU die and the average temperature of water in the block divided by the heat load. This is consistent with what you are doing, right?

Also, for the fittings issue, I still maintain that it's easiest to ignore the effects of tubing and fittings on the assumption that the person setting up the system will be doing his best to reduce their effects to be very small compared to the wb and radiator.

If everyone wants to include them, it will complicate the system pretty impressively because the k values will be needed for all fittings and the roughness factor will be needed for all tubing. You'd need to include a Moody diagram with at least a dozen or so best-fit correlations and, once all this was done, you'd need to iterate enough to form a PQ diagram for every possible fitting and every possible length of tubing. Then that PQ diagram must be fit like all the others so it can be combined with the WB and rad PQ diagrams so that it can then be combined with the pump curve, generating flow rate.

The k values are totally empirical and can be different even between two equally sized, seemingly equally-shaped elbows, for example. It is likely the k values for tees and elbows will be about the same, but I wouldn't be sure yet since I don't really have experience with simple fluid dynamics on this scale size.

Going this far you'd probably want to have delta-P considerations for bends and curves in tubing, which will be on a similar scale to elbows. These particular correlations I don't know off the top of my head, but I'm fairly certain even the Bernoulli equation could lead someone else to a theoretical equation.

All of this can be done if everyone wants.

It seems to me the project requires two significantly different parts - one using components to determine flow, the other using components and flow to determine an overall heat transfer coefficient. Seeing Joe was so kind to give us a forum, might we start making threads for each particular fascet of the project?

And, as futRtrubL says, should we look into considerations with pelt devices? Adding them would require consideration of temperature difference at any given heat load and voltage/current, but once that was done you would know the temperature of the hot side and the total heat leaving it, allowing one to run the heat transfer part of the simulator as if the hotside of the pelt were a CPU. Then the delta-T determined between the hotside and ambient would have the delta-T of the pelt to determine CPU temp.

The pelt part, I think, would require a third thrust of the simulator.

Once this is developed, I think ProCooling is going to gain a great deal of publicity among watercooling hobbyists.

Quite exciting, really.

Alchemy

[Alchemy]

BillA, I'm going to have to submit to your l33tness. I was running too many calcs in my head. When I double-checked with my texts and actually took out the calculator, I see you're quite right about the significance of form friction. I still think the tubing is going to be much less important, but if we're going to put fittings into calculations it's pretty damn easy to add tubing as well.

Except . . .

For the sort of tubing sizes we're looking at (around 1/2 inch) and the sort of flow we're going to see (around 2gph) Reynolds numbers will be around the 100s. This is a transitional region, so the Moody diagrams I have - most of which are quite extensive - have no correlation there for friction factor.

Also, do we have pump curves at different temperatures? Viscosity differences will cause huge differences in pump curves at temperature differences any higher than 2-3 degrees C.

Also, gmat:

The software will not know about surface area and so on. Every element will be known as a data set of flow/backpressure or heat/flow, or both (for rads and waterblocks).
So for a rad you'll need at least 2 data sets:
backpressure vs flow
total heat transfer vs flow
Of course a problem arises there, air flow.
We can solve this by adding, for example, a heat transfer coefficient vs air flow, then (after fixing air flow) applying the resulting coefficient to the heat transfer vs water flow data.
That means for rads -> we need at least 3 data sets.

For each rad you need a PQ curve for the water across the rad and the air across the rad.

You also need a heat transfer coefficient vs. flow rate (if BillA means what I think, this is essentially the same as a C/W vs Q plot) between the air and the radiator metal and the radiator metal and the water.

Separating these two effects could pose some difficulty since you need probes on the incoming air and the rad metal as well as the water. You'd probably need to insulate the probe from the air so it was only measuring the metal temperature. Still, as with almost anything, a good experimental method will tell you everything.

So, altogether, 4 data sets for the radiator.

This is so much more interesting than the other two design projects I'm working on.

Alchemy

[BillA]

indeed this is a fascinating project, involving the melding of a number of different skills

while I would agree that no 'informed' person would use a fitting, most are not so (ahem)
re the fittings:
the k factors exist, and they are not scaleable
the trick will be finding them in the sizes of interest (Imperial Eastman ??)
I am thinking 3/8 and 1/2" only; 45s, 90s, and Ts (through run and branch)
these resistances are expressed as equivalent length, so there is no way to avoid the tubing
(but at 1m in length its no biggie)

some time back I ran off the 'bent tubing' values
(who knows what thread that was ? - pHaestus, LNIKAGE plez)



for the 1m length involved, the tubing type is of no significance

re the temp effect on the pump curves, it is VERY substantial and is quite apparent at testing at even ±5°
ignore it, limit applicability to 25°C (the presumed nominal at which pump mfgrs are generating their data)

"C/W" basis is the temp differential between the CPU/die and the coolant inlet temp; divided by the actual Watts whose measurement and calc was described here

more later

[Since87]

Originally posted by Alchemy
For airflow, might as well keep the pressure drops and airflow in inches water and cfm, which is how most data is given. It's not like anyone's going to take those numbers and

Since all this data will be given in terms of empirical equations, it makes no difference what units things are in so long as they're consistent - it's not like any unit conversion need be done so we can run semitheoretical methods or anything like that.

Leaving fans in CFM and inH2O is definitely my preference. (Actually, I'm still in favor of leaving the fan/rad interaction out of the picture for a first pass at the simulator, and just having the user input a CFM.)

Originally posted by Alchemy

I'd say go for whatever units the experimental data is given in. BillA would probably be best in deciding what units those are.

That could certainly be done with the units specified in the XML model, and the sofware doing the conversion. That throws the burden onto gmat. There would still need to be some limit on what units the software knew conversions for. After all, flowrate can be expressed in firkins/fortnight.

Originally posted by Alchemy

BillA, on your site, how do you measure C/W? My indication is that it is the same as 1/hA, the inverse of the heat transfer coefficient mutiplied by the area of transfer.

My impression is that working with thermal resistances rather than surface areas and convection coefficients is much more practical. Temp gradients across surfaces and localized variation in convection make the whole problem blow up. We're very unlikely to have a significant amount of data in 'hA' form anyway.

Originally posted by Alchemy

It seems to me the project requires two significantly different parts - one using components to determine flow, the other using components and flow to determine an overall heat transfer coefficient. Seeing Joe was so kind to give us a forum, might we start making threads for each particular fascet of the project?

I was planning on setting up some different threads this weekend. Something along the lines of:

'Pump simulation discussion'
'Pump models'
'Radiator simulation discussion'
'Radiator models'
etc.

Suggestions on catergories are welcome.

Originally posted by Alchemy

And, as futRtrubL says, should we look into considerations with pelt devices? Adding them would require consideration of temperature difference at any given heat load and voltage/current, but once that was done you would know the temperature of the hot side and the total heat leaving it, allowing one to run the heat transfer part of the simulator as if the hotside of the pelt were a CPU. Then the delta-T determined between the hotside and ambient would have the delta-T of the pelt to determine CPU temp.

The pelt part, I think, would require a third thrust of the simulator.

Yes, pelts definitely need to be left out for the forseeable future. 'Creeping featurism' is one of the leading causes of project death. We need to keep this things within reasonable bounds.

Originally posted by Alchemy

Once this is developed, I think ProCooling is going to gain a great deal of publicity among watercooling hobbyists.

Quite exciting, really.

Alchemy

I agree but be very careful what you wish for...

[deeppow]

Looks like this holds promise due the efforts of several hard working folks and that the initial tasks are well underway.

So I'll jump ahead to consider what testing of the simulator will be done. As gmat and others of you involved in software development are aware, unit testing, component testing, and integral testing need to be done. From my experience, these seem to go by different names at times depending on the application but I'm sure the comp sci folks must have developed their own nomenclature by now. Someone should probably redefine those for us if the comp sci names are different.

Unit testing is most likely already being due where for example one would make sure the interpolators do what they should.

Component testing should be fairly straight forward in the simulator should be able to reproduce the behavior of the various components, rads for example, based on driving the input and air flow.

Integral testing may be more difficult.

BillA, do you have test results for a system that can be used? Need all components defined plus measurements of system behavior, hopefully with flow rate, cpu (test block) power, etc. varied across a reasonable spectrium. Would be really nice if the states of each component were /measured/available during the testing of each parameter set but I don't know if that is the norm or not.

Anyway, just some initial thoughts on the subject that will need further discussion.

[gmat]

Originally posted by deeppow

Unit testing is most likely already being due where for example one would make sure the interpolators do what they should.

That's what i'm doing right now, a small app that will allow anyone to put a XML file and see the interpolated results on a graphical chart.
Currently i have implemented two polynomial interpolation methods, that seem to produce very similar polynoms, with differences in the order of 1.10^-16. I think the choice will be made on performance as the algorithms involved are totally different (Lagrange and Neville).

Originally posted by deeppow

Component testing should be fairly straight forward in the simulator should be able to reproduce the behavior of the various components, rads for example, based on driving the input and air flow.

Actually once the interpolated data is correct, the sim will base it's figures on that. No 'modelling' behind the scenes, just a big polynomial solver (i'll begin with Newton's method - we'll see later if we need something more powerful).

(note) setting up a thread for interpolation methods could be useful, if anyone besides me has any knowledge about that. I'd be glad if someone provided me with an algorithm for a Bernstein one-dimensional method (also called B-Spline by some ppl, though i thought it was Bezier)

[Les]

Originally posted by unregistered
[

some time back I ran off the 'bent tubing' values
(who knows what thread that was ? - pHaestus, LNIKAGE plez)

[/b]

http://forums.procooling.com/vbb/sho...&threadid=5511

[Alchemy]

Originally posted by Since87
My impression is that working with thermal resistances rather than surface areas and convection coefficients is much more practical. Temp gradients across surfaces and localized variation in convection make the whole problem blow up. We're very unlikely to have a significant amount of data in 'hA' form anyway.

Actually, BillA's C/W term is the same thing as 1/hA. The heat transfer coefficient h is in terms of heat flux per degree temperature. Adding the area term and treating "hA" as a single variable removes all dependence on area.

Yes, pelts definitely need to be left out for the forseeable future. 'Creeping featurism' is one of the leading causes of project death. We need to keep this things within reasonable bounds.

We'll put those in version 2.0

As for the equation solver, the function we need to solve - the pump curve minus the added PQ curves for all components - will pretty much be a very slightly curved line crossing the y-axis at somewhere near 1/2 to 2 gpm, so we can set particular bounds and probably run a Newton's method until we get a y-value of 0.001 or something like that, and take that Q value.

Of course, I'm sure gmat and others would know more about what methods are best in whatever they're programming in.

Alchemy