|
Forums >> Revit Building >> Technical Support >> Schedule totals are not calculated right: 1+1=1
|
|
|
active
Joined: Mon, Oct 2, 2006
5 Posts
No Rating |
When gross area value is set to be rounded to nearest 1.0, Revit still calculate values as exact values. As an example we can get quite strange results: 101 sqm+101 sqm = 201 sqm if exact values are 100.5 sqm + 100.5 sqm = 201.0 sqm We have to present every level gross area total rounded to the nearest 1 sqm (there cannot be decimals). We have to also present grand total for gross area which is calculated from rounded level totals. So if we have several levels in a house schedule grand total can be several sqm wrong. We have several other schedules where we also have to present grand totals that are calculated from rounded values. In my point of view Revit schedules should at least have an option to calculate totals from rounded values if rounded values are used. At the moment we cannot use schedules for calculating areas. As a workaround we have to export schedule to excel for getting accurate totals. We have at the moment 6 Revit Series workstations in our office.
|
This user is offline |
|
 |
|
|
|
active
Joined: Sun, Nov 27, 2005
298 Posts
 |
it sounds like you want to be able to fudge the actual area. If I understand, you have 101.5+101.5=203 and you want it to round to 102+102=104. The reality is you only have 203. I would just explane the nature of the rounding issues. Show the total as accurate as possible.
-----------------------------------
BallewDesigns.com |
This user is offline |
View Website
|
|
|
active
Joined: Mon, Oct 2, 2006
5 Posts
No Rating |
Yes, you got it right. I want 102+102=204. Our legislation requires architects to present gross areas without decimals and calculate totals from them. If total of 1+1+1+1+1+1 is 3 instead of 6 bureaucrats will have something to say... Yes, I understand that it's great that schedules are accurate, but it's not accurate if user want to get results from rounded values. All I want to say is that Revit should also have an OPTION to calculate rounded values as they are.We got feedback from a contractor that received an area schedule. They didn't like that the grand total of area schedule differs several sqm from what he gets from adding presented room areas. They also wanted 1+1 to be 2. With material schedules accuracy is a good thing though... Hope you got my point. My english is not too good ;-)
|
This user is offline |
|
|
|
active
Joined: Sun, Nov 27, 2005
298 Posts
|
I get the idea. The end result can't be that far off or you will get in real issues. If you have 100 rooms and each room is rounded by .5 s.f. then you will be off by 50 s.f. the way you want it to work. The larger the project to less accurate you will be. I would add a note to the schedule that states the issue. "All values are rounded to the nearest whole number. Totals do not reflect addition of rounded values, total reflects unrounded areas with result rounded to the nearest whole number." Seems like the most honest way to look at it.
-----------------------------------
BallewDesigns.com |
This user is offline |
View Website
|
|
|
active
Joined: Mon, Oct 2, 2006
5 Posts
No Rating |
Sadly our legislation doesn't care about honesty  If we put Revit area schedule with round off values in drawing sheet and there is 1 square meter difference in totals we have to change it by hand. We cannot use Revit schedules in our drawings because they do not meet the requirements of the Finnish law. Again, if something is presented with round off values there should be an OPTION to sum those round off values. Doesn't round off mean round OFF. Now we have to export schedules to Excel and do it there, this is not practical nor wise, but it's the only way at the moment. I was told by Autodesk representative in Finland that this is a problem in Norway also. Don't get me wrong - I like Revit a lot. I just would like to minimize the possibility of errors. I think this feature is easier to add to Revit than it's to change laws.
|
This user is offline |
|
|
|
active
Joined: Mon, Mar 20, 2006
219 Posts
 |
This is the issue that I was searching for the answer to because I am having a similar problem...just bumping it back up to see if anyone has figured it out. We have an occupancy load schedule that calculates the occupancy of each room. It is the area of the room divided by the area per person (by code) and ROUNDED UP because (by code) a fraction of a person is a whole person. When we grand total our Occ Load for every room the total we are getting does not add up to the rounded (integerized) numbers, but the nearest, predeanthrofractionalizational numbers. It hasn't been an issue until now...when this small issue happens to makes a difference (plumbing fixture counts, etc.)
|
This user is offline |
|
|
|
active
Joined: Sun, Jun 24, 2007
592 Posts
|
Boy oh boy you guys are going to love this workaround. First off this shouldn't rely on rounding at all so it doesn't matter what things are set to for rounding. Make a room/area schedule as you always have. make sure that it has area as a scheduled field. (and name and whatever else you need.) OKay so I'm assuming this is where your totals don't match the rounded numbers added together. Now: Create a calculated value and call it area integer. it should be a formula, common, integer in the formula field put (Area + 0.49 SF) / 1 SF hit okay. now create another calculated value. call it area rounded. select formula,common,area in the formula field put (area integer) * 1 SF hit okay now: under sorting/grouping make sure to itemize every instance and show grand totals under formatting hide Area and area integer. for area rounded select calculate totals and change the heading to Area hit okay. hit okay. look like a bada$$. should work (change sf to m for metric)
-----------------------------------
I like scooters. and motorcycles. |
This user is offline |
|
|
|
active
Joined: Sun, Jun 24, 2007
592 Posts
|
Oh also remove the .49sf if you want the nearest whole number and not the always rounded up whole number. this was sort of a combination of the two questions but works for both.
-----------------------------------
I like scooters. and motorcycles. |
This user is offline |
|
|
|
active
Joined: Mon, Mar 20, 2006
219 Posts
|
We are rounding up by doing integered .49 add right now, but aren't integerizing the area. I guess that's what makes it "work"? Doesn't integerizing the area just do the same thing accuaracy-wise, just earlier in the calculation so that it is just better hidden? I guess this works to make everything look correct, but you still have the inaccuracy: For instance: Room is 200.4sf and the code says it's 20 sf/person. 200.4 becomes 200 divides by 20 to get 10...add.49 to get 10.49 and it integers back to 10 people. Now it shows as 10 and (if you are correct) no messy decimal places get figured into the grand total. The problem is that 200.4sf should report 11 people. The way that we are doing it shows the 11 people, but the grand total runs the risk of losing that extra person from the calculated total. Your workaround just loses them early enough that they aren't as obviously missing. I like the idea, though. It serves a purpose.
|
This user is offline |
|
|
|
active
Joined: Sun, Jun 24, 2007
592 Posts
|
for that it would be 200.4/20=10.02+.49=10.51 integered = 11 the second step is required to get the units back on (because integer drops the sq ft or people or whatever your unit is) and is so far removed from the rounding that you don't get the error in adding rounded units. it works. perfectly.
-----------------------------------
I like scooters. and motorcycles. |
This user is offline |
|
|
|
|
|
active
Joined: Sun, Jun 24, 2007
592 Posts
|
oh the area example is for the OP. Yours would be the same theory.
-----------------------------------
I like scooters. and motorcycles. |
This user is offline |
|
|
|
active
Joined: Mon, Mar 20, 2006
219 Posts
|
Your suggestion does what I need. I'll have to test my theory about the accuracy later...I think it still holds, but nobody in any code capacity would be able to tell. Thanks for the help rider.
|
This user is offline |
|
|
|
active
Joined: Sun, Jun 24, 2007
592 Posts
|
if you want more accuracy you just have to put .4999999999999999999999999999999999999999999999 more 9's then the amounts of digits revit calculates (i think it does 32 decimal places?)
-----------------------------------
I like scooters. and motorcycles. |
This user is offline |
|
|
|
active
Joined: Mon, Mar 20, 2006
219 Posts
|
that's not where i'm talking about the inaccuracy being, but for the record we do use .4999 because you can't go more than four decimal places without Revit getting upset with you....in these calculated value parameters anyway (we got errors with anything longer), but we haven't rechecked this since we set this up in version 8.
Edited on: Wed, Jul 23, 2008 at 12:22:59 PM
|
This user is offline |
|
|
|
active
Joined: Sun, Jun 24, 2007
592 Posts
|
We'll if you do find whatever innaccuracy your talking about (i think i lost you) let me know. I haven't found any problems with this method,but if I can improve it, i'm all for it.
-----------------------------------
I like scooters. and motorcycles. |
This user is offline |
|
|
|
Search