can we agree on the basis of "C" in C/W ?

[BillA]

3 lines of history
- the WCing community defines "C" (in °C/W) as a temperature difference between the heat 'source' (somehow measured) and the coolant
- after several years I used the LMTD to describe the wb coolant temp, then changed at the suggestion of Les
- Les prefers the inlet temp
- Stew prefers the outlet temp

care to sort this out ?

[bobo5195]

Professional engineers dont agree (my lecturer shruged when it came up but thoses lectures were 1.5 years ago and i was hungover for most of them). It depends which is the better measure as defined by a bunch of testing with other parameters.

I would use inlet as this the thing you have control over.

[Cathar]

Rather than suggest that the outlet temp is superior, I'll just explain the reasons why I prefer it.

It really comes down to the similarity between this application and the way PC's work, and thereby convenience for the end-users to interpret the data.

By measuring performance relative to the radiator outlet temperaure, the heat load (constant measured in Watts), and the flow rate (air & water), we are directly simulating what occurs in PC's as flow rate is varied, and we are providing a direct 1:1 relationship between the flow rate and what temperature comes out of the radiator, and hence into the waterblock.

Waterblocks have their C/W measured relative to the heat load and the inlet water temperature. This is fine and the way it should be, because the waterblock is where the heat is being added. The problem here is how can the average user predict what the inlet water temperature will be given some radiator, a fan, and a pump?

It just seems fairly obvious to me. We know the heat-load (well, we don't really but it is a constant given a fixed CPU program load, and can be estimated fairly well), we know the flow rate, either through measurement or through prediction based upon the PQ curves of the loop components, and we know the air-flow through the radiator through whatever means.

It just seemed to me to be most useful given all that to simply state what the resultant radiator outlet temperature would be, as this provided a value that is of most direct use to the end-user, without them having to work out the temperature drop of the water across the radiator which is what they would have to do if we measured the water temperature at the inlet.

It is clear that as the flow rate varies this then means that the water temperature that enters the radiator is going to be warmer/cooler as the flow rate is dropped/increased, and this doesn't present a nice fixed relationship between incoming air and incoming water. However, if we measure at the inlet we have to raise/lower the heat-load to maintain a fixed dT between the water-in and air-in, but in doing so we are now changing the picture. The CPU does not increase/decrease its heat load as the flow rate changes, or as air-flow rate changes, so I don't understand why we should be quantifying radiator performance with respect to a variable heat load. It's not how CPU's works, and it presents a figure that is less useful to the end-user without them first munging the values to compensate for the thermal mass flow rate of the liquid.

I do also understand the reasons for wanting to keep the air/water delta constant, purely because this removes an extra layer of variability with the test equipment. If test equipment is accurate to +/- 0.1C let's say, and the outlet temperature across a full range of test conditions is ranging from 1C to 10C, then we now have a variable margin of error.

At the end of the day, I do feel that the average user is prepared to accept values with a varying margin of error that approximate their waterblock inlet temperatures, rather than be presented with a C/W figures with a fixed margin of error but then requires them to do thermal mass flow rate compensations to determine the waterblock inlet temperature.

So that's why I prefer the radiator outlet temperature. Just my 2c.

[jaydee]

After reading that I guess we should decide what order of parts should be. Right now I have:
pump>filter>flowmeter>temp sensor>valve>water block in>water block out>valve>rad in>rad out>res>back to pump

If I used rad out I would be missing the added heat from the pump.

[bobo5195]

I thought we were talking about waterblocks only, not radiators as they are complex.

My heat transfer notes say that basically C/W for rads is a bit simplistic. It suggests LM with a correction factor to take into account cooling effects inside the exchanger. In other words horrible stuff for consumers and all 4 temps (air, water, in and out) need to be known for you to even get started and they are all a complicated function of each other. As for simplifying assumptions that’s far to much down the road for it to be helpful, in short for rads I don’t think there is a nice way without knocking off a lot of factors so stuff like weather or not your using the inlet or outlet temp is neither hear nor there.

My personal opinion is that things like this consumers shouldn’t need to worry to much about. An expansion of LHG approximator with a few good results (and Newton based method for solving the matrix equations) and let the masses choose and play around hidden from the maths beneath, intergrate it into your webpage shopping cart and everyone’s happy. Some non dimensional numbers would be useful as well as a benchmark but getting a company to dosh these out is going to be hard and prone to all kinds of problems.

[Les]

1) Cannot recall you ever posting wb performance curves using LMTD or my suggestions that it should be changed to Twater.in
(2) For radiators suggested T(water.in) as being preferred to LMT(D)(water) when no T(air out) was measured(link) T(water out) was not being considered as an option at that point in the discussion.
My ultimate preference for system modeling was "Outlet + 2/3 metre of tubing" temperature(link)

For wbs prefer T(water.in) when using the term "C/W"; it easier for system modeling.
When describing the resistance/impedance would suggest using U; where U is the "Overall Heat Transfer Coefficient"
Q=UAdT(MTD)
A=wb/die interface area
dT(MTD)=LMTD= (Two -Twi)/lin((Tdie - Twi)/(Tdie-Two))

Not 100% that dT(MTD)=LMTD(needs checking).

[BillA]

Stew, so we are clear, this is about SYSTEM C/Ws apparently

". . . we are directly simulating what occurs in PC's as flow rate is varied, . . . "
no, in a PC the flow is a (system) constant

"It just seems fairly obvious to me. We know the heat-load (well, we don't really but it is a constant given a fixed CPU program load, and can be estimated fairly well), we know the flow rate, either through measurement or through prediction based upon the PQ curves of the loop components, and we know the air-flow through the radiator through whatever means."

here I have to presume that every instance of "know" in the above means as estimated by THE observer, different observers having different 'knowledge' therefore different results - no ? did you overlook that the CPU temp is also 'known' ? we probably 'know' the air temp also though I do shudder to consider the real accuracy of an air temp
- but I have a question, how do we know 2 coolant temps (at any point) ? so are these temps obtained with the DIYer's probes and thermometer(s)

this is all too glib by far, lets start with some knowns
a single mfgr is providing comprehensive performance data on their products and systems, for those with an interest much of that data can be applied to similar products and systems

are you proposing a DIY/no-tech mfgr systems test methodology ?
if so why are water temps being measured anywhere ?
the system dT is CPU to air, low tech or high

I suspect you have jumbled component and system testing parameters though you have not applied the exit temp discussion to rad component testing
- got me confused

[jaydee]

EDIT: I am lost never mind.... :shrug:

[BillA]

Les
1) you are correct, LMTD was for rads
2) yes, to make sense the LMTD should be applied to both sides which is why I agreed with you

re system modeling, it is difficult for me as I think in terms of system testing
what Stew seems to be suggesting is component testing done differently for the use in system modeling, your "Outlet + 2/3 metre of tubing" seems similar in intent

so are you guys proposing rad testing using the outlet temp as the set point ?
the equip does not care, but I am mystified

I'll go get a drink, then start on "U"

[Cathar]

Hmmm, maybe I am confused too. What threw me was this statement in the opening post:

- Stew prefers the outlet temp

I only prefer the outlet temp for radiators, not for waterblocks, so I was running down the path that this was all relating to radiators, but you were not to know that. Getting ahead of myself.

In my opinion, that which is most useful is this:

Waterblock performance is measured relative to (heat_die_temp - water_in_temp) / heat_load.

Radiator performance is measured relative to (water_out_temp - air_in_temp) / heat_load, where heat_load is the sum of heat_load from radiator_out to radiator_in.

At least, that's how I approach the definitions of "C" with respect to those loop items. LMTD is a more consistent approach that applies to both, but IMO, harder for the average user to work with, and more difficult to base system simulators around (although not a lot more difficult, but perhaps just harder for the average person to understand the caveats).

[Les]

Originally Posted by unregistered

so are you guys proposing rad testing using the outlet temp as the set point ?
the equip does not care, but I am mystified"

Set point for system should be Air inlet
Set point for wb should be wb inlet

[BillA]

ok, I see where I shot off the rails
when you define 'W' that way for rads, do you understand the needed resolution/accuracy ?
I just bought this http://cgi.ebay.com/ws/eBayISAPI.dll...tem=7556455435 and I know Incoherent can do it, but who else ?
and Incoherent is probably never going to test a rad (too clever by far, lol)

why do you not wish to characterize the wb heat load the same way ?

[BillA]

Les
and the set point for rads ? to be the outlet temp ?
unfortunately I have no data to use to compare the methods, but I should be testing rads in a couple of weeks and will re-visit the subject when I know what the consequences are

kind of moot as the C/W is determined using a temp interval far larger than the component dT, but that too is a consideration

[Cathar]

Originally Posted by unregistered

when you define 'W' that way for rads, do you understand the needed resolution/accuracy ?

I do. However, given typical radiator performance levels such can be commutated to a fair extent by increasing the heat load. Unlike waterblocks, can quite happily supply most radiators with a 500W heat load and then even 0.01C accuracies are no longer as essential for an acceptable degree of error margin. Doing so also makes the quantification of secondary losses significantly easier to observe. Might then start to consider the variations in the thermal properties of the coolant with respect to its temperature, but I can't see this being terribly significant given that people operate their systems ranging from 10C-40C ambients anyway. Regardless, when testing and developing we're concerned with the relative differences in radiator performance, and the relative difference is going to be very close, if not identical, regardless of a 100W heat load or a 500W heat load and the associated coolant temperatures that go along with that.

why do you not wish to characterize the wb heat load the same way ?

Not sure I understand the question.

[Les]

Originally Posted by unregistered

ok, I see where I shot off the rails........
when you define and I know Incoherent can do it, but who else ?
and Incoherent is probably never going to test a rad (too clever by far, lol)?

Or is he,remember link and link

Originally Posted by unregistered

why do you not wish to characterize the wb heat load the same way ?

I do(link)
Mentioned such in e-mail to Cathar and circulated to "you at Swiftech"(22.09.05)

Edit

Originally Posted by unregistered

Les
and the set point for rads ? to be the outlet temp ?

Air inlet, I think.
Will reassess in morning

[BillA]

do I recall correctly that Incoherent is not measuring flow, but back calculating it ?
I did not address this question as I was occupied, note the date
now will have to wait 'till I can generate some new data sets

oof, who has 0.01°C accuracy ? even that HP 2048A is 0.04 on its best day
also I would never presume that the C/W is the same over a 5 fold range, 100 to 500W

[Les]

Originally Posted by unregistered

do I recall correctly that Incoherent is not measuring flow, but back calculating it ?

You are correct.
Hoping the difference can be detected(and maybe measured) when he is rich and gets a flow meter.
BTW Incoherent may be midway thro house-move(he mentioned somewhere that move was imminent)

re e-mail thought twice about circulating but decided was gentlemanly to do,even tho rumours were rife.

Radiator set-point.
Air inlet, but will rethink in daylight morning

[BillA]

I have an un-needed 1/4" mag flow meter I could loan him ??
cost $350 to get it caled though
my experience is that if they work they are is spec, never encountered one that would accept the flowtube # and not be ok

[Kemist]

Originally Posted by unregistered

oof, who has 0.01°C accuracy ? even that HP 2048A is 0.04 on its best day
also I would never presume that the C/W is the same over a 5 fold range, 100 to 500W

Not sure whether resolution is high enough, but GE-Kaye has high resolution thermocouples etc. Not sure how much they cost but im sure they are expensive

http://www.kayeinc.com/validationproducts/irtd.htm

[Les]

Originally Posted by unregistered

also I would never presume that the C/W is the same over a 5 fold range, 100 to 500W

U probably is, for both radiator and wb
"C/W"s, as stated elsewhere,are another matter.

[Cathar]

Originally Posted by unregistered

oof, who has 0.01°C accuracy ? even that HP 2048A is 0.04 on its best day
also I would never presume that the C/W is the same over a 5 fold range, 100 to 500W

Hmmm, we see the curves from your testing that the C/W remains relatively fixed across broad heat-load differences...

What are we after here then? For me, I want a fixed way in which to assess relative radiator performances, and if that can be achieved with a certain degree of accuracy with 250-500W heat loads with 0.1C accuracy equipment, as opposed to 50-100W heat loads with 0.04C accuracy equipment, then so much the better.

As for upholding a single absolute testbed procedure against which all other testbeds can be essentially described as being equal, I don't think that's ever going to be achieved. We can already see transparantly through the actions of certain manufacturer's marketing material that there is no interest to ever provide such, quite the opposite in fact.

So in my mind whatever is done, is being done on a per testbed implementation and that's the way it's going to remain unless some testing company starts supplying products like a "Unified Waterblock and Radiator Test Kit", and even then we'll still have various manufacturers preferring to target and sell to the ignorant with trash figures, and they'll still succeed.

At the end of the day, is this concern applicable to the end user, or to internal testing only? If to the end-user, then the measurements as I suggested is going to be most suitable for them, and easier for them to understand and work with. If trying to provide fastidious accuracy and adherence to strictly defined testing guidelines as suits the more rigorous and discerning customer (i.e. NOT PC water-coolers), then ones hands are pretty much tied anyway.

So let's throw it back and ask what are we trying to achieve here, who is the audience, what do they want, what are they (the wider audience) capable of understanding, and what is an acceptable degree of accuracy for them?

Let's face it, if you're a manufacturer and you're adhering to strict testing and measurement guideliness, it's only going to be used against you by the less scrupulous marketeers. You'll say radiator has "XXX" performance, they'll just advertise as "XXX+10%" with no actual proof, but just say all the right words in public to placate the ignorant to get the dollar. You've done all the hard work, they've lied, but who gets the dollar at the end of the day?

[BillA]

interesting product w/great specs, major drawback is the 24" length - need a bigger chamber

U for rads ?

[Les]

Originally Posted by unregistered

U for rads ?

Q=UAdT(MTD)
A=Frontal area(for example)
dT(MTD)=LMTD = ((Twi -Tao) - (Two - Tao))/ln(Twi -Tao)/(Two -Tai)


Edit: Corrected equation,was arse-bout-tit

[Kemist]

At work ive used the IRTD to calibrate Kaye Digi 4 thermocouples, which are in turn used to validate things like refrigerators. The IRTD is used with a calibrated heating block, not really sure if its used for other things.

[Les]

Originally Posted by Cathar

Hmmm, we see the curves from your testing that the C/W remains relatively fixed across broad heat-load differences...

Have not seen any such curves or indications for radiators.
Only curves are where (Twi-Tai)* is fixed and actual parameters(Q,Twi,Two,Tai and Tao) involved in the rate-equation* are allowed to float(in accordance with the laws of physics). All that is being indicated is that W is behaving like Q(except at high coolant flow where dP*Flow(water) correction becomes significant and has to applied to W) and obeying the Laws of Physics. Gives no indication of the "C/W" [(Twi-Tai)/W] variation with Q.

For wbs on dies, Bill's early work(e.g this does include indications but shows no definitive curves. Here (Tdie-Twi)* change with Q(I understand to be heater wattage(super-insulated and heat-loss-to-ambient adjusted) is measured..These data (would prefer using data as collective noun but...Rome....) suggest measured Q is behaving like the rate-equation's Q***. Additionally since (Twi-Two) is correctly predicted(as shown here) it suggests to me that C/W((Tdie-Twi)/C) is behaving similarly to U. Further data sets (like these) may possibly reveal that this only approximate.


* (Twi-Tai)=C and (Tdie-Twi)=C in C/W
** Q=UA((Twi -Tao) - (Two - Tao))/ln(Twi -Tao)/(Two -Tai)
*** Q=UA(Two -Twi)/lin((Tdie - Twi)/(Tdie-Two))