I am using ClimateStudio for daylight and energy simulation. Whenever I am running Wallacei to iterate through the genes, I am getting daylight result error. Wallacei is successfully iterating the genes, and energy results are being read; however, daylight simulation is not being conducted. An error on the ‘Run CS daylight’ is popping up:
“1. Solution exception:The calling thread must be STA, because many UI components require this.”
It is to mention that, I tried Octopus to run both daylight and energy simultaneously using the same script, and it is working. Also, I tried Galapagos to check if I see any error for daylight simulation. But it worked too. I have attached the files herewith for reference.
There seems to be an incompatibility issue between these two plugins (primarily around the UIs of both)… without going into too much jargon, the short answer is that you may not be able to use the ‘Run CS daylight’ component with the current release of Wallacei. However we appreciate that this ‘incompatibility’ issue may crop up again in the future (although this is the first time we observed this) and so in future releases, we may offer a function that addresses this incompatibility.
Thanks for your reply. Yes, I also think so! Every time, the problem occurs when ClimateStudio (CS) prompts its UI, which Wallacei can not read (it can read cmd though). I tried several ways, but failed due to incompatibility issues. I was trying to write a short script so that wallacei can recognize the UI of CS while iterating the independent variables. However, I don’t know if CS/Wallacei released any API. Solving this issue will be awesome in the future release <3. Will be waiting for that.
we have the same incompatibility issue with Climate Studio and Wallacei. Just for information, we also are not able to run Climate Studio with Hops and already raised an issue at Climate Studio.
I recently ran into this same problem. Basically, I was trying to feed Wallacei with Daylight results from Climate Studio (through the Grasshopper interface), to generate optimized geometry and materials variants and feed them back into CS. (closing the loop)
As mentioned before, there is an incompatibility issue between the CS and Wallacei interfaces. To overcome this, I split the simulations (processes) into two separate Grasshopper files and made the necessary links between them using the data input / data output components. Resulting in one GH file containing the Wallacei workflow and another the CS Daylight workflow. In a way, one could think of it as teleporting data instead of transferring it via a physical bridge.
Now, there was one final issue to overcome. As you guys have mentioned before, Wallacei will not recognize CS UI is running so it will continue iterating variants even if the daylight results (my inputs in this case) are not changing. What I did was to implement a “dummy” DF simulation (using Honeybee and in the same canvas as the Wallacei workflow) which takes a little more time than the CS solver to finish.
This works as a delay since Wallacei will detect the cmd window from the DF simulation and wait until it´s done to iterate the new variant, giving CS enough time to finish the simulation. I´m sure this delay can be implemented with a python script (this will give even more control over how long the cmd command is active, AKA: delay time)… yet it would have taken me longer considering my limited programming skills
This idea worked for me, I hope it´s useful for somebody else as well, while the incompatibility issue gets resolved.
Having a similar issue. thanks for the temp workaround Daniel.
Has this issue been addressed or is there an update from either CS or Wallacei that anyone is aware of?
Thanks for sharing the solution. I wonder how you managed to run the CS simulations and the HB one at the same time since they run one after the other and that does not seem to solve the problem.
Can you share a sneap peak of you definition? I need to run a similar case with Wallacei.
