The Level.Elevation node seems to randomly report wrong elevation value. Tested on several models including a black OOTB template. The error appears @ the 10th decimal. ie: a level of 3950 is being reported as 3949.9999999992 (See attached GIF)
It works fine if I changing elevation value or nudging the level forth and back then rerun the graph…any ideas why would the node do this? (Rivit 2022.1.3 + DR 2.12
Dynamo could be right. The elevation is reporting a rounded number based on project settings. Revit also doesn’t like to move things 0.0000001. I’m sure you’ve seen the message box “Element is too small on screen”. I’d use Revit Lookup to check what the value of the level really is under the hood.
This is because computers don’t do math the way we do, but instead use floating point math to do their work. As such all values can be off by such a rounding error. All computers work this way. in fact if you’d like an example you can search 3950 - 3949.9999999992 in Google. I got 7.9990059e-10 which is further degrees of accuracy off. Pretty much all computers work this way, and as programmers we have to learn how to resolve it.
You can learn more about the way floating point works here: Knowing what can trigger floating point issues and why it happens is good too know. My personal favorite explanation is this one: how floating point works - YouTube.
Fortunately the actual distance you’re off is minimal (0.0000000008 miles is about 70% of the length of a mitochondrion, and if you’re using a building scale unit such as feet or meters you’ll be orders of magnitude smaller then that), but unfortunately you might need the real value. Rounding to the 6th digit will usually suffice to resolve this stuff, which is part of what Revit is doing in almost any form of UI display.
These are newly placed levels using Offset and NO Decimals…this occures no matter what the Project Unit pricision setting are.
Entering an offset value should not be less accurate than Entering/Re-entering the value in the parameter (or nudging the level up and down) to force Dynamo to update!!! Something is defintly wrong here, either with Dynamo or with Revit (Offset value vs Direct input into Parameter)
Hi Jacob,
I would gladly accept that if the behavior in Dynamo would have been consistant. The thing is, it only decides to use the floating point error if I place the datum in Revit usint Offset… If I input the value in the elevation parameter dynamo seems to have no issues!!
I figured I should round the figures anyway in Dynamo but something is definit off about this (making me feel the Offset function in Revit is bugged?)
It is consistent, the offset method in Revit (or perhaps the level being offset) is introducing a different floating point issue which is being suppressed in Revit.
To elaborate: you think you’re offsetting from 0 by 3500. But what is actually happening is “something like 0” is being offset by “something like 3500”, resulting in a value of “something like something like 3500”. Revit is handling those something likes for you; Dynamo (and really any calculator) does not.
I’m guessing you’re working in MM; interestingly that is where floating point most frequently shows up, as the numbers get really big really quick. Offsetting something like 0 by something like 3.5 gets you something like something like 3.5, which is more often reported correctly. Working in native Revit units (decimal feet, which no one uses for anything in building design or construction) also helps.