RIR very slow/crashing in Revit 2021

Rhino.Inside Revit
1

Hi

This issue has been reported before here and here but every time I drop a component on the canvas, it is like the whole script gets re-executed. This happens even with a native GH component and not even connected to anything. The file becomes basically unusable.

The only thing I can think of is that somehow one of the inputs is listening to changes in the GH file (not just the Revit file). Could this be happening?

image
image1273×553 99.7 KB

I know in Dynamo collecting all elements of a category can cause an infinite loop. Not sure if sometime similar is happening here. Does Query Elements re-execture if new GH components are added to the canvas?

Turning off the Revit preview seems to help but adding a native, unconnected GH component shouldn’t actually affect the Revit preview.

2

Are the Grasshopper Autosaves disabled?

Is it possible to bundle this together and send to our team? file upload

Is there any large internalized data in the definition??

3

I have similar issue when working with large rvt files. It seems that grasshopper preview in Rvt slows down the process. So it starts to recalculate it every time i drop down component in GH. Opening Project Information sheet as an active viewport in Revit solves the issue for me (so no geometry preview is visible in Rvt.

4

M Onopko, The first thing i do when opening up a new instance of Rhino.Inside.Revit is turn off the preview, which is a habit i’ve taken from working in grasshopper. I typically work in wireframe, turn layers off for dims, text etc. in Rhino on large projects as well.

Not saying there might not be an issue with a component but realistically you have to take counter measures when working with large projects & be aware of what is driving file sizes and slowness.

5

Hi @parametricmonkey1,

There is a bug on ‘Element Parameter’ component, but let me explain what happens here.

I’m sure your document is more complex than that but this one is enough to reproduce the problem you descrive.

image
image1920×1133 148 KB

This definition takes all walls in a model and increase by 200mm its ‘Unconnected Height’. That means that each time it runs it needs to run completly from left to right side, taking the previous value, computing the new one and assigning it to the wall.

Left side is only reading from the Document, those components that are not black will never provoque this, but on the right side we have a component that is modifying the document, and is modifying the document in a way that the left side needs to be refreshed.

On the status bar is telling us that two objects will be expired on the next solution because of that. ‘Query Walls’ and ‘Element Parameter’ show a white ballon telling the same thing to help you identify the objects that contain obsolete data. ‘Element Parameter’ contains the previous height and will be refreshed.

This never happens in regular Grashopper definitions, unless you use ‘Bake Geometry’ an reference that baked geometry as an input. Grasshopper don’t use to modify the Rhino document, so inputs are stable during several solutions, until the user modify the Rhino document manually.

Now the bug.
Your definition looks more like this, but with a False in your case, but a stable value on both cases.

image
image1920×1133 141 KB

In this case the first time you connect the 200 slider it will update all walls height, will expire again the left side, but the next time, and here is the bug, ‘Element Parameter’ should not update those walls because all already have the expected height. This breaks the loop and the document becomes stable and “fast” again. No white ballons and no message on the status bar.

The bug is that ‘Element Parameter’ is not checking before assigning a new value to break that loop. We do that kind of validation on other components but I forgot the most obvious one :smiley:.

It’s fixed now. Thanks for reporting.
You can test it now on the ‘Daily Channel’ or next Tuesday on the ‘Release Candidate’ Channel.

1 Like
6

@kike I’ve installed the latest daily build and replace the components but am still having issues. I’m trying to troubleshoot more to find where the problem is happening.

One thing I did notice is that the element parameter node is considerably slow. For 3373 rooms it is taking 13 sec to query a single parameter. Is this normal?

image
image1802×554 128 KB

I tried creating filters but RIR didn’t like that is was text, wanted me to use BIP instead.

7

@kike Ok so I’ve done some more testing.

Element parameter component
I managed to get the filters to work which speeds things up. However the slowness I reported with the Element Parameter notes relates to Key Schedule Parameters. It takes about x4 longer than a standard project/shared parameter. Not sure why it is so slow and if there is a filter that will work with Key Schedule Parameters?

Components refreshing
I am still getting components re-triggering when an unconnected component is placed on the canvas. The element parameter component doesn’t seem to be the problem (anymore). All of these components I replaced just to be sure.

From my tests it looks as through it is the Element geometry component. (see here for possibly a related problem). Basically as soon as I have the element geometry component active and place a panel on the canvas (unconnected) the cursor wheel spins.

This was happening before and now when I’ve gone back to re-test, it isn’t happening. I’m wondering if it is the graphical element node. When I re-open the Revit file, I get an error message saying it can’t find the element reference. Not sure why it does this or if I am doing something wrong.

image
image1327×753 51 KB

But what eventuates is a list of nulls coming out of the component. Does te graphic element node re-execture when a new component is placed on the canvas?

The Revit preview also seems to cause this issue.

8

So the Key Parameter is causing the slowdown, thanks for finding this, probably due to the nesting inherent in Key Parameters.

Components refreshing

I’ve always been in the habit of disabling components that i don’t want refreshed, then enabling as needed, or creating stream gates. Ideally this can be remedied by requiring the user to manually refresh the definitions or optionally keep them constantly talking to Revit. Similar to how the Elefront handles referenced Rhino Geometry, granted Revit is more complex in this regard.

image
image537×439 18.2 KB

image
image922×464 41.6 KB

9

The group at the top uses ‘Text Begins Rule’ instead of doing a ‘Match Text’ on each Room. This should speedup the query.

The second group pick a list of Keys from the schedule and filters by “Key Name”. This should be a bit faster than the previous one.
Is not working on 1.0 but will on 1.1.

image
image1560×640 79 KB

The only thing that may fire up a new solution is a change on the Revit model, I don’t see any black component on your screenshot. Do you have any warning on the status bar that tells you about objects will be expired?
Click on the status bar to clear the warnings, to be sure the warning happens when you do not expect it.

About the deserialization message, do you know how to reproduce this?

10

@kike so the Grasshopper preview (wire and shaded) is definitely contributing to the issue. When these are activated, it seems that any change on the GH canvas triggers a refresh. So if I add an unconnected panel that has absolutely nothing to do with Revit, Grasshopper freezes until the preview has finished.

image
image1493×227 39 KB

11

@kike Could the Duplicate Type be re-executing somehow? I also have this part in the script:

filled region
filled region2303×434 87.4 KB

If you look at the video, adding a panel temp freezes Grasshopper. Disabling Duplicate Type component solves the problem. Not sure if it is this node or something upstream because the document is changing. Tracking is set to update

12

Hi,

We did some changes on the upcoming Release Candidate that will be published today. It hopefully alleviate this problem.

You can switch to “Release Candidates” channel from the Options dialog and test it now if you like.

image
image864×1156 77.4 KB

Keep in mind that files you save with a Release Candidate version may not open on a previous version, so please do backups of your files.

13

@kike I don’t see any release candidates, only a daily build. Did this get published?

Also, are there any release notes? This will help me troubleshoot the issue.

14

Yes it should be public now.

Does not Rhino.Inside notify you about this if you switch to Release Candidate channel?

Release notes are here.

Disabled expiring objects when a Revit document change comes from Grasshopper itself.

Daily channel should include this as many other things like components to manage Worksets and new things that will come on 1.2.

15

Nope. No notification on the Release Candidate. Wondering if this is due to me having a high version from the Daily Build installed?

image
image938×662 18.6 KB

16

Totally possible. I should check this.

But the fix should be on the last Daily Channel as well.

17

Thanks, Japhy, great advice, will also implement that habit into my workflow!

18

@kike there seems to be an issue with the Element Parameter components again. When quering a standard parameter, it returns the value as expected. But when querying a Key Schedule Parameters, I don’t get values, I get rooms.

image
image1503×762 204 KB

19

@parametricmonkey1,

What value do you expect?

Maybe the name of the element is returned?

20

I would expect the value of the parameter, no? Is there a reason this wouldn’t be the case?