This post expands on what I did in the final section of the last post to show how I arrived at the answers I arrived at.
Before proceeding, I want to emphasize that what I am about to show is one approach out of many possible approaches to the problem. So if you came up with similar answers via a different path, then all that means is that you think differently from me, which could be a good thing.
If your answers are significantly different from mine, it probably means that one of us made a misstep, and the person that did that could be me, so we should talk. As a frame of reference on “different” given all of the assumptions, etc. I suspect my projections are +/-10-20%. So if you are in that window, we probably agree.
These links will take you to specific locations in the content if you want to jump around. At the end of each main heading, there will be a “Back to Contents” link to bring you back here.
- Step 1 – Associated an Outdoor Air Temperature with Each Boiler Flue Temperature Data Point
- Step 2 – Detect the Changes in Temperature that Correlate with the Various Steps in the Boiler Cycle
- Step 3 – Determine the Cycle Length for Each Logged Cycle and the Number of Cycles per Hour
- Step 4 – Develop a Relationship Between Outdoor Air Temperature and Boiler Cycles
- Step 5 – Determine the Combustion Air Flow Rate
- Step 6 – Determine the Purge Air Flow Rate for Each Portion of the Purge Cycle
- Step 7 – Determine the Total Purge Losses for a Year Given the Current Operating Pattern
- Selecting a Weather Data Source
- Bin Data vs. Hourly Data
- Doing the Math
- Turning the TMY Date and Time into an Excel Date and Time Value
- Calculating the Boiler Cycles per Hour Based on the Outdoor Temperature
- Calculating the Energy Loss for Each Purge Cycle
- Assigning Hourly Purge Losses to Each Boiler
- Step 8 – Determine the Savings Associated with Reducing the Number of Purge Cycles
Step 1 – Associated an Outdoor Air Temperature with Each Boiler Flue Temperature Data Point
For my analysis, I decided to correlate the logged data from the flue gas logger with data from a different logger that we had deployed in the outdoor air intake of the corridor make up air handling system. The thought was that since the air handling system was a 100% outdoor air system, the data from the outdoor air intake would be a reasonable representation of the outdoor conditions during the time that boiler flue gas temperatures were being logged.
As was discussed in the previous post and the post on Aliasing, I used a fairly fast logging rate for the the flue gas temperature to make sure I picked up the nuances of the cycle. But I needed to coordinate that with weather data, specifically outdoor air temperature data, which had a much slower sampling rate.
I accomplished this using the VLOOKUP function in Excel as is illustrated below. Note that I have clicked into the formula bar prior to making the screen shot so that the various variables are highlighted in color in the formula and the cells they are associated with are highlighted in the same color in the spreadsheet.
Specifically, the formula in the orange column in cell D908 …
… goes to a table that is on the next tab (the Cor-MAU-1_0_0 tab) and scans vertically (that’s the “V” part of VLOOKUP) down the first column of data in the cell range that starts with B4 and ends with F10388. It scans down the 1st column (column B) until it finds the closest match to the value in cell B908 in the table on the W._Boiler_Flue_Temp tab. Once it finds the closest match, it returns the value that is in column 2 of that row.
Here is a screen shot of a portion of the Cor-MAU-1_0_0 tab that contains the beginning of the range. As you can see, it is simply the output from a data logger that was monitoring a number of parameters in a 100% outdoor air system serving the facility.
Note that the first column in the range specified in VLOOKUP is column with dates and times and that the second column is the column with the data we are looking for.
The dollar signs ahead of the reference to the range that the table lies in is to make the reference an absolute reference, something I will discuss in a bit more detail in Step 2 since it comes up again there. My point in this section is to illustrate how I picked up data from a logger that had a much slower logging rate and correlated it with data in a logger that was measuring something else during the same time period at a much faster sampling rate.
Incidentally, if you want to see a live demonstration of how to use VLOOKUP, I have one in the video clip that is part of the blog post titled Using Scatter Plots to Assess Building Performance–Part 3.
Step 2 – Detect the Changes in Temperature that Correlate with the Various Steps in the Boiler Cycle
In the previous post, we discussed how it would be possible to use Excel techniques to create “flags” that detected the changes in the data pattern from our flue gas logger that were indications of different parts of the firing cycle. Here is a reproduction of the pattern that can be observed in the logged data for your reference.
A Simplifying Observation
One thing that makes this analysis a bit simpler than it might otherwise be is that each cycle consists of a number of steps that are predictable in terms of when they happen and how long they last because they are programmed into the firing controller. Specifically, we know that each cycle will include:
- A purge ramp up that lasts 30 seconds.
- A full combustion air flow purge that lasts 60 seconds.
- A purge ramp down that lasts 30 seconds.
- A pilot ignition cycle that lasts 10 seconds.
- A main flame ignition cycle that lasts 15 seconds.
- A post-purge with combustion air only that lasts 14 seconds.
The only variable portions of the cycle are the time the burner fires and the time that the boiler stands by with out doing anything. That means that if we pick up an indicator for the variable events, we can figure out where the other events in the sequence need to fall relative to those points in time.
In other words, if I can pick up an indication of when combustion starts, I know that events 1 – 5 on the list above have occurred in sequence immediately ahead of that point in time. And if I can pick up when combustion ends, I know that event 6 on the list above will happen immediately after that.
Finally, if I know when combustion starts for two sequential cycles, then I know the length of one complete cycle of operation. If I subtract the accumulated time for all of the programmed events from the complete cycle time and also subtract the time that combustion is actually occurring from the complete cycle time, I am left with the standby time; i.e. the time that the boiler sits idle between burner events.
Developing the Flags
If you study the diagram above, you will notice that the start and stop of combustion are the two largest temperature change events. Intuitively, that would seem to make them easy to detect by simply looking at the rate at which temperature is changing, which is what I did initially to create my flags.
But what I discovered was that the various spikes in the data also had some pretty rapid changes in temperature, they just did not last that long. So my first stab at making flags based on the current temperature relative to the temperature for the past 10-20 seconds did not reliably pick out only the beginning and ending of the combustion process. Rather it would pick up some (but not all) of the other sudden temperature changes in addition to the ones I was looking for, meaning it gave me false starts and false stops.
Ultimately, I realized that what I was really trying to detect was a sudden change in the slope of the line represented by the data set; i.e the change in temperature relative to the change in time. For instance, when the pilot is ignited, there is a sudden change in the slope of the line from a gradual downward incline to a sharp upward incline.
The same is true for the end of the combustion cycle but the slope then shifts from a gradual upward incline to a sharp downward incline.
Calculating the Slope of the Flue Gas Temperature Line
Here is a screen shot of the spreadsheet tab that I used to create my cycle counter with the formula that I used to calculate the slope of the flue temperature line highlighted so you can see how it works.
The formula, which is in cell E26 of the green column, first calculates change in average temperature (the yellow column) relative to time (the red column). Specifically, it averages the temperature and time for the 30 seconds prior to the time associated with the row that the calculation is in (the cells outlined in purple and blue) and subtracts that from the average temperature and time for the 30 seconds that follow (the cells outlined in red and green)
This is the average change in temperature for a minute centered around the time associated with the calculation. Since the formula uses relative references, when I paste the formula down the column in the spreadsheet, it creates a sliding window that is always looking 30 seconds behind and ahead of the time associated with the current row.
Compare the screen shot above, with this one, and I think you will see what I mean; the formula is in a cell that is one row further down the spreadsheet and so are all of the cells that it references compared to the formula in the cell above it.
Excel and Dates and Times
You may be wondering why the denominator of my little equation includes multiplying the difference in average date and time by 24 and 60. The reason is that I wanted to calculate slope with the units of °F per minute, not °F per day.
As humans, we think of a date and time as a string of different parameters mixed with special symbols. And the order in which they are presented is part of conveying information in addition to the value of the numbers. For instance, as I type this, it is the 25th minute of the 14th hour of the 22nd day of the 3rd month of the 2,016 year since Christ died A very common way of noting this would be to type:
Currently, it is 2:25 pm on March 22, 2016
03 March 2016, 2:25 PM
So a lot of different ways to say the same thing with a lot of interpretation required understand what is being said.
Computers like things to be a bit more straight-forward than that, so Excel does not think of it that way. Rather, Excel thinks of it as being 42,451.600926 days since January 1, 1900. Tomorrow at this time, it will be 42,452.600926 days since January 1, 1900; in other words the number is incremented by 1 each day.
This makes it very easy for Excel to do the kind of math I wanted to do in my calculation. But our human minds would have trouble recognizing 42,452.600926 as representing March 23, 2016 at 2:25 PM. So Excel provides formatting features that let us see the numbers in a manner we can quickly comprehend while allowing Excel to work with the dates as a number.
So bottom line, to get units of °F per minute, I had to multiply the number in the denominator by the number of hours and minutes in a day. I have done a couple of blog posts that include discussions of Excel date and time values so you may want to take a look at them if you are still curious about it. The most recent one includes a little spreadsheet tool that helps you come convert dates and times to the values Excel uses to format the time axis in a graph.
Detecting the Burner Being Turned Off
The next step in the process was to write a formula that would somehow flag that their had been a sudden change in the slope of the flue gas temperature line because that was my clue that the burner was firing or had stopped firing.
The two events I was trying to capture (the start and end of combustion) could be further delineated by the fact that the only event that had a steep upward slope lasting more than 3 seconds when flue temperatures were above about 250°F was the start of combustion.
Similarly, the only event that had a steep downward slope above 500°F was the end of combustion. So I decided to include these items as filters for detecting those events.
Here is a screen shot of the formula I used to detect the burner shutting down.
The formula, which is in the blue column, compares the boiler flue temperature in the yellow column with the 500°F threshold I selected as my “cycle ends” indicator (cell C6, with the orange boarder) and if the current temperature is higher than that but falling off at a rate of 200-300°F per minute (cells D10 and D11, outlined in purple and green), then it places a “1” in the cell. Otherwise it puts a “0” in the cell.
As a result, I now have a column in my spreadsheet where the number will change from 0 to one if the flue gas temperature is above 500°F but falling off at a rate of 200-300°F per minute.
Note that I could have simply entered the 500°F, 200°F and 300°F metrics directly into my formula like this:
But by using cell references, like this …
… I set the formula up so I could play with the variables to fine tune it, which was a handy feature in terms of getting it set up to only trigger on the desired event.
A Word About the Dollar Signs
If you look closely at the cell reference in the formula in the previous screen shot, you will notice that some of them have dollar signs ($) ahead of the letter and number associated with the cell and others don’t. The dollar signs tell Excel to look for the information in a very specific row and a very specific column; the ones indicated by the letter and number after the dollar sign. Because the reference is specific, it is termed an “absolute” reference.
In contrast, if there are no dollar signs, then Excel looks for the information in a cell relative to the cell containing the formula. This is called a “relative” reference.
Applying this to the formula in the screenshot above, the dollar signs are telling Excel:
- No matter what cell the formula is in, it should go to cells C6 for the temperature that will be the trigger for detecting the end of a firing cycle, and
- No matter what cell the formula is in, it should to go to cells D11 and D10 for the slope values that should be used as a part of the detection process.
This is accomplished by referring to the cells as $C$6, $D$11, and $D$10.
In contrast, the formula is saying to look for the flue gas temperature in column C of the same row as the formula (C90 in the example) and to look in column E of the same row as the formula for the slope information (E90 in the example). This is accomplished by not putting dollar sign into the cell reference.
Note that you can have an absolute reference to just the row or just the column in addition to locking down on a specific cell by making an absolute reference to both. A short cut for setting this up when you are typing a formula in Excel is to press the “F4” key while the cell reference is highlighted in the formula window.
The first press puts dollar sings on both the row and column reference. Each subsequent press toggles you through a different option until after 4 presses, you are back to where you started from.
Detecting the Burner Starting
By applying a similar filter but looking for a positive (rising) sudden change in the slope of the flue temperature line and looking for that condition only if the flue temperature was above 250°F, I was able to detect burner start events as illustrated in the formula that is highlighted in the purple column in this screen shot.
You may be wondering why this detector doesn’t also flag the little spike in temperature that happens right after the burner shuts down during the post firing purge cycle. After all, it is a sudden, positive change in slope at a flue gas temperature that is above 250°F, right?
The reason is that it does not last long enough.
In other words, the sliding window that averages the slope for the 30 seconds before and after the point in time that the slope calculation is being done for flattens out the short duration spike. In contrast, a spike that persists will eventually show up as a large change in slope.
In this case, the slope at the beginning of combustion quickly jumps above the 100 °F per minute trigger that I have set and stays there. As a result, I reach a point where the average slope also stays above the trigger value.
In contrast, the spike at the end of the cycle during the post purge is not steep enough nor does it last long enough for the average value to hit the triggering threshold.
Applying a Bit More Filtering
If you look closely at the following screen shot …
…you will notice that while the Main Flame On Detection formula successfully triggers when the burner cycles on, there are actually six data points that met the criteria, (in Rows 285 – 289). This is because the data is noisy; sometimes there would only be 1-2 events that would trigger the flag, other times, 3-4, etc.
I was able to tune the slope and temperature trigger values to minimize the problem, but I never could get it fine tuned so that I only had one triggering event per cycle, which is what I really was looking for. To solve that problem, I added a formula that looked for the first transition from “0” to “1’ as the indicator that the event had happened. For the burner start event, when the formula detected that condition, it would return the words “Combustion Starts). Otherwise, it would put a “0” in the cell. This is illustrated in the screenshot below in the highlighted formula in the gray column.
A similar formula in the white column selects the first burner off event as indicating “Combustion Ends”.
Finally, I added a column that would pick up the “Combustion Starts” and “Combustion Ends” markers and combine them into the same column as illustrated in the formula highlighted in the second red column below.
I could then filter the data for only “Combustion Starts” an “Combustion Ends” events …
… which set me up for my next step.
Step 3 – Determine the Cycle Length for Each Logged Cycle and the Number of Cycles per Hour
To start this step, I took the filtered data shown in the screen shot above and pasted it as values into a new tab in the spreadsheet. I did this because I only wanted the rows associated with a combustion start and end event so I could do math on those events with a regular, repeated pattern that would allow me to copy and paste a formula down the entire spreadsheet. I wanted to get rid of all of the other rows which were hidden but still present when I applied the filter and pasting the data as values did that for me.
This screen shot shows how to paste as values …
So bottom line, but pasting my filtered data as values into a new tab, the process left me with a copy of the data from the previous sheet but only the rows with a combustion start or a combustion end event. After a bit of formatting, my result looked like this.
Notice how the sequentially numbered rows alternate events in a regular pattern, which is what I wanted to allow me to do the next step in my process.
Before moving on, I did a quick scan of column I to make sure that it really represented alternating events. That actually sounds harder than it is. Your eye (or at least my eye) is pretty fast to detect a break in the regular patterns that exist in columns E, F, G, H, and I. So, when I scanned down the columns quickly, right towards the end of the file, I noticed an anomaly.
Notice how there are two “Combustion Start” events detected with out a “Combustion Ends” event between them. A quick check of the original unfiltered data revealed that there was a little “blip” in the flue temperatures and the rate of change that toggled my trigger calculation an extra time for one of the starts.
Notice how the Main Flame On Detection value cycles from two occurrences “1” to five occurrences of “0” then back to 6 occurrences of “1”. There was no off event in between but the toggling of the flag created an extra “Combustion Start” event that was not real.
I could have played with the filters a bit more to get rid of the anomaly, but since there was only one and I had found it, I simply deleted the line before moving on.
My next step was to determine the length of each firing cycle by subtracting the time for a “combustion starts” event from the time for the subsequent “combustion ends” event as illustrated below in the highlighted formula in the 2nd yellow column
A similar formula in the second green column calculates the total cycle time by subtracting the combustion starts time for the current cell from the next combustion start time.
By definition, this includes all of the elements of a full firing cycle including all of the purge and ignition steps as well as the standby time.
My next step was to convert the cycle duration to hours, which basically meant taking the number in the green column and multiplying it by 24 (the highlighted formula in the 2nd blue column) …
… and formatting it as a number …
.. instead of hours, minutes and seconds.
Next, I converted the duration of the cycle into cycles per hour (basically the reciprocal value; the highlighted formula in the second purple column) …
Finally, I correlated the cycles per hour with the average outdoor air temperature for the cycle (the highlighted formula in the second gray column) …
… and the average time that the cycle occurred (the highlighted formula in the second white column).
That set me up for my next step.
Step 4 – Develop a Relationship Between Outdoor Air Temperature and Boiler Cycles
At this point, I was able to set up a relationship between the outdoor air temperature and the number of boiler cycles per hour and develop a mathematical relationship that expressed it. I explained how I did that in the previous post so I won’t repeat myself and will just reproduce the chart here.
I created the chart by filtering the data we have been discussing to eliminate the blanks …
… which gave me this.
I was then able to copy and paste the values in columns M, N, and O into a new tab and develop the chart that I showed at the beginning of this section.
Step 5 – Determine the Combustion Air Flow Rate
As I mentioned in the previous post, the number I was really after was how much energy does a purge cycle cost? The idea was to use the sensible heat equation, which I have reproduced below, to figure that out.
To apply the equation, we can figure out the temperature rise by using hourly outdoor air temperature data and our logger data as was discussed under Step 1. The missing piece of information at this point is the flow rate.
In the previous post, I mentioned that …
The combustion air fan needs to provide the air flow required for complete combustion during high fire. So there is a clue.
… and …
there is a clue in the information we looked at previously
So, lets take a look at what those clues are and how we can use them.
The reason that the first quote is a clue is because it is possible to use principles from chemistry to define how much air is required for complete combustion of a given fuel. It is a branch of chemistry called “Stoichiometry” which comes from a Greek word meaning “measure of elements”.
If you search for “stoichiometric combustion of natural gas” on the internet, you will come up with a number of places where the fuel air relationship is give. It is important to distinguish between the ratio on a mass basis vs. an volume basis and since we are talking about burning cubic feet of natural gas, we need to use the volume basis and the ratio is 9.7 to 1.
The second clue was in the form of the boiler specifications, which I have reproduced below for your reference.
Notice that there are figures for fuel consumption with a number of different units of measure, including cubic feet per hour. So, we could use the 8,798 cubic feet per hour of natural gas rating to come up with the combustion air requirement for perfect combustion at full fire.
But even if that data was not available, most boilers nameplates indicate the maximum energy input rate at full fire. For the boiler I was working with, the 900 under capacity meant the boiler was rated for 900MMBtu or 900,000,000 Btu/hr.
MMBtu is a common boiler rating metric and stands for 1 million Btus. In some ways, it’s a confusing unit but I believe the “M”s have their roots in Roman Numerals, where M stood for 1,000. So 1,000 x 1,000 (MM) is 1,000,000.
The question then becomes:
how many Btus are in a cubic foot of natural gas?
It turns out that the actual value will vary depending the source of the gas, and you should be able to find the exact value for the gas you are buying on your utility bill or in the regulations that govern your utility. For example, here is the value associated with Northwest Natural Gas, the utility that servers our house.
But lacking that, a good rule of thumb is to assume there are about 1,000 Btus per cubic foot of natural gas. The bottom line is that if we know the boiler firing rate and assume stoichiometric combustion, we can calculate the required combustion air flow at full fire.
But, perfect combustion can be tricky to achieve and if we didn’t completely burn the fuel, it would waste energy and also be a bit dangerous since a combustible mix would be dumped out of the flue at roof level. Thus, to ensure complete combustion, burners are set up with a bit more air than necessary.
This is termed “excess air” and works against peak efficiency because the air that is not involved in the combustion process is simply heated up and dumped to the roof. Current best practice is that about 9.5% excess air will provide a good balance between safety and efficiency. So taking that into account, the following table summarizes how I arrived at the peak combustion air flow requirement for the boiler we are discussing.
Step 6 – Determine the Purge Air Flow Rate for Each Portion of the Purge Cycle
The unresolved issue that cropped up for me after I had decided how I would come up with the combustion air flow was that it is not the same for all phases of the purge cycle. Specifically, you will recall from that post and information at the beginning of this post that during the pre-fire purge cycle, the air ramps up to the maximum, holds that flow rate for a minute and then ramps back down. And since the post purge cycle occurs when the boiler has reduced its firing rate to the minimum, then it likely occurs with the minimum air flow through the boiler.
To reflect those contingencies, I made the following assumptions.
Understanding the Burner Turndown Ratio
For most machines that can vary their capacity, there will be a limit with regard to how low they can go relative to their peak capacity. This limit is often expressed as a turndown ratio in the form of Peak Capacity/Minimum Capacity:Minimum Capacity. For the burner on the boiler we were dealing with the turn-down ratio was 10:1. Meaning that the maximum firing rate was 10 times the minimum firing rate.
Given a turndown ratio of 10:1 and a maximum combustion air requirement of 1,558 cfm with 9.5% excess air, the implied minimum combustion air flow rate with 9.5% excess air will be 156 cfm.
Addressing the Pre-fire Purge Ramp Up and Ramp Down
For the ramp up and ramp down portion of the pre-fire purge, I assumed that there was a linear relationship between firing rate and time and that the combustion control system was adjusted to keep the fuel/air ratio correct for the entire process. Mathematically, that means I could assume the combustion air flow rate for the cycle was the average of the maximum and minimum flows, or 857 cfm with 9.5% excess air.
Addressing the Post-fire Purge
Since in theory, the post-fire purge occurred after the boiler had turned down to minimum fire, I assumed that it occurred at the minimum combustion air flow rate or 156 cfm with 9.5% excess air.
Determining the Flue Gas Temperatures During the Purge Events
As you can see from the charts of the boiler cycle, the flue gas temperature is constantly varying during the purge events. One way to deal with that would have been to apply the sensible heat equation to each logged data point to calculate the energy associated with that 3 second interval, and then add it all up to come up with the over-all energy associated with a complete cycle.
To save some time, I decided to make two conservative, simplifying assumptions.
- I decided to assume a fixed leaving air temperature that was the lowest value I observed in the data set for a pre-fire purge cycle for the all of the pre-fire purge cycles; specifically, I used 184°F as the leaving air temperature for all of the pre-fire purge cycles.
- I decided to assume a fixed leaving air temperature that was the lowest value I observed in the data set for the post-fire cycle; specifically, I used 350°F.
The results will be conservative because during the real cycles, some of the events are at a higher temperature, meaning the Δt and associated energy calculated by the sensible heat equation would be higher than I would project with a fixed minimum temperature.
Putting it All Together to Come Up with Energy Up the Flue per Purge Cycle
The following table summarizes how I calculated the energy loss for each segment of the purge cycle.
Incidentally, in case you are curious, I actually ran out the calculation using the data point by data point method of calculating the energy loss up the flue and the result was with-in 5% of what I came up with using my assumed, fixed leaving temperature.
Since my technique was 5% low, it means that if anything I have understated the savings a bit, which is probably better than overstating the savings. Another way to think of it is that there is a 5% safety factor built into my calculation as a result of my conservative estimate of the temperature in the flue for a purge cycle.
Step 7 – Determine the Total Purge Losses for a Year Given the Current Operating Pattern
We now have all the parts and pieces we need to do a projection of the losses up the flue due to the purge cycles for a typical year given the current operating pattern. Specifically, we have:
- A relationship between boiler cycles and outdoor air temperature that was developed in Step 4, and
- The energy cost per purge cycle information developed in Step 6,
All that we need is annual weather data.
Selecting a Weather Data Source
There are a number of ways we could go here including using bin data, a year of actual weather data, or a TMY (Typical Meteorological Year) file. If you went to the Google drive location that I provided in the last post to get the data you needed to try your hand at this, you have discovered that I shared all of these resources with you there.
For my analysis, I decided to correlate the logged data cycles with a typical weather year in Columbus vs. an actual weather year. The TMY files are normalized data, meaning they reflect the average conditions for all of the years in the data set. To my way of thinking, that means they are good ways to asses what, in general, I might think will happen moving forward in time. If I use the TMY data, it is likely that I will not over or understate the savings and other benefits associated with an improvement.
In contrast, hourly weather data for a particular year is what really happened, including extreme conditions. The figure below contrasts a year of TMY data (the blue line representing normalized conditions for several years) with what actually happened in 2013 (the red line).
In general terms, the TMY data masks the extremes That is probably good in terms of projecting savings. But from an operational standpoint, understanding what might happen on an extreme day is probably a good thing. So both data sets have a place in our analysis toolkit.
Bin Data vs. Hourly Data
In the olden days, back when I didn’t have a computer on my desk and a spreadsheet was actually a piece of paper that you wrote on and I did the required calculations with a slide rule or a calculator or an adding machine, I would have likely turned to the bin data for this calculation instead of the weather files.
For one thing, the weather files would have been hard to come by. And for another thing, you basically do the calculations we are about to discuss for each row in the spreadsheet and the bin data spreadsheet has about 24 rows (one for each 5 degree bin between the minimum and maximum temperature for the climate in the area) vs. the weather data spreadsheet, which has 8,760 rows (one for each hour of the year).
So back in the olden days, we used bin data a lot for the pure practicality of it. But now, once you have the formulas set up, which will be virtually the same for bin data or hourly data, its just a matter of copying and pasting them into all of the rows in your spreadsheet. Given the speed of current laptop and desktop computers, its not much more labor and time intensive to do an hourly calculation vs. a bin calculation. And the hourly calculation has a number of advantages to it.
For one thing, you can define what happens for each hour of the day rather than average conditions that need to be applied to the range of hours in a bin. For instance, for a variable flow system that has a calculation based on flow and pressure in the system, you could use a formula to determine flow rate for each hour based on the time of day, day of week, etc.
You could also use a different flow rate for each hour based on flow profile you develop from past experience or trend data. Having established the flow, in the next cell you could use the square law to predict the pressure required based on a pressure and flow reading taken in the system concurrently and the flow associated with the hour in question.
Or if you could use a formula to determine the operating state of the system based on the weekly schedule and known holidays. In contrast, if we were using the bin data like the data I provided on the Google drive for Columbus …
… and had to reflect a schedule that ran a system 5 days a week from 8AM to 6 PM, we would have to apply de-rating factors to the total hours reported in each bin because they represent the hours at the indicated temperature and mean coincident wet bulb conditions for 7 days a week. In addition, out of the 8 hours of the day associated with the 00 – 08 bin, we are only concerned with 1 of them (from 8 AM to 9AM). Similarly, we are only concerned with a portion of the hours represented by the 17-24 hours bin.
The bottom line is that while bin data certainly is acceptable as a method for projecting energy savings, using hourly data will open the door to better precision in the calculations. And current technology means there will be very little difference in the time it takes to do the calculation assuming you are using the same steps in either process.
Doing the Math
What follows are the steps in the process I used to develop my projection of the energy loss due to the purge processes in a typical boiler cycle. Note that once I had the spreadsheet set up, I was able to quickly make copies that allowed be to assess the impact of different cycling rates, boiler efficiencies, and excess air percentages on the results.
The reason for looking at the results with a number of different variations for the inputs is that I did not know certain things exactly. For instance, as we discussed, the boiler flue temperatures we were seeing a range for the combustion efficiency and excess air, not a specific value.
With out the results of combustion efficiency test to narrow things down, I wanted to bracket the savings range that was possible vs. identify a specific number. This is not an unusual situation when you are doing energy calculations from field data given how many variables there are to deal with in a building and it’s systems and the climate it exists in.
What follows will illustrate the steps I went through for my first pass, which:
- Capped the short cycle rate at 7.1 per hour; this was an arbitrary reduction of the maximum observed cycling rate, meaning I was sure that during hot weather there would be at least this many short cycles in an hour. The data we gathered indicates there could be twice as many if both boilers fired the way the East boiler fires when it short cycles.
- Set the boiler efficiency at 72.6%; this was the low end of the estimated efficiency range based on the flue temperature. I discuss that in detail in the preceding post under the Flue Gas Temperature; Another Clue Pointing to Savings Potential topic.
- Set the excess air at 9.5%; this is ideal excess air rate, so it likely represents one end of the spectrum.
After I had worked out the bugs in my first calculation, I made copies of the spreadsheet and adjusted the factors listed above to represent other possible conditions and thus, established the range of savings I illustrated at the end of the previous post.
Turning the TMY Date and Time into an Excel Date and Time Value
The TMY data I used had the month, day, and hour in separate columns. I needed to combine them into one number that Excel could work with, as I discussed previously. There are a number of ways to go about doing this and I have done a number of blog posts illustrating some of them. In fact, there is a video clip associated with the the second post in series about using scatter plots that shows the steps interactively as I go about doing the process vs. screen shots. So, I will not go into a lot of detail here other than to briefly describe the particular process I used for this particular TMY file.
In the screen shot below, the date and time information that was provided in the TYM3 file is in the red columns. My first step was to assign an hour of the day to each row, which I did by simply numbering them from 1 to 24 repeatedly, as shown by the highlighted formula in the first orange column.
This is a fairly safe approach for the TMY data since you know there is a value for each our, meaning that 1 row is guaranteed to be an hour later than the preceding. But if the data was from a logger or a trend file, I would probably have done this a different way because there can be “hiccups” in the data due to power outages, etc. and assuming each data point is displaced by the same value in time from the preceding one could be a bad assumption.
Next, I built a text string for the month and day of the month. Since the TMY files is not for a specific year, I simply added 2015 to the string to make it work out when I plotted my chart. This is what is going on in the second orange column.
The third orange column does a similar thing to create the time part of the text string I need.
Finally, in the fourth orange column, I combine the date and text string to make an Excel date and time value …
… including formatting the column to display it as a date and time vs. a number.
Calculating the Boiler Cycles per Hour Based on the Outdoor Temperature
The yellow cells in my spreadsheet are the data fields that came from the TMY3 file. The only one I am using in this particular calculation is the outdoor temperature in the first column. But I kept them all in case I wanted to use the data for something else.
I calculated the number of boiler cycles per hour based on the relationship I developed between outdoor temperature and boiler cycling rate in Step 4 as illustrated in the highlighted cell in the green column.
But, you will notice that I limit the maximum number of cycles to the value in cell H6, 7.1 in this case. That is because the equation could generate an unrealistic number of cycles at some point. The absolute limit on how long a cycle could last is the sum of all of the events in the firing controller.
In other words, if the boiler shut down immediately after the main flame was proven and then started immediately after the end of the post fire purge, that would be the fastest chain of events that could happen because they are constrained by the firing controller settings. If you look at it that way, you come up with something like this.
While I actually have seen equipment short cycling that much, I did not see that happening on this site on a fairly warm day. So I decided to use an alternative approach that set the cycle time to what would happen if the West boiler fired for as short a period of time as the East boiler.
That even seemed like it might be a little fast so I decided I would do the calculation for a range and let this rate be one of the upper limits and an arbitrarily selected rate of 7.1 cycles per hour be the lower limit.
Calculating the Energy Loss for Each Purge Cycle
The blue columns are where I develop the energy loss for each part of the purge cycle and then total them up. I started writing one big formula that strung all of the equations in the table at the end of step 6 together into one cell. But when I made a typo, it was really hard to find and I decided it would be easier to do a column for each purge phase and then just add them up.
That means that the formulas in the second, third, and fourth blue column are very similar to the formula in the first column, which is illustrated below.
The only differences are the parameters used for flow rate and cycle length and flue gas temperature during the cycle, which are retrieved from the a table on the next tab over ( the Purge Loss 9.5 Pct Excess Air tab) …
… which is just the working table behind the tables I presented at the end of Step 6.
The last blue column simply adds up the other to provide the total loss for one purge cycle where it to occur during the hour under consideration.
Note that the variation in outdoor air temperature is the only reason this total varies from row to row.
Assigning Hourly Purge Losses to Each Boiler
The purple and gray columns develop the actual purge losses for each boiler for a given hour based on:
- The number of boiler cycles per hour (the green column)
- The energy that would go up the flue for one complete purge cycle at the outdoor air temperature associated with the hour under consideration
- An assumption regarding how cold it has to be for the lead boiler to stop cycling.
Thinking Through the Plant Response as the Load Changes
Lets address that last bullet. For this facility (and most facilities) the outdoor air temperature affects the load on the heating system with colder temperatures increasing the load for a number of reasons including envelope losses, colder make-up air, more infiltration, etc.
So lets think about how the plant might respond as it loaded and unloaded including ideal and less than ideal operation. Once we understand that, we can compare how the plant we are working with currently seems to be reacting to load changes to what an ideal plant should do and base our purge loss calculations on that same comparison.
The Plant at Full Load
In theory, on the design day, a perfectly sized boiler (with no safety factor) would just begin to run at steady state as the design condition was reached. For a plant with two boiler required at design conditions, on the design day, both of the boilers would begin to run at steady state as the design condition was reached.
The Plant at Part Load – Option 1
As the load dropped off on the two boiler plant, one possibility would be that both boilers would share the load and as a result, they would both begin modulate away from their high firing rate towards their low firing rate. Once they reached their low firing rate, they would start to cycle if the load were to drop any further.
The cycling would be occurring because at low fire, the boilers would be putting more energy into the system than was leaving it due to the loads. The boilers can not reduce their energy output any further with out cycling off due to physical constrains of their design. So, the control system cycles them off, allows the hot water loop to cool down bit, then cycles them back on to bring the loop back up to temperature. For as long as the energy being taken out of the loop is less than the boilers will put back in at low fire, the cycling pattern will continue.
As the load continued to drop, assuming equally sized boilers, at about 50% load, it should be possible for one boiler to carry the load and the second boiler to be shut down. This would increase the load on the remaining boiler and potentially would shift it back to an operating state where it could modulate its capacity as needed to match the load.
But, if the load continued to drop, eventually, the single boiler that remained on line would reach a condition where the it could not reduce its capacity any further due to the turn down limitations of its burner and other physical constraints of its design. At that point, it would begin to cycle again.
If things were really bad in terms of the staging adjustments, the control system may try to cycle the 2nd boiler during the time the first boiler is cycling. Since at that point, the load is not high enough to keep one boiler running full time let alone two boilers, the 2nd boiler would likely cycle back off very quickly, perhaps doing little if any useful heating. As you will recall, this is the pattern we are seeing in the boiler plant we have analyzing.
The Plant at Part Load – Option 2
Its important to remember that each boiler cycle represents purge losses and stress on the boiler metals due to thermal expansion and contraction. And while the purge operations are necessary for safe boiler operation, ideally, we would like to minimize them. In the context of our discussion, if two boilers are cycling when it should be possible for one to handle the load, then it is likely that we have an opportunity. The question we need to ask ourselves is what would that sort of operation look like?
The answer to the question may be as simple as:
- Keeping the lag boiler off line until the lead boiler is no longer cycling and,
- If the boilers are operating together and begin to cycle, turn one of them off.
This may require some fine tuning to optimize the process, especially if the boilers are different sizes and/or the lead boiler is swapped after so many hours of operation, etc.
It may also be possible to configure the piping connections to keep one boiler loaded while the other boiler experienced the load swings. But if the system was not already piped to do that, such a modification may be cost prohibitive compared to an approach that could achieve the savings by adjustments to the staging of the boilers and their operating set points.
Determining When a the Lead Boiler Begins to Run Steady State for the Current Scenario
There are number of ways to figure out when the lead boiler in the current plant (which appeared to be the West Boiler since it had the longer operating cycle) would begin to stop cycling. By coincidence, we captured a period of time when the outdoor air temperature took a big swing while we were logging boiler flue temperatures, as was illustrated in the previous post. If we take a look at that data, which I have reproduced below …
… we can see that it seems to happen when the outdoor temperature is in the range of 50°F.
If we didn’t happen to have data that captured the event, but had enough data to do a good regression, we could estimate the temperature by solving the trend line equation for the outdoor air temperature where the cycles per hour are equal to 1. Here is what that looked like when I did it for the regression we used to correlate boiler cycles with outdoor temperature.
Based on these assessments and the other data and field observations, I decided to assume that for the plant as currently configured:
- Below 52°F, the West Boiler ran steady state (no purge cycles) and the east boiler cycled at what ever the calculated boiler cycling rate was.
- Above 52°F, both the West Boiler and East Boiler cycled at what ever the calculated boiler cycling rate was.
This is what the purple column …
… and gray column …
… do in my spreadsheet. The white column totals them up.
(Note that to get the purple, gray, and white columns to show on my display with out reducing the scaling of the spreadsheet, I have hidden the first three columns with the TMY data in them).
To get the total purge cost for the year, I added up the purge cost for each hour in the white column and did a little basic math. This table illustrates the results for the plant assuming:
- A maximum short cycle rate of 7.1 per hour, and
- A boiler efficiency at 72.6%, and
- Excess air at 9.5%.
Once I had the spreadsheet set up, I simply made copies of it and then change the three assumptions I listed at the start of this section to establish the potential range of costs associated with the purge cycles for the plant in its current state.
I should also mention that while there were three boilers in the plant, I have assumed that the third boiler was not required. It may have in fact been short cycling also. But since it was off line for repairs, I had no meaningful way to understand how its operation would impact the cycling that I was observing and how much it would cycle.
What I could tell was that on a relatively cold day, two boilers seemed to be able to manage the load reasonably well. If the third boiler had in fact operated in the past, then it is likely that made the short cycling problem worse, not better, meaning my calculations are conservative.
Step 8 – Determine the Savings Associated with Reducing the Number of Purge Cycles
The final step in my process was to add columns to my spreadsheets that reflected reduced cycling for the East Boiler when I thought that was achievable.
Based on my observations and analysis of how the plant was running and how it might be possible to make it run, it seemed likely that we could eliminate the cycling of the East boiler once the West Boiler had started to cycle.
In other words, even thought the East Boiler was cycling on while the West Boiler was cycling, it only was producing heat for less than a minute. That means it was not contributing much to offsetting the load on the plant. That, in turn, implies that the West boiler could carry the load at that point.
I have reproduced my diagram of the boiler interactions below to give you a visual on this.
Notice how the red band (which is the firing cycle) for the East boiler is very narrow and how the West Boiler is off for a significant portion of the time (the white band). During the time I was developing the data for the diagram the temperature outside was running from 55-65°F.
So bottom line, it seems like the West Boiler could handle the load under these conditions with out the East Boiler. And the projections that the West boiler could handle the load until the temperature outside was in the low 50°F range also seems reasonable based on this data.
The columns I added to my spreadsheet modified the purge cycles for the East boiler so there were no cycles for if it was above 52°F outside. In other words, I assumed the West boiler would cycle above that temperature but the East boiler would simply remain off line. Below 52°F, I assumed the pattern that exists currently would still exist. Here is what that looked like for the East boiler (the red column; note that I have hidden most of the Date and time information in the orange columns to show this part of the calculation) …
… and the West boiler ( the 2nd orange column) …
… along with the total projected consumption for the new operating pattern (the green column).
The following table summarizes the saving for this specific condition.
The next table summarizes the savings for all of the conditions I assessed.
The bottom line is that some fairly simple adjustments could potentially saving at least $800 per year and may deliver almost $2,000 per year in savings depending on the specifics of the current burner set-up.
So there you have it; the steps in the procedure I used to assess the savings associated with eliminating unnecessary purge cycles in a boiler plant. It probably seems like a lot to go through, and in some ways, it is. But it actually takes a lot more time to illustrate it or read about it and understand it than it does to do it.
And the reality is that most energy calculations require that you make a number of decisions similar to the ones I needed to make to perform this one, which inevitably take you into the details of how things work and how to make them work better. But that is the key to success in Existing Building Commissioning and Ongoing Commissioning; we want to understand how our buildings work and make them work better. And I can’t help but believe that is a good thing for all of us.
Senior Engineer – Facility Dynamics Engineering