Using Curtain walling as windows

[m.thomas]

At schematic design we use a lot of curtain walls embedded in walls because we can quickly generate most types of window quite easily on the fly without spending time adjusting and setting up window families.

The curtain walling tool is pretty powerful.

But as soon as we want to start scheduling our windows we have to create window families to get the right width and height sizes reported.

Is there a clever workaround or workflow where we can schedule curtain walls as windows with the correct sizes scheduled ?

[cliff collins]

Good question.

I think it comes down to this:

Are you really going to specify windows, which are used in "punched openings"
as individual pre-assembled units, from a single source? ( i.e. Pella, Marvin, etc.)

Or--can a curtainwall or storefront product be used and specified--
for instance "ribbon windows" which are essentially storefront products,
and/or custom-fabbed into rectangular, single opening "windows"?

If there are large expanses of continuous glazing, then go ahead with curtainwall/storefront.

If there are large amounts of single punched openings, the use window families.
It's worth the time, in that case, to go ahead and set up some window families
with instance parameters for a wide variety of common sizes. Develop the families,
place them in a library, use them on the next job. Schedules are then automatically generated the way the software was intended to work.

I think it is possible to schedule only curtain panels--if you must use curtainwalls
for "windows"--but this seems like a band-aid solution, and not "best practice"
use of Revit, or in specifying the correct product for the application.

Just my 2 cents worth.

cheers...........

[twiceroadsfool]

Pretty much what Cliff said. Develop a decent enough library of windows so in SD/DD you have what you need to manipulate them on the fly, and without costing you a lot of budget.

We use CW tool for Storefront and, well.... Curtain Walls. Including long ribbon windows, which are going to be specified and detailed as Storefront.

Windows are... well... Windows. :) You only have to build the library once. If you do it right, you should have MOST bases covered, and itll only take a a day or so to build a pretty robust library of windows.

[dgreen.49364]

What they said...a curtain wall is a curtain wall. A window is a window. Use curtain walls for curtain walls and storefronts, from the beginning and windows when it is a window. Schedule separately later on and no workarounds are necessary.

[patricks]

We typically use the curtain wall type for actual curtain walls or storefronts with glazing and many times with doors in them.

We also often specify storefront assemblies for punched window openings, but for those we use window families with the correct storefront mullion/glass geometry.

[sthedens]

Amen to Collins, Green, Maller and Patricks.

steve t.

[aaronrumple]

I disagree. The curtain wall tool can be used effectively to lay out windows. And it is fast in schematic. They can also schedule alongside windows.

All you need is a nice un-hosted shared window sash. (Another of the many reason I always make un-hosted windows rather than hosted ones.)

Place this inside a curtain wall panel and constrain it to the ref. planes.

Load it up and have a good time.

You might want to think about how you work the window tag. In the example I've shown, it is a type mark + a mark. This takes care of one window having many different sizes.

If you always make sashes rather than hosted frames, then you have a great deal of flexibility with both windows, storefronts and curtain walls. Swapping different sashes is fast should the manufacture change.

Schedule included...

[twiceroadsfool]

Im completely not knocking it, as im sure you guys have a ton of uses for it. But im trying to figure out how its saving you time, since now you have to put in the CW for the overall, AND the windows, and constrain them.

Weve got a Single/Double/Triple made currently, with nested single hostless windows inside them. So if we needed something with an arrayable quantity, and two different windows top and bottom, i think it would be doable in minutes... we just havent had the need.

I suppose if you had a radical condition with a bunch of ups and downs, and odd shaped windows, then it could be handy to do it that way... But i guess at that point its the same as editing the profile of the wall and putting the various unhosted window pieces in there...

[cliff collins]

I'm still going for:

Curtainwalls and storefronts in Revit = Real world curtainwalls and storefronts

Windows in Revit = Real world windows

Simple. Real.

cheers........

[aaronrumple]

Im completely not knocking it, as im sure you guys have a ton of uses for it. But im trying to figure out how its saving you time, since now you have to put in the CW for the overall, AND the windows, and constrain them.

Once you have the sash, making the cw panel and cw take no time (and are part of the template.) The same sash is used for type based catalog hosted windows.

I can layout a run of winows with very few clicks.
I can do a window thet is EQ,EQ,EQ,EQ without any ref. planes and math.
I can easily get windows spaced on a curved wall. Include some vertical mullions and you have a very nice bow window.
My windows can be typed (catalog) based, but then for custom size I can use these.
I can make a flexible window assembly like in ADT with a bunch of panels, doors, louvers and structural mullions all mixed togther. And most importantly.... Save them out for re-use in other projects. They don't need a host. And they cut walls.
And we do do a lot of compositions with odd sized windows.
I can put windows an a sloped surface for tilted walls or roofs. Way cool.
I can do a vault with windows.
Corner windows are simple.
And everything tags as windows.

[aaronrumple]

I'm still going for:

Curtainwalls and storefronts in Revit = Real world curtainwalls and storefronts

Windows in Revit = Real world windows

Simple. Real.

cheers........

Well - right now in Revit.

Curtain Wall = Curtain Wall
Storefront = Curtain Wall
HM Frame, Window and Door = ummmmm ?

Those are very different animals and Revit should understand the differences.
And what's a curtain wall door?

[twiceroadsfool]

Well - right now in Revit.

Curtain Wall = Curtain Wall
Storefront = Curtain Wall
HM Frame, Window and Door = ummmmm ?

Those are very different animals and Revit should understand the differences.
And what's a curtain wall door?

Dont get me wrong. I understand the part about the "loose" window families, thats how my windows are built... Then theyre nested in to Regular hosted window families.

So the Loose Windows i get. Theyre useful in strange conditions, for sure. Its adding in the CW part that i guess im not sure why, but i see it now. For mulling them together youre using the CW mullions, it sounds like.

Interesting idea. :)

[d.stairmand]

I have been using Curtain Walls for All my windows for a few years now - and would never go back. If any of you have had someone change there mind about a window more than 5 times - you will understand. Windows by themselves are just too restrictive. You get someone that "just wants an opening sash in this window here & only here" - window family needs another family whereas curtain walls you just edit it on the fly. "Can you change that door to a Window" "can you add a door into that window please" or vice versa. you look like a bit of a fool when you start saying "the program cant do that" - yes it can - with curtain walls.

Yes the only drawback is creating legends for them - but anyone can use the elevation tool to do this. it even aligns then up for you. make a filter that only shows curtain walls. Tagging them is like normal - just a modified wall tag.

all in all - If your using only typical out of the box windows - use windows. if your using anything that might change - use curtain walls (and we all know how much our buildings change)

[aaronrumple]

Yes the only drawback is creating legends for them - but anyone can use the elevation tool to do this. it even aligns then up for you. make a filter that only shows curtain walls. Tagging them is like normal - just a modified wall tag.

Note that in my examples, they can be tagged with a window tag, schedule on the window schedule and create a legend for the individual sashes.

[m.thomas]

Aaron,

Many thanks for the examples. Thanks to everyone else for their input too.
I need to go away and spend some time looking at how best to generate windows to suit our needs. I guess it'll be a mixture of using windows and curtain walls depending on each projects requirements and complexity of window type.

[sthedens]

This issue begs the bigger question of, "Are we doing BIM, or just 3D Design modeling in order to get 2D contract documents out the door?".

A curtain wall is just that, a WALL. From a structural standpoint, loads transfer through the curtain wall. For storefront and windows you account for the structural load with some type of framing, e.g. Lintel.

If you model windows and storefronts as curtain walls and do a quantity takeoff and you get "x" amount of curtain wall (some of it is actual curtain wall, but some of it isn't). How do you account for the cost difference between them?

[aaronrumple]

If you model windows and storefronts as curtain walls and do a quantity takeoff and you get "x" amount of curtain wall (some of it is actual curtain wall, but some of it isn't). How do you account for the cost difference between them?

Filters take care of that nicely. Also you can asign a non-wall assembly code to the type.

Until Revit has explicit tools for everything - you always have to do some of that. Not just with curtainwalls. (Floors as sidewals, walls or floor slab edges as curbs, floor slab edges as base trim, roofs as vaulted ceilings, etc...)

[twiceroadsfool]

This issue begs the bigger question of, "Are we doing BIM, or just 3D Design modeling in order to get 2D contract documents out the door?".

A curtain wall is just that, a WALL. From a structural standpoint, loads transfer through the curtain wall. For storefront and windows you account for the structural load with some type of framing, e.g. Lintel.



As the other Aaron mentioned, this is ALREADY an issue, any way you slice it. Revit simply cant model everything that is needed to fully document a building. What about barrel vaulted ceilings, Peaked ceilings, arched ceilings? Well, are they ceilings? Or walls-by-face? Because you cant put a ceiling by face. Some people use Roof-By-Face, and have a roof type that is called a ceiling, and change the assembly code.

You mention CW's and structural requirements, but none of that is coming from your Revit Arch model, period. So how is that getting handled by your BIM model?

These issues are important, but theyre already here. This is just another example of how to get our work done while trying to figure out the future.

[wmullett]

I have to say that Revit's Curtain walls and its Storefront are NOT... They can be either or...The only difference in the out of the box description of the two is that one has pre-sets and the other doesn't. REVIT should have named it as such... automatic vs manual - that is the only difference. How you spec it determines if it's storefront or CW !

As far as is it a window or not... Again - why fight this? It is a tool. I use them for simple punched openings and multiple instances because I can schedule them to look the same as windows and do them faster then families.... unless I may want them all the same and they may change size - then I do them as a family.

[cliff collins]

Bear with me--this is going to be a bit lengthy---

I just have a different outlook:
For instance, consider E-Specs for Revit--which uses assembly codes, keynotes
etc. to tie metadata from Revit to "bindings" in E-Specs spec sections. The Revit model
should correlate to a systematic group of components that are used by the contractor and subs to purchase, fabricate (either on or off-site) and construct in the field.

If you look at a building as a kit of parts, or more specifically in terms of Master Spec
divisions--the components that are created in the Revit model should adhere as closely
to the construction industry standards for products as possible.

Call me a purist, but when I think about an opening in a wall, I always think down to the real world, end-user item which will be put into the opening.

If the opening is a large expanse of glazing with aluminum extrusions in a grid pattern
that gets tied back to the skeletal frame, when the opening is measured in the field and shop drawings are developed to create custom sized members that are fabbed up in a glazing contractor's shop---that's a curtainwall.

If I have a similar glazing system which is 12' high or less, that' storefront.
Likewise ribbon windows, which are just a continuous row of smaller divisions of storefront.

If I have punched openings which get infilled with pre-manufactured window units
provided by a window manufacturer, and which may have operable parts and specific
glazing properties, proprietary hardware, finishes and other features that I have specified---and which I can buy off the shelf---that's a window. ( of course--you can also have custom windows...but we avoid them as cost and lead times increase. )

Metadata is placed into the families according to this industry standard nomenclature,
and the model then is organized in harmony with the specifications. How do you do that easily with over-complicated nested families? and is it worth it?

Sure, I can get "smart" ( or over-think things, depending on how you look at it)
and "nest" a window in a curtainpanel, but is it really worth it? How about the next guy
working on the model? How much fussing and wasting time is required to be so "smart"?
Just because I CAN do it in Revit, doesn't mean I SHOULD. My convenience is not the driving factor for how a model is assembled. The model, drawings and specifications
are the deliverables which we are contractually obligated to provide so that the Owner
can get his building built in the most cost effective and timely fashion--that is what drives
the decisions for assembling those documents--not "some cool trick that I can do in Revit
because I'm so smart"...............

Keeping it simple, and organized by industry standards will make things flow better,
and instill a "proper way of producing a BIM model and set of documents and specifications" that can easily be followed by new users and project team members.

Keeping it this way will also simplify thing when the model is shared in an IPD environment. The Curtainwall supplier and installer do not want a bunch of off-the-shelf
packaged window units stuffed into their proprietary system, just beacuse a "smart"
designer stuffed it into the model.

With more and more product suppliers providing Revit content all the time, all the more reason to assemble the model with each component in it's "proper place"--just like
putting specs together correctly.

In other words, model the building with a real-world kit of parts, as that is how it will be ordered, assembled in the shop, delivered and constructed in the field.

Spend some time reviewing and approving shop drawings, writing specs, and having the specs tied to the Revit model and you will see things from a different point of view.
Get some buildings built from the Revit model and the specifications which are tied to the model. It will change your way of thinking. I assure you--and for the better.

cheers.......

[twiceroadsfool]

Bear with me--this is going to be a bit lengthy---

I just have a different outlook:
For instance, consider E-Specs for Revit--which uses assembly codes, keynotes
etc. to tie metadata from Revit to "bindings" in E-Specs spec sections. The Revit model
should correlate to a systematic group of components that are used by the contractor and subs to purchase, fabricate (either on or off-site) and construct in the field.



I have considered, and i have used E-spec. Tied to a Revit Model. It DOESNT matter, since (as the other Aaron and i both pointed out) you could and can change the assembly codes/keynotes that those items are reading. In fact, the last project i did that had the specs generated right from the Revit Model, had roofs for ceilings, Curtain Systems (Not curtain walls) for Armstrong Coffered 2x2 ceiling tiles, and a few other workaround that were/are necessary in Revit for designing anything more than a Big Box.



If you look at a building as a kit of parts, or more specifically in terms of Master Spec
divisions--the components that are created in the Revit model should adhere as closely
to the construction industry standards for products as possible.

Call me a purist, but when I think about an opening in a wall, I always think down to the real world, end-user item which will be put into the opening.

If the opening is a large expanse of glazing with aluminum extrusions in a grid pattern
that gets tied back to the skeletal frame, when the opening is measured in the field and shop drawings are developed to create custom sized members that are fabbed up in a glazing contractor's shop---that's a curtainwall.

I would agree, thats a Curtain Wall. But in Revit, the only differentiation between a "Curtain Wall" and a "Storefront" is the Type parameter information you put in it (I might add, this includes the aforementioned assembly code data, so Storefronts and CW's are NOT the same in revit, just because you use the *CW tool*. (In fact, i believe they should change its name to "repeatable element" tool.




If I have a similar glazing system which is 12' high or less, that' storefront.
Likewise ribbon windows, which are just a continuous row of smaller divisions of storefront.
. I would agree, and i would still make them out of the CW tool.



If I have punched openings which get infilled with pre-manufactured window units
provided by a window manufacturer, and which may have operable parts and specific
glazing properties, proprietary hardware, finishes and other features that I have specified---and which I can buy off the shelf---that's a window. ( of course--you can also have custom windows...but we avoid them as cost and lead times increase. )
We dont all get the luxury of avoiding things because theyre expensive or atypical. I tend to agree with you, and make them window families when i can (which i address more in the next point), but again: Youre thinking solely of the System Family Catagory, which is quite shortsighted. Revit has different TYPES of CW's, that you can define, with so many different objects with information that all that stuff you talked about can still be addressed. Glazing properties? CW Panel information. Hardware/finishes? CW Panel/door and mullion properties. NONE of this means it HAS to be a "Revit window."



Metadata is placed into the families according to this industry standard nomenclature,
and the model then is organized in harmony with the specifications. How do you do that easily with over-complicated nested families? and is it worth it?Sure, I can get "smart" ( or over-think things, depending on how you look at it)and "nest" a window in a curtainpanel, but is it really worth it? How about the next guy
working on the model? How much fussing and wasting time is required to be so "smart"?


You touch on a few things here, but im sorry... Some of them are laughable. We nest families like crazy, and frankly its done to BETTER address the "industry standard nomenclature and harmony with specifications." A "door panel" does not always equal another "door panel." A window doesnt always equal a window. Specifications and industry class information is better suited to the overall model, if it is done piece by piece. Some window assemblies may have two pieces, one with a casement and one with a fixed condition, and they may be pieced together in an overall assembly on site, depending on how your pieces are being selected. Nested families suit this perfectly. More to say, we model it exactly as its getting built.

Addressing the complexity of the Revit techniques and the rest of the project team? Never once has this been a difficulty. The office all reads from the same set of standards, all built with the same nested families. Never ONCE has this been an issue.



Just because I CAN do it in Revit, doesn't mean I SHOULD. My convenience is not the driving factor for how a model is assembled. The model, drawings and specifications
are the deliverables which we are contractually obligated to provide so that the Owner
can get his building built in the most cost effective and timely fashion--that is what drives
the decisions for assembling those documents--not "some cool trick that I can do in Revit
because I'm so smart"...............


Youre also assuming we are doing these things because its more convenient. What many of us are doing is not *some cool trick we do in revit because we can*, its whats necessary to get what we are building documented efficiently and correctly. Tell me how you are specifying and detailing a Gypsum on Metal stud barrel vaulted ceiling and typing it to e spec, without using Revit trickery or an in-place solution? I use the former, and model it out of a roof, that still reports the correct assembly code, and keynote information. For you to do an inplace solution, you have to do the same extrusion sketch (times 2, because now you cant define a ceiling/roof type, so youd half to model in the gyp and studs seperately, or NOT do both... and there go your quantities for the IPD you discuss), so you are AT BEST moving equally as fast as our *revit trickery* but with no additional benefits. And thats at best. Then, to re-edit it (who has ever seen a designer get it right the first time) you now have either detailing objects to fix, plus two extrusions, versus my one ceiling (roof) type extrusion.



Keeping it simple, and organized by industry standards will make things flow better,
and instill a "proper way of producing a BIM model and set of documents and specifications" that can easily be followed by new users and project team members.

Then we disagree on what "proper" is. NONE of the users here have any difficulty adhering and working with our fairly complex Revit standards. And ive thrown brand new revit users in to the middle of jobs.



Keeping it this way will also simplify thing when the model is shared in an IPD environment. The Curtainwall supplier and installer do not want a bunch of off-the-shelf
packaged window units stuffed into their proprietary system, just beacuse a "smart"
designer stuffed it into the model.

In a REAL IPD situation, our "Designer garbage" is getting *turned off* and replaced by their proprietary content anyway, so they shouldnt have much stake at all in how were modeling things. Its not the same as stuffing an Anderson Casement Window 2240 in a Kawneer system. Its placing an object that "revit" calls a window in to an object that "revit" calls a CW. We have a project actually working the OTHER way, where we used revit Windows for a lot of things that are being handled by Curtainwall Suppliers, and theyre handing us their shops electronically. I assure you, i havent had one complaint about them being "Window units." :)



With more and more product suppliers providing Revit content all the time, all the more reason to assemble the model with each component in it's "proper place"--just like
putting specs together correctly.

In other words, model the building with a real-world kit of parts, as that is how it will be ordered, assembled in the shop, delivered and constructed in the field.

Spend some time reviewing and approving shop drawings, writing specs, and having the specs tied to the Revit model and you will see things from a different point of view.
Get some buildings built from the Revit model and the specifications which are tied to the model. It will change your way of thinking. I assure you--and for the better.

cheers.......

A worthy cause, certainly. But even now with *more manufacturers* getting on board with Revit content, even THEY arent building it the way you speak of. The windows/Doors/Lights/equipment that are coming from manufacturers for use in Revit are a total mess, both in the information they have stored in them, (albeit most of it wrong), and the ways theyre modeled. Believe me, im not writing this post to bash your response, but i understand where youre coming from... As a "purist" i really do. But if you think were wrecking the "pureness" of a Revit Model by coagulating Curtain Walls and Windows and Doors, i hope you open that content from manufacturers with a heavily blinded eye. :)

[aaronrumple]

For instance, consider E-Specs for Revit--which uses assembly codes, keynotes etc. to tie metadata from Revit to "bindings" in E-Specs spec sections.

The Curtainwall supplier and installer do not want a bunch of off-the-shelf
packaged window units stuffed into their proprietary system, just beacuse a "smart"
designer stuffed it into the model.


The contractor won't have an issue, because the truly "smart" designers changed the Asembly code, keynotes, etc... Now it is a different animal. There is no longer a curtain wall.

And once again - you draw your HM door/windows and frame using?
(Real slow to make a new door family for each and every HM system and not so "smart".)

[cliff collins]

Aaron and Aaron,

I appreciate the comments and creative ways of using curtainwalls.
Heck, you can even make railings and stud framing out of them--( or vice versa)
but just because you can, doesn't necessarily mean it's the best approach.

It is true that Revit is not really programmed to organize certain products
the same way we would in writing specs.

However, we still take a purist approach and try to be as true to the product
as possible and use the closest available tool that Revit has for the job.

The barrel vault ceiling could go a few ways---if it is gyp. bd., then it could be built in to the
roof structure. If it's a custom ceiling "specialty" from Armstrong, etc. then it could be
a Family in the ceiling category.

Doors and frames would take a whole additional thread, which has probably already been beaten to death here and elsewhere.

cheers......

[twiceroadsfool]

Aaron and Aaron,

I appreciate the comments and creative ways of using curtainwalls.
Heck, you can even make railings and stud framing out of them--( or vice versa)
but just because you can, doesn't necessarily mean it's the best approach.

I tend to not agree with workarounds when theyre just for the sake of workarounds as well, but: Just because you dont like it, doesnt mean its NOT the best approach either. ;)



It is true that Revit is not really programmed to organize certain products
the same way we would in writing specs.

However, we still take a purist approach and try to be as true to the product
as possible and use the closest available tool that Revit has for the job.

Who is deciding what the closest tool is? The "Curtain Wall" tool in Revit is much closer to a LOT of pieces in architecture, than Families/System Families/etc. Terra Cotta Rainscreens come to mind. We did one on a project recently, tons of little pieces of TC put together, and we had to specify which colors went where, how often the pattern repeated, and so on and so forth. Well, a TC Rainscreen is certainly not a Curtain Wall, but its the perfect application of the tool. Hence my comment it should be changed to the "Repeatable Element" tool. A new CW Type, new assembly codes, 5 CW Panels made of the appropriate materials for the TC colors, and we had an intelligent, taggable, countable, renderable rainscreen.


The barrel vault ceiling could go a few ways---if it is gyp. bd., then it could be built in to the
roof structure. If it's a custom ceiling "specialty" from Armstrong, etc. then it could be
a Family in the ceiling category.

Not if the roof isnt above it, you cant. Plenty of times we have barreled ceilings in interior spaces, with the roofs way above, and not barreled. So you can USE a roof (what i was describing), but its not a roof architecturally. You cant turn an out-of-place Family in to the Ceiling catagory, which leaves in-place Modeling, which... refer to my earlier gripes about that. Doing it as "in place" families, SIMPLY for the sake of having it be the Ceiling System Family, is very shortsighted, when there are no other downsides to doing it the other methods provided.

Armstrong Coffered 2x2 ceiling tiles, what will you make them out of? A family? Of what catagory? And then you will manually place them? Another great use of the Curtain System tool, with very little Risk for return.



Doors and frames would take a whole additional thread, which has probably already been beaten to death here and elsewhere.
cheers......

They have, but the particular instance he brings up is perfect for this conversation. I even have a HM Door/Frame family with a sidelight,and the sidelight is parameterized for width/height/mulls, etc. It STILL cant generate what Aaron is describing, faster or better than the CW tool, with an office standard Curtain Wall Type of "HM Door and Frame". At which point, for the sake of using the right REVIT tool, youre creating one offs for every project, and your QC is out the window.

I consider myself one of the more stringent "purists," as you say. But there are some things in ARCHITECTURE that the conventional tools in REVIT dont do well, or dont do at all. To say that the simplest method is always the best, simply because its simple, is... well.... Simple. :)

[mmolina]

I'm still going for:

Curtainwalls and storefronts in Revit = Real world curtainwalls and storefronts

Windows in Revit = Real world windows

Simple. Real.

cheers........

But why can't you tag it as a window, why does it tag as a wall.
it's not a wall, it's a window.

If it looks like a window, if it talks like a window, it's a window.

[Steve_Stafford]

Curtain Walls are walls that can hold a variety of panels and not all of them are glass :smile: Mark, your question reminds of when kids ask "why"...and the answer is..."because" :wink: Because that is the way they (Revit developers/designers) made it (Revit). [tongue firmly in cheek]

[cliff collins]

Heck of a thread............

cheers...

[sthedens]

But why can't you tag it as a window, why does it tag as a wall.
it's not a wall, it's a window.

If it looks like a window, if it talks like a window, it's a window.

Riddle me this, "When is a window, not a window?" When it's a curtain WALL.

At some point Revit had to decide what this thing really was. Was it a window that had a lot of wall qualities (multi-story, room separating, structurally self-supporting, door hosting, etc.), or was it a wall that you could see through like a window. Obviously, they chose wall. Granted, it is a very specialized wall with grids, mullions and panels.

The problem is that the curtain wall tools in Revit are SO much easier to use than modifying window families, or railings (could this be more complex or cumbersome?).

[WYSIWYG-BIM]

Good thread for lively discussion! So how do you handle this situation (it may be the deciding factor for me)....

When you have a punched opening and you have a 3/4" offset all the way around a "window" for caulking how do you get that built into the window? I can get it built in to the CW panel template. Before you tell me it's too samll to worry about I will say that we do shop drawings etc. from our Revit drawings as we are a manufacturer/engineering firm.

Thanks!

[twiceroadsfool]

Handle it exactly the way it gets built. "Windows" have Opening Dimensions, and they have Rough Opening Dimensions. If the hole has to be bigger than the window, make it that way. :)

Thats how ours are all done. If its being made out of a CW, i add it in to the Mullion size, in the mullion used for perimeter conditions, so that at the detail level i can account for the caulk or shim in the space of the "mullion" so that the opening in the wall is correct.

It works in both tools...

[bsqwared]

This thread is very helpful, even though it has strayed a bit off the original question. My reason for opening the thread is because our firm schedules storefront and CWs on the window schedule. In multistory mixed use projects, there is often storefront/CW on the first two floors, and punched windows above. Or on an office project, there will be some areas on the interior where there are "storefront" partitions for offices. I know that not everyone would schedule these the same way (read: cliff), but the original question was "Is there a clever workaround or workflow where we can schedule curtain walls as windows with the correct sizes scheduled?" Is nesting a sash the only way to do this? Please do not tell me that i need to add another schedule for "curtain walls" and another wall partition tag and another office standard and another PITA?

[Steve_Stafford]

..."Is there a clever workaround or workflow where we can schedule curtain walls as windows with the correct sizes scheduled?"...Sorry...the answer is no. They are separate category elements...can't blend them together in one schedule. They don't really share any of the same parameters either.

You could create the dreaded separate schedules and change their appearance so that they look like "one" stacked above one another, assuming you could get the parameters to "match" up, line up.

[WYSIWYG-BIM]

Very clever Steve.

[himanshukhaira69782773]

At schematic design we use a lot of curtain walls embedded in walls because we can quickly generate most types of window quite easily on the fly without spending time adjusting and setting up window families.

The curtain walling tool is pretty powerful.

But as soon as we want to start scheduling our windows we have to create window families to get the right width and height sizes reported.

Is there a clever workaround or workflow where we can schedule curtain walls as windows with the correct sizes scheduled ?

You only have to build the library once. If you do it right, you should have MOST bases covered, and it'll only take a day or so to build a pretty robust library but if you want to install curtain walling at your place then it will also go well.