EnergyGauge Summit has a multipliers field on many input pages to help save time in the data input process, but how exactly do they work? At first glance they are fairly straight forward, but it is very easy for things to get out of hand if you are not careful about how you use them. Here are a few tips to help make sure they are used as intended. 

    So what exactly does a multiplier do. The short answer is it multiplies the component in question.  If you input window1 and change the multiplier to 4 then there will be 4 windows of that exact input combination. That means if window1 is not 12 sq ft there is now 48 sq ft instead, and wall1 needs to be big enough to hold these.  But it is more involved than that. Each component in Summit has the potential to be more than what is input on that particular page. The easiest way to visualize this is the is by looking at the Project Explorer, or the building tree, on the left side of the program. 

Imagine that wall1 also has a multiplier of 4. This does not change the size of wall1, so each of the 4 walls must be large enough to hold 4 each of window1. But we still have a multiplier of 4 on window1. This means that in the sample project we actually now have 16 windows, 4 on each of the  4 walls. If we have a multiplier on Zone1 as well then we now have 4 zones with 4 walls with 4 windows each. This puts our window count up to 64, or 768 sq ft. That is a lot of glass and if it was not by design that could hurt a project where the intention was to only have one window on each of those 4 walls. That would instead be 192 sq ft of glass and would make a significant difference in the final calculation. 

So when entering multipliers we need to take into account the "parent" component of what we are entering. How can we use this to our advantage and what do we need to look out for. Take a hotel for example. In the simplest case lets assume that all rooms are identical. If the hotel 5 stories tall, and there are a dozen rooms total per floor then we have 60 rooms to model, each with their own walls, windows, and systems. How can we simplify that? Well, every floor will have 4 corner rooms. There will be interior rooms separating those corners, and lets imagine there is a room in the center of the floor with no exterior walls (unlikely to be a room for rent but it could be a maintenance closet, storage, or other use). If each floor is identical, then we can break this down to four corner units, 4 interior units separating the corners, and the interior room. If all rooms are the same then these 9 possibilities cover all the cases per floor. Then we can compare floors. The top and bottom floors are unique, but the three floors in between are the same, with a space above and a space below. So we now have three unique floors with 9 unique rooms each, making the data entry now only 27 rooms. We have managed to cut the data entry down by more than half. 

Now that is very handy to have, but there is still one more place where we can run into trouble. Each room we modeled as a zone because each room has its own system. Now if each zone had one window, one or two unique walls, one space associated with it then we only model each item once and multiply the zone, not the components, to get the correct amount of items. But we also have to enter the systems. Just like with the window example systems can get out of hand very quickly. If there is only one system per room then there should be no system multiplier used, since the zone multiplier will take care of it for us. 

What is the worst that can happen if we use multipliers wrong? Well, it depends on what you think is worse. On one hand if a multiplier is used where it shouldn't be then you may not notice anything at all. In the case of the window example you will have a very large amount of glass, but the project will run through a calculation most likely, and the more glass you have the less likely it is the project will pass. After all, glass is far less efficient than an insulated wall at keeping the building cool. The same is generally true in the case of systems. The project may run a calculation, and it may simply fail. How can you tell this is the problem? One way to tell is the Building End Uses pages of the performance calculation reports. This will have a break down of the energy costs of the proposed and baseline buildings used in the calculation, and some of the numbers may appear drastically different. Typically if the systems multipliers are misused, especially in larger projects, the Mech Vent and Space cool categories will be drastically different from the proposed project to the baseline. If these numbers seem off be sure to check your multipliers first as this may be the easy fix. The second possibility is that the project won't run at all. Instead there will be an error message stating that an error in the project exists and the error check should be run. Upon running the error check however you may see that it comes back as errors in project false, meaning there are no errors. This happens because while there are no errors in the proposed project the number difference is so drastic that the baseline building is failing to model all the multiples of the systems. This false positive error check is another sign that the multipliers may be misused and should be double checked. 

So, when entering multipliers it is good practice to think less is more. Otherwise more becomes too much very quickly. And something else to keep in mind, particularly when modeling spaces for code compliance, if the first instance of a zone  passes code and there are multiple identical zones like it there is no reason those zones should not pass as they are the same. Using multipliers is not modeling less, it is just modeling more, more efficiently.