I want to use the Ladybug Fly component to automate EnergyPlus simulation for three instances using different zone geometries:
The boolean toggle for Ladybug Fly is also connected to the node write IDF file and run simulation on the RunEP component.
However, it seems that once Ladybug Fly is activated, the simulation will run the first instance before we see the window indicating the total number of instances to run and asking user’s confirmation and, once confirmed, the rest two instances will be executed:
Would this defeat the purpose of this component to fully automate the workflow if it’s interrupted by the execution of the 1st instance? what if the 1st instance takes a very long time to finish…?
Appreciate your advice on how to fully automate the energy simulation workflow.
test_autorun_v003.gh (519.9 KB)
I believe this is because of the execution order.
the Fly component is after the RunEnergySimulation component on the Grasshopper’s execution order list.
You can move Fly to the top of list by using key “Ctrl+B” when Fly component is selected.
or, separate the toggle to control Fly individually.
Unfortunately, the issue remains after bringing the Ladybug Fly component to the back of the canvas using “Ctrl+B”, i.e. the first iteration will be executed before we see the confirmation window of Ladybug Fly to continue.
Separating the boolean toggles to control Ladybug Fly and that for execute the simulation produces the same issue, see the GH file attached.
ladybug autorun issue _v04.gh (525.0 KB)
I encountered a similar issue running daylight simulations studies in the past.
What I would recommend is:
1 - separate the boolean toggles to control LB fly separately
(i.e. one toggle to control LB fly, one for running the simulation, and one for creating the zones, opening the epw, and choosing outputs)
This way, it is easier to control separately the diffrent processes of your simulation
2 - Create the zones, open the epw you want with the first toggle
3 - Turn the boolean to true for running the simulation. If the simulation takes a long time, then cancel it (it will be re-runned anyway when turning LB fly to true)
4- run your parametric study using LB fly.
I my mind, the overall idea is really to separate the different steps of your simulations in order to be able to control separate items.
The way I would personally do it is by using “false start toggle” for the parts of the simulation that I need to not auto-run when opening the file.
Thank you, @AurelienKeller, for your advice.
I’ll try your suggestion to quickly cancel the first interation/simulation and let it re-run once LB Fly is activated.
As to your suggestion on “false start toggle”, I’m thinking similarly to go with the “limitation” of LB Fly by adding an extremely simple dummy case as the first iteration so that we can quickly continue once it’s done.
How do you think?
Hi @Grasshope, if you really want to control the simulation by one toggle, please use Colibri’s Iterator.
new.gh (517.7 KB)
Thank you very much, @MingboPeng, for your advice!
Hi, @MingboPeng, I installed the TT Toolbox, and it seems the iterator component looks different from what was shown in your image above.
May I ask if this is due to the update of the TT Toolbox?
sorry, just found out that by right-clicking the component and choose RemoteFly, the component will be shown as is in your image.
Thank you very much, @MingboPeng. Will take a look of the example file.
Dear @MingboPeng, for the GH file attached here, once I run the iterator (set RemoteFly to True, or click Fly), only the last case is processed.
Also, sometimes the iterator just kept running the last case for multiple times and I had to intervene to stop the process.
Can you kindly take a look and advise which part i did wrong in terms of using the iterator to drive the simulation for multiple cases?
colibri_iterator_issue_v001.gh (647.6 KB)
It seems it works fine when you removed “dumpHBObjects”, I need to look into this component for more details, but why do you need this? all you need to save is IDF files from “runEnergySimulation” if you want to check the results later.checked.gh
I’ll remove the dumpHBObjects component for the time being as suggested.
Yes, the IDF file contains everything. However, the IDF importer component in HB currently has limitations, and @chris as recommended using the load/dump HBObjects components:
IDF importer component does not correctly identify the air walls
Theoretically, if I do want to dump the HBObjects for all the cases, I can use the iterator to drive it solely and separately so as not to interfere with the simulation workflow. What do you think?
Unfortunately, after I remove the dumpHBObjects component, the workflow runs by skipping the first case.
I’m not sure if it is an issue related to the iterator component itself or this workflow in particular.
Appreciate if you can kindly help to take a look and advise.
workflow automation issue _v003.gh (641.1 KB)
There is a problem with IntersectMass when running the first one.
Move IntersectMass to the upstream will fix this problem if you really want to use this “IntersectMass”
Usually I will bake or internalize the geometry after using “IntersectMass”, and then do whatever you want without including the “IntersectMass” in the workflow.
Unfortunately, I’m unable to replicate the error related to the intersectMass component.
If this is the cause of the issue here, maybe this component shall be put outside the automated workflow as you suggested. A downside is that this part of process cannot be automated which may took quite a long time depending on number of zones and zone geometries, especially for batch processing multiple cases.
I tried the GH workflow again, and the strange thing is that sometimes it works fine, sometimes it will repeat running the last case for multiple times… Still haven’t figured out the cause…
I am also having problems with colibri.
Although I do not input anything for the colibri aggregator to save images, for each one of the iteration it saves an image.
Is there a way to disable this function?
By default, it always saves an image for you. there is no way to disable it in current version.
But, will add this function in the next release.
Thanks for your suggestion,
While we are here, can I also ask you why the colibri parameters can just take in a list of 10 values max?
Do you think there is the possibility to raise the limit?