Retrieve data from nested family

[Keith_Wilkinson]

I'm sure the answer to this is 'no', but I'll ask anyway... 

I have a window that is made up of 2 or more nested window families.  Each of these has an area calc in it.  Is there any way at all to access this data in the parent family?

Cheers

K.

[Keith_Wilkinson]

@barthbradley

yes, the mission as you understand it is correct and your solution looks to work too - thanks.  It's a clever move to keep the area as a length initially to allow you to access the values in the reporting parameter.

The bit I'm not understanding is how you have linked your reporting parameters to the relevant parameters in the nested families - can you explain further?

Cheers

K.

[Keith_Wilkinson]

Ah, okay, there's still an issue - if you change the size of the parent family the area calc in the child doesn't update.... 

Seems @CoreyDaun has looked at this in some detail in the past with no joy... 

I'd still like to know how you linked those parameters though.

cheers

K.

[CoreyDaun]

What? Did I hear my name? 😜

In any case, I've [briefly] reviewed this thread and I think that if a very specific goal is established then it can be reached, but not in as simple or elegant of a manner as you desire.

Is the end goal to create a schedule in which each window family (which is identified by some parameter) will be listed along with the total glazing areas of all corresponding subfamilies? If so...

In the host family, you can employ reporting parameters or link-in the nested parameters and recreate the area calculation formulas, there (in a Shared Parameter). This will be easy to schedule, but every host family will have to be modified to include this calculation, which can be a pain if a host family includes a strong variety of glazing options (e.g. number/shape of areas).

-OR-

You could make the subfamilies Shared, and then 'push' the host Family's identification parameters (and perhaps all other scheduled parameters) to the nested families, and then make a window schedule that includes only the subfamilies and groups them together according to the identifying parameter.

There's a ton of nuance, here, so again, only a very specific ends warrants a very specific means. I hope this helps and that I'm not just repeating what's already been said!

[Alfredo_Medina]

I think the data in families goes in one direction only, like a river. I've never seen a river going in two directions. 🙂

[Keith_Wilkinson]

It's a bit like firing up the Bat Signal... ;o)

Thanks Corey,  I think this is pretty much where I've got to - I've run various iterations of this in different scenarios most of which 'work' but I was just hoping it was something I could simplify by pulling some data through rather than pushing it back.  

The main driver is that it becomes more onerous to ensure every family is reporting the correct values and rest assured no-one is going to check the total until something has gone wrong!  

[Keith_Wilkinson]

I've seen a river go in different directions at different times of the day... well, the tidal part of it at least..  ;o)

[ToanDN]

Below is an example (2017) of using a shared nested family for the panels and subsequently, reporting the sum area for each window assembly via grouping in a project schedule.

[barthbradley]

Why would you want to change the sizes of the windows in the Parent? That defeats the mission you described; which was to “pull” data from predefined components. If you want to redefine the components in the Parent, you are effectively “pushing” data back. This would make “pulling” data from those components redundant, unnecessary – and overly complicated.

The Parent in my family is merely a “mulled” window family containing a combination of windows of a particular type size and shape and – vent and glazing area.  The Parent is reporting a vent and glazing area as a cumulative total of all the different windows in the mulled assembly. Mission accomplished.

Now, if you want to resize one of those components, you would need to do this resizing in the component itself***. For instance, if the bottom window needs to be 500 tall and the top window 1000 tall, you would need to change those dimensions within the nested window family itself, and then reload it. Why? Because the parent is only “reporting” on the component; not defining it.  Try it. Works like a charm.

Lastly, and probably what led to your “issue” and confusion; is that the family I provided back to you, only uses those parameters I pointed out: the ones categorized under “Data” and “Other”. None of your original parameters (which I did not delete) are used to drive any nested window parameters. So, consequently, they effect no change to them.

***The attached family differs from the last, in that both nested family’s parameter values for height and width are modifiable within the Parent – by changing their sizing parameter values under their Properties in the Parent.  Changes made here will “report back” to the Parent, and will update all the vent and glazing area calculations. But note: these parameters CANNOT be associated/linked to parameters in the Parent – because then we’d have a dog chasing its tail.

Hope this helps. Good luck to you.

[barthbradley]

I agree with everyone’s “river” analogy – however, this thread was never describing a bidirectional flow of data between Parent and Child (which is NOT possible with Revit). As I confirmed with Keith, the flow of data he wanted was unidirectional – in this case: flowing from the Child to the Parent (which IS possible in Revit).

Fun Factoid: In 2012 the Mississippi ran backward for an incredible 24 hours in the aftermath of Hurricane Isaac! 

Cheers! 

[ToanDN]

---

@barthbradley wrote:

Now, if you want to resize one of those components, you would need to do this resizing in the component itself***. For instance, if the bottom window needs to be 500 tall and the top window 1000 tall, you would need to change those dimensions within the nested window family itself, and then reload it. 

---

Would it defeat a great benefit of nested families, when they could be built not size specific, and having the dimensions controlled in the host family via nested parameters?

[barthbradley]

I understand what you are saying @ToanDN, but this family doesn’t work the way you’re thinking. Not because it’s flawed, but because it just works differently. Bottom line: it’s the family that @Keith_Wilkinson wanted; or at least the closest that Revit can come to it. Practically, I’ve actually used this technique before to design mulled window assemblies with nested window manufacturer BIM Content. So, I can readily see its benefits.

[ToanDN]

@barthbradley  Okay I can see the benefit if you need to work with static content, e.g. manufacturer's windows.

[Keith_Wilkinson]

There's a lot of underlining in there.

I still need the family to be controlled in terms of size from the parent.  Calculating the areas is much easier to do in the nested family than in the parent - if I have 10 panels and each of which has already worked out it's own area then all I would have to do it total these in the parent which would be easy.  As it stands I need to add formula's to the parent to do this.

We need the flexibility during the design stage to quickly and easily generate new window sizes as the design dictates and with this we need to be confident we are hitting the correct ventilation and light criteria.  So whilst your solution is neat in what it does it doesn't do what I want.... sorry.  I appreciate you input though.  

FWIW I'm clearly not the first to be looking for this as an option and in principle there's no reason the software couldn't do it but I think it's unlikely a 2 way flow of data between parent and child (although limited to one direction for any specific parameter) will be added to Revit in it's current format.  Maybe in its successor or if it gets a ground up rebuild.

[brichev]

barthbradley.  MESSAGE 10. I don’t understand how you do it? Please explain

[lukekvasnicka]

@barthbradley This is fantastic and exactly what I'm trying to do.  Can you help walk me through how you actually achieved the step below? When I create a new reporting parameter in Family9 I don't see any way to have it 'extract' or 'read' the value from Family8's "Formula1" parameter.  What do I need to click?

Family9 has a reporting parameter called “Formula 2”. This parameter reports the value of Family8’s “Formula 1” parameter.

[lukekvasnicka]

@barthbradley Can you help me recreate exactly the example you showed in Message 10 of this thread.  You seem like a pretty active user and I'm trying to replicate exactly the situation you did.  I'm just not sure how you got Formula 2 to report the value of Formula1 from the nested component. 

Any insight is much appreciated! Thanks

[lukekvasnicka]

@Keith_Wilkinson Please stop marking this as a solution.  This is not a solution, it is a question.

[barthbradley · Accepted solution]

I guess I should post here what I sent you by PM a moment ago. I didn't realize there were other inquires about it. 

So, the long and short of what I did was associate the Nested Family Parameter to a Host Family Parameter and then I change the Host Family Parameter to a Reporting Type Parameter.  By doing so, it broke the link between the Nest Family Parameter and the Host Family Parameter - but not entirely.  I edited and added a formula to the Nested Family Parameter and then reloaded it.  As you can see, there is still a Link to the Host Reporting Parameter even though there are "no strings attached". It's actually a BUG I read about years ago, but in this case, one man's BUG is another man's parlor trick.  

[Keith_Wilkinson]

@lukekvasnicka I'm not, Autodesk is emailing me telling me that there is a solution, I've not been near this thread until this morning.  I think something somewhere is broken.  It also seems to be adding 'likes' as well.

Sorry, but it's nothing to do with me.

[barthbradley]

So, basically what you are telling me is that this isn't worth the paper it was printed on?

AARGH!  I'm sooooo disappointed.  I had plans for this windfall.  They're all dashed now.

boohoo.