RTF Fan and Pump VFD Subcommittee
November 16, 2012, 10:00 to 12:00
Attendees:
Nick O’Neil, Clark Fisher, Andy Paul, Levi Westra, Doug Swier, Erin Hope, Jennifer
Williamson, Tom Osborn, Mark Rehley, Bill Koran, Michelle Friedrich, Wendy Lee,
Eric Boyer, Charlie Grist.
Agenda:
•
Review the purpose of RTF Standard Protocols
•
Demonstration of the Fan VFD Calculator and data loading
•
Subcommittee member review of the protocols
• Member reports on use of the Fan VFD Calculator
•
Specific systems limitations for the fan and pump protocols
•
Independent review of the protocol and calculator
• Subcommittee recommendation to the RTF
Notes: Kendall facilitated introductions and introduced the agenda, the subcommittee
Tingleff introduced the use of the calculator.
Friedrich asked about motor loading and the difference in HP pre and post.
Tingleff responded that motor efficiency as a function of load.
Is there a chart that helps the practitioner know what the machine efficiency is? If it’s belts, mechanical drive or…? Tingleff responded that it is variable and therefore it was not addressed explicitly, but the practitioner should use judgment.
Fan curve needs to be accurate for the current diameter of the fan blades and the temperature. The practitioner is responsible for transferring the fan curve to the diameter and temperature to the application.
Friedrich asked if the 1780 rpm and 1800 rpm used in the calculator causes any difference. Tingleff identified that the affinity laws determine that the difference is not significant.
Affinity laws are only used to address lower fan speed. Boyer asked what affinity law exponent was assumed. Tingleff identified that the calculator is set to use 2.0 which they found common for fan applications.

The system curve page provides the yellow cells indicating input and mauve cells indicating an option of measured data. Tingleff admitted that it may be confusing and will attempt to clarify in a future release.
Koran found that the System Curve page was relatively clear. After having read the protocol and the fact that measured data was shown as an alternative of using measured data, that it is clear.
Sweir added that we ought to have the fact that the amps and KW need to be collected before the drive. Some practitioners may prefer to collect data reported from the drive and not be as well read on the protocol requirements for data collection. The calculator should describe protocol requirements of the inputs in the calculator itself.
O’Neil asked about having two tabs showing the amps versus speed so we can compare provisional data between the machine curve kW. Tingleff pointed out that we would have to compare two separate runs to compare amps to machine curve. O’Neil asked if there was any way to compare the two methods in one sheet with statistical comparison.
Tingleff answered that not in this version. A practitioner has to run a pre-post analysis, save it, and then open up a new workbook and enter in the post-only run and manually compare the results.
Grist asked if there is a method to develop the similar feature as is installed in the RTU calculator?
Friedrich asked how we might be able to add additional schedules. Tingleff illustrated how to add another set of schedules. The intent is to have modes only for those where data is collected however. Friedrich asked if there is a method for adding a mode for which there is no data. A lot of buildings have three primary modes: occupied, unoccupied, and warm-up.
Nexant asked who would employ this protocol and Tingleff answered that the likely practitioner would be someone who was familiar with fan and system curves, and not a utility efficiency program manager.
Hope stated that he didn’t see this working on smaller fans (e.g. HVAC fans) which is most all fans of this nature. Not being able to change the exponent from 2.0 will give poor data compared to actual measurements.
The system exponent is on the system curve that is limited to 2.0 and defaults to 1.7. The other exponent is input at the lower speed fan curves and we calculate the linear relationship to the speed and use the cubic. The curve is based on a single point measurement. To get a reasonable fit pressures, would need to be measured at different flows.
Hope identifies that if the calculator has a different savings than what is found in custom measure approaches, people won’t use it.

O’Neil asks how this measurement is different from what programs do during a custom measure analysis? Hope indicated that they did pre-post analysis in custom measure analysis with generally the same identifiers outlined in the protocol for measurement periods.
Sweir identified that this may be more useful in new construction and that post only data could be used to predict the pre-condition. Sweir wonders if the user puts in the system efficiency. Tingleff identified that the drive efficiency does not affect the measurement since the power measurement is taken up-stream of the drive.
Koran added that that the BPA protocols are not this detailed and that these protocols are intended to take pre and post data and take this to annual data. In many projects we don’t have enough data to characterize the annual consumption data.
Swier says that many fans are schedule driven and not necessarily weather driven, so it’s easily annualized.
Boyer asked what the R squared limit was of the data used for weather? Tingleff responded that there is none currently, but it might make sense to add one.
Post project data collection and adjusting the process to establish a system curve if using the amps and % speed. Tingleff added that you need two points for the system curve.
You need the zero point and operating point to get the system curve.
Hope says that when it calculates baseline kW from the post flow, the difference in the fan curve with vanes before and VFD post will be quite different. How does this calculator account for this? Tingleff responded that this is theoretical and the calculator doesn’t work that well with inlet vanes since the fan curve changes shape. This doesn’t apply to inlet vane fans. Hope points out that this eliminates most boiler fans.
Hope adds that in industrial fans there will be system curves easily available. If fan blades are trimmed, there may not be accurate performance curves. Sweir added that the same applies to pumps. Neither Hope nor Sweir added that what he runs into the range of curves based on various trims and they may or may not be.
Hope, what could help would be to list out the eligible applications in the protocol.
Eligibility:
The group identified that the fan protocol applies to the following system types:

Exhaust fans

Refrigeration Fans

Exhaust fans

Cooling fans


Smaller fan sizes (<25) are the good application for this where pre and post measurement are not applicable due to cost.
Systems that would not be eligible include:

Iris dampers

Inlet vanes

It won’t cross and zero flow zero pressure

Bag House fans curves change
Hope and Tingleff added that the protocol works for fixed volume HVAC and
Refrigeration fans. In addition, industrial cooling, material transport, and exhaust fans seem quite applicable. HVAC fans or bag house fans are problematic since do not remain the same downstream (e.g. damper boxes downstream, loaded up filters…).
Hope adds, with the written protocol, we are on the right path with identification of the methods and that the calculators annualization routine is useful. We could expand the protocol by defining the methods for different systems such as inlet vane and iris damper….
Grist asks if the RTU protocol, where we developed a first set of systems applicable to the protocol and then expand it to other HVAC systems types, is the appropriate path for these protocols or are we on a dead end path. Can this be done with this fan protocol?
Hope responded that the protocol could easily be implemented for this limited scope and that there is good information on the methods in the protocol. Then we could add the data collection requirements for other systems such as iris vane systems, HVAC with
VAV fan boxes etc.
O’Neil asked if the bulk of projects will be going pre and post custom measurement, how long will the data collection be needed? Could the protocol help reduce the period of pre and post measurement? The protocol could show that best practice is to measure for two weeks and the protocol shows that we can measure pre and post for a shorter period of time or just the post as spot measurement and wouldn’t that be useful?
Hope adds that we can likely identify the types of systems at BPA based on program participation review.
Sweir mentioned he has provided what he had pre and post power and current so he didn’t need the pump curves and therefore a calculator.
Koran mentioned that he found it clear and found one area where the language in pre data referred to speed and he thought it was a typo. Otherwise he found the protocol to be clear and thorough. Synergistic complication between the protocol and the calculator and believes that section 13 needs to provide a clear user guide, and documentation in the calculator supported with training.

Tingleff believes that there should have a consistent look and feel. Ideally we have a uniform calculator with multiple modules for measures. The user interface is difficult and could benefit from attention.
Koran added that calculators should take into account a common platform for performance modes, and modules. This protocol helps establish consistent methodology for the region for estimating savings where there is no pre-data.
Is there a size limit, what we have proposed is a post only method. Is there a limit to where we want to insist on pre-post. Pre post should be allowed in the final version.
Swier reiterated the applicability of the protocol for sites with no pre data (new construction or where pre data are unavailable.
O’Neil provided the following summary observations for the Subcommittee notes:

The most recent versions of the protocol up on the subcommittee page and the version displayed during the meeting still had some text sections that refer to the production method. We need to make certain we are working from the latest versions of the protocols and calculators. The posted calculator still has the production determinant in it, and it needs to be updated. (11/26/12 - This has now been fixed in an update, so the blank calculator on the website is current)

The system curve exponent seemed to be a big point of contention, but when I ran the calculator using different coefficient values for the same fan inputs, the savings changed by less than 1% going from 1.7 -> 2.0 and were even smaller going from 2.0 -> 2.5. Seems like this is well within the threshold we set up for this measurement, so I’m not sure if it is actually a big deal or not.
Maybe on different system curves it would have a bigger impact, but I’m not sure to what extent it would cause our estimation to fall outside the confidence limits we set up.

We need to be clearer in the protocol and the calculator about where to take power measurements so the practitioner has a clear understanding. Seems like this is an easy thing to clarify.

Add a threshold for the R-squared value on the OAT regression method. I’m not sure what an acceptable minimum might be, but at the least we should publish the R-squared value with the savings estimate if you use the OAT method so a practitioner can see how accurate the regression was.
Next steps:

SBW to update posted documents to the current versions of the protocols and calculators. The posted calculator and protocols still have the production determinant in them, and it needs to be updated

SBW and RTF will add clarity to the users guide section 13 that provide the clear steps for taking the protocol data collection to the calculator.


BPA and others will provide the RTF with a list of fan and pump applications
(systems types) where the protocol applies.

The RTF and SBW will integrate any edits to the protocols provided by the subcommittee

Next meeting is scheduled for November 30 at 10:00