Grasshopper, Processing, Galapagos linked using GHowl

I am trying to develop a set-up that allows me to use Grasshopper, Processing, and Galapagos together using GHowl, but have run into a strange issue that I have not been able to solve.

The link between grasshopper and processing using GHowl appears to work fine, but Galapagos is not able to solve correctly. I have noticed that Galapagos associates the Genome with the wrong Fitness (Genome off by one fitness input). This is noticed when reinstating chosen Genomes.

Files attached (using them as proof of concept), if anyone has any insight that'd be great! Not sure if its a GHowl/Processing/Galapagos adjustment that is needed. Thanks!

Attachments:

multMax2.gh, 5 KB
MultMax.pde, 1 KB

Replies to This Discussion

Permalink Reply by David Rutten on March 29, 2013 at 1:44am

Moved from 'Errors, Bugs and Oveesights' into 'Discussion'.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Hannes Löschke on March 29, 2013 at 1:43pm

Didn't open you definition but from you description here's what's probably happening:

Galapagos triggers a new calculation. All components are triggered along the path from left to right. Once one component is done, the next in line is triggered. The output component doesn't connect to another component, so this is the rightmost in a path or subpath. The input component doesn't get any GH data from another component, so it is the leftmost in a path or subpath. Depending on the topology of your definition, there is a good chance, your input is triggered before the output could send any data.

Now let's assume, input and output are triggered in the correct order. The output component sends data to processing and signals it's finished. No component in the path will know whether the processing part is done or not. The input is called pretty much immediately and collects any data present. This is most likely the cached date from the last calcualtion cycle of the processing part. So while fresh data is sent to processing, the result form the last cycle is fetched/cached in the input.

Pretty much the only chance you have is to do output and input to processing in one component(e.g. script) and wait for processing to singal it's done with the calculation.

Permalink Reply by John Baker on March 30, 2013 at 4:05pm

Thanks for the insights Hannes, I'll see what I can do...

Permalink Reply by John Baker on April 1, 2013 at 2:09am

I've been able to create a single component that sends and receives data through a text file, but have run into similar issues as before. Is there a good way to "wait" for processing to signal it is done and a means to clear the cache when Galapagos is initiated? My current files are attached (you'll need to adjust .txt file paths in the vb script).

Attachments:

VB_TextTrans2.gh, 6 KB
Text_Trans2.pde, 1 KB

Permalink Reply by Hannes Löschke on April 1, 2013 at 6:39am

Your problem remains the same: you do not wait for processing to finish writing the output file. GH immediatly reads the output after it has written the input file. This will most likely read the file that was written in the last cycle. There are several differnet ways to share and wait for data in a Win environment. Shared files on the HDD being the worst.

btw: what is your reason to use Processing anyway? As far as I can see (from an uniformed outsider view), it's just a C-style code editor with some built in graphics and 3D object library. As far I can see, you could as well use the GH C# script component.

RSS