rads in parallel

[bobo5195]

Having looked at bill adams graphs of radiators which shows that for the most part there perfromance is flow rate independent, why dont people run radiators in parallel?

Flow rate maybe halved (to each) but resistance will also decrease as there are two seperate routes to go through (flow area is effectively doubled). Also the temprature difference accross each rad is greater so more heat disipation can take place.

[Incoherent]

Originally Posted by bobo5195

why dont people run radiators in parallel?

Because most people only have one perhaps.

[Long Haired Git]

Because the plumbing is more complex.
I ran my two rads in parallel, but wouldn't do it again.
See, the flow restriction caused by rads relative to a modern restrictive block (Storm design, WhiteWater design) is bugger all.
Experiment here:
http://www.uitp.com.au/cgi-bin/approximator.htm
If you've already got split paths (eg: LRR WW outlet) and you've got two radiators, go for it.
A lot easier to fit two radiators in a case than one big one.

[bobo5195]

I was thinking less from a flow point of view (and restrictions) but more for temperatures and increasing radiator performance. I would need to punch up some numbers but two rads in parallel should have a large increase in heat dissipative capacity as they have a higher dt but no loss in performance due to lower flow.

I was thinking of doing something similar to your java app in flash (to learn the program /programming language it uses properly) but the maths got hard. I tried a more general approach to yours using the algebraic riccati equations (solution to a symmetric quadric matrix Ax^2+ Bx+C=0) which assumed that everything could be modeled as a quadratic head loss (or head creator in a pumps case). After thinking about it im not sure about limiting myself to only quadratic models of head losses though. Also my (crappy) programming ran into a brick wall with all the look ups need for wattage and stuff. I was going to fall back and use the approach you were using (which is i assume to use a 3 way splitter in which Q is conserved and then use dp = f(v) where you look up f(v) and use and iterative loop to solve).

In answer to your questions and problems on your page.

Pumps in “manifolds” is an intrinsic problem with your approach. A test to make sure that a pump cannot pump water backwards would help. I need to think and punch numbers but im not sure if using the extended Bernoulli (which is an approximation after all) can model the way you want. Water may flow backwards in the manifold simply recalculating around the parallel loop from the pump entrance to exit without flowing in the overall loop. Either way there are major problems with having pumps in parallel paths.
For some loops you may not be able calculate an answer.

Correction of source data for fittings is easy as pie. Head loss because of fitting is about as easy to calculate as your going to get. All you need is the actual pump fittings that go in an out.
Derivation of losses for pipe diameter changes is easy. I cant remember it off the top of my head but the analytical solution (doesn’t include stuff like recirculation losses) uses conservation of mass flow then energy loss being from momentum being conserved. I have the derivation somewhere. The loss is of the order v^2.

Extrapolation good. The problem is extrapolate to what. I think for the purposes of the program a simple dp=k*v^2 is good enough but a lot of work needs to be done to establish this fact. Some turbulent losses work on v^4 scales for example and some due to the differential nature of the navier stokes equations are going to be logarithmic. The flow in channels of a waterblock is going to be all turbulence and probably all boundary layer this makes things tricky. It may also be temperature dependent. I would like at sometime to run a DIY blocks for whom I have dxf files through CFD to see what happens.

For pipe friction factor I had always planned on using for my proggie the darcy friction factor for the pipe friction instead of hazel williams which posed problems in getting a stable solution as its has to be iterative (checking lamina or turbulent flow etc). I think darcy is better as it can easily model water cooling friction factors (can calculate data instead of getting hold of empirical results) and is more accurate especially if some viscosity numbers for actual water cooling fluids. Plus I was planning on including some corrections for bends in pipes (you know the vector of where the pipes are coming out so you can work out a “good route” between them) and it would be more accurate to use darcy for this, though using the shallow bend hazel Williams factor might be good also.
If you would like pressure drop calcs for a pipe I could send you a subroutine with ease.

Head loss for various stuff should be easily available. I can get your weight in empirical data if you want. Doing stuff from first principals is a little hard but its gold standard empirical data so cant complain.

The heat inputs stuff should be easy with look ups (if your not a crap programmer like me). The pump stuff I was just going to model as a singular heat input of X watts. Which I think is okay heat is mostly transferred from the pump to the water instead of the air. Could use an insulated pump to test this.

[Long Haired Git]

Originally Posted by bobo5195

I would need to punch up some numbers but two rads in parallel should have a large increase in heat dissipative capacity as they have a higher dt but no loss in performance due to lower flow.

Comparison is two rads in water flow parallel vs same two rads in water flow series. Air flow is assumed parallel. Complexity of plumbing (T's, extra tubing) probably offsets any gains from reduction in head by each radiator. As we both agree, any impact from minor flow rate changes is going to be miniscule.
Hence, you plumb for whatever is easiest to plumb, which is typically serial.

Originally Posted by bobo5195

i assume to use a 3 way splitter in which Q is conserved and then use dp = f(v) where you look up f(v) and use and iterative loop to solve).

Java is OO, so keep that in mind. First I use an iterative approach to solve the flow rate. Each obj is asked to calc its head based on a set flow rate. Pumps are positive, restrictions are negative. I keep nudging the flow rate until I get near enough to zero. I worked on mathematical solution for only several minutes before I decided we have fast computers and loops in languages for a reason.
In my latest version (still in debug) I then do a second iteration to find the C/W and delta-T values, with again some objects producing positive delta-T's (pumps and blocks heat the coolant) and some objects cool the coolant (radiators) so negative detlta-T's until the coolant temp at the end is "close enough" to the coolant temp at the beginning.
I have a forumlae engine that accepts limitless additions of blocks of "x.y^z". That said, as per the graphs, most things just need two or three blocks.
Each object just needs then a PQ formulae.
Blocks need a Wattage for the thing they are cooling, and a C/W formulae to approximate the CPU temp to coolant temp delta-T.
Radiators also need a C/W formulae for their cooling efficiency. I'd love to have a three-dimensional map as the figures I have are from BillA's testing and he maintained a constant water/air delta-T, which is not what I want. Oh well.
Pumps have a wattage, and a formulae for approximating the % of that wattage added as heat based on flow rate.

Originally Posted by bobo5195

Pumps in “manifolds” is an intrinsic problem with your approach. [SNIP]For some loops you may not be able calculate an answer.

.
Yep - I just don't handle it properly so flag it as "use with caution".

Originally Posted by bobo5195

Correction of source data for fittings is easy as pie. [SNIP]Derivation of losses for pipe diameter changes is easy.

.
Yep - I have a little app that I can predict it with. The issue is time in getting to it, and also programming the GUI to enable barb selection. I got sidetracked into trying to enforce sense (ie, can't select 1/2" tubing for a 3/8" barb) but it got hard so I did something else. This is a hobby, so when it stops being fun....

Originally Posted by bobo5195

Extrapolation good. The problem is extrapolate to what.

Well beyond the approximator. Supply the PQ and CW graphs for a block or rad, and that's what it can do. I've done some work on modelling jet blocks and other designs, but way beyond my capabilities!

Originally Posted by bobo5195

If you would like pressure drop calcs for a pipe I could send you a subroutine with ease.

I can deduce a formulae using an app off the web, but the issue is it doesn't map to testing I found elsewhere. Perhaps silicon tubing is "sticky" to water flow vs the material properties of the apps?

Originally Posted by bobo5195

The heat inputs stuff should be easy with look ups (if your not a crap programmer like me). The pump stuff I was just going to model as a singular heat input of X watts. Which I think is okay heat is mostly transferred from the pump to the water instead of the air. Could use an insulated pump to test this.

In my latest version, I just have a selection widget where you select how many watts you want going from the thing-being-cooled into the water. It defaults to 70W.
For pumps, I use a formulae based on the stuff I found at Swiftech, where more power gets consumed when the flow rates go up, and then factor in that, like you, "most" heat goes into the water. Typically I vary from 60% to 80% of the pump wattage. Its just an approximator.

Anyway, so far it concurs with real world stuff. Eg: It too predicts the Iwaki 30 is worse to use than a 20 as the heat from the pump undoes any benefits from the flow rate.

[Output]

I use my rads i parallell. I've also modified my nexxus XP block for better flow since there are alot of narrow channels that lead in/out of that block.

[bobo5195]

I guess we’ll see what the differences when your proggie can produce the graphs. It depends on the relative magnitude of the performance change. I think the plumbing side might be counteracted by ease of placement. Either way it would be something for the “cooling nutters” because of the extra cost of the second rad.

Good to here that you’ve nearly got the temps working. That makes things 10x more useful and might help me since ive always like low flow but nobody believes me! (I know is should keep that abit quiet around here, else ppl will start hammering me with facts). I would like to see how much temperature in the loop is steady state (ie never gets removed but is needed for heat transfer stake). Fieled for cost would be nice so that things get all added up (possibly iterate to find $$/w for cheapest cooling. Might earn some money off referrals there , although it’s a moon on a stick style idea at the moment.

The concept of a good approximation is less important than I imagined given how general your program is (a[i]*x^N ; equation input). This should make fitting any approximation even if it is not decimal polynomial easy. Fitting the “correct” graph from test data is important however. This is better left to being discussed elsewhere but I am concerned that testing data that can be obtained by “the man in his garden shed “ with an accurate interpolation would be less suitable than just saying the curve is of the form a.x^2 and trying to fit the best approximation through these points.
This is immediately obvious when talking about radiators. Im going to have a look over my heat transfer notes but im sure theres an analytical or empirical derivation of the change in C/W for a radiator under different conditions. Either way it’s a difficult task.

I think I got a method of evaluating a pump flow in parallel but I would like to read up on it. Two pumps (not necessarily similar but operating in the same direction) would work with your formula but pump / resistor calculation is impossible and would not work for any cases. So use with caution, should change to use never.

Quote:
Originally Posted by bobo5195
If you would like pressure drop calcs for a pipe I could send you a subroutine with ease.
I can deduce a formulae using an app off the web, but the issue is it doesn't map to testing I found elsewhere. Perhaps silicon tubing is "sticky" to water flow vs the material properties of the apps?

Im not sure what the problem is with your pipe friction. The best method for friction would be http://www.lmnoeng.com/DarcyWeisbach.htm ) or perhaps a little worse but less of computational problem (http://www.lmnoeng.com/HazenWilliamsDesign.htm) . A little calculation of the Reynolds number (see below). Reveals that flow in water cooling pipes is near borderline for lamina/turbulent transition so that is perhaps where the problems are coming from, for a good model to be used some work will need to be carried out so perhaps hazen Williams is useful.

Re=Vl/v

Assume charcteistic length of pipe diameter and characteristic velocity of average fluid velocity V. Dynamic viscosity is 1*10^-6 for water. Using Q in lpm to calculate the velocity gives

Re=21.2*Q/D

For typical water cooling values of 1lpm and 12.5mm it becomes obvious that flow is in the transition range

[Long Haired Git]

My app is not going to help with your low flow quest, because the rad graphs I use are BillA's and he kept a constant 5°c delta between the water temp and air temp.
Hence my approximated rads perform better than they should whilst the water temp is closer to ambient than that.
There's a new article in the pipework with a bunch of rad testing, so I'll wait for that.

[bobo5195]

ah well nevermind one of these days you all learn mwahaha (probably not as its quite obvious by the data that im wrong as modern wb are not low flow enough)

I worked out pumps in loops last night but im going to do the math and do some back of the envolope calculations first to make sure im right. Basic assumption is that a pump will always mean that water will recirculate around the loop. When the water exits the pump its sees two resitances back around the loop and trhoguh the rest of the system. There is a caveat though i think as the pump itself is the only thing creating enough dp to pump it around the loop as opposed to all the other pumps in the system.

Nice to hear theres a new reviews about.