I have been trying to create a graph that inserts a fitting or valve into a pipe whenever it intersects with Spaces that meet some company specific criteria. Thus far, I have been able to identify and select all the pipes in the project that intersect with these Spaces, obtain all the desired intersection points between the pipes and spaces, but when using the MEPFitting.ByPointsAndCurve node from the MEPover Dynamo package to actually insert the valve, I get inconsistent results. A few minutes ago, I ran the graph on a project, and it did exactly what I wanted. But when I “un-did” the graph, restarted it, and ran it again on the exact same model, it only worked for 50% of the pipes. Same graph, same model, within minutes, but different results.
When I test my graph on a small test project (~2 spaces and ~12 pipes) it seems to work every time with valves being placed on the intersection points while also inheriting the host pipe’s system type. However, when I run the graph on a larger scale project (~100 spaces and ~1,000 pipes) I only get a few successful valve placements and rarely will they inherit the host pipe’s system type. The error I get within the MEPFitting.ByPointAndCurve node during these trials reads "Warning: List indices must be numeric."
Any thoughts on what might be wrong or causing these issues with the graph?
I can only assume that the problem may be related to one of the following things:
User error. This usually seems to be the most likely option…
Timing. With a lot of information, and cross products being passed through the graph, maybe nodes are processing information prematurely, incorrectly, or in other unexpected ways.
Inconsistent or ambiguous Data Types. In some of my research, I’m come across instances where Dynamo was possibly interpreting data inconsistently. Maybe there is some place in the graph where the data being generated is not explicitly one type or another?
Possible random node outputs. I know the Element.Parameters node used to rearrange the results in a different way every time it was run. Maybe there is some other node that behaves inconsistently?
I have already spent a good bit of time trying to test and troubleshoot this issue, and I think I have officially exhausted all of my ideas. I respect your time, but any help or advice that you could lend on the issue would also be greatly appreciated.
Other Forums I found helpful in the creation of my graph:
We can’t really speak to inconsistencies without a full dataset (hard to identify the difference between models without being able to see the models), but this error may be associated with how the MEP fiting is getting inconsistent list levels.
Ensure the list depths match, and flatten the lists before the MEPfitting node, or otherwise adjust list levels (@L2 and @L1 perhaps?) and see if that resolves this test issue.
Thank you so much for your reply! This was something I pondered for a while too, but when I match the list depths for the elements and their associated points, I get the same “Warning: List indices must be numeric.” warning from the MEPFitting node and on top of that there are no instances of a valve that appears in Revit.
In the second forum I tagged above, @T_Pover somewhat addresses this same thing in his first response. I went ahead and tried your suggestion anyways just to be safe and I received the response below:
I do agree with you though, and I feel almost certain the issue has to do with the way the points are being read by the MEPOver node. Do you have any more ideas on what it may be? Again, Thank you for all of your time and effort!
Sure Thing! I’ve been running my graphs mainly using the Nibco Ball Valve family as the family type needed for your MEPFitting node, but if it’s also possible (or easier) It would be nice for the graph to also be able to work using the generic standard out of the box coupling you get from Revit as well. I just had some issues when I was first using the coupling so I made the switch to valves for the sake of testing. Here iss the Nibco Ball valve family, and I assume you already have the generic coupling family from Revit. However, if you do not let me know and I can provide that with you as well! Thanks!
Hi @bkirby, i have also been working on a script to automate valve placement on pipes (as per your referenced thread, presume thats where you got the valve family from?). I have also come across errors on very large projects, and it sometimes took hours to run, for it to eventually fail and send pipes all over the place. You are right that the order is imperative, otherwise pipes try to connect to the wrong one.
A few things I noticed with your script:
The list of points and list of pipes does not match. You have 6 pipes and 8 points.
All points need to be split to work with the MEPover node.
Sometimes I had errors when it tried to place a valve on a pipe that was not long enough. So I introduced a pipe length checker.
For large projects, it might be better to perform the script per view instead of the entire model.
The ball valve family you supplied is as family that has its size set by a type parameter. The MEPFitting node will only work with fittings that have their sizes set by an instance parameter.
I also tried the out of the box family you mentioned, but I get really crazy results (pipes jumping up and down). I will have to look into that, but it seems like an error that I won’t be able to fix short term.
@T_Pover I really appreciate your time looking into this, and I’m glad its not just me seeing these things happen! When you were building and testing these nodes, did you find a specific family or piece of content that worked well and had the given criteria you mentioned? All I really need is some sort of pipe fitting or accessory to be inserted into the pipe in order to break it as it enters these spaces. Again, thanks for all your help thus far as this has been quite the troubleshooting experience!
@T_Pover I think I might be narrowing down on where these issues are residing. In the meantime, I did notice that when running the graph with the new content you shared, I saw that it was never able to inherit the host pipe’s “System Type”. Do you know if this has to do with the family and how it’s built, or does it have to do with the MEPFitting node not joining the two elements completely? have you ever had this issue during your tests with this fitting? I included a snip below to show you exactly what I’m seeing (The red piece is the “Undefined” NLRS_50 fitting). I can’t thank you enough for all of your help and guidance.
@T_Pover, that is really interesting. I’ll dive more into the family itself and see if I can find a reason for this and let you know what I discover.
Sorry that it’s been a little while since I last gave a solid update, but I took the content you shared and put it through some extensive testing over these past few days to see if I could figure out some patterns that might give us some more answers into what’s going on. I did discover some findings though that you may find interesting or hopefully know the reasons for:
My graph seems to be running now without any error from the MEPFitting Node, and I honestly cannot explain why. Although it is still inconsistent to some level, each “failed” run now just gives me a “null” in the drop down dictionary list similar to whats shown in the snip below.
I found that the node works best and gives the most consistent results when it is run fresh. by this I mean when Dynamo is completely closed out and reopened with the graph and then given its first official run. Maybe this might have to do something with the way your MEPFitting node receives and dumps information during each run? I’m not sure but it is something noteworthy.
As I shared before, I’m still getting inconsistent results from the node. Sometimes it works perfectly the first time through, but more often than not it takes about 2-5 successive runs to complete all the instances for the “medium sized” test project I’m working with (~3 spaces and ~20 pipes). I do notice that with each “failed” run the graph still inserts one or two fittings, but what’s odd is that for some reason it all the sudden clicks and in the last run all the missing fittings pops in that weren’t caught in the previous runs. Kind of interesting.
Also to go along with our last discussion, some instances I find naturally inherit the system while others do not. I ran the graph a couple of times using the Nibco Ball Valves I shared earlier and got something that turned out like the snips shown below. I’ll try and do a bit more testing with some different fittings and see if there’s a reason why some work better than others.
I guess a question I might have for you in order to make sure my end is working the way it needs to, is with the MEPFitting node, is there any assumed criteria that is made by the node and its associated code for the data/information coming into it? I know you talked about some of the assumed family type criteria above, but what about the points or the elements? should they follow a specific data type? Just thoughts I’m having that might be able to fix a simple error and make the graph/node run as the way it is intended. Let me know what you think and if any of these findings spark an idea! As always I thank you for your time and help and I appreciate you working with me on this and taking time to help!
I know the node can give some irregular results depending on the project and families used. The reason for this is that the node really does a lot of stuff and taking into account every possible situation is simply impossible (for me as someone who just makes these nodes as a hobby at least).
It is indeed advised to run the graph once after opening because you will get unwanted results if you run it multiple times. It will divide pipes more than you want and make a mess of things. The way the node is setup (in a nutshell) is like this: for every pipe it will:
sort the list of points from start to end of the pipe
place the fittings at the given points
rotate the fittings so that they align with the pipe
set the fitting sizes the same as the pipe’s
shorten the existing pipe to span from start point to the first fitting
copy the pipe and place it at the first fitting and adjust to length so that it spans from first to second fitting
repeat the above until there is a piece of pipe between every fitting and the initial end point of the existing pipe
lastly, connect every fitting with the pipes.
So that’s a lot of steps just to place a bunch of fittings. Besides that there are some helper functions for checking system types, connections, aligning etc.
I think you have to find a way to connect every pipe size to a specific family type. You could create a dictionary where every pipe size will be the key and the valve type will be the value. Springs has a great dictionary node that’s easy to use.
