List.GetItemAtIndex from Count, Range or Sequence

I’m working on a life safety occupancy calculation graph and this section is splitting out unique names of each occupancy use for filtering down the line. I’m trying to get rid of the manual Code Block 1-6 and somehow substitute it with a generated list based on the Count as there may be 6, 8 or 15 depending on the project. As it stands I can continue this logic for 15 or 20 alternate uses, but it seems redundant and I’m likely missing some logic to simplify.


I saw another post about List.AllIndicesOf, but couldn’t figure out how to work it in.

Not entirely sure what the question is really attempting here, how you’re using the data, or what you’re after… you already have a 1 dimensional list, and can query and manipulate the elements in that list - that is to say you have what you need, just get all parameter values and make all the desired calculations in one go. Don’t complicate things unless you have to.

On a related note, last weekend my team at the Beyond AEC Hackathon took home “best cross discipline hack” for a custom workflow we built specifically for life safety stuff. I’m almost caught up on sleep. I’ll be posting the info about the first half of the workflow sometime soon, perhaps this weekend, but likely will be two or three weekends until I find the time to clean up, document, and organize everything. I’ve got some busy weekends these next few weeks - life is getting in the way of my hobby of doing more work than I get paid for. Shoot me a PM if you’d like to know anything more before I manage to organize the post.

1 Like

@nickroz The workflow seems flawed.
Rather than attempt to address the issue you’ve outlined, I’d suggest that you elaborate on the desired final result of the exercise.

1 Like

@Vikram_Subbaiah @jacob.small We’re taking each floor’s areas per smoke compartment (healthcare) and filtering by each primary use (string). Then we want to sum the area of each primary use, divide by the occupant load factor (area per occupant), and round that number up to the nearest integer. We then want to divide that integer by the count of areas per primary use (per smoke compartment) and pipe that decimal number back into a parameter in the area itself so we can total it in a Revit schedule and avoid the built-in roundup() function.

Names of each Primary Use could vary project to project as some teams may modify their key schedule, so we need a flexible way to pull strings from a unique list of what’s actually in use in that project.

@nickroz Kindly create a small Revit file with some/all of the elements and parameters outlined above.
This would help others understand your problem better while also providing a base for others to provide you with suggestions/solutions.

1 Like

Maybe I’ve misunderstood what you’re asking for, like the guys say its difficult without context, but If your looking to simplify getting items at an index you can use the following code block or nodes

list = “A”…“Z”;
count = List.Count(list);
minus1 = count - 1;
index = 0…minus1;
range = list[index];
//node = List.GetItemAtIndex(list, index);
//(“A”…“Z”)[0…25];

Area per smoke compartment is something we didn’t touch on, and I admittedly don’t know much about it. The workflow we built was centered around rooms being assigned a use, calculating their occupant load based on the associated occupant load factor, and calculating the result. The code block I posted above did all this math for you. I don’t agree that the name of primary use should ever vary - the building code only gives you so many options to chose from, and you have to stick to them to be compliant. You just have to build them all in at the beginning - you may not need a residential use today, but you may in the future, so build it in anyway.

Once you have the occupancy of the rooms, I can see a few ways to work smoke compartmentation into this, but the all hinge on this question: What are you using to track the area and extents of the smoke compartments? I’d reccomend an area element as you can then grab all rooms contained in the area, and sum the total occupants based on that, and tally the count for each type of use. Assign those values to a parameter so you can re-work the math in the future, and do your math with those values (still in Dynamo).

@jacob.small I don’t have my graph working for smoke compartments yet, but it acts like a building within a building, so it just adds one level of nesting. We use a “Smoke Compartment” text parameter assigned to the areas to sort/filter them in our schedules. Our corporate life safety process currently only uses areas, not rooms.

I don’t agree that the Primary Use name should ever vary either, but our company (corporate) template only bakes in the following, so people get creative with the naming/formatting of the additional ones.
template

@Vikram_Subbaiah See attached RVT (2016) and Dynamo 1.3 script that requires Clockwork. It currently works for areas without taking into account smoke compartments (next step).
WIP_LifeSafety_v1.3.0.dyn (336.4 KB)
Area_LS_Example.rvt (424 KB)

As you can see the graph is a bit long in the tooth as I designed it for 20 Primary Uses. I’m hoping that something like the graph from @adam_bear1 could assist to reduce the far right blue/green groups that are currently duplicated 20 times.

Understatement of the year! Lots happening there. It helps to be able to see the scope and understand what you’re up to better now. I’ll take some time tomorrow night to see what I can come up with. No promises but I have some ideas brewing around a pair of defined functions for the blueish and green nodes, storing some more data in the areas themselves so you can pull more and look up less, and a List.GroupByKey node.

Any chance the higherups would respond to a reccomend change to the template? It’s missing a lot. Like a lot a lot. Even for the stuff you have you are missing allowable travel distance, common path, separation from adjacent occupancies, etc. All of this varies by use.

@jacob.small Thanks for taking the time to review. It seems like I could consolidate the blue/green portion with some type of while loop that can dig through the list of Primary Uses and do math for each until no more Uses exist. Not sure how to compile that in Dynamo yet though.

Regarding the template, I’m taking small steps to get it more functional for our projects. Headquarters is on their own path with the template updates, but our current system isn’t calculating occupants correctly, so that’s the first hurdle. I’m considering having the Dynamo script load in a more thorough key schedule to the project before it runs, but that’s for another post.

@nickroz See if this works.
WIP_LifeSafety_Vik.dyn (23.2 KB)

This is the graph …

Revit schedule …
20170922-9b

3 Likes

Thanks @Vikram_Subbaiah - that’s one hell of a simplification! I guess I need to read up further on list structure and digging through levels.

The division calcs were slightly off but reverse engineered your solution and added a couple of nodes to get the calculation working for smoke compartments on multiple levels. See attached and let me know if there’s anything I can do to simplify further.

Area_LS_Example.rvt (456 KB)
WIP_LifeSafety_Vik_edit_v1.3.0.dyn (37.4 KB)


It still chokes on non-placed areas as they produce nulls, so I may need to add another filter to the beginning to remove them.

Thanks again. @jacob.small

1 Like

Step 1 on almost anything which involves rooms, areas, or spaces should be to filter out any unplaced (or better yet delete them which is good modeling practice anyway). Best to do this filtering by asking if the area is greater than zero and filtering out the unplaced. :slight_smile:

Well organized and executed graph Vikram! The levels and lacing are poetically simple! :smile:

1 Like

The 0 filter is in there, but I’ll try adding a string filter for Not Placed.

EDIT: The 0 == node didn’t work, so I replaced it with a code block with x == ""; and now it gets rid of the nulls.

2 Likes

When you find yourself doing something repetitive, you can be sure there is a better way.

Took a quick look and it seems pretty good.

Thanks @Vikram_Subbaiah.

1 Like

Found an issue where the occupant calc (Math.Ceiling) would erroneously round up if the division came out to an even number (integer). Added in this logic test to eliminate that problem.