Overhead Sectional Door Array Problem

[phyllisr]

Consider the attached .zip file with three families I created for overhead doors as a gift in exchange for some assistance with a tricky array problem. I included the type catalogs in hopes someone will be interested enough to tackle it.

These work correctly but because the third panel is different in OSG, I cannot make the family function with the section quantity - height - section height array and formulas. Any thoughts on an approach that might work? I have considered just about everything but know full well they will not work and why they will not work (two complete arrays for both sections with visibility parameters; one lower array, a fixed unit and one upper array; arraying the reference planes and more).

Any brilliant ideas?

[guitarchitect7]

If you knew that the glass panel of third family would always be the second or third panel from the top and never change, then you could do an array for all the panels below the glass one, and have the glass and panel above be static.

[phyllisr]

...then you could do an array for all the panels below the glass one, and have the glass and panel above be static...

Thought of that already. First problem is that you cannot have an array with only one element. The type in the original image would generate the error illustrated in the attached clip. Even if this worked, assuming the design intent is to keep the glass at approximately eye level, it would not always be in a specific position. If you had six panels, it could be fourth from the bottom.

But thanks.

FYI, I am aware I am obsessing over a problem I could solve very easily by creating individual families with 4, 5, or 6 equal divisions made like the OSG family I posted. Just prefer "like" families to be consistent and prefer having as few families for our users to find/swap as possible.

[guitarchitect7]

Then I'm stumped! I really don't think its possible since your floating a completely different family within an arrayed family, and since that location changes constantly, you have no static reference points.

I would be very curious if someone finds a solution.

[aaronrumple]

Avoid the array of panels all together. Just make 1 panel. 1 void. 1 glass. Then do an array of lines on the surface of the door panel. Much, much simpler. Takes less memory from Revit. Looks exactly the same as what you have now in both 2D and 3D. In fact, then all three of these door styles could be merged into one family. Nested panels also makes this more complex. Here it just isn't needed. Far fewer parameters can be used.

Sometimes the best solution is just to avoid the problem in the first place...

[phyllisr]

We have already considered your line array approach.

First, lines using an array formula generate constraint problems and do not always flex correctly. See attached simple Line Array Example. The lines perform as expected when flexing the height but generate an error when flexing the width. This is a known issue and the subject of numerous other posts. I can get around this by creating a nested line family. See attached simple Nested Line Array Example. This does work in a project (and a user can enter the overall height and the desired section height for variable results) but then there is no reason to skip one nested generic model for another. Further, in order to insure interior and exterior views are correct, I must create the array on both the interior and exterior surfaces, adding yet more content and more things for Revit to calculate. Using my nested component OS Section family solution, it is one array calculated once. Note that my original family is smaller than the Nested Line Array Example that does not yet include the array on both sides.

Second, I cannot uncover any method using your 1 panel - 1 void - 1 glass solution that can generate the variable section quantity in the second example. How do you suggest I create a void and glass that will appear 4, 5 or 6 times in the correct location and size between the arrayed symbolic lines? Unless perhaps you are suggesting what I already did with the nested OSG Section family?

Third, can you explain how your method will allow me to control the location of the void and glass as illustrated in the third image? What if my door is 10'-0" tall, thus returning 6 sections @ 1'-8" each with the vision panel in the fourth position instead of the third?

Finally, can you explain how your method can combine all possibilities into a single family?

I would be delighted to concede your point if you can post a functional solution that accomplishes my intended result (flexing the number of sections relative to the height) using your "one of each" method . Until then, please consider that perhaps I am not avoiding a problem but rather I am solving one.

[aaronrumple]

You know of the limits and solution for working with arrayed lines. So no need to go over that. But there is very good reason to use one nested object over another. As you have already stated, your system doesn’t work for your OSG family. This system work the way you want – yours doesn’t. I would think that would be reason enough.

Also a simple nested line family is a lot simpler to set up and maintain than a library of panels. I only need link one parameter – not a whole set. Far fewer things to go wrong. Don’t get me wrong, I’m not against nested families. I use them all the time when they allow me to reuse content and reduce development time.

I chose to place two arrays. Each hosted to the face of the door. I could have made this just one generic model with two lines (or four if I wanted to see joints on the side.) and done just one array. But setting up the array isn’t difficult doesn’t add to the number of required parameters and the constraints don’t clutter up the family.

Of course the previously posted file was larger – this is no mystery. I added my new geometry, but your old nested information was still there. Purging the unused information drops the file size 256KB to 200KB. And as we all know – it isn’t always file size that impacts the performance of Revit. I’ve always found that complexity impacts performance more than file size. Nested files are always more complex for Revit to calculate. The completed example is 232KB. Still less than your original.

Second – see the attached. Just a few simple formulas.

Third – see attached. Just a few simple formulas. I’ve set it up so that the top of the glazed panel will be as close to 6’ as possible. You can set up much more complex conditional testing than this if desired. I’ve tried to lay out the formulas so you can follow how the calculation is being done. You can eliminate several parameters by using slightly longer formulas…

You’ll see I’ve collapsed OSG and OS into one family. You can use the same technique to incorporate OSG Section Qty in as well. However, this again gets into an issue of enterprise maintenance and lowering the overall cost of developing content. OSG Section Qty is significantly different from OS that I think it should be a separate family. Adding in the extra void and glazing solid needed to make OS both OS and OSG Section Qty isn’t too tough, but it does add an extra layer of constraints that might not be obvious to someone opening the family a year from now. I think that has to be considered in keeping development cost down. About the only thing I didn’t do was set the glazing thickness…

A few other points. I wouldn’t include a side-to-side flip. This only adds keystrokes for flipping a symmetrical family. I’d also place the flip arrow clearly on the exterior side of the wall. This provides good visual feedback for the user and away from the default door number placement.

I’m not at all sure why the leaf width is tied to the number of panels. Right now it has no effect on the family geometry other than making the width value deviate from the actual width of the door. Seems strange, but I’ll trust that is desired.

[phyllisr]

I took a careful look at your family and am having difficulty understanding your solution. I was able to "break" it in about 30 seconds. Attached are images illustrating the points below. For this exercise, consider Dick and Jane as the average user Tony and I support every day.

• The array does function correctly when flexing the height. Jane will send me an urgent email when facing a deadline if she uses your family. Further, she will tell everyone how the deadline problems are because of Revit. If she uses my family, there will be no questions.
• There is no relationship between the array and the location of the vision panel. This time, Dick has a deadline for a presentation and he wants to plot the elevations of the 12-unit townhouse project and all the vision lites are in the wrong place. He calls me first then sends a follow-up complaint email with a copy to my boss.
• This does not combine all the families into one single family as you suggested was possible. What about my original OSG Section Qty family?
• The calculations required to flex your family are extensive and require considerable resources. Test both your solution and mine in a project with 50 doors and time how long it takes to generate a change. In Dick's large high-bay warehouse project, how many emails do you think I might get from him and his team complaining about the speed?
• Compare the Family Type dialog boxes as illustrated in the side-by-side image. Which one do you think Jane will understand? Is your family really a few simple formulas?
• Related to the previous bullet point (though less critical), Dick and Jane can change the sides, top and bottom frame at will depending on the manufacturer in my example. If you add this flexibility to yours, the number of parameters required to flex your non-working family is more than double what is require to flex mine. Once you create additional conditional formulas the control the vision lite location and insure that it relates to the array, you might quadruple calculations required.
• Dick thinks this is totally cool (assuming you can solve the earlier problems) and adds to the agenda for the Advanced Content Team meeting (a group of "power users" capable of complex work and interested in learning). Since the sessions are only an hour, how many sessions do you think it will take so the power users fully understand how to create this and be able to do so independently?

Perhaps we should submit our solutions in a separate post and let other AUGI members vote or choose which families they want in their library. I remain delighted to concede your original point if you can post a functioning solution.

[aaronrumple]

My bad... Mea culpa, mea culpa.

I posted a version before I locked the array. Attached. Enjoy. You should have seen that.

• Fixed. Enjoy.
• Fixed. Enjoy.
• As I noted. The same concept can be applied. I'm not going to do your entire job. Mute point. As I also noted - I wouldn't as explained.
• Only flexing instanced parameters is time consuming - which is the same as changing parameter in a type to make a new type. You area using types. Performance of switching types is no big deal. Works fine here. Switching types on 100 doors took a split second.
• If I polished this (which ain't my job mind you.): The user inputs go in the dimensions group. Those controling the family go in constraints. You don't change constraints (least in our office that is the policy.) In fact you roll them up and never look at them.
• No. It is one more user paramter. The calculation is already being done. I just used one value since it ain't my job.
• One session. Unless they are really bad at math. It is all simple math. Revit's formulas are pretty simple. (...a power user should know the basics of formulas in my opinion.) Or maybe it is your job as Design Applications Manager.
• Do it however you like.
• Awaiting your functional solution.