Small issue - Honeybee_Run daylight Simulation done output

Hello,

I found a small issue on the Honeybee_Run daylight Simulation component. As you can see from the screenshot the done output return True even if the simulation didn’t even started, but just for the fact that the Rad file (?) has been written and actually the result folder created. Is it something wanted? Because this create some problems when planning many simulations one after the other in a “cascade” style, where the following could start when the previous end using the True in the done output of the previous as input in the the runRad input of the following simulation. Thank you.

best

Francesco

Hi Francesco,

I think your logic is right but at the same time writing the radiance file is a task which is done at some point. Isn’t it? Can you tell me more about your case? In Grasshopper logic the components under shouldn’t trigger if the component upstream hasn’t finished the execution.

Also can connecting the same boolean toggle to both writeRad and runRad potentially solve the problem?

Mostapha

Hello Mostapha,

what I had to do recently is a bunch of simulations (10) for a total of about 4 days. I wanted to run the first simulation and come back after the weekend (approx.) to find everything done. So I prepared all the building variations and I did input every configuration in one daylight simulation component. (next image)

Afterwards to have one simulation done after the other, since the “done” output get true just after the writeRad input is true (as I described before) I used the output resultFiles that before the .ill files are writte is null, when the .ill files are written is not null anymore. So I used this “switch” to have a true output after the .ill files where written (and I delayed the true output of 1 miunte). So after 1 minue that every simulation was complete (.ill files written) the next was starting. (next image)

So the point is that it would be good if the “done” output would get true only when the simulation end to use it as the input in the runRad input of next simulation, in order to avoid the trick of the null output (that is just one possibility there could be many).

Best

Francesco

Hi Francesco, I see your point here… and Holly Cow! that script is huge. I wonder if there was another way to animate the sliders? I’m happy that it worked for you anyways.

Hi,

I’m impressed with this spaghetti plate …

I wonder if the example of the Polinator can not fit this issue. After all it runs all the connected sliders and simulate one after the other. Can be …?

-A.

Hello,

thank you for the suggestion Abraham. I heard about Pollinator but I thought it was still in dev stage. I will check about it.

Best

Francesco

Hi Francesco,

The suggestion of the Polinator was not because of the polinator itself but because the file runs automatically the sliders. In the discussion, if i remember well, i attached a file using it. I’m attaching it again here. Have a look at stage 6. I just think this may help.

-A.

ParametricEnergy_01+Pollinator.gh (555 KB)

Hello Abraham,

thank you for the definition! I will check it.

Best

Francesco

Hello again Abraham,

thank you for the suggestion it looks very useful. More than Pollination itself (like also you say) that is just a visualization and result reading tool, nevertheless very interesting but not the solution to simplify a process like the one I presented, what would be very useful is the script by David Rutten, Permutations. Actually I knew about but I totally forgot. Is it already implemented into GH? I don’t think so. So where I can download it? I could copy paste it from your definition, it is the Run all the iterations component but it is orange and the there is no icon so I am not sure it is a working one.

Best

Francesco

But actually I still have a doubt:

how GH or the component WRun all the iterations" knows when is the time to change the value of one of the sliders? This can happen only when the running simulation is over, so to start another, so does it know when the simulation is over? Or it happens automatically that the value inside the slider is not changed yet untill what it produce (next simulation) can run?

Best

Francesco

Hi Francesco,

I would answer your question with a yes.

I simplified the example to just the necessary ones to see how it runs and goes. See attached. See the dat recorder at the right to better understand the process. Basically it runs one after the other, so imagine that you change a slider value for a simulation. It is performed and then you change another value, and so on …

Additionally take a look at the TTToolbox Brute Force component. Didn’t use it, but i understand it runs all possible values of the connected sliders.

-A.

Propagator.gh (19.9 KB)

Abraham,

thank you a lot again. I will go through your suggestions and definition and I’ll let you know.

Best

Francesco

hello Abraham,

so I tested it and I think it works for simulations the component that run all the iterations, so thank you very much. I have just one question: do the component work also with a boolean toggle? Or only with the click button? Because with the click button first you have to wait that the first simulation is completed then you can start the run all the iterations component. If this works also with the boolean toggle then with just one boolean toggle is possible to start everything (the daylight analysis component and the run all the iterations component) so it is not necessary to wait that the first simulation is completed.

Best

Francesco

Hi Francesco,

Glad to hear it works for you. I tested myself the BruteForce and it works exactly as the Propagator component.

They both use the Click button. They require the switch on/off and don’t like the True/False option. Moreover, they require to switch to False in order to perform the action, or at least, to show the results. So i’ll stick with the click.

I think that the reason it runs the first one is not related to the BruteForce/Propagator but rather to that that the Run input is set to True. Don’t see any work around this since this run must be set to true. Maybe if you kill the shell window for the first run it can save some time.

-A.

Hi mostapha, I’ve been following your tutorial on Daylight Sim and I encounterd the same problem as described by Francesco. The component doesn’t show any warnings, only the red wires coming from the results. Some outputs are null and the last, “done” it’s set to truth. I found the idf files generated in it’s directory. It doesn’t matter if it’s a complex geometry or just a box I get the results. Any ideia how solve this?
Thanks! :slight_smile:

Hi Mostapha,
I tried conecting with the same bolean toggle, but it didn’t work, nor the oposite, one toggle for each . I checked on the directory and it’s missing .csv and . iel. files. There was a rad file, even do I couldn’t acess it from the component. There was also a file named error that contaied the following:


*** PID 13516: rpict -t 10 -vtv -vp 14.993 -40.506 40.808 -vd -0.174 0.796 -0.579 -vu -0.123 0.566 0.815 -vh 57.247 -vv 26.991 -vs 0.000 -vl 0.000 -x 1826 -y 803 -af unnamed_IMG.amb -ps 8 -pt 0.15 -pj 0.6 -dj 0 -ds 0.5 -dt 0.5 -dc 0.25 -dr 0 -dp 64 -st 0.85 -ab 2 -ad 512 -as 128 -ar 16 -aa 0.250 -lr 4 -lw 0.050 -av 0 0 0 -e error.log unnamed_IMG.oct

rpict: 0 rays, 0.00% after 0.0000 hours
rpict: 279116 rays, 100.00% after 0.0000 hours

Thanks!
Isabela