Simulating Peak Ice

This year ice in the tank was finally melted between March 5 to March 10 – as ‘visual inspection’ showed. Level sensor Mr. Bubble was confused during the melting phase; thus it was an interesting exercise to compare simulations to measurements.

Simulations use the measured ambient temperature and solar radiation as an input, data points are taken every minute. Air temperature determines the heating energy needed by the house: Simulated heat load is increasing linearly until a maximum ‘cut off’ temperature.

The control logic of the real controller (UVR1611 / UVR16x2) is mirrored in the simulation: The controller’s heating curve determines the set temperature for the heating water, and it switches the virtual 3-way valves: Diverting heating water either to the hygienic storage or the buffer tank for space heating, and including the collector in the brine circuit if air temperature is high enough compared to brine temperature. In the brine circuit, three heat exchangers are connected in series: Three temperatures at different points are determined self-consistently from three equations that use underground tank temperature, air temperature, and the heat pump evaporator’s power as input parameters.

The hydraulic schematic for reference, as displayed in the controller’s visualization (See this article for details on operations.)

The Coefficient of Performance of the heat pump, its heating power, and its electrical input power are determined by heating water temperature and brine temperature – from polynomial fit curves to vendors’ data sheet.

So for every minute, the temperatures of tanks – hot and cold – and the volume of ice can be calculated from energy balances. The heating circuits and tap water consume energy, the heat pump delivers energy. The heat exchanger in the tank releases energy or harvests energy, and the collector exchanges energy with the environment. The heat flow between tank and ground is calculated by numerically solving the Heat Equation, using the nearly constant temperature in about 10 meters depth as a boundary condition.

For validating the simulation and for fine-tuning input parameters – like the thermal properties of ground or the building – I cross-check calculated versus measured daily / monthly energies and average temperatures.

Measurements for this winter show the artificial oscillations during the melting phase because Mr. Bubble faces the cliff of ice:

Simulations show growing of ice and the evolution of the tank temperature in agreement with measurements. The melting of ice is in line with observations. The ‘plateau’ shows the oscillations that Mr. Bubble notices, but the true amplitude is smaller:

2016-09 - 2017-03: Temperatures and ice formation - simulations.

Simulated peak ice is about 0,7m3 greater than the measured value. This can be explained by my neglecting temperature gradients within water or ice in the tank:

When there is only a bit of ice yet (small peak in December), tank temperature is underestimated: In reality, the density anomaly of water causes a zone of 4°C at the bottom, below the ice.

When the ice block is more massive (end of January), I overestimate brine temperature as ice has less than 0°C, at least intermittently when the heat pump is turned on. Thus the temperature difference between ambient air and brine is underestimated, and so is the simulated energy harvested from the collector – and more energy needs to be provided by freezing water.

However, a difference in volume of less than 10% is uncritical for system’s sizing, especially if you err on the size of caution. Temperature gradients in ice and convection in water should be less critical if heat exchanger tubes traverse the volume of tank evenly – our prime design principle.

I have got questions about the efficiency of immersed heat exchangers in the tank – will heat transfer deteriorate if the layer of ice becomes too thick? No, according also to this very detailed research report on simulations of ‘ice storage heat pump systems’ (p.5). We grow so-called ‘ice on coil’ which is compared to flat-plate heat exchangers:

… for the coil, the total heat transfer (UA), accounting for the growing ice surface, shows only a small decrease with growing ice thickness. The heat transfer resistance of the growing ice layer is partially compensated by the increased heat transfer area around the coil. In the case of the flat plate, on the contrary, also the UA-value decreases rapidly with growing ice thickness.

__________________________________

For system’s configuration data see the last chapter of this documentation.

Mr. Bubble Was Confused. A Cliffhanger.

This year we experienced a record-breaking January in Austria – the coldest since 30 years. Our heat pump system produced 14m3 of ice in the underground tank.

The volume of ice is measured by Mr. Bubble, the winner of The Ultimate Level Sensor Casting Show run by the Chief Engineer last year:

The classic, analog level sensor was very robust and simple, but required continuous human intervention:

Level sensor: The old way

So a multitude of prototypes had been evaluated …

Level sensors: The precursors

The challenge was to measure small changes in level as 1 mm corresponds to about 0,15 m3 of ice.

Mr. Bubble uses a flow of bubbling air in a tube; the measured pressure increases linearly with the distance of the liquid level from the nozzle:

blubber-messrohr-3

Mr. Bubble is fine and sane, as long as ice is growing monotonously: Ice grows from the heat exchanger tubes into the water, and the heat exchanger does not float due to buoyancy, as it is attached to the supporting construction. The design makes sure that not-yet-frozen water can always ‘escape’ to higher levels to make room for growing ice. Finally Mr. Bubble lives inside a hollow cylinder of water inside a block of ice. As long as all the ice is covered by water, Mr. Bubble’s calculation is correct.

But when ambient temperature rises and the collector harvests more energy then needed by the heat pump, melting starts at the heat exchanger tubes. The density of ice is smaller than that of water, so the water level in Mr. Bubble’s hollow cylinder is below the surface level of ice:

Mr. Bubble is utterly confused and literally driven over the edge – having to deal with this cliff of ice:

When ice is melted, the surface level inside the hollow cylinder drops quickly as the diameter of the cylinder is much smaller than the width of the tank. So the alleged volume of ice perceived by Mr. Bubble seems to drop extremely fast and out of proportion: 1m3 of ice is equivalent to 93kWh of energy – the energy our heat pump would need on an extremely cold day. On an ice melting day, the heat pump needs much less, so a drop of more than 1m3 per day is an artefact.

As long as there are ice castles on the surface, Mr. Bubble keeps underestimating the volume of ice. When it gets colder, ice grows again, and its growth is then overestimated via the same effect. Mr. Bubble amplifies the oscillations in growing and shrinking of ice.

In the final stages of melting a slab-with-a-hole-like structure ‘mounted’ above the water surface remains. The actual level of water is lower than it was before the ice period. This is reflected in the raw data – the distance measured. The volume of ice output is calibrated not to show negative values, but the underlying measurement data do:

Only when finally all ice has been melted – slowly and via thermal contact with air – then the water level is back to normal.

In the final stages of melting parts of the suspended slab of ice may break off and then floating small icebergs can confuse Mr. Bubble, too:

So how can we picture the true evolution of ice during melting? I am simulating the volume of ice, based on our measurements of air temperature. To be detailed in a future post – this is my cliffhanger!

>> Next episode.

Ice Storage Hierarchy of Needs

Data Kraken – the tentacled tangled pieces of software for data analysis – has a secret theoretical sibling, an older one: Before we built our heat source from a cellar, I developed numerical simulations of the future heat pump system. Today this simulation tool comprises e.g. a model of our control system, real-live weather data, energy balances of all storage tanks, and a solution to the heat equation for the ground surrounding the water/ice tank.

I can model the change of the tank temperature and  ‘peak ice’ in a heating season. But the point of these simulations is rather to find out to which parameters the system’s performance reacts particularly sensitive: In a worst case scenario will the storage tank be large enough?

A seemingly fascinating aspect was how peak ice ‘reacts’ to input parameters: It is quite sensitive to the properties of ground and the solar/air collector. If you made either the ground or the collector just ‘a bit worse’, ice seems to grow out of proportion. Taking a step back I realized that I could have come to that conclusion using simple energy accounting instead of differential equations – once I had long-term data for the average energy harvesting power of the collector and ground. Caveat: The simple calculation only works if these estimates are reliable for a chosen system – and this depends e.g. on hydraulic design, control logic, the shape of the tank, and the heat transfer properties of ground and collector.

For the operations of the combined tank+collector source the critical months are the ice months Dec/Jan/Feb when air temperature does not allow harvesting all energy from air. Before and after that period, the solar/air collector is nearly the only source anyway. As I emphasized on this blog again and again, even during the ice months, the collector is still the main source and delivers most of the ambient energy the heat pump needs (if properly sized) in a typical winter. The rest has to come from energy stored in the ground surrounding the tank or from freezing water.

I am finally succumbing to trends of edutainment and storytelling in science communications – here is an infographic:

Ambient energy needed in Dec/Jan/Fec - approximate contributions of collector, ground, ice

(Add analogies to psychology here.)

Using some typical numbers, I am illustrating 4 scenarios in the figure below, for a  system with these parameters:

  • A cuboid tank of about 23 m3
  • Required ambient energy for the three ice months is ~7000kWh
    (about 9330kWh of heating energy at a performance factor of 4)
  • ‘Standard’ scenario: The collector delivers 75% of the ambient energy, ground delivers about 18%.
  • Worse’ scenarios: Either collector or/and ground energy is reduced by 25% compared to the standard.

Contributions of the three sources add up to the total ambient energy needed – this is yet another way of combining different energies in one balance.

Contributions to ambient energy in ice months - scenarios.

Ambient energy needed by the heat pump in  Dec+Jan+Feb,  as delivered by the three different sources. Latent ‘ice’ energy is also translated to the percentage of water in the tank that would be frozen.

Neither collector nor ground energy change much in relation to the base line. But latent energy has to fill in the gap: As the total collector energy is much higher than the total latent energy content of the tank, an increase in the gap is large in relation to the base ice energy.

If collector and ground would both ‘underdeliver’ by 25% the tank in this scenario would be frozen completely instead of only 23%.

The ice energy is just the peak of the total ambient energy iceberg.

You could call this system an air-geothermal-ice heat pump then!

Earth, Air, Water, and Ice.

In my attempts at Ice Storage Heat Source popularization I have been facing one big challenge: How can you – succinctly, using pictures – answer questions like:

How much energy does the collector harvest?

or

What’s the contribution of ground?

or

Why do you need a collector if the monthly performance factor just drops a bit when you turned it off during the Ice Storage Challenge?

The short answer is that the collector (if properly sized in relation to tank and heat pump) provides for about 75% of the ambient energy needed by the heat pump in an average year. Before the ‘Challenge’ in 2015 performance did not drop because the energy in the tank had been filled up to the brim by the collector before. So the collector is not a nice add-on but an essential part of the heat source. The tank is needed to buffer energy for colder periods; otherwise the system would operate like an air heat pump without any storage.

I am calling Data Kraken for help to give me more diagrams.

There are two kinds of energy balances:

1) From the volume of ice and tank temperature the energy still stored in the tank can be calculated. Our tank ‘contains’ about 2.300 kWh of energy when ‘full’. Stored energy changes …

  • … because energy is extracted from the tank or released to it via the heat exchanger pipes traversing it.
  • … and because heat is exchanged with the surrounding ground through the walls and the floor of the tank.

Thus the contribution of ground can be determined by:

Change of stored energy(Ice, Water) =
Energy over ribbed pipe heat exchanger + Energy exchanged with ground

2) On the other hand, three heat exchangers are serially connected in the brine circuit: The heat pump’s evaporator, the solar air collector, and the heat exchanger in the tank. .

Both of these energy balances are shown in this diagram (The direction of arrows indicates energy > 0):

Energy sources, transfer, storage - sign conventions

The heat pump is using a combined heat source, made up of tank and collector, so …

Ambient Energy for Heat Pump = -(Collector Energy) + Tank Energy

The following diagrams show data for the season containing the Ice Storage Challenge:

Season 2014 - 2015: Monthly Energy Balances: Energy Sources, Transfer, Storage

From September to January more and more ambient energy is needed – but also the contribution of the collector increases! The longer the collector is on in parallel with the heat pump, the more energy can be harvested from air (as the temperature difference between air and brine is increased).

As long as there is no ice the temperature of the tank and the brine inlet temperature follow air temperature approximately. But if air temperature drops quickly (e.g. at the end of November 2014), the tank is still rather warm in relation to air and the collector cannot harvest much. Then the energy stored in the tank drops and energy starts to flow from ground to the tank.

2014-09-01 - 2015-05-15: Temperatures and ice formation

2014-09-01 - 2015-05-15: Daily Energy Balances: Energy Sources, Transfer, Storage

On Jan 10 an anomalous peak in collector energy is visible: Warm winter storm Felix gave us a record harvest exceeding the energy needed by the heat pump! In addition to high ambient temperatures and convection (wind) the tank temperature remained low while energy was used for melting ice.

On February 1, we turned off the collector – and now the stored energy started to decline. Since the collector energy in February is zero, the energy transferred via the heat exchanger is equal to the ambient energy used by the heat pump. Ground provided for about 1/3 of the ambient energy. Near the end of the Ice Storage Challenge (mid of March) the contribution of ground was increasing while the contribution of latent energy became smaller and smaller: Ice hardly grew anymore, allegedly after the ice cube has ‘touched ground’.

Mid of March the collector was turned on again: Again (as during the Felix episode) harvest is high because the tank remains at 0°C. The energy stored in the tank is replenished quickly. Heat transfer with ground is rather small, and thus the heat exchanger energy is about equal to the change in energy stored.

At the beginning of May, we switched to summer mode: The collector is turned off (by the control system) to keep tank temperature at 8°C as long as possible. This temperature is a trade-off between optimizing heat pump performance and keeping some energy for passive cooling. The energy available for cooling is reduced by the slow flow of heat from ground to the tank.

Frozen Herbs and Latent Energy Storage

… having studied one subject, we immediately have a great deal of direct and precise knowledge … of another.

Richard Feynman

Feynman referred to different phenomena that can be described by equations of the same appearance: Learning how to calculate the distribution of electrical charges gives you the skills to simulate also the flow of heat.

But I extend this to even more down-to-earth analogies – such as the design of a carton of frozen herbs resembling our water-tight underground tank.

(This is not a product placement.)

No, just being a container for frozen stuff is too obvious a connection!

Maybe it is the reclosable lid covering part of the top surface?

Lid of underground water/ice storage tank.

No, too obvious again!

Or it is the intriguing ice structures that grow on the surface: in opened frozen herb boxes long forgotten in the refrigerator – or on a gigantic ice cube in your tank:

Ice Storage Challenge of 2015 - freezing 15m3 of water after having turned off the solar/air collector.

The box of herbs only reveals its secret when dismantled carefully. The Chief Engineer minimizes its volume as a dedicated waste separating citizen:

… not just tramping it down (… although that sometimes helps if some sensors do not co-operate).

He removes the flaps glued to the corners:

And there is was, plain plane and simple:

The Chief Engineer had used exactly this folding technique to cover the walls and floor of the former root cellar with a single piece of pond liner – avoiding to cut and glue the plastic sheet.

My Data Kraken – a Shapeshifter

I wonder if Data Kraken is only used by German speakers who translate our hackneyed Datenkrake – is it a word like eigenvector?

Anyway, I need this animal metaphor, despite this post is not about facebook or Google. It’s about my personal Data Kraken – which is a true shapeshifter like all octopuses are:

(… because they are spineless, but I don’t want to over-interpret the metaphor…)

Data Kraken’s shapeability is a blessing, given ongoing challenges:

When the Chief Engineer is fighting with other intimidating life-forms in our habitat, he focuses on survival first and foremost … and sometimes he forgets to inform the Chief Science Officer about fundamental changes to our landscape of sensors. Then Data Kraken has to be trained again to learn how to detect if the heat pump is on or off in a specific timeslot. Use the signal sent from control to the heat pump? Or to the brine pump? Or better use brine flow and temperature difference?

It might seem like a dull and tedious exercise to calculate ‘averages’ and other performance indicators that require only very simple arithmetics. But with the exception of room or ambient temperature most of the ‘averages’ just make sense if some condition is met, like: The heating water inlet temperature should only be calculated when the heating circuit pump is on. But the temperature of the cold water, when the same floor loops are used for cooling in summer, should not be included in this average of ‘heating water temperature’. Above all, false sensor readings, like 0, NULL or any value (like 999) a vendor chooses to indicate as an error, have to be excluded. And sometimes I rediscover eternal truths like the ratio of averages not being equal to the average of ratios.

The Chief Engineer is tinkering with new sensors all the time: In parallel to using the old & robust analog sensor for measuring the water level in the tank…

Level sensor: The old way

… a multitude of level sensors was evaluated …

Level sensors: The precursors

… until finally Mr. Bubble won the casting …

blubber-messrohr-3

… and the surface level is now measured via the pressure increasing linearly with depth. For the Big Data Department this means to add some new fields to the Kraken database, calculate new averages … and to smoothly transition from the volume of ice calculated from ruler readings to the new values.

Change is the only constant in the universe, paraphrasing Heraclitus [*]. Sensors morph in purpose: The heating circuit, formerly known (to the control unit) as the radiator circuit became a new wall heating circuit, and the radiator circuit was virtually reborn as a new circuit.

I am also guilty of adding new tentacles all the time, too, herding a zoo of meters added in 2015, each of them adding a new log file, containing data taken at different points of time in different intervals. This year I let Kraken put tentacles into the heat pump:

Data Kraken: Tentacles in the heat pump!

But the most challenging data source to integrate is the most unassuming source of logging data: The small list of the data that The Chief Engineer had recorded manually until recently (until the advent of Miss Pi CAN Sniffer and Mr Bubble). Reason: He had refused to take data at exactly 00:00:00 every single day, so learned things I never wanted to know about SQL programming languages to deal with the odd time intervals.

To be fair, the Chief Engineer has been dedicated at data recording! He never shunned true challenges, like a legendary white-out in our garden, at the time when measuring ground temperatures was not automated yet:

The challenge

White Out

Long-term readers of this blog know that ‘elkement’ stands for a combination of nerd and luddite, so I try to merge a dinosaur scripting approach with real-world global AI Data Krakens’ wildest dream: I wrote scripts that create scripts that create scripts [[[…]]] that were based on a small proto-Kraken – a nice-to-use documentation database containing the history of sensors and calculations.

The mutated Kraken is able to eat all kinds of log files, including clients’ ones, and above all, it can be cloned easily.

I’ve added all the images and anecdotes to justify why an unpretentious user interface like the following is my true Christmas present to myself – ‘easily clickable’ calculated performance data for days, months, years, and heating seasons.

Data Kraken: UI

… and diagrams that can be changed automatically, by selecting interesting parameters and time frames:

Excel for visualization of measurement data

The major overhaul of Data Kraken turned out to be prescient as a seemingly innocuous firmware upgrade just changed not only log file naming conventions and publication scheduled but also shuffled all the fields in log files. My Data Kraken has to be capable to rebuild the SQL database from scratch, based on a documentation of those ever changing fields and the raw log files.

_________________________________

[*] It was hard to find the true original quote for that, as the internet is cluttered with change management coaches using that quote, and Heraclitus speaks to us only through secondary sources. But anyway, what this philosophy website says about Heraclitus applies very well to my Data Kraken:

The exact interpretation of these doctrines is controversial, as is the inference often drawn from this theory that in the world as Heraclitus conceives it contradictory propositions must be true.

In my world, I also need to deal with intriguing ambiguity!

And Now for Something Completely Different: Rotation Heat Pump!

Heat pumps for space heating are all very similar: Refrigerant evaporates, pressure is increased by a scroll compressor, refrigerant condenses, pressure is reduced in an expansion value. *yawn*

The question is:

Can a compression heat pump be built in a completely different way?

Austrian start-up ECOP did it: They  invented the so-called Rotation Heat Pump.

It does not have a classical compressor, and the ‘refrigerant’ does not undergo a phase transition. A pressure gradient is created by centrifugal forces: The whole system rotates, including the high-pressure (heat sink) and low-pressure (source) heat exchanger. The low pressure part of the system is positioned closer to the center of the rotation axis, and heat sink and heat source are connected at the axis (using heating water). The system rotates at up to 1800 rounds per minute.

A mixture of noble gases is used in a Joule (Brayton) process, driven in a cycle by a ventilator. Gas is compressed and thus heated up; then it is cooled at constant pressure and energy is released to the heat sink. After expanding the gas, it is heated up again at low pressure by the heat source.

In the textbook Joule cycle, a turbine and a compressor share a common axis: The energy released by the turbine is used to drive the compressor. This is essential, as compression and expansion energies are of the same order of magnitude, and both are considerably larger than the net energy difference – the actual input energy.

In contrast to that, a classical compression heat pump uses a refrigerant that is condensed while releasing heat and then evaporated again at low pressure. There is no mini-turbine to reduce the pressure but only an expansion valve, as there is not much energy to gain.

This explains why the Rotation Heat Pumps absolutely have to have compression efficiencies of nearly 100%, compared to, say, 85% efficiency of a scroll compressor in heat pump used for space heating:

Some numbers for a Joule process (from this German ECOP paper): On expansion of the gas 1200kW are gained, but 1300kW are needed for compression – if there would be no losses at all. So the net input power is 100kW. But if the efficiency of the compression is reduced from 100% to 80% about 1600kW are needed and thus a net input power of 500kW – five times the power compared to the ideal compressor! The coefficient of performance would plummet from 10 to 2,3.

I believe these challenging requirements are why Rotation Heat Pumps are ‘large’ and built for industrial processes. In addition to the high COP, this heat pump is also very versatile: Since there are no phase transitions, you can pick your favorite corner of the thermodynamic state diagram at will: This heat pump works for very different combinations temperatures of the hot target and the cold source.