Egress Paths

1

Progress I’ve made on a graph to calculate egress paths. Credit to @Dieter_Vermeulen for the head start.

@jacob.small - This is what I’ve been talking about in other threads.

Fire Exit Risk Assessment_Take 47_Mark 47.dyn (320.8 KB)

You’ll need this too – SetIntersection (Any).dyf (7.0 KB)

3 Likes
2

Greg this is a lot to digest, and I mean A LOT. Really good work too. Kudos.

I can see why you’ve got some issues with speed and system resources though. You’re trying to build one graph to do it all. As a result, there are a lot of nodes passing bits of data along many times. You’d be well served to reduce the number of nodes (my understanding is that every time dynamo moves data between nodes it needs RAM) and any outputs on those nodes (again, more outputs = more ram) whenever possible.

It appeared like you had started to build a filter to reduce the number of elements you’re working on at the start of the graph, which I think is a great idea, but as you’re aware efficiency of these calculations is going to be key. Try something like this which will reduce the rooms to the elements associated to the level of the active view:

1144×580 26.4 KB

The codeblock so you don’t have to retype:

List.FirstItem(
	List.FilterByBoolMask(
		rooms,
			Document.Current.ActiveView.GetParameterValueByName(
				"Associated Level"
			)
			==
			rooms.GetParameterValueByName(
				"Level"
			)
	)
);

If you would like I can try to look at other groups of nodes and attempt to make them more efficient when I have time - DD set goes out next week.

3

No problem. It’s my beast to tackle. Any help, at any time, is appreciated.

I did start with a similar filtering method (I think you can see the remnants of it still in the graph) but then I found a test project that had rooms on 2 levels, spaced 18" apart, in the same view and that strategy no longer worked. I figured I’d revisit that after I nailed down the rest. It’s the easiest part to work around. I can always have the user select rooms at the start.

Right now, the biggest killer is when I try and get the intersection of the first set of lines with the surfaces. In the example I mentioned above, most of the space is given over to circulation and I have more than 65,000 lines trying to intersect with a series of surfaces (or merged to one polysurface). I’ve let it run for 30 minutes with no joy. I thought I might try splitting it out into multiple sets of lines per surface and see if that helps. This is the part of the graph where I was looking to use a Python or C# node.

I’m doing it all in one graph primarily because I don’t know how to split it up into multiple graphs. I’m modifying the output from the room boundaries right away so I’d need some way to store that information for a future run. Considering where the graph slows down, however, I’m not sure it matters much.

I may still want to break the graph at some point to show the user how the graph is breaking up the space. Depending on how you model the room bounding elements, particularly where 2 rooms meet at an opening not defined by a door, you may get inaccurate results. I think it will be important to show the user what Dynamo will be using for its analysis so they can modify the model to suit their needs.