[Request for Feedback] Dynamo as a shared service

[jingyiwen]

Example of what a Shared Service using only Dynamo Graphs “as services” could be ^^

Are you interested in executing your Dynamo graphs on Autodesk Cloud Services (e.g. Autodesk Docs, etc.)? Do you have graphs that need to be run in sequence? Do you wish to schedule graph execution? Do you wish some of your graphs could run automatically when certain triggers happen? If so, we would love to hear from you!

We are exploring the idea of Dynamo as a shared service where users can create custom actions that are triggered when changes take place to data stored in the cloud. To help us understand how might we bring the most value to you, please fill out this survey (https://autodeskfeedback.az1.qualtrics.com/jfe/form/SV_6mNT4RDwBxfugZM ). The survey should only take 5-10 mins and your thoughts and ideas will be appreciated!

[GavinCrump]

From an organizational perspective there would ideally need to be some sort of safeguard to avoid the everyday user putting this in place. Maybe tied to permission level of users on ACC projects (admin only?).

Interesting idea, survey submitted! Limited API and Python access are a thumbs down from me but I understand why they would potentially be variables given a revit session isn’t the likely window in for this idea.

[Nick_Boyts]

I agree with Gavin. Seems like something only project admins should have access to. Also brings up an interesting situation between hub owners and design consultants. I wouldn’t want the hub owner placing automated scripts in my folder without my team being able to confirm use and vice versa. As for API and Python access, I agree again that this would be really limiting but also makes sense depending on how it gets implemented. I’d prefer something like the Data.Remember node functionality where Revit data could be read and stored locally to the run without access to the model itself - potentially with the ability to “push” to Revit manually.

[Aaron_Maller]

I think this could potentially be really fantastic, BUT a lot of the success is going to come down to the details of how its implemented or controlled. Because there are a lot of worrying aspects, too.

1. Revit Version/Dynamo Version/Package Version- When we say its “running on ACC/ACS” i assume that means its running in a Revit instance thats in the cloud, similar to how Publishing works. But that brings up:

1a. How do we know what point release of Revit (or whatever) that machine is running? Things change in Revit (and in Dynamo) point release to point release. And then:

1b. Package Authors sometimes have to pivot to accomodate the situation from 1a, so how does all of this get transparent (or manageable) enough? Not all project teams always move to the latest point release of Revit or Dynamo, so thats a real issue.

2. Would this only be for certain types of Graphs? In your flowchart example, you are making a one way export routine, for both graphs. But we have a ton of routines we may want to automate that DO write data to elements IN the actual model. How would that work, element borrowing wise?

We have a few workflows that write data to EVERY element in the Model, and i would LOVE to be able to have them run daily or nightly. Im just curious what that looks like. Or is it one way only, like batch PDF writing, where it opens a copy of the model DFC and runs a routine, and then the model is discarded?

Also, what is the process for reviewing changes and approving them, or is it going to do a "brute force run and then SWC and ‘you get what you get and you dont throw a fit,’ because if a graph goes sideways and deletes a ton of elements (happens alllllllll the time), and then it auto-syncs, thats bad news bears.

3. Very curious how permissions and control would work, obviously. Who can run a graph on a certain model, and how do users know which graphs are running on their models transparently?

[jacob.small]

Great points here, many of which could have multiple routes to resolve (offhand 1 could be resolved with a linter to prep the graphs before putting them on the service, and limiting the graph to that Revit release), second half of 2 could be resolved with an output node and logging, 3 could be resolved with permissions or shared projects and logging) but with different outcomes depending on which route is chosen. As such it’s less about the ‘what about this technical aspect of it’ than ‘what would the community want from it if this were a thing?’

It’s important to note that this isn’t even an alpha offering, more of an inquiry into what the the community might like out of such a tool, and what the use cases might be. Stuff like your idea of updating a parameter for EVERY element in the model is a good use case which will certainly help the team craft the idea.

I do wholeheartedly agree that worksharing is a concern here. The handling method which Design Automation integrated could be added to the Dynamo service, but I’m not sure how functional that would be in reality.

[GavinCrump]

Having thought about it some use cases for this include:

1. Auto update model health dashboard in model at end of day so its up to date for model manager/users in morning

2. Extract schedule contents or extracts to other formats automatically for consolidation elsewhere such as PBI (literally had a user wish for that today, too bad our forgedev was busy…). Sort of like data exchange I guess, but for dynamo users

3. Lightweight inteference checking

4. Data completion for cobie, ifc prevalidation

5. Batch export pdf and/or dwg. Unsure how feasible really but that’s a big one for firms without savvy developers. AEC spends way too long printing. Heck if autodesk made that easy for the masses you woupd become very well liked by the average tech…

Or a big one… all that but enforced by the hub admin (e.g. a client auditing the models at given milestones or ongoing). Scary.

Maybe the option to run detached as one mode and another that actually syncs out the session. I could see people resistant to the latter in case a script does something wrong.

These all have most of the following drivers in common I think:

• user wont run a script manually (too busy, no time, cb bothered)
• the script runs slow and is inconveient in session, or too many models not enough humans
• the script needs users not to own elements to complete its run successfully/entirely

@Aaron_Maller’s one about auto writing is a great one too, lots of use cases. Auto classify elements at intervals would be sweet, I have scripts for it but good luck getting people to remember to run them… A bit like night rider by Anker, but well… a bit cheaper I guess?

It feels lile this is an APS/Forge lite given all the things can be done that way. Is that maybe the main driver here? More users/BIM managers automating at that level with a lower entry barrier? Feels promising, and if executed well could give Dynamo a whole new lease on life in the AEC ecosystem.

[jacob.small]

Dynamo has always had 3 goals (well, as long as I can remember anyway).

• Provide a simple, coherent, and capable tool
  • We want you to be able to do as much as possible without having to get a second degree in computer science. You’ll still have to learn (a LOT), but not as much.
  • To me this is best expressed by looking at the ~40 lines of C# code to get the scale of a view element, vs the 3 total nodes to do the same.
• Foster a collaborative computation ecosystem
  • We want you to be able to share work with each other and innovate together.
  • The 6.1 million package manager downloads, MONTHS of community authored learning content, and extremely active and helpful forum are the best expression of this.
• Enable users at every level of ability
  • We want anyone who wants to benefit from Dynamo to be able to get something out of it.
  • The option to leverage work from another industry entirely in generative design, dynamo player, design scipt, a Python node, a custom node, or 500 nodes to get the same outcome is a great example of this.

To me Dynamo as a service is a clear extension of those goals (simpler than APS, collaborative in sharing graphs, and even users who can’t hit run can benefit).