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

Why do we drive on Parkways and park on Driveways?

It never ceases to amaze how the name of an item will influence a person to believe that item may actually carry that property.  High Definition Hair Color Products probably doesn’t mean the same thing as High Definition Television Sets when considering what ‘High Definition’ is representing.  Just because an object carries a certain name does not guarantee that it will have that characteristic.  The Name should provide clarity, not add confusion.

A parameter named Voltage means nothing to describe what information it actually contains.  A user wants to believe that that parameter is an actual value of Voltage, but it could easily be a just number or simply text.  Also, lists are shown in alphanumeric order.  Looking for Air Flow parameters based on a system name would require searching through an entire list, even in the same group, if they are not somehow bundled together.  Using a Prefix of 227 will bundle all the Air Flow parameters together in one area.

All the possible attributes for a shared parameter, the Disciplines, Types and Groups of Parameters, were considered when developing a Prefix Standard in the Labeling Convention.  The categories naturally developed based on the available options.  The order of the numbering also aligns with the current list of options when working with Shared Parameters.

Some standard libraries have developed a brand for each parameter, in order to identify that parameter with the library it belongs to.  This requires every equation or reference to a parameter to show that brand in it.  Most libraries do not use any special naming procedure that easily lends to confusion once multiple parameters are found in the same model, carrying the same name, but different GUIDs.  Selecting the correct parameters becomes very difficult.  The Prefix provides a recognizable brand that is more about function than just recognition.  As parameters are sampled, they are renamed according to the Labeling Convention and obviously there are many instances where duplicate or redundant parameters turn up.  The Master Library does not contain duplicate parameters that carry the same name, giving priority to the dominant parameter.

300Voltage is a Text Parameter and 321Voltage is an Electrical Potential Parameter.  300Voltage is omitted from the Master Library, because it is not necessary while a 321Voltage exists.  Similarly, 224PressDropCoilCooling is a Shared Parameter for the pressure drop across a cooling coil that is a unit of pressure and is found in the Revit Master Shared Parameters v2.1 from Autodesk.  Another example is 320FullLoad, which is a parameter for Full Load Amps that is based on Current also found in that library.

The Prefix helps sort the Library of parameters in an understandable order, provides a branding as well as important information on the parameter.  A quick reference of the Prefix Sheet can be seen HERE.  There is also a PDF of the Prefix Standard available when you download the Master Library packet HERE that is FREE.  When dealing with Units of Measurement, this will hopefully become clearly beneficial.  That is for another time.

-Craig

www.ModelingDynamics.net

What is a GUID anyway?

Computers don’t think like humans, yet.  There needs to be some form of code that allows for a massive database of possible parameter combinations to contain data.  The idea of one organization managing all those codes in the world just doesn't make sense.  A Global Unique Identifier, or GUID, is a 128-bit alphanumeric value that is created by a random generator ^[1].  If you are worried that the world will run out of these values, know that there are about 5.2x10^36 possible combinations.  Still concerned? If each person copied the entire internet every second, there would only be enough GUID code combinations to last about one billion years ^[2].  Even if those numbers are a little off, the concept is that there is a vast space available.

Keeping that in mind, it makes sense for Autodesk to utilize the system within the B.I.M. software of Revit.  It is critical for Revit to protect the information of a model from corruption.  Using the GUID values helps accommodate this.  With this advantage, also comes a major disadvantage.  If two shared parameters carry the same Name, yet have different GUID codes, then they will not populate the same tags or schedules.  The GUID must be exactly the same for parameters to work collaboratively.

It takes some work to get one company into a standard where everything works well internally.  However, any Revit Families developed end up being generic for those families to work from one project to the next.  Families from a Manufacturer don’t tend to work unless someone takes the time to modify the parameter assignments to fit a specific schedule or tag.  When available time becomes a factor, it is easy to drop schedules completely and revert back to drafting the information.  If only manufacturers were developing their families using the same shared parameters that companies are using in representing equipment selections in the B.I.M. models.  With the amount of possible GUID assignments, it is no coincidence that some Shared Parameters with the exact same GUID information are showing up in multiple sources.

Standard parameters are out there, are being identified and placed into the Master Library.  As the Master Library is adopted, families and schedules will begin to work together, regardless of where they come from.  Manufacturers can begin to provide equipment using the Master Library, if not already.  Companies would be able to standardize their own schedules and not have to worry about the fields populating correctly.  No more manually drafted tags and schedules and the information can be provided that is referenced throughout a model.  Swing by HERE for your own Free copy of the Master Library.

-Craig

www.ModelingDynamics.net

[1] http://en.wikipedia.org/wiki/Globally_unique_identifier

[2] http://betterexplained.com/articles/the-quick-guide-to-guids/

Not a What or a How, but a Why

It isn't What that drives you or How that intrigues you but the Why that compels you.  Technology is advancing, but the Why must remain the driving force in the scope of a project.  Dreaming big is great when time and budget are thrown out the window.  Showing What is possible means nothing when it cannot be accomplished in a necessary amount of time.  Even showing How it can be done, may not convince anyone if they don’t see an advantage to the effort.

It is the Why that has to compel us to achieve the What through the How.  Why draw on paper when the information can be developed faster on a computer?  Why draw multiple 2D views when a single 3D view can create the same content?  Why design and then model the content separately when the design can aid in the modeling?  Why manually change sizing when the design changes in the model can automatically provide the correct size as controlled inputs change?  Why manually draft schedules when the schedules populate as model elements are placed?  Why even settle for one manufacturer’s schedule when more standardized schedules are needed from project to project?  So, the question becomes Who is going to provide this, What does it look like, How is it accomplished and When will it be available?  

What if the shared parameters were already out there?  How could they be identified?  How is it possible to know which ones to use?  In a constantly growing library of shared parameters, a collection of parameters began to rise to the top.  These top parameters were found in multiple families across many major manufacturers and companies.  The Master Library is based on the discovery of these parameters and follows a Labeling Convention that identifies the purpose of each parameter.  

Hopefully, the Why becomes evident and the What and How will follow.

- Craig

www.modelingdynamics.net