Revit Architecture Forum
Welcome to Autodesk’s Revit Architecture Forums. Share your knowledge, ask questions, and explore popular Revit Architecture topics.
abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

Revit Family Calculated Value Accuracy Issues

15 ANTWORTEN 15
GELÖST
Antworten
Nachricht 1 von 16
tjones1410
2169 Aufrufe, 15 Antworten

Revit Family Calculated Value Accuracy Issues

Because someone will ask, the information below is based upon Revit version 20.2.30.45, 20200826_1250(x64), 2020.2.3.

 

Revit appears to apply different methods of rounding/precision based upon the type designation of the number.  A parameter set to Length with a value of 0.2 inches returns a different value when included in a formula that changes the unit type from Length to Number.  Regardless of the units used, the math should be consistent, but it isn't.

 

Unit Type, Parameter Name = Value

Length (Type System Parameter), Width = 3' - 0"

Length (Type Shared Parameter), Clear Width Adjustment = 2.25 in.

Length (Instance Shared Parameter), Width Per Occupant = 0.20 in.

 

The following formula (Unit type = Number calculated value) based upon the above parameter values and unit types results in an incorrect value as the Width Per Occupant value is apparently converted to a length fractional value and then back to a number unit prior to the formula being resolved.

 

Allowable Occupant Load = (Width - Clear Width Adjustment) / Width Per Occupant

 

Result = 169.411765 instead of 168.75.  I assume the six decimal place accuracy is inherent to Revit as I left the formatting unit type set to General for the resulting value.

 

Using the Number unit type and the calculated value formula Width Per Occupant / 1" resulted in the value 0.199219.  Given the original input was 0.20 in, the result should have been the unitless 0.20.

 

I note that the instance shared parameter Width Per Occupant displays as 0' 0 51/256" in the properties box when assigned to a Revit door family inside the project model.  Dividing 51/256 = 0.199219.  I therefore conclude that Revit's internal calculations are erroneously applying a unit display format rather than retaining the original value when used in a Revit family calculated value that changes the unit type.

 

Inconsistently, displaying the original Width Per Occupant parameter value in Decimal Inches format using the Length unit type results in the value 0.20 in which matches the original input.

 

The ridiculous work-around is to multiply the the Width Per Occupant value by a value of 100 (moving the decimal point based upon the original input precision of two decimal places), using the "round" function which basically restores it to its original input value, and then dividing by 100 again to move the decimal point back to its original location.

 

The following formula (Number type units) then results in a correct calculated value identifying the number of occupants the clear width can support:

 

rounddown(((Width - Clear Width Adjustment) / 0' 1") / (round((Width Per Occupant * 100) / 0' 1") / 100))

 

This isn't the only aberrant mathematical behavior I've come across in Revit when converting between unit types using formulas.  However this one just seems blatantly wrong.  Please tell me this is not working as intended and may be fixed in future releases!

 

It seems to me unit display formatting should always be applied only when the value is actually displayed and the original input value's integrity always retained until purposefully altered.

15 ANTWORTEN 15
Nachricht 2 von 16
Alfredo_Medina
als Antwort auf: tjones1410

It´s because we use this awkward feet and inches measurement system in the US. If all distances were decimal, you wouldn´t see that problem. However, I don´t think is a Revit-related problem. Other software might give the same results. The process that you described is the same that I have had to do with my exit door tags for life safety. You need to convert to decimals, and use roundup functions to get consistent results. Not to much of a problem, in my opinion. 


Alfredo Medina _________________________________________________________________ ______
Licensed Architect (Florida) | Freelance Instructor | Profile on Linkedin
Nachricht 3 von 16
tjones1410
als Antwort auf: Alfredo_Medina

I think you've missed the point.  The issue isn't having to convert units.  The issue is that 0.20 inches should still be 0.20 when converted to a unitless value.  Revit equates 0.20 inches to a 0.199219 unitless value.  Whatever the fractional representation of 0.20 inches looks like, when its shown as decimal inches it should still be 0.20 inches.

Nachricht 4 von 16
HVAC-Novice
als Antwort auf: tjones1410

I assume Revit is metric and converts Feet to metric units... calculates, rounds etc., and then converts back to imperial units for the US users. 

 

Same is true for most computer systems. Like a building automation system that uses °F only uses °F on the surface, but internally is metric and it exhibits similar odd rounding for the imperial user. Same way a 3.5" floppy disc is only approximately 3.5", but exactly 90mm

Revit version: R2025.4
Nachricht 5 von 16
ToanDN
als Antwort auf: tjones1410

No issues here.  See attached 2019 file.

ToanDN_0-1616622162959.png

 

Nachricht 6 von 16
Alfredo_Medina
als Antwort auf: tjones1410

I did not miss your point. You have to set the formatting units of the parameter to 2 decimal units, so that instead of 0.199219.... you get 0.2


Alfredo Medina _________________________________________________________________ ______
Licensed Architect (Florida) | Freelance Instructor | Profile on Linkedin
Nachricht 7 von 16
tjones1410
als Antwort auf: ToanDN

Thanks for the example file and testing in 2019.  There is some extreme weirdness going on here.  I exported your shared parameters to a new shared parameter file.  I opened your file in Revit 2020 and then created two new shared parameters of the same type with an "x" in front of the parameter name.  I then created a separate door tag using the new x-parameters.  Your tag calc seems to work.  My tag calc gives me the wrong numbers.  Both tags appear to be set up in exactly the same way.  I can't figure out why yours does the calc as expected and mine modifies the Width Per Occupant value from its original entry of 0.2" to 0.199219.  Note the occupant load calculated value is incorrect because of it in my tag.

tjones1410_0-1616683845926.png

Revit 2020 file attached.

 

Nachricht 8 von 16
tjones1410
als Antwort auf: ToanDN

And same thing in Revit 2019.  Created a new door tag.  Added the x-params.  Same result.  Revit 2019 file attached.

tjones1410_0-1616685360422.png

How is this possible?

Nachricht 9 von 16
FAIR59
als Antwort auf: tjones1410

It isn't about the tag definition. With fractional inches, you can't  get to a decimal value of 0.2.

These are the values in the database 

FractionalFeet_01.PNGFractionalFeet_02.PNG

To get the correct value:

Change the ProjectUnits for Length to [ Decimal Feet ] , change the value to 0.20", and change the ProjectUnits for Length back to [ Feet and FractionalInches ].

Nachricht 10 von 16
tjones1410
als Antwort auf: FAIR59

Interesting.  Your screenshot shows an entry value for Width Per Occupant = 0.199, but my screenshot shows the entry value as 0.20.  If you change that entry value to 0.20" does it correct the calculation?

 

Please note that both those tags are in the same file and using shared parameters with exactly the same definition but different names.  The data entry in my file for Width Per Occupant for both tags was entered as 0.2".  The left tag in your screenshot shows the correct irrational number representing 0.2/12 = 0.016667 (rounded up).    Your screenshot for the tag on the right shows the irrational number for date entry = 0.199".  The tag on the right shows the result of 51/256/12 = 0.016602 (rounded up).  51/256" is the best Revit can do to represent 0.20" as a fractional value.

 

The screenshots for both tags indicates that they have Project Units Length are set to Feet and fractional inches.

 

Regardless of the Project Units setting, the values should match given the same data entry.  However, it does appear that there must be something different about your version of Revit vs. mine as it apparently changed the data entry value to 0.199" instead of 0.20" when you opened the file.

 

To be clear, the value was entered as decimal inches not fractional.

Nachricht 11 von 16
tjones1410
als Antwort auf: FAIR59

Changing the Project Units to Decimal Feet and then making the entry also resulted in incorrect values.  Changing the Project Units to Decimal Inches did result in the correct values.  0.20" remained 0.20" when entered as .2".

 

However it is unreasonable to expect the average Reviteer to remember to change the Project Units before entering data and then back again.  I still maintain this is a flaw in the general Revit programming.

 

The other weird bit is once the value has been entered correctly by the above method, re-entering the same value after the Project Units have been changed back to Feet and fractional inches retains the correct value of 0.20".  It's only the initial data entry that is flawed.  Also, copying a door with correct value (or incorrect value) retains the state of that value if .2" is re-entered.  However changing the value to anything else and back again by entering .2" results in the original behavior of changing the value to .199".

tjones1410_0-1616764508668.png

 

 

Nachricht 12 von 16
FAIR59
als Antwort auf: tjones1410

I agree that limiting the input-values to the rounding of the Unit-format is a flaw, though probably an intentional one.

The work-around would be to set the rounding of the [ width per occupant ] parameter in the tag to 6 decimals. Then you can use the tag to input the correct value ( no switching of Project-Units required ) 

Nachricht 13 von 16
tjones1410
als Antwort auf: FAIR59

After giving it a think, I believe the simple solution is to set define the Width Per Occupant shared parameter as a Number type instead of a Length.  This eliminates any ambiguity in the use of that value other than unit type and eliminates the need for mathematical gymnastics.

 

Thanks all for your thoughts!

Nachricht 14 von 16
Alfredo_Medina
als Antwort auf: tjones1410

Whatever gymnastics you have to do to get it right inside the family editor, that's fine, as long as the end result on drawings is always correct. It does not matter if internally you have to use number or length format, or 2 decimals or more, or multiply or divide by other units, as long as the end result is correct when the building official reviews the drawings for life safety. 


Alfredo Medina _________________________________________________________________ ______
Licensed Architect (Florida) | Freelance Instructor | Profile on Linkedin
Nachricht 15 von 16
tjones1410
als Antwort auf: tjones1410

I came across an old Revit symbol annotation family data block that I had created several years ago that also used the Length type parameter for the Allowable Width Per Occupant value.  I discovered that the loss of data integrity occurs if the data entry is done in the Properties box vs. clicking on the value in the symbol and making the entry there.

Data entered by clicking on symbol = 0.2".

tjones1410_0-1617283052699.png

Data value entered in Properties box while element is selected as 0.2".  (Note the value must be different than that already entered for the anomaly to occur.  For example change the valve to 0.15" and then to 0.2".  If the value is 0.2" to begin with it remains 0.2".)

tjones1410_1-1617283138988.png

Revit 2018 properties box

tjones1410_2-1617283350301.png

Revit 2018 family file attached.

This is definitely aberrant and inconsistent behavior  with respect to data entry in Revit and should be addressed in future releases in my opinion.

 

Nachricht 16 von 16
delie
als Antwort auf: FAIR59

Hi, how did you reach this area, I need it to work under family parameters at least for constant or numbers (no units)

Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.

In Foren veröffentlichen  

Autodesk Design & Make Report