Showing posts with label Calculations. Show all posts
Showing posts with label Calculations. Show all posts

Friday, September 28, 2018

Color Fill Calculation Failed is Back

This warning appeared quite a bit with Revit 2016 and patched in subsequent updates.



I've clicked Restart to no joy and I've submitted the error. I've done the Edit Color Scheme and Cancel process described for Revit 2016 with no joy either. Hopefully it will get sorted out again.

Friday, September 07, 2018

Post Echo - Units - Accuracy - Tolerance

I saw David Baldacchino's tweet yesterday sharing a link to a blog post for another software product called FME from Safe Software. The article goes into detail more related to their own product naturally but it does describe the math and computer problems that developers deal with. I found it quite interesting as well as confirming much of what I'd read and been told in the past.

Have a look! It's titled: "FME 2018 Infinity War: How Automatic Tolerance Defeats Infinite Precision without a Snap – but with Anchored Vertices!"

Thursday, September 21, 2017

Fixture Units don't Update

I read a post at RFO that said the value for Fixture Units added up along a pipe run were correct at the pipe (in properties) but that tags attached to those pipes did not report a matching value. My first thought was that the system's Calculations parameter was assigned to something other than Flow. So I mocked up a quick test (using version 18.1.1.18 - 20170907_2315(x64) - 2018.1.1). Three families, two with the same Fixture Units assigned and one rogue.


I changed the middle fixture to be the same as the outer two and the pipe properties responded, the tag didn't (2nd from left). I took a look at the Calculations parameter for the Sanitary Piping System. This is using a stock Imperial Plumbing template. It's already set to Flow.


I switched it to None, clicked Apply, and the tags responded with this (Performance does the same).


I changed it back to Flow, clicked Apply, and the tags responded again but now they report the correct values.


I thought that there might have been a subtle change within the Mechanical and/or Piping settings that I missed when Revit 2018 arrived. I don't think there is though.

If you're counting on Fixture Units being added up and reported correctly in tags, you'll need to keep an eye on this. I've been able to wake up the tags by toggling between Calculation Settings for the Pipe System.

Added: Temporarily adding a pipe or altering the connected pipes also cause the tags to wake up. Also, just to make things stranger, changing the fixtures again I find the information displayed in properties of the pipe does not respond either, nor does a schedule of Pipes. However, if I have a Piping Systems schedule that does update as changes to fixtures are made.

Sunday, April 24, 2016

Revit MEP - Wire Size AWG vs MM

I wrote a post about this subject before. There is an app at the Autodesk Exchange Apps that offers trap door access to revise the bias toward AWG size versus.

It is called Convert Wire Size (AWG to MM) and it sells for $4.00 USD. I haven't used it myself but for those firms that need wire size reported in millimeters squared it may be the solution you need/want until Revit itself allows us to switch the criteria directly itself.

I'll be curious to hear how well it satisfies what engineers are asking for.

Friday, April 17, 2015

Revit MEP - Circuit Length Calculation

I received an email asking if I thought it would be possible to use a Line Based family to calculate wire length for circuiting purposes. It was prompted by reading an earlier post about using them for Egress Path calculation and documentation. I think it's a reasonable approach for Egress Paths because there is no such tool or concept already in Revit.

Electrical circuits on the other hand do calculate their length already, granted it does so simplistically. It combines the X/Y/Z distances of the devices from the panel (and each other) to arrive at a total circuit length.


A friend some years ago sent me a PDF that showed a bunch (a couple shown above) of different equipment and device layout schemes he did to better understand how Revit arrives at a value for Circuit Length. What it shows is that Revit does nothing to factor in obstacles which force the wiring to go up or down or around the things that are more than likely going to increase the total circuit length.

To be fair...how could it really? How detailed is the model? How long do we want the software to interrogate the model, the linked models to do a better job? It's a bit like requiring all conduit to be modelled, even 3/4" conduit feeding single gang boxes in a wall when there isn't a single stud in the model. Like with so many things in life, it's about context.

It's one thing to put a single gang box on a wall to indicate one is required here and another thing entirely to run conduit to all the way to it when you can't be sure it can really go there. Or like showing a pair of outlets back to back on a demising wall in a residential project where fire rating and sound attenuation would require them to be separated by a minimum distance.

Some things are still conceptual (schematic) in nature even in fairly detailed models. If we start modeling every stud then perhaps it becomes more reasonable to expect more system detail too. Then again if I have to create a run of (15) 3/4" conduits across a wall or ceiling I probably ought to model that situation because it's going to take up a lot of space and everyone else ought to be aware of it.

It's also been my observation that no matter how good software gets at a task there are always outliers that dismiss its results as still wrong. That written, it does matter and Revit should improve how it does calculations and how much say we have in the outcome because the length it calculates is also used internally to contribute to other calculations like wire sizing and voltage drop.

Setting aside how circuit length should be calculated (it might surprise you to know that engineers don't always agree on this), I'd consider this approach if my task was to determine how much wire was needed, a little closer to actual requirements than might show up in the circuit properties. I'd create a schedule focused on Electrical Circuits.


What you see above: I created a couple panels and added a bunch of duplex outlets. I assigned them to circuits. The schedule's second column is Revit's calculated length, no more effort on my part than placing devices, creating circuits and choosing a panel.

I sorted the schedule by Panel and then Circuit, provided a header for Panel and footer for totals. I added a parameter for Length Factor (a number) and then a Calculated Parameter for Total Estimate (a length) which uses a formula of Length Factor * Calculated (column 2).

Then I consider each circuit's circumstance and enter in a factor that increases or decreases Revit's own calculation according to how easy or hard the actual wire run or routing will be...or at least what I think it will be. A factor of 2 doubles the length etc. This calculation doesn't factor into load calculations like for Voltage Drop...but then neither would using a line based family.

This doesn't account for situations that might share a neutral (or ground) or runs that are comprised of individual conductors in conduit (like THHN or THWN) or a wiring combined into a common jacket like Cerro's NMB (a typical household wiring product).

That's the risk/difficulty of automatic calculations, the closer you examine situations the more outliers there are. It can be a bit like arguing about something being 99.6 percent correct. If it costs another $1000 to get to 99.9 or 100%...is that difference worth it?

Friday, April 10, 2015

Spaces instead of Areas

Area plans have their quirks. They can only exist in their own special area plan views. They've got rules and quite often people want to break those rules. If we need to do that then we end up sketching boundaries a lot. Areas don't know anything about Rooms either. That means we're probably going to have to enter some data twice if we must use Areas pretending to be Rooms, all to document fussy Room area requirements

If that's the situation we find ourselves in...do we have access to MEP's Spaces? If so we could consider...this...

The plan in this image is an architectural model (yeah really simple mock-up). Is it obvious what I've done? I've got Room tags reporting area only as well as Space tags reporting a little different area value along with Room name and number. It also has a Color Scheme applied to Room departments.


It's also a separate model I called Area Calcs. I linked the Architecture model into Area Calcs. The Room tags I mentioned a moment ago are actually Room tags, tagging each room's area in the link. For Spaces however I opted to just sketch Space Separators over the linked model since I need to identify different parts of the room's boundaries to calculate area anyway. A Space isn't different from a Room when we rely on walls for their boundary, in how they calculate area at least. Sketching our lines gives us complete control over the results without dealing with Area Rules.


A Space Separator is a linestyle (like Area Boundary and Room Separator) and I changed the appearance to a much thicker burgundy line so it stands out against the linked file's plan. I ended up applying transparency to Walls too. Once I defined the boundaries I needed I used the Space tool and opted for Place Spaces Automatically. This creates a Space wherever one is possible within the boundaries I've created. This is done floor by floor, assuming there is more than one floor.


Just in case you weren't aware of this already, a linked file has a Room Bounding option.


If this option is selected then Place Spaces Automatically creates Spaces wherever Revit finds Rooms and valid boundaries even where there aren't any rooms (note my interior design comment later). Since I need to define room area differently that's not going to help me now. It's intended to speed up the process for engineers while they are preparing their project to start work.

Now that I've got Spaces I can take advantage of a separate tool called Space Naming Utility (SNU). It is crazy that this tool is still a separate installation but it is. At least it isn't locked away in subscription only access anymore. I keep hoping it will show up inside Revit in the next release.

Sorry I digress, it (SNU) will read (from the linked file) each room's name and number and pass it to the equivalent Space's name and number.


One risk here is Revit might not figure out which Room is supposed to be related to a Space. However, if we examine the properties of a Space we'll see right away whether Revit can see a room relationship or not. Plus any Spaces that don't update will be a clue or at least identify a Room that hasn't been filled out with information properly yet. I'm hoping to apply the 80/20 rule here and win.


If I want to use Fill Patterns too, like below, I can create a separate view that only shows a customized Color Scheme that applies Fill Patterns instead of a solid color fill. Then I just stack (overlay) this view on top of the other floor plan on a sheet. I just need to make sure the view is using Wireframe so it doesn't mask the floor plan.


I can even add a separate Color Scheme legend to the other view that's stacked over the floor plan.


Choosing this route might come down to how I answer these questions:
  • Do I have Spaces? (Are they part of the Revit version I use?)
  • Which is worse, sketching Space Separators or Area Boundaries?
  • Which is more fun, using Space Naming Utility or manually updating Area data to match relevant Room data?
  • If I know a Dynamo/API programmer then maybe I can improve the Room to Area process instead?
This popped into my head last evening while I was mulling over a client's email. I've suggested using Spaces in the past to help deal with linked interior design models so this time around it didn't seem quite as crazy to me as it did the first time.

Want to poke around the files (Revit 2015) I used for this post?

Area Plans
Area Calcs

Your mileage may vary...

Monday, February 23, 2015

Revit MEP - Electrical Wire Size

Revit mEp is very American because it is hard-wired to do its calculations based on the AWG based wire sizes that are defined in the templates Autodesk provides to us. When you need to reference metric sizes/standards instead there is no place to change this bias and if you attempt to change wire sizes to metric equivalent (CSA or Sq. mm) values you'll find calculations, like Voltage Drop, either cease to work or you get strange results.

Working through this issue with a client recently they decided (or at least hoped) it would be acceptable to provide a chart that allowed the reader to cross reference the AWG size against the locally relevant size. This firm is based here in the USA but working on a project outside the USA. Perhaps in that context this could be forgiven by the client. I don't know how well that approach will work for firms that are working at home, outside the USA.

Fwiw, Autodesk IS aware of this bias. Providing more flexibility is among the many things they have to find time to include in future releases.

Saturday, February 07, 2015

Revit 2015 MEP - Calculations and Performance

When Revit 2015 Update Release 3 became available a new MEP setting became available for Pipe and Duct Systems called Performance Mode. If you examine the Type Properties of a Piping system (or Duct) you'll find this additional setting.


The help documentation (link below) offers up this table to break down which system classification calculations are made available to us and which are able to take advantage of this new Performance choice.


This is intended to improve performance when working/editing large MEP system networks. For each system type we choose to assign this Performance setting to, Revit's system propagation is disabled on every system assigned to that system type. The Calculations parameter can be included in schedules, which can make it easier to toggle on and off. Keep in mind, if the file is opened in a previous build (not Update Release 3 or newer) then the parameter may/will not display correctly.

At first glance it doesn't seem much different from choosing None because to restore system propagation we have to change the setting back to use a calculation method, other than Performance or None. My initial expectation was that None would shut down calculations entirely and Performance would permit some calculations but do so in a way that would improve my experience or perception of performance, Revit's responsiveness as I work.

As I've learned from the developers, despite carrying a name that suggests to me otherwise, under the hood, using None does NOT tell Revit to completely ignore everything related to the connected network. This new Performance setting DOES allow Revit to completely ignore any system (as far as calculation propagation is concerned) that is assigned to the Performance setting.

As I understand them, the two choices are a trade off between accepting slower performance for each and every model (our) interaction (by choosing None) or having a quicker response (from Revit) for each model interaction, choosing instead to endure a longer wait after turning back on calculations (using Performance). Perhaps in a future release we'll just see None eliminated or replaced by Performance? At the very least I think the naming is a bit misleading.

A side effect of using this setting is that duct/pipe sizing and the System Inspector will not work on systems that are assigned to it either.

You can READ the Help Documentation HERE.

Thursday, November 21, 2013

Room Area Net vs Gross

When it comes to documenting room area we have one global setting called Room Area Computation, found in the Area and Volume Calculations dialog.


We get to choose from four options that affect the entire project's room area calculations: Wall Finish, Wall Center, Wall core Layer and Wall Core Center. Wall Finish tends to work for net area calculations while Wall Center works better for gross area.

When we need to be able to show both net and gross one approach we can take is to use Area elements and Area plans. Unfortunately area and room objects are totally ignorant of one another. That means an area plan using area elements is NOT a room so we've got a lot of redundant data entry to deal with. Another way to deal with it is to print sheets with the Room Area Computation set for one condition and then switch to the other setting for other sheets intended for that condition. We'll need some "redundant" views with tags etc. but perhaps it will provide the necessary differences required.

Another possibility if we are using Revit, the version that includes all the disciplines tools, is to take advantage of MEP Spaces. They ignore the Room Area Computation setting, they only reference Wall Finish. This means I can create a space for each room, yes some redundancy. I can use the Space Naming Utility (subscription extension) to pass the name and number of the related room to the space name and number parameters so I don't have to enter the redundant information. The end result could look something like this, where I use a plan focused on spaces and another focused on rooms to show both net and gross area calculations.

This nexst image is Gross Area using Wall Centerline as the Room Area Computation settings.


This image is the Net Area using Spaces instead, leaving the Room Area Computation the same as for the above.


This is using Area elements instead matching names and numbers manually. The API might be able to be harness to resolve this to some degree.


Something to consider.

Saturday, November 09, 2013

Foundations and Insulation Calculation

I got involved in a thread at RevitForum.org that asked about calculating the total bitumen insulation required to cover concrete foundation surfaces. The original post described using the Paint tool and how much time it took. I always wonder if people are responsible for the calculations or just curious whenever I read such requests. Sometimes I ask. Intellectual exercises might be interesting but they can waste a lot of time if the results don't actually get used by someone.

Since I put the effort into it already I decided to use this post to share the example project I created in response. I shared an earlier version in the thread but this one has more ideas expressed.


I'm inclined to try to use schedules and formulas to calculate/predict the insulation material required instead of using paint and a material takeoff. The Isolated Foundations (footings) have one form (most of them) so there aren't compound layers like foundation slabs, floors or walls.

It isn't as simple as just reporting all the surface area of each kind of foundation. It isn't even simple to do just that. The surface touching the ground doesn't get the insulation (my understanding in this situation). No insulation is required where a column sits on a footing so we need to subtract the column base area from the top of footing surface area. No insulation is required where a wall sits on a footing either.

We also have parameter inequity. Isolated Footings don't have a "thickness" parameter. Foundation Slabs and floors do. Inconsistent application of dimensional values is the sort of trouble we face when we use the provided family categories (as their naming/behavior implies we should) and try to compile their information using the "same" notion of dimensional criteria. They just aren't all equal, they don't have the same "beliefs".

My approach started out with a foundation schedule that includes footings and slabs, a schedule for walls and a third for columns. I needed to distinguish between footings and slabs so that I could create formulas to figure out the area for the top and sides of each kind of footing. Floors and Slabs have Default Thickness and Perimeter. When they are rectangular they also have Width and Length. If they are irregular they don't. Foundation footings don't have thickness but have Width and Length.

I used a formula to divide the Volume to arrive at an Approximate Height to use to calculate surface area for top and sides. I used a parameter called Is Slab (an integer) so my Bitumen formula could decide which formula technique applied. I just enter a 1 for slabs and 0 for footings. This is the foundation schedule for wall footings, isolated footings and slabs/floors.


As you can see I added some rows to the header to explain the empty cells in the schedule. I also added the formulas (after capturing the images) to the comments so it's possible to validate the results without having the model.

Here's the schedule for the walls. I've not resolved the overlap of walls onto footings or the walls and their own footings in the schedule above. I'd probably create another schedule for subtracting the bottom surface area of the walls, or if possible include it in this one.


And here's the schedule for the columns, I put the (-) in the header to make it a little more obvious that the area should be subtracted from the other totals.


You may already know that columns don't have a base width or length parameter that we can see in schedules. They have a type name but the parameters that govern their base dimensions are called "b" and "h", like the corresponding graphic in some structural design manuals I've seen. I added two shared parameters, Base Width and Base Length, to the column family and just made them equal to "b" and "h". That's probably the easiest way to resolve content that fails to use system parameters that are compatible with other families, as well as content that you download and find the same conflict between other content of the same category.

Assuming the approach above is completely uninteresting these are some possible alternatives we could consider.
  • We can "paint" on materials and there is a Split Face tool which will work on floors, foundation slabs and walls but not structural foundations or columns. We can model all foundation elements as floors and/or foundation slabs which would make it easier to use the Split Face tool and then paint on the insulation.
  • Use a combination of the schedules above and some use of the Paint tool and material takeoffs.
  • We can create separate families for the insulation conditions that can be scheduled by themselves, or at least for the foundations that can't be "painted" with Revit's paint tool.
  • We can build more complex footing families that have an additional form(s) for insulated surfaces and these can in turn be used to define them in a material takeoff, instead of a regular schedule.
  • A talented programmer with the Revit API could take into account all sorts of permutations and generate a pretty comprehensive summary).
I've posted the project file if you'd like to DOWNLOAD IT. Happy insulating!

Wednesday, March 13, 2013

Revit MEP Heating and Cooling Loads Results

I received an email from a Revit MEP user asking about results that don't seem to make sense. I'm writing about this because after some experimentation it seems odd to me too. This doesn't involve a complex model, just a simple test they did using a single room. I attempted to mimic their emailed explanation fully realizing that there are myriad possible things I could do differently. Despite the possible variables I was able to reproduce what they were concerned about.

Still Curious?

When they set up a test and then changed one variable (Outdoor Air) the resulting report shifts peak cooling month by one month (their result).

These are the test conditions: Walls surrounding a Space such that it is 100 SF. I placed a floor, ceiling and roof but I don't know that they did that. I used these settings for Occupancy, lighting and power.


These are the energy settings I used for the first report.


These are the energy settings I altered for the second report, only changed the Outdoor Air setting, nothing else.


These are the two reports side by side. Report on the left is the one without Outdoor Air changes and the one on the right is after changing Outdoor Air. Notice the two month advance? There are also subtle Dry and Wet Bulb values.


Their question to me and mine now as well is, "Is it reasonable to expect a so called simple change like this would cause such a jump in the calculation time frame?" I've recommended they reach out to the Autodesk Revit support team so they can examine their dataset first hand. Seems odd to me though.

I should also mention that I changed the Outdoor Air for both the Zone that the space belongs to and the Energy Settings dialog. I didn't seem to matter when I tried changing only one of those for the Outdoor Air.

Comments?? Did I miss something obvious?

Friday, March 08, 2013

Concrete Volume between Slab and Beams

A message via Linked In arrived the other evening asking about the volume of concrete when slabs and beams are involved. The hopeful question hinged on the slab reducing its volume by however much the beam overlapped the slab. The answer is a qualified "yes" because it is aware when Join Geometry is used but in the opposite direction, beam reduces volume not the slab.

Here's a floor slab that is 20'-0" x 20'-0" x 6" thick and a 12" Wide x 24" Deep x 20'-0" long concrete beam reporting a volume of 200 CF and 40 CF respectively, before using Join Geometry (slab properties shown).



Here's the properties of the beam before Join Geometry as well, reporting a volume of 40 CF.



Here's the properties of the beam after Join Geometry, now reporting a volume of 30 CF.



I didn't bother capturing an image of the floor slab, its volume didn't change, still 200 CF. I hope you'll take my word for it. The point of the exercise is to determine how much concrete is really needed, at least in my mind. The floor slab volume is intact (for this particular condition at least) but any beams that are joined with the slab will reduce their volume appropriately.

That means a two schedules, one for slabs and one for beams, should provide a reasonably close total if you look at both schedules together. It might be cool if the slab could inherit the beam volume and report a total that included the beams or the reverse subtract the beams from the slab.

In the field the beam and floor, minus any topping slab, are often poured together so the reinforcing ties it all together. Curiously, the way Revit deals with beam sizes and types is generally in conflict with how engineers think of the beam size as it relates to the slab. It's never simple or easy is it?


Saturday, December 01, 2012

Set Calculations to Stun

Attending sessions at a conference is always a good way to come up with ideas for new blog posts. This post was inspired by David Butt's session at Autodesk University 2012 about Pipe and Duct Systems. I was working as one of his lab assistants and he mentioned this so I made a note to myself to mention it again, here.

By the way sorry about the title, I was thinking of the Star Trek "Set phasers to Stun" command that Captain Kirk often uttered. Literary license, I was just rhyming Stun with None.

In Revit MEP you can create systems for pipe and duct, meaning just the act of sketching one of them assigned to a particular system will impose certain design properties and graphical qualities to that element automatically. In the past the only way a duct or pipe could behave this way was to connect it to a component or to another duct or pipe that was already. That made it harder to just sketch pipe or duct (schematic design) and use it to represent different uses, like supply or return air, or hot versus cold water.

One of the properties of these systems is called Calculations and you can choose between None, Flow Only or All.


Since Revit only does fluid based calculations (piping) it doesn't make much sense to "waste" any CPU cycles on trying to do calculations on pipe systems for gases like oxygen or nitrogen. Same is true if you really aren't going to rely on Revit for pipe sizing or related calculations either. Any system that isn't going to need this ought to be assigned to None.

Wednesday, July 25, 2012

Panel Schedule and Load Calculation Addition

A thread at AUGI that started in December 2011 described a situation that Panel Reports show some connected loads as "0". The thread wandered around a bit but Martin Schmid with Autodesk responded on Tuesday with some insight after the development team did some research. Martin prepared a video to help explain what can cause this.

He wrote in his reply at AUGI:

I was able to reproduce this today with some help with our development team. The issue seems to be related to having your connector's Load Classification Parameter associated with a Parameter that has an empty value specified.

You can see in the video that when I create a Load Classification parameter, it has no value... when I then associate that with the connector, the connector ends up with a load classification with no value. Thus, when you connect this, there is no value that propegates into the panel totals, since the panel totals are dependent on summing values from load classifications. As soon as I set a value on the parameter associatd with the connector's Load Classification, the values tabulate.


A reply at AUGI shortly thereafter reminded members to also check the Part Type setting for their families. Using stock content it isn't likely that this would be the issue but for any custom content that has been downloaded or created internally, checking everything you can won't hurt.

Tuesday, July 24, 2012

Electrical Panel Load Calculations

Another "inside" gem from Inside the System which offers deeper insight to how the numbers work. If you are a Revit MEP user and electrical is your game, then you'll want to read it. Thanks to Martin for taking the time to put it together.

Friday, January 27, 2012

Occupancy Data Application

I've written about the workaround solution for documenting occupancy information in room tags in the past. I've even shared a sample project file based on the work I did for Scott Davis' past firm WLC Architects in 2005 (before he joined Autodesk). Until the API came along we were faced with a semi-inelegant solution that involved manual data entry and checking before plot day. Even after the API nobody really addressed this issue directly, till now...

Rahul Shah (blog: Revit Sticky Notes) works for Wood Bagot in the UK. He responded to a query at AUGI with a promise to write an application to push a calculated value to make Occupancy information taggable. He posted his solution today on his BLOG.

His written instructions on the blog post are:

    NOTE: In order to use this plugin you will have to add "Occupancy Load Factor (as area type)" and "Occupancy Load (as integer type)" shared parameters to your project file and assign them to Room object as Instance. Also, calculated occupany load value is not dynamically linked with other values so if you change room size or occupany load factor then you will have to rerun this tool to update occupancy load value. Please read the Readme.txt file contained in the zip file for more information.

You can DOWNLOAD IT NOW!

Wednesday, September 14, 2011

Schedule Concepts - Calculated Values and Headers

Prompted by a few questions read at RevitForum.org and AUGI in the past few days I decided to record another short video. I used ducts and the notion of figuring out how much they cost based on a cost/ft scenario. The pricing you'll see in the video and screen captures are quite a bargain so you might want to rush out to buy some duct if you can get a supplier to match them?

The concept discussed in the video for calculated values relies on the stock Cost and Length parameters, Cost x Length. The assumption is that the price entered for Cost is the cost of the duct per linear foot (easily applied to metric values). None of this presumes it's the appropriate way to price them, the concepts can be applied to anything else.


The other concept demonstrated in the video is adding a group header to several columns in the schedule. The trick to getting a group header is how you go about selecting the columns. When you click in a header field Revit thinks you want to edit the value. You need to click and drag to select the other columns so you don't just select the column header you click on first...click and drag...then let go of the mouse button to finish. Watching the video is probably more "obvious". Not hard to do, just subtle. Kind of like learning to drive a manual transmission.


Monday, August 29, 2011

Calculations Galore via BIM Productivity

I meant to write this the day after I wrote about the Electrical Productivity Pack post but got side tracked. Jake Boen shared some of his cleverness with a Autodesk University lab I did a few years ago. For that session he created families that provided calculations that don't necessarily derive their results from actual model information, using annotation symbol families.


He decided to make some of these things (calculation minded solutions) available commercially on his new site BIM Productivity.

Some of his offerings are:
Point to Point Fault Calculation
Mechanical Ventilation per 2006 IMC
IECC Allowable Watts per Square foot
IBC 2006 Minimum Plumbing Facilities
IBC 2006 Area Modifications

Check them out!

Friday, February 13, 2009

Math - Data Entry

Various parameters types will accept mathematical equations as valid data. This means you can do some "math" within a parameter instead of figuring what the value you need is elsewhere and then enter it into Revit. To do so you must enter the equal sign (=) first followed by the formula.

As an example: I have three items that need to fit within an available space that is 12 feet wide. I'd like the middle item to be centered between the other two. Yes, I could add a dimension between just the three elements and use the EQ control. But less obvious perhaps and the reason for this post is that I can enter a calculation into the dimension field instead.


Formula is this: =((12'-5')-2.5')/2
In plain english:

Overall Space minus two Desk Widths minus one Desk Width divided by two

The result:

Yes it is easier in this case to do this instead...just discussing possibilities.