Finding Duct/Pipe fitting length using Parameters Map

[Anonymous]

Hey everyone,

Taking another step forwards on my system run scripting. the basics are in place and I'm calculating run lengths for selected sections of duct or pipe. I've been doing this by grabbing data from ParametersMap which has some great stuff. However, my problem comes when trying to estimate run lengths for fittings. Depending on the setup of the fitting, Revit sometimes lists 12 length parameters. For ducts, a cross fitting has four lengths but they're listed as Length 1, Length 1a, Length 3, Length 3a. It makes it difficult to identify the fitting you're dealing with let alone the best way to calculate a length approximation.

Is there a page somewhere that describes these variables? Is this related to how the family is built? Is there a simple way to find the run length of a fitting without sorting through all these parameters, short of using the bounding box to calculate an approximation?

Thanks for this,

[Anonymous]

So, for the time being, I am able to identify if the fitting is a swept angle (loft) by looking to see if the fitting has the "Center Radius" parameter. If it does I can calculate the run using the radius and the sweep angle.

For the rectangular fittings, I have no real solution. Currently I am averaging the x and y distances of the bounding box, and that seems to provide a decent approximation. It seems like without a label of the fitting type, that's as good as I'm going to be able to get.

[Anonymous]

I'm embarrassed I didn't think of this earlier, but I guess I just got obsessed with all the useful data in Parameter Map, and the fitting name isn't in there. I can grab the Family Symbol and use it to get an idea of what fitting I'm working with. Then it's just a matter of determining calculations depending on the fitting.

It would still be useful however, to get some sort of an idea of what the variables inside the Parameter Map mean. In a couple I have seen variables named "12", "3a", etc which I assume are length related, but it's hard to know.

[jeremytammik]

Dear Chris,

Congratulations on making good progress.

The best way (I think) to determine the length of a pipe or a duct is to query its location curve and use the distance between the start and end points.

For fittings, I agree that analysing the bounding box is a good start.

You could narrow it down a bit more by querying the fitting for its full geometry and analysing that to find the connector faces.

More importantly, you could retrieve the fitting connectors and their exact position and direction to improve your approximations.

The approach using connectors would work well for ducts and pipes also.

For those trivial cases, it should obviously generate the exact same results as using the location curve, so you could use that to verify that your algorithms work properly.

Using the named parameters is tricky for many reasons.

It is language dependent, which is bad. 

Anyone who creates a fitting family can name any parameter any way she chooses.

Maybe avoiding language dependency is why some people name their family parameters A, B and C instead of Width, Length, Breite, Länge, etc.

It still leaves you wondering what they might mean, though.

Afaik, a convention has been introduced for steel framework families for structure, and the Revit API also adds some classification support for those, e.g., cross section types etc. Not sue whether similar conventions exist for HVAC fittings.

Cheers,

Jeremy 

[jeremytammik]

The Building Coder discusses some approaches to distinguish MEP fitting shapes, e.g.,

• http://thebuildingcoder.typepad.com/blog/2011/03/distinguishing-mep-element-shape.html
• http://thebuildingcoder.typepad.com/blog/2011/05/improved-mep-element-shape-and-mount-ararat.html
• http://thebuildingcoder.typepad.com/blog/2016/02/ifc-import-levels-and-mep-element-shapes.html#3

They might be of use for your fitting length analysis as well.

Looking forward to hearing how you end up solving this.

Cheers,

Jeremy

[Anonymous]

---

@Anonymous wrote:

Afaik, a convention has been introduced for steel framework families for structure, and the Revit API also adds some classification support for those, e.g., cross section types etc. Not sue whether similar conventions exist for HVAC fittings.

---

It would be awful helpful. I have little issue with shared parameters, thanks to many of your shared parameter tools that you've shared with all of us. But it is still a colossal headache to deal with the variables that they introduce.

Have you seen this website before?

http://openrfa.org/blog/value-standardized-shared-parameters

I think the challenge is that there are varying steps along the way that all use Revit content, but they use it differently. A designer may be concerned with having a width, depth, and diameter for each airflow type. As a detailing/fabrication person, I'm more concerned with standardizing first width and depth, second, and third on tees (as an example). And making their orders and guids predictable. Airflow is not totally impertinent, but more so on my end.

So my engineering coworkers may really appreciate something like this

http://openrfa.org/shared-parameters/approved?title=&field_data_type_tid%5B%5D=66&field_group_tid%5B%5D=199&field_parameter_tags_tid=All

Whereas it's going to fall short for me. But it's open source, so maybe we should partake and not fuss.

Now with intent to avoid totally derailing:

Chris, families can be built in so many different ways, with so many different practices, you'll want to establish what the constants will be between each fitting family that you come across. Connectors will be that consistently present element to work with, and their behaviors are often forced to be consistent too. Drawing lines between them, catching their intersections, and doing math with that will be a flexible route.

You can even do a case by case basis. If the family instance is a mechanical fitting, you can establish if it's a tap, tee, elbow, etc. and do different math based on those criteria.

[Anonymous]

If I'm understanding you both correctly, the inconsistencies I'm running into with ParametersMap is because the entries are dependent on how the family is constructed and therefore could change in the future, breaking references. Is this true of all parameters in ParametersMap? I'll have to investigate built in parameters further. Currently I'm not even calculating the length of duct runs using connectors, rather I'm just grabbing the length parameter.

If it really just comes down to connectors and trying to identify the fitting, it would seem like a waste. I was really excited at the potential when I stumbled across ParametersMap, but it needs to be consistent to be useful. I guess it's a balancing act between giving the user freedom and consistency.

I shall plod on!

[Anonymous]

Some parameters will be built in. Those will be rather consistent and I would not shy away from using them. But I've found that you'll generally be dealing with custom family or shared parameters, not built in, when dealing with fittings. The pipe itself will rarely need anything but built in parameters, but fittings, fixtures, and accessories will.

So I'd estimate that it can be a mix of connectors and built in parameters that suit your needs.

[Anonymous]

So I spent some time thinking about this and also looked through The Building Coder content, and it's been really helpful. I didn't realize the connector type was listed in the MEP Model, and that's a great start to what I'm trying to do. Using that I should be able to interpret the selected run intention and generate very reasonable approximates using the connectors. It also allows me to use friction loss rules of thumb based on fitting type, which is awesome.

Secondly, I had been thinking about how to approximate a run length when you don't know much about a fitting. As previously stated I had been using the bounding box to grab an average between length and width. However, The more I think about it I think I have a better approximation. Essentially I've been getting all of the various connectors on the fitting, and doing a length calculation between each connector and the center of the fitting. From there I total each pair of lengths and take the largest total of two. In the case of symmetrical fittings this produces a nearly perfect run length, and in other cases it might slightly overestimate, but not by much. On swept fittings, like S bends, it may slightly underestimate, but we could compensate if desired.

One other thing I wanted to ask is how do you differentiate between a shared parameter and a built in parameter? Is it Parameters vs ParametersMap?

Anyway, thanks again for the help. If I come across anything else, I'll post it up.