Wall Height in Takeoff

[mamoosh]

When you create a schedule of the walls, it has area, volume, length, and width, but no height. For the estimate, we usually need to know how high is the wall, especially since the walls in the same family and type do not necessarily have the same height. This enters a bug in take off since we usually group them in family and type and do the take off on linear feet.
dividing area by length does not work cuz area excludes the openings.
any idea on it?

[Alfredo Medina]

Unfortunately, if it's not by Area / Length, the only other way to get that data is by exporting the model to .mdb (database). In the Walls table, there will be a field called "Unconnected Height" with that information.

[cliff collins]

It may be possible in RAC 2011 to use a "reporting parameter" to give the height value in a schedule if used with Shared Parameters, I have not confirmed this. I'm fairly certain that
a wall width can be reported from a door family using this technique, which is new in RAC 2011. Good luck.

cheers.

[Alfredo Medina]

It may be possible in RAC 2011 to use a "reporting parameter" to give the height value in a schedule if used with Shared Parameters,...


Hmm... but where would you do add those parameters, given that a wall is a system family?

[cliff collins]

Good question.

Perhaps use a dimension on the wall itself, and add a reporting height parameter?

Looks like this does not work, it would make a good Wishlist item..........

Pretty basic request to be able to schedule wall heights for take-offs. LOL

Edit: But, how would this work for a wall with a sloped or radiused top?

cheers

[twiceroadsfool]

You can do it in an in-place family, but it doesnt work well. It will report the Walls "Height" which will not account for edited profiles or attachments.

Im curious: Those of you that want a height parameter, what should it do when a wall has a variable height parameter? (Not being facetious, i really want to know.)

If a wall has an Edited Profile that has arcs at the top?
If a wall is attached to Roofs / reference planes that vary in height?
If a wall is stepped so the top is flat, but at different heights?
A wall thats placed my Mass face that is curved in section so it arcs as it rises... Is its height the max vertical dimension or the arc length?

[cliff collins]

"But, how would this work for a wall with a sloped or radiused top?"

Yeah--I asked that same question above.

But--how about providing the prerequisite ability to have a height reporting parameter for walls of constant / continuous height, as a place to start? The majority of walls in most jobs have a constant height.

Then at least most users could accept the fact that "it doesn't work for walls with profile edits/non-constant heights". Then enter into "hack land" or "workaroundville" thinking for the non-constant height conditions.

cheers

[twiceroadsfool]

Im not disagreeing with that at all. Im nore just curious what it would or should do in those conditions. Id prefer to see it display for Flat walls (as the physical height, not the "entered Height," in the case of flat attachments and flat edited profiles (which shouldnt happen anyway, but i digress).

The moment the top isnt consistant, id like it to just shift to "VARIES" and call it a day. But, for QTO, it still wont help. (But why youd be doing QTO of a variable height wall using a height parameter is beyond me).

Walls by face / non verticals, i have a tougher time with. I guess if they HAD a Flat face i would want an absolute height (normal to the surface), but anything not Flat i would default to VARIES as well. But thats tough, because there is really:

1. Non vertical, flat, uniform. (Has a height)
2. Non vertical, flat, non-uniform. (Has no consistant Height)
3. Vertical, non flat, uniform. (Has a height)
4. Vertical, non flat, non-uniform. (Has no consistant Height)
5. Non vertical, non flat, uniform. (Only has a height as some derivation of arcs and orientation, but could be argued it has one definition of "height")
6. Non vertical, non flat, non uniform. (Never going to have a height).

[Ning Zhou]

maybe wall height on average? this will accommodate most cases (profile edited, sloped, etc.)
thickness = volume / area
height = area / thickness
don't know if this makes sense

[Alfredo Medina]

maybe wall height on average? this will accommodate most cases (profile edited, sloped, etc.)
thickness = volume / area
height = area / thickness
don't know if this makes sense

Well, at least 'height = area / thickness' does not make sense. :)

[Ning Zhou]

oops, lost in math.
height = area / length, area and length should be available in schedule or material takeoff.

[barrie.sharp]

I don't understand why you need a takeoff for height? I thought that measuring the length and knowing the height was to get an area anyway.

[nancejd]

You would want to know the wall height, because as walls get taller, the potential to increase the number of studs per given length, or in the case of steel studs, the gauge of the stud exists.

Why not have an average height for a given wall? Most walls have a level head, ut for variations, at least an average height would give you a good approximation of what you're dealing with.

If I could have a function to round numbers, which could then be used in formulas as the rounded number, that would work best. Then I could calculate what I was after. Basically, I'd like to have functions for all of the mathematical operations.

[twiceroadsfool]

Youre going to decide stud frequency based on the AVERAGE height of the wall? That sounds scary...

[barrie.sharp]

Would the stud frequency increase only at the section of wall above a certain height?
Maybe you would want to schedule wall length within given height ranges?

I am genuinely curious because wall height schedules have been put to me as a flaw in Revit but like I say, our guys only use it to get areas. I'm interested in other applications because it hints closer towards what we need and how the factory might help. Maybe a field that shows lowest and highest would be more useful in certain situations. It is important to ask why we want it because it's not a simple solution

[Scott Womack]

A better question is this. I have in one exterior wallwhich is made up as follows:
1 Brick
2 Airspace
3 Cavity insulation
4 exterior sheathing
Core Boundary
5 metal studs
Core Boundary
6 interior gypsum board

Unlocked the Brick, airspace and cavity insulation on the bottom, and the studs and interior gypsum board on the top. The wall runs 10' from level one to level 2. The brick etd. is set 4' below level one, and the studs and finish are 5 ft above level 2.

A What is the average height?
B What is the correct "area" of this wall?

Becareful what you are asking for. Fixing it may deprive us of some the power/flexibility of the walls.

[nancejd]

Youre going to decide stud frequency based on the AVERAGE height of the wall? That sounds scary...

Decide, no, but use it as a piece in the puzzle, especially when I'm working through the design on a first pass basis, you bet. Generally, I'd up the gauge of the studs before I decreased the on center spacing in any event.

[nancejd]

Would the stud frequency increase only at the section of wall above a certain height?
Maybe you would want to schedule wall length within given height ranges?

I am genuinely curious because wall height schedules have been put to me as a flaw in Revit but like I say, our guys only use it to get areas. I'm interested in other applications because it hints closer towards what we need and how the factory might help. Maybe a field that shows lowest and highest would be more useful in certain situations. It is important to ask why we want it because it's not a simple solution

I don't see how you would do that without breaking the structure of the wall at a horizontal plane, which I think would be more work for a framer. The reality is that most of the walls that are built are straight, plumb, and of equal height across the top. Fields that gave you high and low point for a wall, after it is attached or the profile is altered would be ideal.

[mamoosh]

I see the question is drifted from what it was:
when you use RSMeans, you need the wall height inorder to estimate it in linear feet, right?
"Height=Area/Length" does not work because of the openings in the wall.

I wish the forum had the capability of using graphics to convey the meaning visually.

hope the thread gets back to the main question.

[twiceroadsfool]

I dont think its drifted as far as you think. We all understand what it is youre after. The thing is, the answer CURRENTLY isnt given by the software. So were debating what that answer SHOULD look like, in the event the software became ABLE to deliver such a thing.

Right now, flat it, it wont do it. Yes, there are workarounds, but as youve obviously figured out, theyre going to have upsides and downsides. (Openings, profiles, Stacked Walls, etc)