Python node not working in Generative Design - Why?

Can you run a python loop in GD?

Here’s a dyno script >>

The node skilfully circled in red is a python node which contains this code:

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

rect = UnwrapElement(IN[0])
site = UnwrapElement(IN[1])

		
#always need a moose 
moose = 0
count = 0
while moose < 500:
	#pick random side of the rectangle
	side = random.randrange(0,4,1)
	Line1 = rect[side]
	st1 = round(random.random(),2)
	st2 = round(random.random(),2)
	if st1 > st2:
		st1, st2 = st2, st1
	#Get the distance between the two startpoints on the baseline
	L1len = (Curve.SegmentLengthBetweenParameters (Line1, st1, st2)/1000)
	L1len = round(L1len,2)
	#Force the width (in metres) 
	while L1len <10 or L1len >20:
		st1 = round(random.random(),2)
		st2 = round(random.random(),2)
		#Make sure the points are right way round
		if st1 > st2:
			st1, st2 = st2, st1
		L1len = (Curve.SegmentLengthBetweenParameters (Line1, st1, st2)/1000)
	
	#Create two points along chosen baseline
	pt1r = Curve.PointAtParameter(rect[side], st1) 
	pt2r = Curve.PointAtParameter(rect[side], st2)
	#Create the other two corners of the yard by offsetting either X or Y
	if side ==3 :
		pt3r = Geometry.Translate(pt2r,25000,0,0)
		pt4r = Geometry.Translate(pt1r,25000,0,0)
	elif side ==0:
		pt3r = Geometry.Translate(pt2r,0,25000,0)
		pt4r = Geometry.Translate(pt1r,0,25000,0)
	elif side ==1 :
		pt3r = Geometry.Translate(pt2r,-25000,0,0)
		pt4r = Geometry.Translate(pt1r,-25000,0,0)
	elif side ==2:
		pt3r = Geometry.Translate(pt2r,0,-25000,0)
		pt4r = Geometry.Translate(pt1r,0,-25000,0)	

	yard = Rectangle.ByCornerPoints(pt1r, pt2r, pt3r, pt4r)  

	good = []
	for lines in site:
		intersec = Geometry.DoesIntersect (lines, yard)
		good.append(intersec)
				
	if sum(good) == 0:
			moose += 500
	moose +=1
	count +=1

cheese = 21

OUT = pt1r, pt2r, pt3r, pt4r, sum(good), count, cheese, yard

All this works fine in dynamo but when I export to the GD engine…

Hello
try replace

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

rect = UnwrapElement(IN[0])
site = UnwrapElement(IN[1])

with this

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

rect = IN[0]
site = IN[1]
1 Like

Oooooo!!! There seems to be some output! Awesome! Thank you!

Can you explain why please?

I thought I had to unwrap because the site boundary (green line) was from Revit.

si that the Python nodes to be compatible with Refinery there must be no reference to the Revit API (the UnwrapElement method allows you to expose objects to the Revit API)

1 Like

Interesting! Again, thanks. :slight_smile: I’m finding out quirks as I go along.

Is there anywhere where all this stuff is written down or is it a ,“trial and error” thing?

There are explanations of @JacobSmall on this post

1 Like

This is a study I want to know about… What are we doing with moose and cheese?

On a less light note, be careful with the Random module in Python when using GD. You’ve correctly constrained the value to 2 with the included seed value, but this is preventing you from adequately exploring the larger scope of the design space when set to a static 2 the way it’s done here - what if the value was 1? 4? 16? Those could provide the ‘ideal’ result and you’ll never see it right now.

When in doubt, keep a means of controlling the values, and for ‘infinite space’ problems it’s best to break things down to MANY controllable values (you can run new studies as you learn about the design space in previous studies).

In this case, I’d consider an alternative logic flow (sorry for not making better graphics on this - this was all I had time to build while on a phone call):

In less time than it took me to export the graph workspace image above the study produced 38 generations of 100 results, and came up with two options with a score of 10 - one moose is interfered with, but otherwise all other goals were optimized.

And adding in the time it took me to write that paragraph about the 38 generations of 100, I’m getting perfect scores:

Likely worth adding more fit functions and program (driveways? ratio of addition to main unit? fenced in yards? whatever the cheese output was?) or otherwise ‘locking down’ the space a bit more.

In totality it took very little time, and provided a layout with some potential:

Pretty good for a ‘on a conference call at 7:30pm study’ in my opinion.

Thanks for the inspiration on the quick study. DYN attached.
Avoiding Moose.dyn (146.7 KB)

Dynamo Core 2.8, and I believe no custom nodes beyond what’s required for generative design.

Hope you got something from it. :slight_smile:

2 Likes

I just had a chance to have a quick look at your script.

image

:joy: :joy: :joy:

1 Like

As I typed that I realized that somewhere out there is an AI doing image recognition and has incorrectly identified a moose as a tree, and trees as moose because “they are both tall and have a structure which branches as it goes up.”

The question is: does it have trees tagged as moose, or moose tagged as trees?

1 Like

Maybe there is a hybrid species we’ve not discovered yet and by this conversation it’ll be discovered sooner?

1 Like

So I got a chance to put this into GD… I can’t get it to run… Even after 24hrs it’s still swirling.

image

Also the delete bin is greyed out. Any ideas why?

What’s the spec of the pc you use?

It’s a 15" Thinkpad with an i7, but that’s not the issue.

Notice you have multiple studies running concurrently. You’ve basically put yourself into a loop as a result. Note that optimization studies cannot be ‘paused’ without letting the first generation finish, then the pause shows up, and you can hit that and it continues until the 2nd generation finishes… it’s not a great system but it works. Just don’t rely on pause too much - think of it as more for the ‘I’m back from lunch and will be starting back up my real work soon, but don’t want to quit so I can kick this back up when I go to that meeting at 4’ situations than ‘I need my computer back, stop this now please’. There is (a significant) lag in it’s function.

Also, if you send new studies before the other one finishes (or pauses) you’re goin to be suck waiting everything out as there isn’t a way to ‘unpause’ and ‘pause’ in succession without risking putting yourself into a loop like you are…

The ‘way out’ is likely by restarting your cpu entirely (give it five minutes in the ‘off’ status). Go back into GD after the restart, and delete the studies. If a study (any of them - moose or otherwise) ‘auto starts’ wait for that pause button to become available (it’ll get there in time), pause the study, delete the study, and go from there (only starting one at a time going forward). :slight_smile:

1 Like