One Less Button: Living in a Typeless Model Part 2

There was a time when playing a video game meant punching a button as fast as possible, eventually straining the muscles in the hand.  Then a wonderful device became available that could simulate repetitive button pushing where the user simply holds the button down.  Imagine watching two players side by side. One madly punching buttons while the other holds it down.  Who would you think is being silly?

Now, transition over to two designers modeling an HVAC system in 3D.  One designer is placing each element and connecting everything together.  The elements are static and the size has to be changed manually every time it is needed.  Double checking the work would require checking calculations externally from the model.  Now, let us think of a second designer.  The elements are still placed manually and connected together, but the sizing is accomplished automatically through performance requirements collected in the model.  Changes to the performance are instantly reflected in the size selection of the Families and the performance data can also be used to size the duct or pipe connecting everything.  Double checking the work would require engaging some form of data feedback in the model.  Who would you think is being silly?

Revit Families can have Family Types that allow for preset information to be used for specific equipment sizes.  The user has to manually choose a Family Type in order to achieve the correct size.  What if the Revit Family didn't have any Family Types because the information was shown through instance-based equations that calculated the information used to decide the size.  Air requirements are added to a Zone, that causes a Terminal Unit to increase a size and increase the capacity of the hydronic reheat coil.  Now that coil will adjust the heating water flow requirements of the piping system it is connected to.  One change in the system has a cascading effect on other elements.  Who would you think is being silly?

-Craig

www.ModelingDynamics.net


Source: http://en.wikipedia.org/wiki/NES_Advantage

Living In A Typeless Model: We’re Not Talking About Voice Commands

If Susan told her son, Eddie, to buy 10 Granny Smith Apples that each weigh 12 ounces for Grandma Jane’s Perfect Apple Pie recipe, she is asking for ten 12 ounce Instances of a Type of Granny Smith Apple.  Because Eddie heard her wrong, he bought 10 Red Delicious Apples of various sizes from 8 to 14 ounces.  He got the wrong Type of Apples and the Instance size of each apple was only affecting that specific apple.  That is a general idea of what Type and Instance are referring to in Revit.  A Type Property applies to all elements and changing the value in one will change that value in all occurrences.  An Instance Property applies only to the one element and directly changing the value does not affect other instances.

  

Using Type Properties may sound like an advantage, but what if Susan wanted to change the recipe and provide 5 Granny Smith and 5 Red Delicious.  If you changed the Type information for one Apple, it would alter all the Apples and there is no way to prevent that as long as the Apple selection is a Type property.  If you were to change the Type Property of the Apple to an Instance Property, then half of the apples could be changed independently.  The question then becomes what if we have 100 Apples and need to edit some of them.  Do I need to individually edit each instance?  The complex answer to that is simply No!

Instance properties can be edited in groups through schedules.  Obviously, the parameter being used must be available in a schedule.  In this case, Susan decided to only change the 14 ounce apples back to Granny Smith.  In the schedule for Apples, sort by the Weight and uncheck the requirement to ‘Itemize every Instance’.  This is referred to as collapsing a schedule.  Every instance of the Apple is now represented in a common line by the corresponding weight and changing the parameter value will edit every instance simultaneously that is represented in that line.  When the edit is done, the schedule can be expanded by checking the ‘Itemize every Instance’ box.  Sort by Mark and see what the single edit did for Grandma Jane’s recipe with Susan’s twist.  By facilitating as many parameters as possible with Instance Parameters rather than Type-based parameters, users have more flexibility in manipulating data throughout a model.  

One interesting fact to note, Instance-based equation results can contain type-based parameters.  Type-based equation results cannot contain instance-based parameters.  Varying values of a parameter cannot logically provide the same result in an equation.  Using Instance-based parameters for results will free up the potential for information and make it easier to obtain logical equations that work.  We’ll get deeper into that next time.

-Craig
www.ModelingDynamics.net

DISCLAIMER: All names appearing in this post are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

The Contingency Plan: Default Parameters

After about five minutes in Revit trying to develop a schedule, it is easy to see how unforgiving the parameters can be.  Get the wrong parameter, either from the family or the schedule, and nothing in that field works.  It’s no wonder that a lot of firms have moved away from using any Live Schedules and sticking with manually Drafted Schedules.  The stress of creating schedules may be gone, but not the time savings from a well-developed system of families and schedules.  It is an uphill battle, but once the system is running, the benefits of manipulating data through schedules become a major benefit.

There are many default parameters throughout Revit that automatically show up under certain categories of families.  Why not utilize them?  Well, in a way they are being utilized by leaving them alone.  The setup of parameters is not forgiving and there really is no way around that.  Two parameters cannot occupy the same field.  So what happens when the setup is not working and there is a deadline looming before lunchtime?  It is imperative to give yourself a contingency plan for just that occasion.  When you prepare for unexpected circumstances, they don’t become migraines to a project team.

Unknown Parameter in Tag?

The ‘Comments’ default parameter is possibly the most useful parameter in Revit.  So leave it unused for normal operations!  When something does go wrong, it is available to use when there is simply not time to fix what isn't working as planned.  Also, many of the default parameters may be used by Manufacturers to represent their product. Utilizing parameters from the Master Library allows for the values in the default parameters to be preserved.  One other topic, to cover another day, is the importance of having backup parameters when automatic sizing or calculations don’t function properly.  Create content to be populated automatically, but when the system isn't ready for full automatic performance; give yourself a manual override (812ManualOverride).  That’s when Live Schedules really get fun!

So, leave the default parameters for backup support and also develop parameters that can be used when needed to get project data on plan before a system is fully functional.  The end goal is still completion of a project and documentation of the model, not necessarily getting everything in a model running perfectly.

-Craig

www.ModelingDynamics.net

A Rose Is A Rose: Shared Parameter Names

A rose by any other name is still a rose.  So, no matter what it is called, a rose will carry the same attributes.  It will look the same, smell the same and hopefully bring smiles to certain loved ones just the same.  Call it a Cinnamomeae and it is still the same flower.  Similarly, despite what a Shared Parameter is named, or even what group it is assigned to, it is possible for it to perform seamlessly with Models and Family files.

The most important attributes of a Shared Parameter are the Global Unique Identifier (GUID) value and the Datatype assignment.  The name and group can change without affecting the performance of the parameter.  Change the GUID and the Parameter is now a separate Shared Parameter.  Change the Datatype and risk corruption in a file and loss of that project.  Because of this, great care has been taken to only change the name and provide a starting point for the grouping of parameters.

As the Shared Parameters were sampled from manufacturer families, there began to develop a library of parameters that were found across many different sources.  As Shared Parameters are added to the Master File, the original name of the parameter is archived and a new name is given using the Labeling Convention (Reference Here) based on its properties and purpose.  The Labeling Convention will help identify the parameter as part of the Master Library, but won’t affect the Shared Parameter’s ability to function in a model that has not adopted the Labeling Convention.  

Families that have already been created using parameters from these existing libraries (AD 1-1) will still work, without any modification, in schedules that are being used by Families of the Labeling Convention (ME 1-2) as shown below.  As the existing families are inserted into a model following the Labeling Standard, the Shared Parameters will be labeled according to that standard.  Opening the Family, from within the model it has been loaded into, will also replace all the old names of the parameters with the new names.  Families originating from an existing library will work with new families following the Labeling Convention of the Master Library in the same Schedule, provided they are the same GUID, without doing any work.

Did anything else catch your attention?

-Craig

www.ModelingDynamics.net