A few days after the last post, I got handed a model that seemed like it should have worked perfectly. The nested families were already set up as Shared. The IFC export was running. The geometry was coming through.
But the asset data? Completely missing.
When this happens, it’s easy to jump to conclusions, and there were certainly a few floated to me, including:
- “The nested family is pushing data up to the host.”
- “The host is being ignored in the export.”
- “You can’t even apply data to nested families properly anyway.”
None of that is actually happening. It’s a fundamental misunderstanding of where Revit stores data and how the IFC exporter reads it.
Here’s what was actually going on in the model
The data had been applied to the host family. The nested families themselves were blank. To make it slightly more confusing, the host families didn’t contain any geometry to export. They were essentially empty containers. Because there was no parameter linking set up inside the family, and no geometry on the host to carry the data out, the exporter did exactly what it was supposed to do. It exported the shared nested families as their own IFC objects, and it exported the host as… well, nothing.
The nested families existed in the IFC and were exported exactly as they were in Revit, with no asset data.
Revit doesn’t magically synchronise parameters between host and child unless you explicitly link them. Shared vs. non-shared only dictates whether the nested family gets its own IFC identity. Where the data lives dictates what gets written to that identity.
If you want the data on the nested element in IFC, it needs to be on the nested element in Revit.
So what do you do?
So what do you do when you’ve inherited a model where all the data is sitting on the host, but the nested families are the ones that need to carry it out?
You can fix it manually, but that’s tedious. A quicker way is to write a simple script to copy the values across. I threw together a C# macro and a Dynamo Python node that does exactly that.
I’ve shared a copy of the code in both C# and Python on the original GitHub repo.
The code in both these instances is a blind push. It walks through the family instances, grabs a predefined list of parameters from the host, and slaps them onto the nested families. No clever logic, no validation, no attempt to handle unique asset code sequencing. It just moves the data from one place to another so the IFC export actually has something to read.
It’s not a perfect production workflow. If you’ve got multiple nested components under the same host and each one needs its own unique asset code or sequence number, this script will just copy the same value across all of them. For that, you’d be better off using a Revit schedule, or a tool like BIMLink, Planworks Tables, or Rushforth Tools to batch-edit the values in Excel. Or you could extend the script to generate unique sequences.
But for remediation? The scripts as they are give you a quick way to unblock a deliverable without rebuilding the content from scratch.
No Comments