Stop running script after a certain amount of time

python
dynamo

#1

Hi,
when I program scripts, it often happens that I create a loop that runs infinitely. The script can not be canceled. The only solution is to completely close Revit. For large Revit projects, restarting Revit and Dynamo consumes a lot of time.
That’s why I’ve built a script that runs only a predetermined working time and then breaks off.

The idea is not new, but I did not find a good solution in this forum.

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

import time
start_time =time.time()

sec = IN[0]

i=0
result=[]

ss=time.time()-start_time
while ss<sec:
	result.append(i)
	i+=1
	#do something
	ss=time.time()-start_time
OUT = ss,result

Any other ideas are welcome:)
Merry Christmas


#2

Hi @Fiesta

Did you see this?


#3

Hi Kulkul,
i did not see that.
But this is also a nice idea to use the running time, if a node needs to wait for other nodes.


#4

I just noticed this discussion…

Using time as an "Await" mechanism is a bad idea. Let me explain.

Some of the student projects I have supervised do a tremendous amount of calculations. Some of the FEM projects calculated everything in the whole project using machine learning algorithms. This could easily take 10-20 days where the computer ran 24/7

We could register when the Ram was near maximum the computational time went through the roof before it started flushing and then again started over filling up the ram. Some calculations went from milliseconds to minutes!

If an “Await” mechanism was based on time, this would end dramatically wrong. So no don’t base this on time!

I have two nodes at the moment, one called “Await” and one called “Circut”, they seem to be the only longtime valid mechanisms at the moment. Await waits for some other process to finish before passing data. This is a node several has coded with many different names. The Circut node holds data back until the “state” in the circut is set to true (bool), then the circut is established. In other words, a switch on/off essentially.

I am researching in other possible ways to do this, but none of them includes time, so I will strongly recommend not to go this way.


#5

This is a really good idea :slight_smile:

If only it’s functionality could be added to other nodes somehow?

I might add OUT = 'Runtime of %s seconds before exit' % int(ss), result

It would be ideal to use it with a data shapes input so that we could be prompted how long we want it to run?

Happy Christmas!

Mark


#6

@erfajo
Your are right - the “wait for time” would be not the best method for a lot data, but if you have a realy small script and this script has a normal processing time less than 10sec. I think in this case “wait for time” is a good idea.

But actually I wanted to stop the Skirpt from a certain second, not start. Only for testing the script and i don’t wanted to restart Revit if my script fails.

@Mark.Ackerley
Unfortunately, I do not know how to connect the script to another node.


#7

Building it into nodes would be rather easy… but how the nodes are being used is impossible to figure. especially if nodes go into large graphs, then nodes based on time could make everything failing. It would be rather unpredictable in such cases.

To my knowledge is neither Revit of Dynamo coded to support asymmetrical computational functions… but it will come at some point.
-In that case would this be the next thing I would code an “await” mechanism for.

Your “stop” thing is what my Circut node is for… then you can evaluated what you need before you as human pass whatever is needed.


#8

I’ve just seen Erik’s post…

@erfajo Hi Erik, of course you are right in what you say.

Ideally Dynamo would have more built-in catcher’s for this kind of thing, but it’s all manual right now…

But I think it’s useful to have this in the toolbox as an option. Having adaptability is a big reason why I use Dynamo. But I appreciate it doesn’t work for all graphs. I have an autosave in my batch plotting for similar reasons :slight_smile:

Your await and circuit nodes are fantastic, but if you accidentally write something which will take 5 years to run, the nodes will never finish.

Cheers.

Mark


#9

correct, but in that case, I would be able to see it still was running and not finishing… if I wasn’t aware of this and it was time driven, then I would end up with the result in a very unpredictable manner. If it was a graph I had made but used by others and they trusted the results, then it would be really problematic.

So no, there is no options for any computational aspects should be “time-driven”.

Better safe than sorry :slight_smile:

Measuring time, on the other hand, could be very useful and there is also another aspect where time could give a helping hand… but it must be taken very deeply into consideration in each case.


#10

We might have to agree to disagree on this :slight_smile:

I would be able to see it still was running and not finishing…
This is incorrect, you can’t know that it is not finishing… You would only know that it was still running… You wouldn’t know if it will finish in an hour, or at the end of the universe…

You could kill the programme, but then maybe you lost all of the computation of the nodes running up to the python?

Maybe something simple in the final python node was wrong and by exiting and quickly fixing that you save your 2 weeks work rather than losing it…

then I would end up with the result in a very unpredictable manner
This is incorrect, the node will tell you that it was stopped by time.

there is no options for any computational aspects should be “time-driven”.
I think this could be phrased better :stuck_out_tongue: Absolutes are unlikely :slight_smile:

As I say, the nice thing about Dynamo is that I can choose to add this and you can choose not to :slight_smile:

Have a good Christmas!

Mark


#11

As I wrote in the first post…

Using time as an “Await” mechanism is a bad idea …-… so I will strongly recommend not to go this way.

Anyone can do whatever they like if they can code it :slight_smile:


#12

Put me in camp @erfajo on this as I’d exercise some extreme caution here. If your graph usually takes 10 seconds, and it’s taking more than 10x the time, there is a reason which needs to be evaluated. Could be n^2 testing, overly large data set, element binding issue, or complex relationship with other elements in the Revit model, or anything really. Stopping said actions mid-way though will either cause you to have to start the ‘long’ process a second (third, nth) time (saving you nothing). Or worse yet could lead to failed updates on the second run so you’ll think you finished, but because the part which was timing out didn’t re-run you’ll get mis-matched lists and easily process the remainder of the content, missing out of processing a sizable chunk of data.


#13

Hey Jacob,

Thanks for the feedback :slight_smile: Who would of thought this would be quite such a contentious issue?! I feel quite the first year student getting grilled by the heads of school :smiley:

The big point here is that there is no Dynamo ‘stop run’ button… If you kill it, you lose everything.

I’m suggesting using this code to avoid killing Dynamo when stuck in an infinite loop or if I accidentally created a graph/code which would take unreasonable amount of time to run.

If your graph usually takes 10 seconds, and it’s taking more than 10x the time,
I don’t think that’s the problem, if it executes in a ‘short’ time I can live with that. It’s if killing Dynamo is quicker that letting it finish.

I would be very interested in tips to make python or graphs more efficient, perhaps we should start a dedicated thread?

Could be n^2 testing, overly large data set, element binding issue, or complex relationship with other elements in the Revit model, or anything really
If this was accidental, then you want it to stop, you’ll get to see how far through it went and you can re-evaluate. If it was what you wanted and it took too long, at least you (have a crude) way of narrowing down which was the slow bit. Maybe initially you set it to 10 seconds, then 100, then 1000… you can see where the bottle necks are, but heck, maybe it does just need 2 weeks, just like Erik’s students. You’d only be running it if it saved you a few months worth of manual work, or was just impossible without Dynamo.

Stopping said actions mid-way though will either cause you to have to start the ‘long’ process a second (third, nth) time (saving you nothing).
As stated above, perhaps the final python had a simple mistake and the entire rest of the graph has executed, now you can see how far that node got, fix it and run to completion. Quite a saving.

Or worse yet could lead to failed updates on the second run so you’ll think you finished, but because the part which was timing out didn’t re-run you’ll get mis-matched lists and easily process the remainder of the content, missing out of processing a sizable chunk of data.
I would suggest integration of a window which pops up to tell you that a node did not run to completion.

If you are forced to kill it, perhaps the bit you thought was broken isn’t and you rerun to have the same error force you to kill, open, run again… let’s imagine that process takes you hours… that’s painful.

Let’s imagine that you did actually fix it in one of those attempts, only for a second error to occur. in this workflow there’s nothing to tell you that, you keep trying to fix the first problem.

If it exits of its own accord you get feedback which you can use to inform your process… That’s why this is useful.

But yeah, I’ll use it and just not tell you :stuck_out_tongue: (that’s my strategy when told to use Autocad or Sketchup) I’ll let you know how I get on, if it turns out to be a dumb idea, I’m quite happy to tell you all!

Have a great Christmas,

Mark


#14

@Mark.Ackerley,
I (and I think this goes for @JacobSmall as well) we don’t want to grill anyone, just warn for using time as an await mechanism.

What I have experienced concerning the student project was, that one single run was done really easy, within seconds but when doing large-scale testing where we let dynamo run several thousand files literally… then began problems!

As I remember it @Jonathan.Olesen had 16 mill. calculations, and he used the machine learning algorithms writing the base for the next scenario. @MadiJun (Nicolai/Mathias) had even more calculations done!

All of them was about --> open a scenario, do the calculations, close the file… redo the process.

This meant that we could measure that at some point the Ram would be filled up, not knowing exactly when that was. But when we reached that level, then time exploded. The computer had as such no problem while it just waited until ram was flushed and it could continue… but time went in those cases into minutes!

We could also see that changing computers meant something, and of course the processor, ram and all that stuff matters.

In other words, something which worked in the base case or in a smaller amount of cases was fine… it was large-scale testing which triggers the problem.

Since we could calculate in advance that it would take 2 days for some tests, they simply started our lab computers and went ahead with other stuff on their personal computers.

If you then thought that everything goes well and then would have added a constant like time… then you will essentially kill all you have done.

You could come back 2 days later and register that the last 1,5 day had you computer used input data created by dynamo which was wrong… then everything would be wasted.

I never know how my nodes will be used, I have to think worst case scenario, thats why I am watchful towards time as a await mechanism.

lastly…
I will also wish everyone a great Christmas :slight_smile:


#15

Thanks Erik, I was only joking, I know this is all about process :smiley:

I’d really love to know more about the projects your students do, do you have a webpage (in English sorry)?

I really don’t think everyone is going to use this all the time, but I will find use for it, without it breaking my parametric Snowman.

Have a good evening,

Mark


#16

I know we do crasy stuff… but all project are actually available in this forum… just try searching “Technical University of Denmark”, I think you will get some hits :slight_smile:

As I try to say when student ask for things others think is not possible… the sky is the limit, let’s go for it…


#17

@erfajo
Happy to see you back in the forum discussing stupid trivial things. :slight_smile:
Enjoy the comming days with friends and family


#18

I am afraid not… I have been active these days since you and @Mark.Ackerley individually got me to work on some coding just before I had settled for Christmas… Thanks both for that, always fun to do some coding… despite I have planned otherwise :slight_smile:

I am not going to participate as much as I did earlier… too many things happened… none mentioned none forgotten :slight_smile:

Not that many days ago I ended up in a private discussion which included many noble members, including some from the team… which showed me that there is no reason for me to contribute as such… however, I try to service those who use my still growing package as best as possible.


#19

I think I’ve posted something similar before, but this is usually called the halting problem:


#21

Maybe I am thinking about this wrong, but since Dynamo is list based, wouldn’t you be able to predetermine the number of iterations a node should preform based on the input length? If so, couldn’t you program a stop in the try statement to break when that number of iterations was exceeded?