There are two problems with calculations that involve division by a value that could be zero:
1. As previously noted, division by zero produces an undefined result, and therefore an error in VBScript.
2. Even if you try to use a conditional statement (such as If statement) to test for a zero value and only perform the division if the value is non-zero, VBScript evaluates the entire statement, not just the parts on the logical path, so if division by zero exists, even in the section that should not be evaluated, an error condition will still occur.
Fortunately, it is possible to write a formula that works around this limitation, as can be seen in the attached sample file. There are, no doubt, many ways to have ACA help in the calculation of occupant loads and I know others have done far more with this than is shown in the sample file here, but this should get you past the issues with division by zero in a formula property. The file was created in ACA 2011, so anyone using ACA 2010 or later should be able to take a look at the file.
I chose to create new Property Set Definitions [PSDs] for the newly created properties, rather than add them to the out-of-the-box [OOTB] PSDs, on the theory that that would make migrating to future releases easier, by keeping my customizations separate. You could just as easily add them to the OOTB PSDs if you want. I also chose to make the Occupant_Load property part of a style-based PSD. This assumes that you make use of different Space Styles for different space types/uses, and that each Space Style would always have the same occupant load factor. This allows you to enter the occupant load factor in the Space Style once, rather than for each instance. If you do not use different Space Styles for different space types, you could add the Occupant_Load property to an object-based Property Set Definition and enter the load factor for each Space you create. (Choose an appropriate default value for that property if you go that route.) The Space Styles used here are all OOTB ACA 2011 styles, with the custom SpaceStylesCalc PSD attached and a value for the Occupant_Load property entered. Spaces that have no occupant load (non-simultaneous occupancy areas) are set to 0.
If you want to use a style-based property, but want the ability to occasionally override that value on an individual Space, that can also be done; if you cannot figure out how to do so, post back and I will try to find time to add that to the sample file.
The SpaceObjectsCalc PSD is object-based and contains the Occupants formula property. This property uses the OOTB SpaceStyles:BaseArea property as the area on which the occupancy load calculation will take place. The example file does not attempt to allow for the fact that, depending upon the applicable code, some occupancy load factors will be based on gross square feet and others on net square feet. The calculation involves dividing the SpaceStyles:BaseArea property by the custom SpaceStylesCalc:Occupant_Load property value.
occLoad = [SpaceStylesCalcs:Occupant_Load] If occLoad = 0 Then doCalc = 0 occLoad = 1 Else doCalc = 1 End If If doCalc = 1 Then RESULT = [SpaceStyles:BaseArea] / occLoad Else RESULT = 0 End If
The formula property starts off by setting a variable called occLoad to the value of SpaceStylesCalc:Occupant_Load. It gets around the division by zero issue by using two If statements. The first tests the value of occLoad. If occLoad is zero, then the variable doCalc is set to 0 and occLoad is reset to 1. [Any non-zero value would do, since the formula property will not return a calculated value when SpaceStylesCalc:Occupant_Load is set to 0. If occLoad contains a non-zero value, doCalc is set to 1 and the value of occLoad is not changed.
At this point, we now have a variable that tells us whether or not a calculation should take place (doCalc) and a variable for the divisor that will not be equal to zero. The second If statement tests the value of doCalc. If it is set to 1, then formula property returns result of dividing the value of the SpaceStyles:BaseArea property by the value in occLoad (the original value from SpaceStylesCalc:Occupant_Load). If doCalc is set to 0, then the formula property returns a value of 0.
Notes:
1. In the Enter Sample Values area of the formula property definition, the Format for the SpaceStyles:BaseArea property has been changed from the default Area, which rounds to two decimal places adds " SF" (imperial units version) to the area value, to a custom Property Data Format called Standard-8, which is a copy of the OOTB Standard Property Data Format with the precision increased to the maximum eight decimal places. The text suffix of the Area Property Data Format will cause math calculations to fail. The increase in precision is probably overkill, givent the calculation at hand. If you have large drawings with many Spaces, you might see an improvement in performance by using the OOTB Standard Property Data Format (three decimal place precision), or a custom one with less precision.
2. I created a custom Property Data Format called Occupants, which I applied to the formula property. This does two things - it adds a text suffix to the result (" OCC"). If you plan to use this value for further calculations, you will want to change the applied format to one that is only numeric in the formula property definition, as was done for the SpaceStyles:BaseArea property in the SpaceObjectsCalc:Occupants formula, as indicated in "Note 1" above. The other thing is does is round the calculated value up to the next whole number. When doing occupant load calculations, I always round any fractional amount up to the next whole person. If you choose to do your rounding this way, be certain to set the Round Off value to 1, as well as set the rounding to Up. Leaving the value set to 0 can have unexpected results. I did a series of articles on rounding in ACA properties (ADT properties at the time) back in August and September of 2005. I have not tested rounding much since then, but expect that things probably still work the same in more recent versions. If you are having problems with rounding using a Property Data Format, there are ways to calculate the desired rounding as part of the formula property. Those articles from 2005 and the referenced sample files show how.
http://architects-desktop.blogspot.com/2005/08/rounding-up-property-data-values.html
http://architects-desktop.blogspot.com/2005/08/rounding-revisited.html
http://architects-desktop.blogspot.com/2005/09/rounding-redux.html
http://architects-desktop.blogspot.com/2005/09/rounding-to-death.html
3. I added a Schedule Table into the sample file to display the pertinent property values associated with the Spaces in the sample file.
Looks like your schedule table is being cut off in the PDF you posted. I would not have been able to do much trouble shooting in a PDF, anyway.
Are your certain that your Spaces are exactly 88 square feet, and not 88.00000001 square feet? ACA does math on the raw values, not the formatted values. Your Schedule Table may report an area of 88 SF, but if that is the result of applying a Property Data format that has zero decimal place precision rather than the actual value, the occupant load may round up.
As for the occupant total issue (which I cannot see as it is beyond the edge of the PDF), my previous post did allow that there might be issues with rounding. I did not anticipate someone wanting to generate a total number of occupants by checking the total box for that column. Once again, ACA does math on the raw, unformatted values, and if you want to have a total for the occupant load (a perfectly reasonable request, and one that I would probably want as well, on a real project), then using the Property Data Format to do the rounding is not a good idea. You should, instead, have the formula property handle the rounding. More than you ever wanted to know about making Schedule Table column totals reflect the sum of the actually displayed values can be found in this blog post:
http://architects-desktop.blogspot.com/2011/11/rounding-and-column-totals.html
That post also has links to the rounding articles to which my first post in this thread linked.
For the occupant load calculation, all we want is for the value to round up for any fractional amount. This can be done in the formula quite easily. Once way is shown below. In the second If statement, instead of setting return values as was done in the original file, I set the "result" to a variable named occs. A third If statement was added, testing the result of subtracting the integer portion of occs from occs. If this is not equal to 0, then occs is reset to the integer portion of occs plus 1. If it is equal to zero, then occs is a whole number and there is no need to reset the value. Finally, the value in occs is returned as the RESULT.
occLoad = [SpaceStylesCalcs:Occupant_Load] If occLoad = 0 Then doCalc = 0 occLoad = 1 Else doCalc = 1 End If If doCalc = 1 Then occs = [SpaceStyles:BaseArea] / occLoad Else occs = 0 End If If occs - Int (occs) <> 0 Then occs = Int (occs) +1 End If RESULT = occs
In the attached drawing file, I modified the schedule table from the first posting to add a total to the occupant load column. The sample file contains spaces whose areas and occupant load factors result in fractional amounts. With the revised formula, the raw number is the same as the displayed number, and the total is the sum of the displayed numbers.
If both stock rooms are the exact same area (as opposed to rounding to the same area) and the values in all other columns are likewise, you can add a quantity column and the rows will collapse into one. If you do not want to show the quantity, you can hide that column. If you want the total area, you can add a formula column that would show the product of the quantity column and the area column. (If you only want to show the total area, you can hide the area column, too.)
You may want to look into Zones. You can assign Spaces to Zones, and the Zones have an automatic property that reports the total area of all Spaces and other Zones (if any) assigned to them. It is likely a bit more work to set up, but short of doing some serious customization (well beyond that with which I have experience), it is the only way I know of to aggregate the areas of multiple spaces.
Sure. You will need a property to hold the fixed property value, and then modify the formula property to use that value instead of the calculated value.
In the attached file, I added a new, manual integer property to the SpaceObjectsCalc PSD, called Occupant_Override, assuming that this should be set on a per-Space basis, rather than once for all Spaces of a particular Space Style. I made the default value 0, and that value means that the Area/Occupant Load value should be calculated, if possible, and used as the RESULT. The formula property gets modified as shown below, adding a test for the value in the Occupant_Override property (assigned to a variable called occOverride). A new If test has been added. If the value in occOverride is zero, then all of the previous formula's If statements get executed (in other words, no change in the result). If the value in occOverride is set to anything other than 0 (presumably, positive integer values would be entered), then that value becomes the RESULT.
occLoad = [SpaceStylesCalcs:Occupant_Load] occOverride = [Occupant_Override] If occOverride = 0 Then If occLoad = 0 Then doCalc = 0 occLoad = 1 Else doCalc = 1 End If If doCalc = 1 Then occs = [SpaceStyles:BaseArea] / occLoad Else occs = 0 End If If occs - Int (occs) <> 0 Then occs = Int (occs) +1 End If RESULT = occs Else RESULT = occOverride End If
NOTE: This formula does not check to see if a non-zero value entered into the Occupant_Override property is less than the calculated value, and if so, return the calculated value instead. That could certainly be done, if you wanted to make certain that an occupant load less than the code-mandated minimum could not be "accidentally" entered as an override value. The point here was to demonstrate that an override is possible.
In the attached file, I have updated the previous file to include the Occupant_Override property and amended the Occupants formula property as shown above. I added a column to the Schedule Table to show the value of Occupant_Override for each Space. Off 119 and Lobby 104 have override values other than zero. I also noticed that the previous version of the Schedule Table had no sorting applied, and chose to sort this version by the SpaceObjects:Number property, in ascending order. The file is in AutoCAD 2010 format, so anyone running ACA 2010 or later should be able to open it.
