Help me with a PN Workflow issue?

[Anonymous]

For our K-12 School Renovation Projects,
we typically start off by engaging in "Teacher Meetings";
where we Program the space,
and then we'll design multiple scenarios of interior layout,
that satisfy the Program.

We'll present these "Design Scenarios" to the Client,
and further refine the layout, before finalizing the design.

My question is:
Where to place these scenarios, and how much/little should they integrate
with the Base Constructs/Views that will become the Construction Docs?

My first inkling is to:
1. Start by making an Element for each logical grouping of spaces (eg.
Science Labs, Administration, Locker Rooms, etc.).

2. In each of these Elements, reference in the Construct(s) for that Level.
These Constructs are Existing Conditions, at this point.

2a. Optionally, xclip these xrefs to the boundary of the applicable Program
Area.

3. Design/Draw the renovation on top of the xrefs. Do not duplicate any
Objects that represent Existing to Remain, but draw demo, & new elements, as
required.

3a. Optionally, copy the xrefs (in modelspace) to the side as many times as
required for each Design Scenario.

4. Setup Layouts *directly* in these Element dwgs for titleblock and output.
(in other words, do not create PN Sheets for outputting this information...)

4a. Setup *multiple* Layouts in the same Element dwg, to output more than
one scenario.

5. Once a Program Area is finalized, copy that Design Scenario into the base
Construct(s). And then proceed with PN, traditionally as it was meant to be
utilized for the remainder of the project.

Sound good?
Anyone have a better method?

Things that are important to me:
1. I do not want to totally divorce the Room Layout design from the base
building constructs, in case something changes there, un-related to the
specific layout (eg. new columns, chases, partitions, etc.)
2. I want to minimize the amount of CAD re-work that will be required to
incorporate a finalized Design Scenario into the core PN files.

--
Halten Sie an! Oder meine Mama wird Schießen!

[Anonymous]

>3. Design/Draw the renovation on top of the xrefs. Do not duplicate any
>Objects that represent Existing to Remain, but draw demo, & new elements,
>as required.

forgot another key point:
*Annotate* in the Element, in Modelspace.

This is a tough one, because things like Schedule Tags will need to be
re-done when this info is incorporated into the typical PN workflow. No way
to copy a tag from a Construct to a View, and keep the reference link, that
I know of... 😞

--
Halten Sie an! Oder meine Mama wird Schießen!
"Corey A. Layton" wrote in message
news:5829146@discussion.autodesk.com...

[Anonymous]

My advice would be to use it as full PN. That is, use views and sheets as
you normally would. You could always copy your project and delete the
discarded options once a design is finalized.

My method creates a lot of dwg files, which I have never had a problem with,
but have encountered many who think it's a bad idea. Use divisions to your
advantage. You can always change them when you move towards CD, but to
start, use divisions to handle the optional designs (A, B, C, etc.).

For each component (Existing, Demo & New) you will have a Base construct.
This is the drawing information that is the same across all design versions.

For each component you will have constructs that are specific to its
particular design version. So, a typical file tree might look like:

Constructs -
01-Existing Lower Floor-Base
01-Existing Lower Floor-A
01-Existing Lower Floor-B
01-Demo Lower Floor-Base
01-Demo Lower Floor-A
01-Demo Lower Floor-B
01-New Lower Floor-Base
01-New Lower Floor-A
01-New Lower Floor-B
01-New Lower Floor-C

Views -
01-Lower Floor Plan-A
01-Lower Floor Plan-B
01-Lower Floor Plan-C

Sheets -
A101-Lower Floor Plan-A
A102-Lower Floor Plan-B
A103-Lower Floor Plan-C

Using divisions appropriately really makes it easy to define your Views,
which can then just be dropped onto the Sheet. Like I said, it creates a
lot of files, but when there are design changes that affect all options, it
saves a lot of time and reduces a lot of errors. At times it may feel
overdone (I've had drawing files that only contained a single object) but
this method helped me manage multiple options, and combinations thereof. A
function that makes this a lot less cumbersome is the ability to simply drag
objects in your current drawing into another Construct, or even create a new
one on the fly. It seems more logical to me that to change an object's
identity (from existing to demo, or base plan to option A, for examples),
you change its category (via changing which Construct it lives in) rather
than changing its properties, but heck, maybe that's just me. .-)

Let me know what you think.


"Corey A. Layton" wrote in message
news:5829146@discussion.autodesk.com...
For our K-12 School Renovation Projects,
we typically start off by engaging in "Teacher Meetings";
where we Program the space,
and then we'll design multiple scenarios of interior layout,
that satisfy the Program.

We'll present these "Design Scenarios" to the Client,
and further refine the layout, before finalizing the design.

My question is:
Where to place these scenarios, and how much/little should they integrate
with the Base Constructs/Views that will become the Construction Docs?

My first inkling is to:
1. Start by making an Element for each logical grouping of spaces (eg.
Science Labs, Administration, Locker Rooms, etc.).

2. In each of these Elements, reference in the Construct(s) for that Level.
These Constructs are Existing Conditions, at this point.

2a. Optionally, xclip these xrefs to the boundary of the applicable Program
Area.

3. Design/Draw the renovation on top of the xrefs. Do not duplicate any
Objects that represent Existing to Remain, but draw demo, & new elements, as
required.

3a. Optionally, copy the xrefs (in modelspace) to the side as many times as
required for each Design Scenario.

4. Setup Layouts *directly* in these Element dwgs for titleblock and output.
(in other words, do not create PN Sheets for outputting this information...)

4a. Setup *multiple* Layouts in the same Element dwg, to output more than
one scenario.

5. Once a Program Area is finalized, copy that Design Scenario into the base
Construct(s). And then proceed with PN, traditionally as it was meant to be
utilized for the remainder of the project.

Sound good?
Anyone have a better method?

Things that are important to me:
1. I do not want to totally divorce the Room Layout design from the base
building constructs, in case something changes there, un-related to the
specific layout (eg. new columns, chases, partitions, etc.)
2. I want to minimize the amount of CAD re-work that will be required to
incorporate a finalized Design Scenario into the core PN files.

--
Halten Sie an! Oder meine Mama wird Schießen!

[Anonymous]

I have annotated both in the Construct and in the View, depending on the
situation, but I would say that all your tags should be placed in your View
drawings.


"Corey A. Layton" wrote in message
news:5829150@discussion.autodesk.com...
>3. Design/Draw the renovation on top of the xrefs. Do not duplicate any
>Objects that represent Existing to Remain, but draw demo, & new elements,
>as required.

forgot another key point:
*Annotate* in the Element, in Modelspace.

This is a tough one, because things like Schedule Tags will need to be
re-done when this info is incorporated into the typical PN workflow. No way
to copy a tag from a Construct to a View, and keep the reference link, that
I know of... 😞

--
Halten Sie an! Oder meine Mama wird Schießen!
"Corey A. Layton" wrote in message
news:5829146@discussion.autodesk.com...

[Anonymous]

Anthony Mason wrote:
> My advice would be to use it as full PN.

Thank you for suggesting this option, Anthony.

Although, it is proper use of PN,
I doubt that my Users would "warm up to the idea".

The biggest hassle with this method is all of the separate Constructs,
set to different Divisions.

It *is* a hassle to work on multiple scenarios,
when each instance is in a separate file, IMO.

And when you're done,
there's *still* no way to transport the Schedule Tags from the Design
Scenario View dgs,
to the Plan views that will be used for Construction Docs.

I'm not saying that your idea is wrong.
(because, technically, it's right a rain...)
I'm just saying that I know that method would not be
received well in this office.

--
Halten Sie an! Oder meine Mama wird Schießen!

[Anonymous]

> Thank you for suggesting this option, Anthony.

No problem. I'll actually save that message so I can explain it in case the
situation comes up here. .-) Mostly, I just have a hate-hate relationship
with xclip.

> Although, it is proper use of PN,
> I doubt that my Users would "warm up to the idea".

*cough*iron-fist*cough*
Users can be brought into line. It's management that has to be convinced.

> The biggest hassle with this method is all of the separate Constructs,
> set to different Divisions.

> It *is* a hassle to work on multiple scenarios,
> when each instance is in a separate file, IMO.

I agree, this is a perfect example of finding the lesser evil in an
imperfect system. Dealing with the divisions isn't so bad, as long as you
assign them properly when you create the construct.

> And when you're done,
> there's *still* no way to transport the Schedule Tags from the Design
> Scenario View dgs,
> to the Plan views that will be used for Construction Docs.

When you copy your project, just use the existing Scanario Views for your CD
Views. Do you have something going on in these drawings that makes them
unusable for CD?

> I'm not saying that your idea is wrong.
> (because, technically, it's right a rain...)
> I'm just saying that I know that method would not be
> received well in this office.

Story of my life. .-)