You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First-- I'm hoping this is the right space to put this idea... If there's a better place, I'll be happy to post it elsewhere.
I'll describe the study and the (apparent) problem I had in getting the CSE results I wanted.
I was studying DHW recirculation on a residential project where the DHW heater is far (~100 feet) from the fixtures. This is not uncommon with ADU development where the projects want to run DHW from the Main House below grade to the ADU (there's a significant code compliance element here forcing this kind of approach, but that's background) Typically, these systems incorporate an on-demand recirculation system.
I was studying the energy use of this kind of DHW setup relative to a compact one using a tankless electric unit. So, in short, studying where there's energy parity between Efficient Heater+Long Distribution vs. Inefficient Heater+Compact Distribution.
To the question:
I set up a model with some DHWLoops and DHWLOOPSEGS and BRANCHES. I noted in the results that the DhwMFL meters didn't really change across the hours in which I was studying. I had the recirc pump operating several times a day to correspond (roughly) to the hot water draw profiles, and I was hoping to account for the temperature of the return water to the Heat Pump Water Heater.
I concluded that the conductive losses in the hot water supply/return lines is assumed to be static (the hot water temperature assumed constant), since this is good enough for most multifamily systems as a rough approximation. In my case, I've got a long insulated supply line and uninsulated return line running underground, so I expect the conductive losses to asymptotically approach 0.
Assuming I've got all of this correct, it's probably non-trivial to add this level of analysis, so I include it as a 'feature request'. Not important, just thought I would throw it out there.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
First-- I'm hoping this is the right space to put this idea... If there's a better place, I'll be happy to post it elsewhere.
I'll describe the study and the (apparent) problem I had in getting the CSE results I wanted.
I was studying DHW recirculation on a residential project where the DHW heater is far (~100 feet) from the fixtures. This is not uncommon with ADU development where the projects want to run DHW from the Main House below grade to the ADU (there's a significant code compliance element here forcing this kind of approach, but that's background) Typically, these systems incorporate an on-demand recirculation system.
I was studying the energy use of this kind of DHW setup relative to a compact one using a tankless electric unit. So, in short, studying where there's energy parity between Efficient Heater+Long Distribution vs. Inefficient Heater+Compact Distribution.
To the question:
I set up a model with some DHWLoops and DHWLOOPSEGS and BRANCHES. I noted in the results that the DhwMFL meters didn't really change across the hours in which I was studying. I had the recirc pump operating several times a day to correspond (roughly) to the hot water draw profiles, and I was hoping to account for the temperature of the return water to the Heat Pump Water Heater.
I concluded that the conductive losses in the hot water supply/return lines is assumed to be static (the hot water temperature assumed constant), since this is good enough for most multifamily systems as a rough approximation. In my case, I've got a long insulated supply line and uninsulated return line running underground, so I expect the conductive losses to asymptotically approach 0.
Assuming I've got all of this correct, it's probably non-trivial to add this level of analysis, so I include it as a 'feature request'. Not important, just thought I would throw it out there.
Beta Was this translation helpful? Give feedback.
All reactions