Grasshopper

algorithmic modeling for Rhino

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

Views: 458

Replies are closed for this discussion.

Replies to This Discussion

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.

Attachments:

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.

Attachments:

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

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service