Parametric wea runs same results

[jaclu]

Hi @mostapha

I have watched your youtube tutorial on parametric runs with pollination (very helpful). Instead of varying the geometry I am trying to vary the month and hours of a direct sun recipe.

I’ve set up the iteration and data recorder but have noticed that even during different analysis hours, direct sun results are the same. Does the job only intake the first wea file found?

This is my setup

example of testing June 21 8am-10am and 11am-1pm

running the jobs individually works to get different results but when combined, the 11am-1pm run is showing 8am-10am results.

Any ideas?? Your help is very appreciated!!

[mostapha]

Hi @jaclu! I will have a closer look at your definition. You should be able to submit several wea files for different runs. You need to make sure that you rename them so they don’t overwrite each other.

Meanwhile, if you are downloading the results and visualizing them in Grasshopper why don’t you run it for all those hours in one go and then use the hourly results component to load and visualize the results for each timestep?

Since you are loading the results hour by hour either of these two components should work for you.

[jaclu]

That is the angle I was going to attempt next! Will use that method for now it’s actually probably easier.

Overwriting may be the issue… By renaming, do you mean rename the run or the wea?

Does look like each run has the same wea…

[mostapha]

Hi @jaclu, You are right about the source of the problem.

I imagine that you are connecting the WEA object from the output of the component to the recipe. Under the hood, the handler for the input converts the WEA input to a WEA file. Since the name is based on the location and not the hours all those WEA files will be named the same and overwrite each other. As a result, the recipe uses the last generated WEA file.

The solution is to save the files to WEA yourself and name them differently before connecting them to the Recipe. Here is an example:

@chriswmackey, is there a better way for doing this that I might not be aware of?

[chriswmackey]

Hey @jaclu ,

Thanks for letting us know about this. We hadn’t considered this case but it makes sense. I just updated the code that handles the Wea input to include the start and end HOYs in the name of the Wea file that is written:

fix(wea): Include datetimes in the name of the Wea file

This way, you won’t have one file overwriting another as you change the HOYs.

You can get the update on your end if you run the LB Versioner in an hour or so. It will also be included in the next release of the Rhino plugin.