As this may have been mentioned a few times on the forum, I would love to see a method to do direct sun only daylight calculation with LBT. I would like to run a ab 0 simulation but I recalled I saw from other posts that the current DC method will not run properly if we set ab 0 in radiance parameter input. In HoneybeePlus we had an option to read direct sun only results but that option is not available in LBT now. My understanding is the DC method already give us the ab 0 results and we just need to expose it.
This may be already in your pipeline as I saw you guys mentioned ASE component a few times. While we are waiting for that, do we have a work around to access the direct.ill files now?
I do saw another post recommending using direct sun component. However, I suspect grasshopper will freak out with the direct sun component on a bigger model.
Itās possible that the HB Direct Sun Hours recipe already gives you what you need. It runs an -ab 0 simulation. Itās the same metric as that computed by the LB Direct Sun Hours component except that it uses Radiance. So it can handle a bigger model without freaking out. The only limitation is that the recipe converts the input Wea to a constant irradiance so that each sun position gets weighted equally and you can actually count the number of hours from the results.
If you actually need the hourly direct irradiance or illuminance, then you are correct that these are calculated under the hood by the HB Annual Daylight and HB Annual Irradiance recipes. Theyāre just not exposed on the component outputs. If you check the simulation folder of the Annual Irradiance recipe, youāll see that there are actually direct results that are right next to the total results:
So you can use that if you need it. The direct illuminance results in the Annual Daylight recipe are a little harder to reconstruct right now but they are there. Still, it might just be easier to run an Annual Irradiance simulation and multiply the direct results by 179 if you need direct illuminance instead of trying to reconstruct them from the current Annual Daylight output.
Thank you Chris for the guidance. Good to know that there is a HB Direct Sun Hours component that use Radiance.
And you are right I do need the direct illuminance value so HB Direct Sun Hours may not be the right one. I tested with the Annual Irradiance recipe and it works quiet straightforward. However, do you mind explaining a bit about the difference between the two recipes? I saw total_sky and direct_sky files in the initial results and are they leading to total and direct results directly or there are some math behind it as the Annual Daylight recipe?
Also out of curious, why we are not reconstructing the grids in Annual Irradiance? Assuming reconstructing the grids will speed up the simulation.
Also, the Annual Irradiance results (total) times 179 is giving me a higher values comparing to Annual Daylight results (total), about 1.6 times higher. I donāt expect exact same value but 1.6 times higher values seems wrong to me with the exact same model and radiance parameters. Any idea why @chris?
Ah, sorry that I forgot thereās a little more of a difference between Annual Irradiance and Annual Daylight other than the multiplication by 179. The sky irradiance values are also different and I would be that accounts for the 1.6 difference that youāve noticed.
So, yes, the right way to get the direct illuminance is by reconstructing the direct_sky files in the initial_results. I think weāll add a step to do this in the recipe soon since we are planning to add ASE at some point. I think we just wanted to make it a little harder for people to get ASE right now because, if we tell people that they can get it, they are immediately going to think we can do LEED daylight, which is not going to be true until we implement dynamic window groups.
The only difference between the initial_results and the final results is that the sensor grids in the inital_results are split up for optimal parallelization whereas the final results are split based on the structure of the input sensor grids. If you really need direct illuminance right now, you can use this command to reconstruct the initial_results into final results.
Thank you Chris, I got two follow up questions then.
This is a critical one. My understanding is that the sky irradiance values are higher than sky illuminance values as they are full spectrum. So I think using Annual Irradiance recipe and then multiply results by 179 is giving me the āwrongā (higher) results because Iām looking for illuminance values for ASE purpose. Do you agree?
I respect the decision of ASE. For my project I donāt mind hacking a bit but wonder if you can point me to a few places where the code lives.
a. the radiance command for the ill files (direct and total for annual irradiance). I understand the illuminance one (total - direct sky + direct sun) but donāt understand the irradiance one.
b. If I want to hack the Annual Illuminance results, the procedure should be I) direct_sunlight.ill ā final folder II) final folder ā results, am I right? Is there a command for the step 1?
Are they using the daysim discretized sky of 144 patches or the ā2 phaseā (I think you refered it to previously) simulation with a more precise direct sun?
I believe so for the Annual Daylight, as you can see from the initial results folder there are three files: total_sky.ill, direct_sky.ill, direct_sunlight.ill and I think the final result = total_sky - direct_sky + direct_sunlight.
For Annual Irradaiance, Iām not sure as there are only two files there, total_sky.ill and direct_sky.ill. Per Chrisās previous reply, the final result = total_sky.
Yes, both the Annual Daylight and the Annual Irradiance recipes use the same āEnhanced 2-Phaseā method that accurately models the direct sun. To answer @Bing 's questions:
I had never thought of it that way but your logic makes sense. If you want to do a side-by-side comparison of the two recipes, you can compare the code in this file to the code in this file. I see that we need to specify that the sky is for a broadband solar study when we create the sky in the annual-irradiance recipe but we use the default visible sky in the annual-daylight recipe. So thereās definitely more happening there other than just multiplying results by 179. The notion that the broadband solar sky just has 60% more solar energy than the visible sky seems like a reasonable explanation.
There are a few different commands in the recipe that produce and process ill files. So I donāt know which āradiance command for the ill filesā you are asking about. In any event, I decided that weāre a little overly-concerned about the ASE situation here and thereās still quite a big jump between a matrix of direct illuminance values under the hood of the recipe and people thinking that the recipe does LEED ASE. So I just updated the annual-daylight recipe to be like the annual-irradiance one and it will give you the direct illuminance results right next to the total ones:
So just update to the latest development version of the plugin and youāll be able to get the matrices of direct illuminance.
Thanks Chris for the changes. This definitely save my effort of hacking the results. Will test it and report back.
Meanwhile, there is still one remaining question I did not understand yet - why the annual irradiance recipe is not creating a direct_sunlight.ill file if it is using the same method as annual daylight? The recipe annual daylight and annual irradiance seems very similar so maybe just the files got deleted? I would suggest if we can align these two to avoid confusion.
I think your question will be answered when you see the new annual-daylight simulation. The annual-irradiance recipe is calculating the direct sun .ill files. They are just getting saved to the initial_results/final/direct folder instead of initial_results/[GRID_NUMBER].
Got it. I do see it now both recipe is giving two folders - direct and total. I think direct equals direct_sunlight as we had before and total is the one that do the math. Let me know if I got it wrong.
Just a follow up on this as we ran some sim recently after this change. We found the direct.ill files have three times of the data for each point comparing to total.ill. My guess is the direct is recording r g b separately while total is not. I wonder why we are treating them differently?
More importantly, I wonder if this difference will break the result handling process when we plug the result folder path to the HB component.
Youāre right @Bing . This is a bug, which Iāll fix when I get the chance.
In the meantime, it might be better for you to use the Annual Irradiance recipe for this case. I recently added a visible_ option that allows you to compute just the visible irradiance (which you can multiply by 179 to get illuminance). The ādirectā results from the Annual Irradiance recipe should be correctly converted from RGB to full-spectrum and using this recipe has the added bonus that you can run Weaās at timesteps other than 1.
I just wanted to say that I think we might still refactor these ādirectā capabilities here one more time. They will all be available but just distributed differently across the Annual Irradiance and Annual Daylight recipes.
We came to the realization that the use of ASCII matrices (instead of binary matrices) thatās needed to get the direct illuminance results can really slow down certain steps of the calculation when there are a lot of sensors. Given how often people use the Annual Daylight recipe in parametric studies, this can really add up. So we would really prefer to use binary matrices as much as possible under the hood of the Annual Daylight recipe and remove the direct illuminance results.
However, given the flexibility that weāve already built into the āAnnual Irradianceā recipe, this one is going to be slower no matter what. So Iād much rather just say that āif you need direct illuminance values, just use āAnnual Irradianceā and set the visible_ option to True.ā My response would be similar if you need illuminance\irradiance values at sub-hourly timesteps since this is much more easily supported in Annual Irradiance than Annual Daylight, where we have to coordinate the sub-hourly timesteps with an hourly occupancy schedule.
The other thing that makes me comfortable with this approach is that, if people need a really fast way to get cumulative radiation or average irradiance over time, they can use the Cumulative Radiation recipe instead of this time-consuming (but very flexible) Annual Irradiance recipe. So it feels like thereās a recommended recipe for all situations depending on whether speed is more important to you vs. having a full record of results.
If I got it correct, you would like to remove the direct component for annual daylight recipe, and we can use annual irradiance component with visible only option to get the irradiance then multiply it by 179 manually. I think this is fine for advance user and maybe adding one option to do the math in some post-processing component will help some intermediate users.
I understand your concern of simulation time and I agree if people are using daylight recipe way more than irradiance recipe (hourly). So I agree with this approach.
However, I do feel the issue still exist. Just throw in a thought here, how about adding a āoutput direct only resultsā option if the direct component is the only part that requires ASCII format of data. This may expand the capacity to do direct only parametric design?
Yes, @Bing , you are understanding the proposal correctly. Iām thinking of some ways that I could help people multiply by 179 and change the units from W/m2 to lux when they use the Annual Results to Data component. For the spatial visualization, I think it might just be easiest to tell people to use the native Grasshopper multiplication component.
This is a good suggestion but itās unfortunately a lot more work to implement in the annual daylight recipe given the way that we execute recipes right now. However, if Iām understanding correctly, youād ideally like to run a study where you ONLY care about the direct irradiance and you actually arenāt interested in the total irradiance at all? If so, there might be some ways of adding an extra input to the Direct Sun Hours recipe to accommodate this.
I think we (at least me) got lost a bit what we are trying to achieve. The ādirect sunā result came as āfreeā side product will help to calculate ASE when running a sDA simulation. This is the main reason I was looking for this. I guess from this point of view, if we move the functionality to irradiance simulation, it still requires us to run another simulation, which does not help as I can just run a ab0 daylight simulation.
So it is not that we donāt have the capacity to run direct sun only simulation, but more like we can hit two birds with one stone from efficiency point of view. If it is causing a simulation speed problem that we have to take it out and run another simulation, I will say it is fine, either ab0 calc or irradiance sim can do that task.
In terms of Direct Sun Hours, I believe you are referring the HB one correct? The issue with direct sun calc is that it is only outputing 0/1 that we cannot adjust the threshold as needed.
