ACP Revit Architecture: Parametric Family Breaks When Array Count Changes

Parametric Family Breaks When Array Count Changes

A curtain-wall mullion family was built with an array of 6 vertical fins spaced 12 inches on center, driven by a parameter called "Fin Count" (integer, default 6) and a spacing parameter "Fin Spacing" (default 1'-0"). The family is loaded into a project and placed on 14 curtain wall segments of varying lengths (from 8 feet to 40 feet). On the 8-foot segment, the fins overlap and the array throws a constraint error. On the 40-foot segment, the fins stop at 6 and leave a 4-foot gap. The family author also nested a fin profile family and constrained it to the array's first and last references. When a user tries to change "Fin Count" to 8 on the 40-foot segment, Revit returns "Constraints are not satisfied" and the array collapses to a single fin. The project has 14 instances, and the family is also used in a linked model that has already been issued.

1. Diagnose why the array fails at both the 8-foot and 40-foot extremes, and explain why changing Fin Count collapses the array.

Read the worked answer

The array is fixed-count, fixed-spacing, which is the wrong parametric strategy for variable-length hosts. With Fin Count = 6 and Fin Spacing = 1'-0", the array occupies exactly 5'-0" of host length regardless of how long the curtain wall segment is. That single design choice explains both failures:

8-foot segment: 5'-0" of fins on an 8'-0" segment should fit, but the fins overlap because the fin profile has width and the array spacing is measured center-to-center while the profile extends beyond the centerline. If the profile is, say, 4 inches wide, the effective footprint is 5'-0" plus half a profile at each end; on a short segment with end constraints, the array cannot satisfy both the spacing and the end offsets.
40-foot segment: the array is hard-capped at 6 fins, so it covers 5'-0" and leaves 35'-0" bare. The "4-foot gap" the user sees is the remainder after the end constraints pull the last fin inward.

Why changing Fin Count collapses the array: the nested fin profile is constrained to the array's first and last references. When the count changes, Revit must re-solve the array, but the first/last references are locked to the nested profile's geometry, which was dimensioned against the original 6-fin layout. The solver cannot satisfy the new count and the old first/last constraints simultaneously, so it collapses to a single element (the fallback state). This is a classic over-constrained family: the array count, the spacing, the host length, and the nested profile's end constraints are all fighting for control.

The judgment: the family was authored for a fixed condition and is being asked to serve a variable condition. No amount of parameter tweaking fixes that; the array strategy must change.

2. Propose a corrected parametric strategy for the mullion family that handles 8-foot to 40-foot segments, and address the already-issued linked model.

Read the worked answer

Corrected strategy: drive the array by spacing, not by count, and let the count be a calculated value.

Replace the fixed-count array with a "Move To: Last" or "Move To: 2nd" array whose spacing is a formula, not a fixed number. The count becomes Host Length / Fin Spacing rounded, and the spacing adjusts to distribute fins evenly. This makes the family host-driven rather than count-driven.
Remove the nested profile's constraints to the array's first and last references. Instead, constrain the profile to a reference plane that is itself driven by the array spacing. Over-constraining the nested element is what causes the collapse.
Handle the short-segment case with a conditional: if Host Length is below a minimum (say 6'-0"), suppress the array or reduce to a single fin via a visibility parameter. Revit formulas can drive an integer count with if(Host Length < 6', 1, rounddown(Host Length / Fin Spacing)).
Add a minimum spacing check so the 8-foot segment does not produce overlapping fins: Fin Spacing = max(1'-0", Host Length / Fin Count).
Test the family at 8', 12', 24', and 40' before reloading.

For the already-issued linked model: do not silently swap the family. The linked model's 14 instances will re-solve on reload and may change appearance. Instead:

Version the family (e.g., "Mullion_v2") and load it alongside the old one.
Map the 14 instances to the new type only after confirming each segment's expected fin count.
Notify the linked-model owner that the family is being replaced and provide the new family file so they can update on their schedule.
Do not delete the old family until the linked model has been updated; deleting it will orphan the linked instances.

The judgment: fix the parametric logic at the source, version rather than overwrite, and coordinate the change with the linked model owner rather than forcing a reload.