Schedules unit format

[avalencia60]

Hi every one, when I make a gross area schedule the totals of the areas are rounding the numbers and they are not exact with the numbers above. Is there a solution to give a unit format for the totals in order to not round the number. See the attached image.

Thanks, Alex

[Steve_Stafford]

It (your image) is "off" by 1 square foot. Alter the rounding to allow for more decimal places and you will get closer to a matching number. The reality of modeling and having software calculate area is that the values are more "real" than your builder can achieve or that a person might have the tolerance or attention span to appreciate.

I encourage people to add a note for readers explaining what schedule totals really mean. In this case the total is "accurate" while the individual numbers are expressing an "arbitrary" rounding off of decimals of greater accuracy. In this case the individual rooms are rounding to the nearest SF. Therefore a total that is off by one SF is not too surprising really.

In what capacity can a building department object? They usually only check for minimum requirements or not violating code or zoning minimum/maximums.

[irneb]

Rounding errors tend to give problems yes. Unfortunately there's no way to get rid of them in Revit (or for that matter anywhere else) - they're a fact of life.

The issue you're picking up is the compounding of rounding errors which makes the schedule "appear" incorrect. E.g. the "true" value might be something like this:
Real = Int
689.56 = 690
136.62 = 137
189.85 = 190
136.62 = 137

Totals
1152.65 = 1153

Instead of
1152.65 = 1154So Revit uses the more acurate real numbers (not the integers) when calculating everything (including the total). Then takes the answer of each in turn then rounds them to the nearest integer. This way the total is actually more accurate than one which would "look correct".

[avalencia60]

Thankyou very much for your answer, but unfortunately, Building Department officials are always looking for errors, no matter how small, to justify their jobs.

Alex.

[Steve_Stafford]

Yep, and there is nothing wrong with pointing out that the project isn't affected by the rounding "error", could they please focus on more important items? :)

[jsteinhauer]

Alex,

Someone at the Building Department was having heart burn over .0867% difference between calculated and displayed? As Steve is pointing out, it's not truly an "error", or something they should be concerned about. I would let them know, you're more concerned about oh lets say building code violations. I've attached an image for changing the rounding in a schedule.

Cheers,
Jeff S.

[MikeJarosz]

Here's the same problem in Excel:

88520

The erroneous example is really (1.45 + 1.45 = 2.90), but has been rounded on the screen to the nearest whole number, including the sum.

[irneb]

Well, if you have to "fix" this ... all I can think of would be to place a opaque text over the total and type in manually.

You might have been able to use the round (http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User's_Guide/2654-Tools_an2654/2894-Formulas2894/2897-Valid_Fo2897) function in the formula of a calculated field in the schedule. But lo-and-behold, ADesk in their invisible wisdom decided:

"No! Thow shall not be allowed to use such function on areas. Thow shall be chastised for using Inconsistend Units!"

[irneb]

You might have been able to use the round (http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User's_Guide/2654-Tools_an2654/2894-Formulas2894/2897-Valid_Fo2897) function in the formula of a calculated field in the schedule. But lo-and-behold, ADesk in their invisible wisdom decided:

"No! Thow shall not be allowed to use such function on areas. Thow shall be chastised for using Inconsistend Units!"Actually there seems to be a work-around for this. Say your schedule has the Area field included. Add a calculated field, set it to be an area type and make it's formula thus:

For square meters:
round(Area / 1 m²) * 1 m²

For square feet:
round(Area / 1 sf) * 1 sf

Now hide the original area field in the Formatting tab, and rename the calculated field to what you want it displayed as in its column heading. A total on this column will now use the integer values instead of the fractionals.

If your areas are to show to say 2 decimals, then modify the formula thus:
round(Area / 0.01 m²) * 100 m²

[irneb]

Doing this side-by-side shows how inaccurate it actually is:
88521

[DaveP]

There have been many, many threads on this over the years.
That total IS NOT INACCURATE. It is the display of the individual values that has been rounded.
As in Mike's example, 1.45 + 1.45 = 2.90, which would you say is the "inaccurate" value? 1.45 being displayed as 1, or 2.90 being displayed as 3?
And which would you rather have on your documents?
Would you rather have your schedule give you the total as 2? Which do you think the Building Department would complain more about?
This is really only an issue when you have a small number of lines in your schedule and some anal-retentive takes the time to add them all up (again). I'm guessing they would overlook the same difference if it was in a schedule of 100 lines. They most likely wouldn't take the time to add all those values again. And if they did, they'd be likely to miss one anyway.


It can also be addressed by a simple note saying the equivalent of "values may not add up to 100% due to rounding errors"

[Steve_Stafford]

Not rounding errors, just "due to rounding". :)

[MikeJarosz]

Not rounding errors, just "due to rounding". :)

exactly........

[CADastrophe]

What about something like:


Each of the values shown in all instances herein reflect the rounded results of the actual values factored into and/or derived from calculations, therefore, all calculations based upon these rounded figures may produce results that appear imperfect.

[Steve_Stafford]

Okay now it sounds like our lawyer wrote it, our work is done here. :)

[avalencia60]

Thank you to all of you for the wonderfull answeres, but the only way that I founded out was to move a little bit the area boundary lines to reduce the fractions in the schedule (something I know is wrong) but with that note I will solve the problem.

Thanks again, Alex

[MikeJarosz]

Excel has a feature that allows totals to be calculated as displayed. They describe it thus:

"Precision is a measure of the degree of accuracy for a calculation. Excel stores and calculates with 15 significant digits of precision. However, you can change the precision of calculations so that Excel uses the displayed value instead of the stored value when it recalculates formulas"

It comes with a warning that the sums could be inaccurate. Of course, Revit is not Excel, no matter how much we wish we could copy cells in a Revit schedule as easily as we do in Excel.

[irneb]

There have been many, many threads on this over the years.
That total IS NOT INACCURATE. It is the display of the individual values that has been rounded.
As in Mike's example, 1.45 + 1.45 = 2.90, which would you say is the "inaccurate" value? 1.45 being displayed as 1, or 2.90 being displayed as 3?
And which would you rather have on your documents?errors"I think you misunderstood me. I'm referring inaccuracy of the rounded and totaled version. E.g. using Mike's values:
1.45 => 1, and 1 + 1 => 2. In this case the rounding-error is 0.9 in total. Using the method Revit does, the rounding error in total is only 0.1 for the total, but 0.45 for each row. IMO this is more accurate than the 0.9 error - you can't do anything about the 0.45 (so that doesn't apply).

My example was chosen to show how this "error" could actually alter the total by more than 1.0. E.g. using Revit as normal the total in mine would show as 969.4 => 969 with an error of 0.4. But using the special-pre-rounded-then-totaled it becomes 971 with an error of 1.6. The later being obviously much more inaccurate - though it "looks" correct by only looking at the rounded rows.

As Steve's already said in post #2, it's actually better to explain this phenomenon to the recipient. They actually get more accurate results using Revit's default calculation. If they don't want accuracy but only want appearance, then use the special calculated total method as per the work-around in my post #9. And yes, I know a lot of such recipients (especially government types) don't care about true accuracy - appearance is paramount to them: Bureaucracy means paperwork is more important than the physical truth.

[Devin_82]

Sorry, just jumping in a little late here, but I have a solution to the so called "problem" of the rounded values not adding up to the total. BTW, I am 100% against using this method, but I have been overridden by my management in the past where they just don't want to here it from the building department or the client or whoever.

Pretty simple actually, create a new calculated value, called Integer, set it to be an integer type, in the formula field place the formula Area / 1SF. The result is a rounded, unitless number based on the default rounding rules (you can also include the plus.49 trick to force a round up, Area/1SF + .49). Then create another calculated value, Called Area Integer, of the Area type and set the folrmula to be Integer * 1SF. When all of these integerized areas are summed at the end of the schedule they will all add up because you are removing the fractions before summing them up.

Hope this helps, just don't tell anyone it is my fault when they come back and say that the total area is inaccurate... This can create other issues, and you will probably figure them out long enough if you start down this path, but no specific ones are coming to mind right now. Sample size will matter and sorting will potetially cause issues, but this seems a little easier than the solution in post #9. Though i like the flexibility of post #9 in that you can choose the number of decimals to force rounding on, the 2 decimals for example...

[MikeJarosz]

the so called "problem" of the rounded values not adding up to the total....

These people who cannot tolerate slight imperfections in their data don't understand computers or how they calculate. They most likely learned to do their calculations on slide rules, where exact answers are virtually impossible. Funny how toleration disappears when the the "mistake" is made by someone else.

Anyone out there remember the logarithic theory underlying slide rules? I still have my yellow-face aluminum Pickett model, in the original suede leather case. Got me through statics, dynamics, strength of materials and more moments of inertia than I care to remember. And the answers it gave were never accurate. Nevertheless, I passed every course.

[DaveP]

You bet I remember that.
I've been helping my 17 year old with Pre-Calc lately.
Natural Logs, Base 2, Base 10.
She's to the point now where she's learning as a High-School Junior what I did as a College Sophomore!

[irneb]

Pretty simple actually, create a new calculated value, called Integer, set it to be an integer type, in the formula field place the formula Area / 1SF. The result is a rounded, unitless number based on the default rounding rules (you can also include the plus.49 trick to force a round up, Area/1SF + .49). Then create another calculated value, Called Area Integer, of the Area type and set the folrmula to be Integer * 1SF. When all of these integerized areas are summed at the end of the schedule they will all add up because you are removing the fractions before summing them up.Similar to the workaround in my post #9.

Though I'm with you on the inaccuracy. As I've tried to explain in later posts: Doing this round first then total: can lead to huge errors because it's compounding each rounding error for each value. Forcing a round-up is fine if you would rather want to err on the positive side. But as per my example in post #10, the error is already on the positive side - so in that case adding .49 would make for an even greater error.

[Devin_82]

But as per my example in post #10, the error is already on the positive side - so in that case adding .49 would make for an even greater error.

The error isn't always on the positive side, it can be on the negative side as well. For example 10.4+10.4+10.4+10.4=41.6, rounded Revit would show that as 10+10+10+10=42. An example of when you would want all the individual values to force rounding up before summing is when calculating occupant loads for exiting. If you have several different spaces with different occupancy factor gruops exiting into a corridor and you need to verify that the door is wide enough, we want to round up. There are no fractions of people, so we always round up the number in each space or occ factor group. Would the work around in post #9 be able to force round up? I haven't tried it out yet. Good thing about Revit is that there is usually many ways to approach a challenge, so if one solution doesn't do exactly what you want, you can usually find another way to do it.

[MikeJarosz]

There are no fractions of people

You have discovered integer programming.

Integer programming is an operations research technique that allocates resources that cannot be broken into pieces like people or lightbulbs or most manufactured items. Anyone interested should look up the "knapsack problem". I used it once to determine the best combination of elevators for a high rise tower.

[irneb]

There are no fractions of people, so we always round up the number in each space or occ factor group.Good point. Rounding up may be preferable in such cases. Though rounding up simply to get a Gross Area for submission is likely to overestimate the submission costs / levies / etc. in some councils (there are some in my country which use the GA for these calcs, while others don't). Of course the more items in the schedule the more prone it would be to these rounding ... extras (OK let's not call them errors).

You mention space / occ group. Do you mean you combine all occ groups into one item, then round that up? So you're fine with 0.23 of a person inside a particular room, but not when that "partial person" is counted in the "office space". Or am I misunderstanding?

As to the workaround forcing a round up, just change the round to roundup. Note it's actually a "workaround" noted in adesk's tips-n-tricks (I'm not taking credit for it): http://wikihelp.autodesk.com/index.php?title=Revit/enu/Community/Tips_%26_Tricks/Use_Round_function_for_Length_and_Area_parameter

[Devin_82]

You mention space / occ group. Do you mean you combine all occ groups into one item, then round that up? So you're fine with 0.23 of a person inside a particular room, but not when that "partial person" is counted in the "office space". Or am I misunderstanding?[/url]

Sorry for the late reply, busy end of the year...

I had the same question, but the powers that be basically said that it would be overkill and not in keeping with the spirit of the code to which we are trying to comply. The reason we do it sometimes is that we might schedule the individual occupancies of specific spaces in a building that are of the same occupancy group. Since we schedule those values, which are in themselves collections of different spaces that we have lumped together into "leasing" for example, we want to make sure that when we show the total occupants for each occupancy group that the individual numbers documented elsewhere add up correctly. Its a pretty specific example, but its a case when I needed to make it happen.