Data from nested families

[AnnabelleSwain]

It would be great if data from nested families was available within the family it is nested into. There are many ways this could be used, but the main use case for my firm would be setting up window families. We often need to calculate the total area of glass used in a window and the total area of operable portions of the window. Currently we use complex formulas to get these simple numbers, since reporting parameters are unable to be used in type formulas. If data from nested families was available, we could set up nested glass and operable window families with area parameters and just grab the sum of their areas. We cannot use shared families for this because we need Revit to read the window as one piece since we use Room Calculation Points to get ratios of the light and air provided in each room in our project.

In the window shown below I would like to harvest the relevant data from each highlighted panel.

     

Below is an example of the formulas needed. To get the areas we need to basically find the total height and width of the glass and the operable window. This tends to be done by taking the total height and width and then subtracting the mullions from the total, but the formulas are different for each window layout.

[AlexLibengood]

I need to be able to create a "Reporting Parameter" in a host family that does a "Read-Only" on the parameter of a nested family.

For example, I have a window family that has nested trim casing families that I can swap out from within the project using a family label parameter.  Each of these swap-able nested families has the same "trim width" parameter.  The window family has geometry that needs to change size based on how big the nested casing family is.  If the nested casing family can "report" it's width to the host family, then the host family can change the size of the geometry based on the size of the nested family using a instance parameter in the host family that "reads" the parameter of the nested family without changing the nested family.

There are so many families that I've created that would benefit from this feature!

[HadiMoosavi]

has this been resolved?

[jkidder]

The lack of the ability to use dimensions from a nested family in a host family is a continuing problem in family development.  Currently host families can only tell a nested family information, but nested families desperately need to be able to tell there hosts information so that the host family can use that in calculations.  Nested families often represent real world products and may be used in multiple locations. The host family needs that information of the nested (dimensions, type marks, etc.) to report.  Currently, this isn't possible.  You have to choose between having the host dictate a dimension (may lead to to families breaking if they aren't designed to flex or families that are an unproduceable size), use dynamo to tell the host family information (have to build a script and rely on people to run it) or manual input (have to rely on it to be done).

Doors are a common issue - The nested frame should be able to report its frame type and other info to the host door

For one with products, take a shower family.  The host family has the shower fixture and associated grab bars and clearances.  We use the same shower pan at several locations, some with grab bars and some without.  They all are the same shower pan, and we need that shower pan to be the same size, and its nested so we can know how many shower pans of that size the project needs.  But if we change to a different shower fixture product and the size changes I want the grab bars to adjust based on that new size, not require me to go into the host family and manually match the new enclosure wall thickness and overall size, but the host family can't read (without changing) those parameters.

[Ric_Weber]

Excellent Idea!  It can also be found here: https://forums.autodesk.com/t5/revit-ideas/host-family-to-read-only-or-quot-report-quot-the-paramete...

@kimberly_fuhrman-jones, Thank you! 

[AnnabelleSwain]

Hi @kimberly_fuhrman-jones , Great seeing you last week! This idea was one I presented at ITF and the developers encouraged me to log it on Revit Ideas and post it in the ITF feedback system. They wanted more information to see if this could become a viable feature. Since I have used the link to this post in my ITF report, if it needs to be merged, could the 8 year old post that @Ric_Weber linked please be merged into this one.

[jmeuris]

I do concur this reporting of downstream data in nested families could be improved. At the other hand for the 15+ years I'm using Revit I've always been successful subtracting the required data from nested families in direct reports in Revit (No need for Dynamo if all is setup correctly)

• Your nested families need to be set as "Shared" >>> Then they will be able to report their metadata in project schedules
• Of course proper Shared parameters is a necessity to be able to populate Revit schedules
• Upstream parameters can be linked downstream. This could be useful to create a child tag/asset code to create a relationship between Parents and children...

[jkidder]

@jmeurisShared families help (and I use them all the time) but they don't solve the problems mentioned where the HOST needs to know information only the CHILD can tell it.  While we can schedule child families independently, we can't see that data, other than the type name, in the host family.  Information only flows downstream, we need information to flow bi-directionally.  If you have three host families (Wall mounted sink with nested clearance and faucet, each has a different faucet and type mark) that all need to react to a size of the same shared nested component (in this case the sink depth) the three hosts can't control the depth of the component (the sink) or there will be a discrepancy (the three sinks need to be identical depth).  That nested component needs to tell the width to the three hosts so they can respond (adjust the clearance location based on the front edge of the sink - upstream flow of information).   If one of those host sink families has a product change the nested sink needs to be swapped, and the clearance location needs to adjust again based on the nested depth.

In some cases the information could avoid being passed if constraints to nested reference planes were stable, or if a reporting parameter could be used in a formula, but neither is the case and there isn't a way (other than manual or dynamo) to constituently pass information from a nested family upstream to its host.  Both options are time consuming, and manual movement of data is error prone.

[jmeuris]

@jkidder 

Got it—now the goal is much clearer! Leveraging upstream data within Families could be a big advantage here, since manually maintaining those relationships is both risky and time-consuming. Using a Dynamo script is a possible workaround, yet it requires customizing the script for each family to target the right parameter(s).

The main concern I see is that adding these constraints and managing upstream/downstream data will make the families more complex. That could increase their size and potentially slow down performance in projects where they’re used.

Let see what Autodesk thinks of it!

[jkidder]

@jmeuris 

I actually think it will reduce complexity (I don't care about the size, performance would depend on how well its implemented).  Since data can't currently be passed bi-directionally there isn't a "single source of truth" and often both the host and nested families have to have the same or similar formula's that could be eliminated if those values could be passed both directions.  

The user time and training needed to input data into upstream families (manually or with Dynamo) would be eliminated and QC of that transfer wouldn't be required.

There is also flexibility and options I've avoided adding simply because the data would have to be passed manually.

[Susana_Duarte_LMSI]

Not sure about all the complexity explained for every case, but I do agree that complexity could be reduced in some cases because the would not need to be duplicated information, formulas and objects.

One example is the need to have multiple voids (and their formulas) because one is used to cut the family and another the host in the project. Same with the connectors theme... Doing a family with multiple water meters is a nightmare. This is not an easy theme, but one that would really pay off to put some time into it.