Multiple lists - Index of matching values - Faster

Lists-Logic
,
#1

Hello,

I am trying to filter and select a list of elements in Revit through Dynamo. I am filtering this based on the ‘Mark’ parameter, by providing a list of parameter values. I am able to make it work with the scrip below. However, my original project has close to 20,000 elements. When I try to use the same script for that, it takes very long to run. It took 25 mins to select 10,000 elements. Is there a way I can restructure the lists to make it go faster. Any input would be much appreciated. Thank you.

Element Selection Script - 2
Element Selection Script - 21894×1049 85.7 KB

#2

@raj.k If I’ve properly understood, seems like what you are trying needs a relatively direct approach.
In any case its highly unlikely you’ll need List Map anymore

getItems
getItems1666×488 53.6 KB

1 Like
#3

Thank you for the response @Vikram_Subbaiah. However, I am unable to find the node “List.IndexOf”. Is that in a newer version of Dynamo? I am currently using Version 2.0.4.0.

#4

Element Selection Script - 3
Element Selection Script - 31883×1025 67.6 KB

#5

@raj.k You’ll need to show us the output of Element.GetParameterValueByName
IndexOf gives -1 when there is no corresponding element in the list

#6

@Vikram_Subbaiah here is the watch node at Element.GetParameterValueByName. To keep it simple I am trying to get the indices of first 99 elements. I thought maybe the IndexOf node does not accept a list for “Element” input.

Element Selection Script - 4
Element Selection Script - 41802×945 56.1 KB

#7

The list of Marks are most probably strings (the other list mostly comprises of integers)
You can check that with an Object Type node
The string list with numerals can be converted to numbers using the String.ToNumber node (might have a slightly different name in your version of Dynamo)

#8

It feels as if you are going about this in the wrong way if you’re after speed.

I recommend you try reducing the original selection to reduce the compute resources and computational complexity. some thoughts:

  1. Try storing the GUID in the excel file by adding that to the export, and then select the elements by GUID instead of mark - this means you’d have them in a matching order and would only ever get the 300 or so items, as such having the least complexity and likely best speed.

  2. Try filtering out to objects of just a certain type (ie: if you’re working on Doors, Filter our the walls and windows), or using category, family type, or a less robust selection method.

#9

@Vikram_Subbaiah, yes both lists are strings. I ended up using a small python script to filter the index numbers from original list. It works, and has cut down the time significantly (25 min vs 8 mins).

Element Selection Script - 5
Element Selection Script - 52012×1049 79 KB

#10

@JacobSmall Thank you for your suggestion. I will try to implement it.

To give you a background. I am trying to import a large SAP2000 model to Revit through Dynamo. Since Revit assigns it’s own element IDs, I decided to “Mark” the elements with element IDs from SAP2000. This way I could extract a list of elements from SAP2000 and would be able select them in Revit based on the SAP2000 element IDs.

#11

Ah! Dynamo created elements should introduce element binding into the graph, which means you can update the elements by running the same graph a second time (one graph per import per project!). Alternatively you can access the IDs of the created elements for previous runs via the bindings, and export that and the associated ‘Mark’ values to an excel file.

You can then use that excel file to pull the associated elements ID or GUID via the SAP mark.

It’s a pain to reverse engineer but the ‘how to’ can be found in the AU course linked to this thread: Element Binding in Revit

Long term best to create the relationship via exporting the GUID and mark at time of first import (assuming bindings won’t work due to lack of graph/file management).

#12

One approach worth to mention is the use of dictionary. If you store all your mark data in a dictionary prior to the search, and then query from this dictionary it might be faster and it will let you deal with duplicated mark and empty marks as well.

The screenshot below illustrates this :

Dict
Dict1769×612 162 KB

#13

@JacobSmall and @lkichenin thank you for your suggestions. I will study them and see if I can improve the current script to run faster.