topic Re: Connector Neighbours in Revit API Forum

Connector Neighbours

Anonymous — Mon, 26 Feb 2018 21:42:31 GMT

Hello Revit API Forum,

I was working on a script last week to run QA checks on systems to make sure everything is kosher. This was my first introduction to Connectors which seems like a pretty powerful system.

It started to give me some ideas for other Connector uses regarding mechanical systems. I was hoping to be able to do something like the following:

Get an element

Get it's connectors

Find the connector ends

use the ends to "climb" down the system branch by finding the neighbouring element and repeating the process

The issues that have been arising are the following:

An element can have more than two ends

I'm not sure hot to get a reference to a neighbouring element using connected Connectors

branching through systems in this fashion could cause you to essentially get lost in the branches unless you map N number of forks.

The direction of the connectors are often bi directional, so how does one know you're progressing in the correct direction even if you could get the neighbours?

Essentially if you wanted to grab piece A on a duct, and iterate through the neighbouring ducts to Piece B, what would be the correct method to do this? You don't have to get super detailed with source, I'm just looking for the high level approach.

Thanks for this.

Re: Connector Neighbours

jeremytammik — Mon, 26 Feb 2018 22:01:24 GMT

Nice task!

Maybe these discussions and other ones they point to will help:

http://thebuildingcoder.typepad.com/blog/2016/06/traversing-and-exporting-all-mep-system-graphs.html

http://thebuildingcoder.typepad.com/blog/2016/06/store-mep-systems-in-hierarchical-json-graph.html

Good luck and have fun!

Cheers,

Jeremy

Re: Connector Neighbours

MarryTookMyCoffe — Tue, 27 Feb 2018 10:35:32 GMT

I work on pipes , but maybe it is not that different in duct.
First revit look up will help you with what is reference to what, so I suggest to install it, if you didn't already.

all pipes have connector manager with connectors, connectors have all ref (that show to what there are connected), with pipe there is this little thing that you have to check i connector from all refs is not the second connector from connector manager.
You need to check if connector is right kind(physicalConn).
Usually neighbour connector have the same orgin and opposite direction(this one not always rule, like in placeholders).

In family you can check which connector is prime and which is secondary and go with this link.
With branches you can always make a list of points to look if you not make a full loop, not the best solution but for big project.

In my case I only needed to go through all connectors until I will find pipe(i had like 4 or 5 families connected with each other).

Re: Connector Neighbours

Anonymous — Tue, 27 Feb 2018 17:07:45 GMT

Okay, so from the sounds of it this system is as robust as I'd hoped. I'm going to wade through this and I'll post back about what I was able to come up with. Thanks for pointing me in the right direction.

Re: Connector Neighbours

Anonymous — Wed, 28 Feb 2018 16:17:32 GMT

Not much time to be super specific but here are some additional pinpointed leads that should help in accompaniment with Jeremy's posts.

An element can have more than two ends

Check if the connector.connectortype == connectortype.end

I'm not sure how to get a reference to a neighbouring element using connected Connectors

Connector.AllRefs will return connectors connected to the one you're looking at, then you can look at their hosts

branching through systems in this fashion could cause you to essentially get lost in the branches unless you map N number of forks.

Yup. But this is why you're a programmer, you're the bad ass that will get this licked 😉

The direction of the connectors are often bi directional, so how does one know you're progressing in the correct direction even if you could get the neighbours?

Connector.CoordinateSystem.BasisZ will help you make sure you're facing OUT from the fitting if airflow is not the concern.

Re: Connector Neighbours

Anonymous — Wed, 28 Feb 2018 18:12:25 GMT

Hey Chris,

I've had to do this for a couple different tools, so I thought I'd just create a quick repo for you to check it out. It's a pretty basic bit of source that I threw together real quick, but the general idea is there. You'll definitely need to tweak it to meet your needs, but I hope it helps:

https://github.com/geoffoverfield/RevitAPI_SystemSearch

Let me know if you have any questions or need help with this.

Don't forget to mark an answer - it helps the next person find their solution faster!!

Re: Connector Neighbours

jeremytammik — Thu, 01 Mar 2018 09:37:47 GMT

Dear Geoff,

Thank you for the system traversal module... it looks very useful.

I added it to The Building Coder samples for posterity:

https://github.com/jeremytammik/the_building_coder_samples

https://github.com/jeremytammik/the_building_coder_samples/blob/master/BuildingCoder/BuildingCoder/MepSystemSearch.cs

Cheers,

Jeremy

Re: Connector Neighbours

jeremytammik — Fri, 02 Mar 2018 09:25:25 GMT

Dear Geoff,

Are you aware of the Revit SDK TraverseSystem sample?

Have you checked out some of the other MEP system traversal solutions I implemented and discussed?

Can you compare your solution with those, please?

I am wondering whether to discuss these in more depth in the blog... or maybe just make a list of them, for people to evaluate for themselves...

Thank you!

Cheers,

Jeremy

Re: Connector Neighbours

Anonymous — Fri, 02 Mar 2018 19:20:17 GMT

Another high level question regarding these branching systems:

Considering the potential for loops to be present, am I right in assuming that finding the shortest/all routes from a given start and end is non trivial?

My workflow intention was something like:

1 - Select start and end point in a given system

2 - find the user's intended route through the system (likely the shortest one)

3 - do a calculation on the given run using connectors and their references

I'm wondering if at step two the intended route could be ambiguous, and if so, how do you handle it?

I'm also wondering how you use the map once you map the system to proceed from the start in a direction that brings you closer to the end. This can't really be done with spacial location because to assume the end is specially further from the start than the middle may be a false assumption.

At the moment I'm considering making the user select the entire run, but the original intent would be a lot simpler (for the user...).

Re: Connector Neighbours

Anonymous — Fri, 02 Mar 2018 20:20:11 GMT

So it seems to me that you have a couple options on your hand. You can:

Let the user pick their own route
Offer the most direct route
Offer the shortest route (Not necessarily the same as #2)
Take a path that passes points (like if you have some kind check system everything needs to pass)

Based on that, you'll have to do some math & logic on the search process. Check out the image below (it's pipes - not ductwork... but same principal):

You'll encounter tons of systems that have an infinite number of ways of laying them out. In the drawing above, if you were to go from start to finish taking the "direct route", which may be the least amount of turns, you'd go straight down south, the east - covering 300' of pipe/ductwork in your case. If you wanted the shortest route, you could take the top route (follow the most northern pipes) and you would only pass through 296' 1/12" of pipe...

Never presume to know what the user wants... Most users will all have different ways of doing things - from East Coast to West Coast; North to South America and Europe... If you want to give them options (which I would always recommend for enhanced UX), give them options. Otherwise just build what you can, and add to it later.

If you really want to explore this and make a powerful tool, look at the differences between depth-first vs breadth-first searches, which are intended for graph systems like this:
https://stackoverflow.com/questions/3332947/when-is-it-practical-to-use-depth-first-search-dfs-vs-breadth-first-search-bf

https://stackoverflow.com/questions/687731/breadth-first-vs-depth-first/687752

https://www.youtube.com/watch?v=bIA8HEEUxZI

https://cs.stackexchange.com/questions/298/graph-searching-breadth-first-vs-depth-first

https://www.geeksforgeeks.org/depth-first-traversal-for-a-graph/

https://www.geeksforgeeks.org/breadth-first-traversal-for-a-graph/

There really isn't a "right answer" for this. It's got to be a balanced combination of what the users want and what you can reasonably create in a timely manner. What's important is that whatever you create, make it scalable so you can always come back and build on it later! So if you start by making them select their entire path, make it so that you can make edits and build on it without having to rewrite the whole thing... I've had to do that. It's not fun.

Don't forget to mark your answers... It helps the next individual find theirs faster!!

Cheers,

Geoff Overfield

Software Engineer

FabPro, LLC

Re: Connector Neighbours

Anonymous — Fri, 02 Mar 2018 20:23:52 GMT

Hey Jeremy,

I am not familiar with that bit of your work. Can you send me a link, and I'll check them out! I'll DM you with my opinion on whether to add it to the blog, or create some kind of repository of solutions for people.

Re: Connector Neighbours

jeremytammik — Sat, 03 Mar 2018 11:52:33 GMT

Dear Geoff,

The Revit SDK TraverseSystem sample is part of the Revit SDK, obviously.

It determines the correct order of the individual system elements in the direction of the flow and stores the entire directed graph in XML.

Here are some discussions of it:

My AdnRme sample performs traversal of electrical systems:

https://github.com/jeremytammik/AdnRme

Here are some discussions of that sample:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.40

Here is another much simpler traversal implementation:

http://thebuildingcoder.typepad.com/blog/2013/02/simple-mep-system-traversal.html

I am looking forward to hearing what you think of them, especially if your traversal implementation beats the TraverseSystem one 🙂

Thank you!

Cheers,

Jeremy

Re: Connector Neighbours

Anonymous — Mon, 05 Mar 2018 14:09:33 GMT

Thanks everyone for the quick responses, and the wealth of information. I don't think there's one reply in this thread that isn't deeply helpful and as such I have a hard time picking a "solution". So, everyone gets kudos!

Re: Connector Neighbours

Anonymous — Mon, 05 Mar 2018 14:21:15 GMT

To assist future visitors that might land on this page through Google or some similar service, I believe you can tag more than one post as a solution. I'd pick one of Jeremy's with links and one that Geoff posted, perhaps his sample?

Alternatively, you can tell me "You're not my mom" and I'll bug off 😉

Re: Connector Neighbours

Anonymous — Tue, 06 Mar 2018 14:33:06 GMT

You're not my mom!

Answers selected. Though honestly, most of this content is pertinent.

Re: Connector Neighbours

jeremytammik — Mon, 19 Mar 2018 14:30:52 GMT

Thank you all very much for the fruitful discussion!

Saved for posterity by The Building Coder:

http://thebuildingcoder.typepad.com/blog/2018/03/connector-neighbour-conduit-transition.html#2

Cheers,

Jeremy

Re: Connector Neighbours

doc.inge.fernando — Sun, 06 Mar 2022 19:23:00 GMT

Inge de la longitud veré la forma lo que si me sería de gran ayuda poder modificar la dirección de flujo gracias

Re: Connector Neighbours

doc.inge.fernando — Thu, 31 Mar 2022 20:55:19 GMT

Alguien me puede indicar, cuales podrian ser las razones de que no funciona la palabra this en una linea de código

Como se ve en la imagen no reconoce a esta palabra, gracias

Re: Connector Neighbours

jeremy_tammik — Fri, 01 Apr 2022 06:59:11 GMT

`this` refers to the current instance in an instance member method. Your code snippet is probably not part of an instance member method. I would suggest reading about this for yourself in the .NET documentation:

https://duckduckgo.com/?q=c%23+this