It’s not just a very nice package, it’s an amazing package. Just doesn’t play well with workshare monitor. I had confirmed it was only the scripts which used Datashapes UI++ nodes. I have also had it do the same in the regular Dynamo environment as well.
Interesting - I’ve not found it too useful but then maybe I’m using it wrong. I’ve never worried about timing of synchs and I don’t normally care who is in the model (in the central, yes). How do you use it @jacob.small? (not to hijack the thread)
I’ve got a Cache Disk installed on this computer so these first numbers are only indicitive of multiple read/writes of the same data;
With the cache disabled;
And with it enabled, cleared, and only running a single test (which didn’t impact the results as much as I thought it would);
I run the disk cache all the time so, unless it’s getting around the cache, it doesn’t seem like that the bottleneck… of course I could be talking out of my nose.
@Greg_McDowell I think that those numbers are indicative of read/write speeds not the amount of data being stored there. Out of curiosity after clearing the cache does the undo history go away?
I can elaborate on workshare monitor more in a PM but even stuff as simple as when a user syncs and how long it took can shed a lot of info into the health of the model. Even just knowin who all is in the model at any given moment tells you a lot.
On WSM I’m interested, PM me too please.
I’ve seen other issues (Revit-related/Relational database related) with workshared models, logical but concerning if not noticed, and lets share it after investigating.
Marcel
Thinking about how Dynamo is maintaining the Undo history might explain some of the issues I’m/we’re having with large graphs affecting lots of elements. Perhaps the core program could introduce an option to dump the information from memory rather thank keep it. Thoughts?
If you are using python within your script, have you looked at the revit api’s “dispose” calls to remove elements from memory after you have done what you require?
Hi @Greg_McDowell and @jacob.small. I agree with @jacob.small on the fact that is a RAM issue. I tested 2 computers: one with 8 Gb RAM and another with 16 Gb. On both the usage of RAM memory after the process rises to the 80%-85% so the guess is that all the processes remain stored in there after finnish. I used memClean to monitor this.
I think the best solution for this issue might be a node or a python code that sweeps the ram usage after the process.
@Brendan_Cassidy, @Dimitar_Venkov and others in this thread suggested something to do at the end of the script.
have you tried them already?
Cheers.
I haven’t as it required an installation my my last office’s IT department wasn’t too keen on installs and plugins. As the Datashapes package worked within Dynamo no installation was required and I was able to self test it and incorporate it on my own.
Clearing the working set may solve some of the issues, but be careful as this can remove undo capability and other functionalities. Letting stuff sit in your virtual memory should be fine for most users and most scripts unless you have a slower or nearly full HDD.
@Jorge_Villarroel can you do a simiar check and report the amount of virtual memory used by your script? The instructions above indicate how to do that if you don’t use workshare monitor, but if you do use WSM it’s easiest to check the stats there. (See the image 3/4 of the way down).
Hi @jacob.small:
When I opened Revit: Revit Virtual Memory (RVM) was around 25% and Physical Memory (PM) around 60%
- While running with Dynamo Open:
Also, RVM rose to 50%.
- When it ended this is the situation:
- Then I ran the second part of my process (2° script) and I got this (while running):
- when it ended:
-After all of this, I can’t any longer work in Revit in a proper way.
So, what do you think?
.
It is odd to see that 30% of your CPU is in use when you’re ‘done’… is there something running other than Dynamo, Revit, and WSM? Revit idling used
Ill try and get some testing of my own in next week when I have a free moment.
@jacob.small sorry for late reply. No, only the processes that you mentioned. I have a SSD and pentium i5 with 8GB RAM.
Hi,
Today i ran a quite large script in revit/dynamo and it suck up almost all of my RAM. I have 64 gb installed. My take on it? Try to break down the workflow to avoid such one timers and run smaller targeted operations one at a time.
Maybe delegating as many operation as can be to python can help. Kulkul mentioned it.
I do save frequently and have not had stability issues with neither revit nor dynamo. Running 2018, 1.3
Kind regards,
1 Like
Thanks for sharing! Yes, KulKul recommendations are the once that I adopted by now. Trying to change every geometry creation into python nodes might be a powerful solution.
Cheers
2 Likes
how do i setup a time node in the graph, it is not clear to me… (don’t want to use clockwork, it crashes my dynamo)
Hello
I have the same problem with big scripts.
The only way to solve it for me is to run an empty script after the big ones. Then revit goes back to original speed.
Could you provide us the script to reproduce the issue?
I know it isn’t really a solution but if you disable your view extensions on dynamo, it stops crashing.