Set parameter value to elements in a list of lists

Hello Everyone :slight_smile:,
I’m trying to develop a script that calculates the air flow values of air terminals using existing data from a Revit schedule. However, I’m stuck in the last step where I set the parameter values to the elements, which in my case are air terminals. My issue is that the air terminal elements are in a list of lists, and my calculated air flow values aren’t. Is there a way to set the value at index 0 for instance, to all the elements that come under list 0, and the same for the rest of indices? I would appreciate any input.

I don’t quite understand what you are trying to do- but it is probably easier to stick with the model elements (air terminals) and set parameters directly on these elements.

The schedule is just displaying parameters of these model elements (such as air flow )- right ?

1 Like

@nouh0052,

hi,

can you explain further the data structure of your data, specially the node at the of your script. For example, there are more elements than the parameter values going to the Element.SetParameterValuesByName node.

-biboy

Thank you all for your response!

I might’ve not explained properly the idea behind my script. I have an Air Terminal Schedule in my Revit project (have a look at the schedule attached below). In the schedule the air terminals are sorted by space number and are not itemised, in order to get the count number of air terminals per space, and use that to calculate the air flow values using Dynamo.

Therefore in Dynamo, I made the air flow calculation using data from the Revit schedule and then i tried to sort the air terminals coming from All Elements Of Category node by space numbers just to get them in the right order as they are in the schedule. So after having them sorted each list contains the amount of air terminals per space (but in dynamo they are itemised ofcourse). My issue was that i want to apply air flow values into those lists of air terminals. For example, i want to set the air flow value at index 0 (39.84) to all the air teminals that come under list 0 (they are 18 air terminals), and the same for the rest.

I’m not sure if that’s possible, but i was thinking maybe one solution could be to duplicate the number of air flow values according to the amount of air terminals per list, so the indices would match if i use list flatten, although i couldn’t figure out a way to achieve that due to my beginner skills.

But any other ideas that’ll help would be great!

Forget about the Schedule, all the data is in the elements. What your trying to do is read a Schedule containing Air Terminals, then later collecting all the Air Terminals and then think of a way to link there 2 arbitrary lists back together.

Secondly you are sorting the numbers of the Spaces before grouping the Air Terminals, there is a mistake there, your Air Terminals are not sorted the way you want them to. (You are grouping the unsorted Terminals using sorted Keys, the order will be wrong).

The basis of this idea should look something like this (not tested):

Thank you Bjorn for your solution. I haven’t thought of not using the schedules, its brilliant and less complex! I tried to apply your solution however its takes us back to the same issue, where you apply the values to a list of list, which doesnt work unfortunately.

What is the error message?..

Its about list lengths, since the index length doesn’t match in both lists

Which Node is that? From which package?

This should just work with the OOTB Element.SetParameterByName:
https://dictionary.dynamobim.com/2/#/Revit/Elements/Element/Action/SetParameterByName

Are you on a 1.x version of Dynamo?

Makes sense, i was using the wrong node from a package by an accident. This actually solves the problem, however i discovered one issue in the calculation, the formula should be (Outdoor Airflow / Count) rather than (Flow / Count). The outdoor airflow parameter is a space parameter, do you know how to include it in the formula?

I figured it out ! Here’s the final solution :slight_smile:

Picking the wrong Node here seems fairly easy, I also did not spot the difference the first time. Personally I keep Nodes from Packages that mimic the OOTB Nodes to an absolute minimum.

1 remark, the result will be the same in this case but you are doing something potentially dangerous. You are asking for data, then reducing the data (unique values) and then applying that data to a list of elements that has been changed (Grouped here) in the meantime. That means you open yourself up to the same problem you had first where the sorting was wrong. Have a look at the Keys output from the GroupByKey Node.


(And then you can remove the Unique Node.)

This way the data and the elements are being questioned and written back to in the same list structure. Again, same result here, but in more complicated scenario’s something to be mindful of.