The Z Build(s) 3.0 - Go Big and/or Go Home

[Grimlakin]

Man thats some good looking work. You have my applause and appreciation for sharing it here.

 

[Zarathustra]

Man thats some good looking work. You have my applause and appreciation for sharing it here.

Thank you sir!

It still feels a little bit messy to me, but once I get the medusas hair of wires inside the flexible conduit, I think I will be much happier with it

 

[Brian_B]

Will it be able to keep up with the heat sent to and mixed in the reservoir from the much faster moving GPU and CPU blocks?

The thermodynamic equations for that are pretty easy, if you wanted to prove it on paper. But it's easier to just YOLO turn it on and see what temps actually do. I bet it will be just fine - doesn't take nearly as much flow as you'd think it would to adequately cool a computer system. 0.6 gpm is still a decent amount of flow.

 

[Zarathustra]

The thermodynamic equations for that are pretty easy, if you wanted to prove it on paper. But it's easier to just YOLO turn it on and see what temps actually do. I bet it will be just fine - doesn't take nearly as much flow as you'd think it would to adequately cool a computer system.

Yeah, it winds up being a set of differential equations. The flow may be faster across the blocks, but that means that each cycle of water also heats up less, so it isn't a big problem.

This is a rather unique way of looking at things due to my approach of breaking up the loop and using the reservoirs as mixing chambers instead of having a single slug of water travel the full loop.

My real concern is that since I have a rather extreme amount of radiator capacity, that my lower than ideal flow rate won't be able to fully take advantage of it, as the coolant may get too close to ambient before exiting the radiators.

IN order to mitigate this, I think that once I am done flushing, I am going to change the block side portion of the loop around. The truth is that most of the time, when the gaming machine is on, the workstation will be either idle or turned off. What this means is that during the highest load conditions, I will see load on both the game GPU and Game CPU but not on the workstation CPU.

This wasn't a concern when I thought the radiator flow rate was going to be really high, but now that I have learned that it won't, I think I'll probably benefit from splitting the heat sources such that the Game GPU is on one reservoir, and the Game CPU is on the other, instead of both being on the same reservoir as I currently have it laid out. It makes the tubing layout slightly less convenient, but given the relatively low flow through the radiators, I think it will be thermodynamically more efficient.

0.6 gpm is still a decent amount of flow.

It's weird. When I started building custom loops years ago, the rule of thumb was that you had to have at least 1GPM to get good results. That is ~227 L/h

These days everyone seems to go for lower flow.

I have personally measured a contraction in delta T (coolant to core) in upping the flow rate from ~1GPM to ~1.3GPM in the past. This is certainly in the "limiting returns" area of the curve, but it still took a degree or two off, which can mean the difference between a stable OC / boost clock or not.

It has been a while though. Back when I did this testing I had an older EK Supremacy EVO block on my Core i7-3930k overclocked at 4.8Ghz at 1.445v

I don't have the data or my chart from back then anymore, but I vaguely recall predicatively charting the limiting return curve out to the right, and estimating that I'd see delta T benefits out to ~1.6 to 1.8GPM somewhere, after which increasing flow any further would be a waste of time. That winds up being ~350-400 L/h, which is MUCH higher than seems to be targeted these days.

Maybe the blocks are different these days? I'd imagine that with tighter and smaller microchannels, you'd heat a "slug" of coolant in the block across the block more, and because of this it would be less efficient at cooling due to the second half of the block having a much smaller Delta T to the core than the first half. (as we all know, heat transfer rate is proportional to delta T.)

So, the faster the coolant flows, the less of a measurable difference there is in temperature of the coolant entering the block vs leaving it, and the small;er that difference is, the more efficient the block is. But the closer you get to a difference in temperature across the block of zero, the less of a difference added flow makes. You'll of course never hit zero, but you can make the difference smaller and smaller.

On the flipside, the faster you push coolant through the loop, the more waste heat (friction + pump waste heat) gets into the loop, the quicker you hit the limiting returns as well.

Maybe modern blocks are designed to be less restrictive, and because of this, boosting the flow is less important?

Or maybe modern loop builders are just more focused on build aesthetics, and less conncerned with cooling performance than in the past?


Us old school builders were 100% about maximizing the overclock through minimizing temps. Aesthetics almost didn't matter at all.

I remember running whining 80mm high RPM Delta fans in my bedroom 24/7 back in those days.

 

[Brian_B]

I have personally measured a contraction in delta T (coolant to core) in upping the flow rate from ~1GPM to ~1.3GPM in the past.

Sounds correct - that's how the math would work out anyway. Energy = (mass flow) x (delta T) (x some other constants that end up canceling out in this case). You've got two loops, so that equation plays to the heating loop for energy going into the reservoir, and then a separate run of that same equation for the loop going out to your radiators. Your blended reservoir temp (if there were perfect mixing) would be the ratio of flow rates and their associated return temps dumping into the reservoir.

In the case of the radiators - don't you ~want~ the return temp as close to ambient as you can get it? I mean, that's the lower bound on how far you can cool anything without shifting to an active cooler someplace. I know you have the two separate loops here, and you do need to make sure the heat in actual < heat out capacity, so there is a lower bound on how low you can let the flow rate go through the radiator loop otherwise you won't be able to reject the heat being added. But I don't think you will be constrained by having too cool of a return temp there.

Water has an amazing heat capacity coefficient. Not many natural fluids are better. It's really good at picking up and moving heat per unit mass, so it doesn't take a lot of mass flow to move a lot of heat. It really just boils down to what your acceptable upper temp is for the return on the hot leg, and then making sure you have enough flow in y our cold leg for your radiators to be able to dissipate that with ambient temp being the lower boundary condition.

So if i were to work out some back of the envelope algebra, and we assume you have sufficent radiator capacity to dump all the input heat:
(keep in mind this is mass flow, so 1 gallon = 8.3 lbs, convert to your favorite unit)
Qin = m1 * (Tmax - Tblend)
Qout = m2 * (Tblend - Tmin)

Qin = Qout
m1 * (tmax - Tblend) = m2 * (Tblend - Tmin)

Tmax will be water temp, and what that can actually be will be based on how effective your water blocks are and the most limiting component in that loop ends up being at it's on-die junction temp.

Tmin will approach ambient temp, but won't ever really be able to reach it - part of those DiffyQs you mention if you wanted to run it that far. I gloss over them because you can't really affect them at this stage - your hardware is set, so you got what you got.

I guess if you know your flow rates, you could solve for what your max water temp would be and get a feel for if that's gonna work for your setup. Just use ambient at the radiator for Tmin for the moment as a starting assumption - maybe add a few degrees for localized heating or HVAC tolerance, etc. Qin would be the total heat rejection you need (sum of all components cooled).

pertinent conversion rates
1 W = 3.41 BTU
1 BTU = 1°F change in 1 lb water
1 gal water = 8.3 lbs

Tb = -[(Qin/m1) - Tmax]
Tmax = [(m2*Tb)-(m2*Tmin)+(m1*Tb)] / m1
-- could probably merge those two equations and reduce that down a bit more if you wanted to.
Note this only really works if we hold Qout = Qin -- in real life Tmax may hit a constraint or your radiator loop may not be able to keep up and you see Tblend creep up until you can finally get a delta T across the radiator that it can reject with ambient air

 

[Zarathustra]

In the case of the radiators - don't you ~want~ the return temp as close to ambient as you can get it? I mean, that's the lower bound on how far you can cool anything without shifting to an active cooler someplace. I know you have the two separate loops here, and you do need to make sure the heat in actual < heat out capacity, so there is a lower bound on how low you can let the flow rate go through the radiator loop otherwise you won't be able to reject the heat being added. But I don't think you will be constrained by having too cool of a return temp there.

The cooling effectiveness winds up being a combination of the flow rate through the radiator and the temperature when exiting the radiator.

Higher flow rate results in higher exiting temperatures (less of a temperature decrease across the radiator) but there is also much more coolant at that slightly lower temperature than there would be if the flow rate were to be slowed down. Then you get a lower coolant temperature exiting the radiator, but much less cool water to average out.

If your flow is high enough that it is enough to mix with the hot coolant coming back from the blocks, having it just exist the radiator at or near ambient would be ideal.

BUT lets combine the two radiators as if they were a linear percentage progression through the two of them.

The coolant in the radiator will drop in temperatures faster, the hotter it is. Across the radiator, the coolant will become cooler and cooler as it moves along.

If the flow rate is too slow, at some point, lets say 75% through the two radiators, the coolant temperature will start approaching the ambient air temperature. At that point, the remaining 25% of the radiators will be almost completely ineffective at cooling.

Because of this a higher flow rate, ideally so high that there is no measurable difference in the temperature entering the radiators and exiting them - will allow the radiators to work more efficiently, and cool equally well across the radiators.

This of course means that the coolant existing the radiators will be warmer, but this is fine because it will be a very high flow rate of incremental temperature change, instead of a very low flow rate of large temperature change.

If we think of it in terms of heat flow instead of in terms of coolant flow, or temperature in vs temperature out, because of the increased flow rate making the radiators more efficient, you actually have more heatflow despite only having a temperature change between the coolant in and coolant out that is barely measurable.

Because of this, a theoretical coolant loop where there are no downsides to cranking up flow rate infinitely (like added frictional heat, pump heat, pressure risks or power use) will be at its peak of heat transfer efficiency when the flow is so high, that the coolant measures the same anywhere in the loop you measure it, regardless of whether it is immediately after a radiator or immediately after a hot water block.

You have then turned something resemble static thermal transfer between coolant and block and coolant and radiator into something resembling more of a differential equation.

Water has an amazing heat capacity coefficient. Not many natural fluids are better. It's really good at picking up and moving heat per unit mass, so it doesn't take a lot of mass flow to move a lot of heat. It really just boils down to what your acceptable upper temp is for the return on the hot leg, and then making sure you have enough flow in y our cold leg for your radiators to be able to dissipate that with ambient temp being the lower boundary condition.

So if i were to work out some back of the envelope algebra, and we assume you have sufficent radiator capacity to dump all the input heat:
(keep in mind this is mass flow, so 1 gallon = 8.3 lbs, convert to your favorite unit)
Qin = m1 * (Tmax - Tblend)
Qout = m2 * (Tblend - Tmin)

Qin = Qout
m1 * (tmax - Tblend) = m2 * (Tblend - Tmin)

Tmax will be water temp, and what that can actually be will be based on how effective your water blocks are and the most limiting component in that loop ends up being at it's on-die junction temp.

Tmin will approach ambient temp, but won't ever really be able to reach it - part of those DiffyQs you mention if you wanted to run it that far. I gloss over them because you can't really affect them at this stage - your hardware is set, so you got what you got.

I guess if you know your flow rates, you could solve for what your max water temp would be and get a feel for if that's gonna work for your setup. Just use ambient at the radiator for Tmin for the moment as a starting assumption - maybe add a few degrees for localized heating or HVAC tolerance, etc. Qin would be the total heat rejection you need (sum of all components cooled).

pertinent conversion rates
1 W = 3.41 BTU
1 BTU = 1°F change in 1 lb water
1 gal water = 8.3 lbs

Tb = -[(Qin/m1) - Tmax]
Tmax = [(m2*Tb)-(m2*Tmin)+(m1*Tb)] / m1
-- could probably merge those two equations and reduce that down a bit more if you wanted to.
Note this only really works if we hold Qout = Qin -- in real life Tmax may hit a constraint or your radiator loop may not be able to keep up and you see Tblend creep up until you can finally get a delta T across the radiator that it can reject with ambient air

It's been a while since I took thermodynamics in college.

I'll have to spend more time re-reading this portion of the post when I don't have to rush to a meeting.

Thermal transfer winds up being rather simple qualitatively, but once you start calculating these things it gets a little complicated.

In theory I know I'll take all the flow rate I can get (at least without inducing the negative side effects above) but putting numbers on it becomes a little more complex. Might even have to structure it as a differential equation.

Though I'm not sure it even makes sense when I can just hook it up and test it

But for now the pan is to move the game GPU and game CPU to different reservoirs/mixing chambers to prevent the case where the radiators are rendered less effective by the coolant dropping too low in temperature before exiting.

 

[Brian_B]

If the flow rate is too slow, at some point, lets say 75% through the two radiators, the coolant temperature will start approaching the ambient air temperature. At that point, the remaining 25% of the radiators will be almost completely ineffective at cooling.

True, but you hit ambient, so... you didn't need the additional cooling, right? And if your Qin =/= Qout, then your inlet temp starts to creep up, and your gradient across those radiator fins will spread back out, as some differential function of inlet temp and radiator efficiency.. until you hit that magic condition where your radiator is at capacity and that 25% overcapacity has shrunk to zero and your outlet temps start to creep up too.

Flow rate is a variable in that equation, for sure.. but just because you hit (what I will call) saturation condition of the radiator doesn't intrinsically mean you need to up the flow rate to make the radiator more effective -- it could very well be you have enough capacity as it is, and that additional 25% is contingency. That's what I'm trying to state. Although I think the idea of "Hook it up and test it" is probably the best bet here.

I just push back against the thought that you ~need~ to be using 100% of the radiator for reason of wanting to utilize the radiator you purchased. You may very well need it for additional heat rejection capacity, but that's a different rational all together. Although maybe it's a distinction without a difference. More flow is (almost) always better, but this thing is already so overkill I struggle to just thing you ~need~ more flow or more cooling for any practical reason. But hey, it's impressive to see, and your build! I do enjoy watching it come together.

 

[Zarathustra]

True, but you hit ambient, so... you didn't need the additional cooling, right?

In a traditional loop that exits the radiator and goes straight into the block, that would be accurate*, but since I have decoupled the hot sides and the cold sides of my loop, they can operate at different flow rates, so ambient at too low in the "mixing chamber" can be a lot worse than above ambient at higher flow, depending on the mixing ratios, flows and temperatures of the other loop parts.

(*Sortof, as you still could wind up in a situation where the flow is suboptimal for the block)

I just push back against the thought that you ~need~ to be using 100% of the radiator for reason of wanting to utilize the radiator you purchased. You may very well need it for additional heat rejection capacity, but that's a different rational all together. Although maybe it's a distinction without a difference. More flow is (almost) always better, but this thing is already so overkill I struggle to just thing you ~need~ more flow or more cooling for any practical reason. But hey, it's impressive to see, and your build! I do enjoy watching it come together.

You are probably right. But i still would like to make the most of it, have as much as possible of my overkill radiator capacity actually show up in lower core temps under load, instead of being wasted along the way due to flow restriction

 

[Brian_B]

In a traditional loop that exits the radiator and goes straight into the block, that would be accurate*, but since I have decoupled the hot sides and the cold sides of my loop, they can operate at different flow rates, so ambient at too low in the "mixing chamber" can be a lot worse than above ambient at higher flow, depending on the mixing ratios, flows and temperatures of the other loop parts.

(*Sortof, as you still could wind up in a situation where the flow is suboptimal for the block)

Nah, it still applies like a single loop - just takes longer because you have that mixing effect -- Tblend as I call it in the equations.

 

[Zarathustra]

Nah, it still applies like a single loop - just takes longer because you have that mixing effect -- Tblend as I call it in the equations.

Well, what I am talking about is related to mixing ratios.

If we had the coolant coming in from the radiator at 0.8GPM at ambient (lets make it easy and say 20C) and the coolant coming in warmed up from the blocks lets say at the same flow rate at lets say 26C, this would be a 50:50 mixing ratio, and we'd expect temperatures to be at about 23C.

But now, lets tackle the real situation of two block loops that are essentially just a D5 a few bends, a couple of QDC's and and a block each. Flow is probably going to be higher. Maybe even 1.3GPM each. The temperature increase across the blocks will likely be small at that speed, but since we are dealing with a 600W GPU, lets assume it rises by 2 degrees, and comes out the other side at 22.

If coolant is entering the mixing chamber at ambient (20C) at 0.8GPM and mixing with 22C coolant coming in at a total of 2.6GPM, that is 3.25 times faster. I'd expect the mixed temperature to be ~21.5C, and increase of 1.5C in just a single cycle. (and the water will continue circulating and increasing up until breakeven)

If instead I had a higher flow rate through the radiators (lets make it easy and double it) of 1.6GMP, and a higher temperature of 20.5C, then the mixed temperature (weighted average) in the reservoir after one cycle would be 21.4, instead of 21.5...

These are all theoretical numbers, but the issue is that ambient becomes the temperature floor, and if your capacity is so great that it brings things down to ambient, then you lose cooling capacity as you get temps down to ambient too fast.

I'm looking forward to seeing what the actual temps I get wind up being.

 

[Brian_B]

These are all theoretical numbers, but the issue is that ambient becomes the temperature floor, and if your capacity is so great that it brings things down to ambient, then you lose cooling capacity as you get temps down to ambient too fast.

I still get hung up on this right here and can't see how it's an issue. But anyway, fun to theorize. Looking forward to seeing what it does once you flip the switch on.

 

[Zarathustra]

I still get hung up on this right here and can't see how it's an issue. But anyway, fun to theorize. Looking forward to seeing what it does once you flip the switch on.

You have to separate heat flow from coolant flow and temperature.

Think of it this way.

Imagine pushing a theoretical very low flow rate through the radiators top the point where the dwell time of any given slice of coolant in the radiators is so long that it is guaranteed to be exposed to the radiator for 10x longer than is necessary to bring it down to ambient.

Then we start gradually increasing flow rate.

As flow rate continues to slowly increase, the temperature of the exiting coolant will remain the same, at ambient.

But while the temperature remains the same, we are moving more and more coolant per unit time, and as such we are moving way more heat.

The more flow we have, the more volume of coolant at ambient we have, so our mixing ratio in the reservoir gets more and more favorable, and thus the temperature in the mixing chamber/reservoir gets lower and lower.

Then at one point, we have increased the flow rate enough that water temperature starts being measured above ambient at the radiator exit. We now know that we have sufficient flow to utilize ALL of the radiator. But despite the fact that our radiator exit temperature is now rising, we can still continue to crank up the flow rate, and still see an improvement in the mixing chamber / reservoir, because the exit temperature will rise very slowly, but the flow will rise much faster, so the flow results in an even higher cool to hot coolant ratio in the mixing chamber, and the mixing chamber still is lower than it was before.

This is because per the heat transfer fomula the lower the delta T to the ambient air is in the radiator, the faster and more efficiently it is able to remove heat.

So if we ignore friction and pump heat entering the loop, the faster we pump that coolant through the radiator, the higher the average temperature it maintains throughout the radiator, and thus the faster the heat can be removed from the coolant. It may exit the radiator warmer and warmer, but - again - ignoring pump and friction heat - the mixing ratio in the reservoir when compared to the hot coolant coming back from the blocks will become more and more favorable at a faster pace than the temperature exiting the radiator goes up, and the whole system becomes more efficient at removing heat.

Essentially, ambient temperature at a ridiculously low flow rate is useless, because there is not enough of it.

Ambient temperature at a high flow rate is best case.

But warmer coolant temperatures at higher flow rates are going to be better than low flow rate at ambient.

 

[Brian_B]

You have to separate heat flow from coolant flow and temperature.

What you say is true, and I don't dispute the effect more flow will have on the radiator. I entirely agree.

But let's hold the flow rates you have constant (because in reality it will be constant, you aren't varying the flow rate in response to anything once you have it in service) and consider that case:

As it runs, in those slices of time - one of three things will happen:

If you are removing enough heat/energy with the radiator as-is, it won't matter a bit that this radiator waste capacity is occurring or not. The temp in your reservoir will stay at this temp and things will proceed forward as you say in a static manner - even though the radiator isn't being utilized 100%. What is going in equals what is going out - you have achieved that static state condition.

If you aren't removing enough heat/energy... then the temp in the reservoir is going to rise. This is important. you can't ignore the fact that the reservoir temp will start to creep up. And once that temp starts going up, ocer the next slices in time, the inlet temp to the radiators goes up, and the delta T between that and ambient goes up, so they become more effective ~and~ that gradient across the radiator you talk about starts to shift out.

Conversely, if you are removing ~more~ energy/heat than putting into the system, your reservoir temp will start to drop... all the way until you get back to that radiator condition you are trying to avoid for some reason, with that ambient air temp as a floor constraint for everything. Even though the flow rates may be mismatched, in this condition, the return temp from the radiators will be sufficiently low enough that it will result in a lowering temp, because it all goes back to the fact that the steady state condition is going to be proportional to mass flow ~and~ temperature.

It's why I'm really just considering the static Quiescent condition - that's going to be worst case anyway, when it all hits equilibrium steady state. And it will hit steady state at some point... well, if you it doesn't get so hot that the hardware crashes first anyway (which sets the ceiling constraint for how high you can let temps ultimately get). You can evaluate the dynamic conditions with differential equations, but they aren't your constraints, so not really much point to it other than it's interesting to see the heating and cooling curves.

Your radiator discussion is entirely true, in a single slice of time. But you really do need to look at energy flow over time and drive/allow enough time for the situation to a get to a quiescent condition to see how it's really performing. I mean, this is why we stress test computers isn't it - to see if the thermal management holds once you get to that steady state condition under worst case power draw, or if it craps out after getting saturated or heat soaked over time?

 

[Peter_Brosdahl]

Alright, Z, here's a go big but from a different era. Don't want to derail your thread, but imagine doing something like this:

View this content on Instagram

View this content on Instagram

 

[Zarathustra]

Alright, Z, here's a go big but from a different era. Don't want to derail your thread, but imagine doing something like this:

Sorry, Can't see it

Between my pihole, my VPN and LIbrefox, I have never been able to see anything on Instagram or TikTok, and for the last year or so, reddit is now off limits as well.

I guess I'll just do without them. No content is worth being tracked.

 

[Zarathustra]

What you say is true, and I don't dispute the effect more flow will have on the radiator. I entirely agree.

But let's hold the flow rates you have constant (because in reality it will be constant, you aren't varying the flow rate in response to anything once you have it in service) and consider that case:

As it runs, in those slices of time - one of three things will happen:

If you are removing enough heat/energy with the radiator as-is, it won't matter a bit that this radiator waste capacity is occurring or not. The temp in your reservoir will stay at this temp and things will proceed forward as you say in a static manner - even though the radiator isn't being utilized 100%. What is going in equals what is going out - you have achieved that static state condition.

If you aren't removing enough heat/energy... then the temp in the reservoir is going to rise. This is important. you can't ignore the fact that the reservoir temp will start to creep up. And once that temp starts going up, ocer the next slices in time, the inlet temp to the radiators goes up, and the delta T between that and ambient goes up, so they become more effective ~and~ that gradient across the radiator you talk about starts to shift out.

Conversely, if you are removing ~more~ energy/heat than putting into the system, your reservoir temp will start to drop... all the way until you get back to that radiator condition you are trying to avoid for some reason, with that ambient air temp as a floor constraint for everything. Even though the flow rates may be mismatched, in this condition, the return temp from the radiators will be sufficiently low enough that it will result in a lowering temp, because it all goes back to the fact that the steady state condition is going to be proportional to mass flow ~and~ temperature.

It's why I'm really just considering the static Quiescent condition - that's going to be worst case anyway, when it all hits equilibrium steady state. And it will hit steady state at some point... well, if you it doesn't get so hot that the hardware crashes first anyway (which sets the ceiling constraint for how high you can let temps ultimately get). You can evaluate the dynamic conditions with differential equations, but they aren't your constraints, so not really much point to it other than it's interesting to see the heating and cooling curves.

Your radiator discussion is entirely true, in a single slice of time. But you really do need to look at energy flow over time and drive/allow enough time for the situation to a get to a quiescent condition to see how it's really performing. I mean, this is why we stress test computers isn't it - to see if the thermal management holds once you get to that steady state condition under worst case power draw, or if it craps out after getting saturated or heat soaked over time?

I guess the point is, I have invested heavily in radiator capacity. I want to be radiator capacity limited, not flow limited.

If the temps in the loop start climbing, not because there is insufficient radiator capacity, but because there is insufficient flow to fully take advantage of the radiators, I would consider that to be a fail.

 

[Zarathustra]

...and I apologize for the silence, there will be some updates in the not too distant future.

This is a busy time of year between work end of year deadlines and holiday family obligations....