Cycles and sliders

Hello everyone,

I'm making some hourly solar radiation simulations in a large geometry with more than 1000 individual buildings, so I'm calculating one building at a time. To do this, I created a "buildings" slider to select each building and run the solar radiation simulation and save the result into an excel file. It works, however it takes around 2 hours to compute radiation in all buildings, but I think there's nothing I can do about execution time.

The problem is that I would like to change the Analysis Period automatically and restart the "buildings" slider so that I don't have to check my computed every 2 hours, but I just can't figure out how...

For instance, suppose I want to calculate hourly solar radiation for the 21st of January, from 6am to 7 pm. It would be convenient if I could Animate the "hours" slider so that once the simulation for the last building was finished the "buildins" slider went to 0 again and the hour changed to 7. And so on...

Perhaps a small script with a basic cycle would solve the matter, but I still can't figure out to control the sliders as they have no input options.

Any ideas?

Thanks in advance!

And I'm sorry if this is a basic question or it has been discussed before (I'm new here and I didn't yet find similar discussion on this website).

Replies to This Discussion

Permalink Reply by Joseph Oster on January 18, 2016 at 7:57am

re: "computes and records 1327 radiation values per loop" - Do you mean "per one outer loop"?

My guess is that the inner loop computes ONE radiation value per iteration?

So without being able to see your code and examine the data, I can see the potential for getting 1327 + 1326 + 1325 + etc. values being recorded, which is not what you want. So you need to examine what is being recorded by the inner loop and perhaps disable 'Record data' and build your own list of results, appending each building value to a list that is passed through the start/end inner loop components.

P.S. Is 'Record data' disabled on the outer loop? Did you flatten the output of the inner loop?

As usual with large data sets, you want to get the code right using only ~10 buildings before trying it with 1327.

Permalink Reply by Sara on January 18, 2016 at 8:36am

Yes.

One radiation value that is the sum of all radiation values on the facades of one building.

Well, it's easier if I show you my code.

I first tried with 10 buildings and it was fine and seemed fast. Then I introduced the whole set of buildings for 6am and it took something like 5 seconds to calculate each building, which is perfectly fine since I am using LadyBug, and it was done in less then 2h. But 1327 x 10 ruined everything... It must be something with the way I'm recording the data.

Thanks again for your help!

Permalink Reply by Joseph Oster on January 18, 2016 at 8:46am

Go back to ten buildings. Turn off 'Record data' in the outer loop. Use the 'Data Recorder (Rec)' component to examine the output from the inner loop. I'm sure you can fix this and then switch to Anemone "Fast Loop" on the inner loop - I think you'll see dramatic improvement.

Permalink Reply by Sara on January 18, 2016 at 8:52am

The code was missing.

Attachments:

Radiation_Buildings_2.gh, 5 MB

Permalink Reply by Joseph Oster on January 18, 2016 at 9:16am

OK, I don't have "TT Toolbox" - is that necessary to debug the loops? I don't need to write to an Excel file.

Attached is a modified copy of your file with only ten buildings (much smaller!) but all I get for output is nulls... Can you make this work without "TT Toolbox"?

Attachments:

Radiation_Buildings_2016_Jan18a.gh, 402 KB

Permalink Reply by Sara on January 18, 2016 at 9:34am

Data recorder works for 10 buildings yes, I will try will the 1327 just to see if it gets slower because I need the results in excel organized by 1 column for each hour to input into another program - Data recorder gives me a huge list

Permalink Reply by Joseph Oster on January 18, 2016 at 9:42am

You don't understand... If you want help with Anemone loops, I need to be able to run your code with just ten buildings and examine the data at various points. Rushing to 1327 buildings misses the point where things apparently get whacky.

I suspect that if you organized this code so that the radiation calcs were simply a replacement for the 'Volume' component in my examples, it would work fine, no matter how many buildings. Something is amiss in collecting the results.

Permalink Reply by Joseph Oster on January 18, 2016 at 9:54am

By the way, looking at just the first 11 buildings, it's obvious that many surfaces are blocked by adjacent buildings. I don't see anything in your code that accounts for that?

P.S. It looks to me like the code you posted today depends on other files? At least this one:

C:\DAYSIM\wea\PRT_Lisboa.085360_INETI.epw

Permalink Reply by Sara on January 18, 2016 at 10:13am

Sorry, I didn't understand that you were unable to run the code. "TT toolbox" is not essential but to prepare the results for the other program.

Yes my code depends on that specific weather file (attached).

The adjacent faces aren't a problem since one of the faces receives 0 radiation and the other that might receive a bit is accounted for in the right building.

Attachments:

PRT_Lisboa.085360_INETI.epw, 1.5 MB

Permalink Reply by Joseph Oster on January 18, 2016 at 12:54pm

Sigh... How to summarize...

First, there appears to be a HEAVY overhead just opening this file, perhaps due to the pre-processing of the PRT_Lisboa.085360_INETI.epw file. More than one minute! And the loops haven't even started yet. This is a one time overhead - re-starting the loops after that doesn't have this long delay until you close and re-open the file.

Second, I got some encouraging results rather quickly but then spent WAY TOO MUCH TIME trying to replace the inner loop with a "Fast Loop". These are not well behaved in the sense that they don't respond to <ESC> like the "Classic" loops do so you can't stop them; and I never got the same results as the "Classic", no matter what I tried - but ultimately, I just got too frustrated with "Fast Loop" causing Rhino/GH and my whole laptop to freeze up - VERY BAD!!!!!!!!!!

I re-wired the loops slightly so that the hour used by your 'analysisPeriod' cluster is determined by the 'D0' value inside the inner loop.

I added a "Loop On / Loop Off" switch to stop/start the looping (which was useless with "Fast Loop" - grrr....).

I 'Simplified' the 'D1' output of the inner loop and enabled 'Record data' and 'Output after the last' on the outer loop.

And I got this - four buildings over three hours takes about 20 seconds:

Eleven buildings over three hours takes about one minute.

I'm not sure what will happen when I increase the hours and number of buildings but will try it when I have more time. It might be a good idea to avoid writing to Excel inside the loops and wait for the end results before writing them to an Excel file?

There are more possibilities for re-wiring based on simplifying various outputs but I'm tired of this for now and have other things to do. The exponential slowdown you observed might be due in part to Anemone adding an extra branch path every time it loops; adding 'Simplify' might help this?

P.S. 11 buildings over 13 hours (6am to 6pm) took 5 minutes 38 seconds.

Attachments:

Radiation_Buildings_2016_Jan18c.gh, 408 KB

Permalink Reply by Joseph Oster on January 18, 2016 at 2:29pm

100 buildings for 13 hours (6am through 6pm) took one hour and twenty minutes on my old laptop, running mostly in the background.

Not sure if it got slower near the end (or if I just got less patient).

At that rate, 1327 buildings would take ~18 hours!!! Ouch.

I wonder if swapping the loops is any faster? Once through the buildings and 1327 times through the list of hours?

Results for 100 buildings attached - do they match the data you have?

Attachments:

Radiation_Buildings_2016_Jan18e.gh, 23 KB

Permalink Reply by Sara on January 19, 2016 at 5:22am

Joseph thank you so much for your time, I'm sorry for the trouble...

The results you sent match my data, yes.

How old is your old laptop? 1h20 per "hour loop" is very good compared to ~1h40 I got with the old code (not to mention that, besides getting slower and slower as the "hour loop" incremented, I used 2 different PCs, and one of them crashed every time in the middle of the 3rd loop...).

Yet I doubt it can get significantly faster, since ladybug takes ~3/4s to execute...