Riser Packages

[Darren Young]

Anyone got any good tips on Riser packages (from Revit).

Scope boxes for the Riser seem like a good way but they're not typically defined at the beginning of the project. As such, the detailer generating them would need Project Admin permissions to import the area in Stratus and set it up.

I really don't want to give Project Admin to all users as I then can't enable/disable other areas of functionality for them (trade specific filters/reports, etc.).

[craigjonnson]

Can you control the contents of the package by worksets?

[acad2015]

Maybe create a riser number parameter that the detailer would fill in with the contract riser number? Then create rule in your filter on Stratus based off of that parameter. Maybe have a company standard prefix also in the parameter so that the rule and filter would work across different projects?

[Darren Young]

To be Clear...I'm talking about a "Stratus" riser package from Revit. (hence the post in the Stratus forum)

Stratus can read levels and scope boxes from Revit. Those can be assigned to "Areas" in Stratus so that parts are automatically able to be filtered and added to a Package (In Stratus) that's named per the area.

To setup Areas in Stratus, you need to be a Project Admin. So it's been requested to give all detailers Admin access which means nothing else in the UI can be filtered or enabled/disabled based on their role.

Ideally these would be setup ahead of time by a project lead but they want to create them AdHoc and have each detailer do this. I'd like to not give Project Admin permissions to absolutely everyone.

[acad2015]

Sorry, I was under the impression that you had access to your Revit parameters in Stratus. It appears that you don't. So ignore my previous comment.

[Darren Young]

There is access to Revit parameters in Stratus. But I'm asking about best workflows that leverage the intended Revit/Stratus interoperability.  A "package" is a real thing in Stratus...it's not just a property associated with an object.

[acad2015]

Alright Darren, I'm going to try one more time then I'll leave you alone. Haha. I figured out how to access the parameter I created in Revit in Stratus. I then created a filter and deliverable definition in Stratus. Added the deliverable definition to the project I wanted. I then went to my deliverable tab for that project and hit Generate deliverables. It generated packages for all of the content that I applied the Riser number to in Revit.

I believe this will get you what you are looking for. The detailer does not need Admin Rights, the package is automatically generated, and your package name will include the area abbreviation if you add it to your package naming convention. You have a lot more experience than me in Stratus however, so please shoot holes in my logic because it will help me in the long run.

Forgot to mention I did bring in my scope boxes and levels in at the beginning as well so the filters for areas were automatically generated.

[Darren Young]

That sounds feasible. Just not sure when I'll get time to get that far.

[davidratx]

Is there a process issue here too? The riser parts would be in an eligible scope box for normal deliverables. I would think the riser parts would have to be assigned to a riser package prior to the rest of the floor.

It was explained to us that the same part can not exist in two packages of the same category. So thinking you would want to also make sure your package categories are the same so you aren't doubling the BOM for the riser parts.

[craigjonnson]

Hi Darren, yes i did see that this is in relation to Stratus and from what i know in Stratus and Revit resulted in my reply. Davids comment is valid re: a unique reference. I dont have a current working solution, and noting that you do not want to give admin rights. I would look at getting the users to make the risers into an assembly, this would take care of the unique name and you can assign assemblies into a package within stratus.

[Darren Young]

Our preferred workflow is to make assemblies in Stratus. I've heard of a few companies w/issues when they have a mix...sometimes spool in Stratus...sometimes using Revit (native, eVolve, Victools, etc.).

Having the areas setup in the scope boxes allows the filters to work better in Stratus to filter to the riser a little easier like the do everything else.

I'll review of few of these ideas and see if I can't get them on a slightly different path.

[davidratx]

You've certainly hit on something we have been trying to work through as well. Perhaps Straus could add a priority feature to the scope boxes so you can define which one to use first when they overlap.

[acad2015]

So I have been doing more set up today. Filters, deliverable definitions, Groupings, Project deliverables, Package Categories etc. Of course I have been testing as I go. Since y'all gave me a real world problem that I would have to tackle at some point any ways, I ran with it. Here's what I have for this exact situation. Everything I will talk about will be pertaining to Stratus.

The way I handled the Risers and non Risers being their own packages is how I described in my previous post. I created a Filter named "Mechanical Pipe Risers" which I cloned from my "Mechanical Pipe" filter. In the Mech Pipe filter I had to add a rule saying to exclude anything that had my company standard prefix for riser numbers in the "Riser Number" parameter that I generated in Revit. I added the opposite to the Mech Pipe Riser filter. (Pretty sure you could just do it one or the other and get it to work the same depending on your workflow.) After that you just add those filters to your deliverable definitions.

After saying all of that, if you can generate your deliverables but not generate packages until they know what they want to consider a riser, then great. Just re-generate your deliverables when they decide whats a riser.  If you already packaged them then you have to un-package them and restart from what I've seen.

Also, I made it generate a Mechanical Piping package for Level 01 Sector A1 and a Mechanical Piping Riser Package for Level 01 Sector A1.

This process is working great for me so far. I am going to continue setting up trying to use this method the least amount of times as possible, but it does work for me. Hope this helps and also hope I am not completely off topic for what you are trying to accomplish. Y'all have a good one.

[Andy Robins]

Our preferred workflow is to make assemblies in Stratus. I've heard of a few companies w/issues when they have a mix...sometimes spool in Stratus...sometimes using Revit (native, eVolve, Victools, etc.).

Having the areas setup in the scope boxes allows the filters to work better in Stratus to filter to the riser a little easier like the do everything else.

I'll review of few of these ideas and see if I can't get them on a slightly different path.

How about using the Stratus Parameter for Assemblies, add a value to the parameter with a Riser prefix like Riser_001, Riser_002, Riser_003 etc they they will automatically be made into Stratus assemblies on publish and will show up in the filters, select them all and add to a Package.

The parameter can be set at a company or project override level so you could test it without changing all the companies workflow