@giorgio_butturini reported a similar issue with 5-phase right before we left for London and I didn’t get a chance to study the case. I have more time now to get it fix.

Can you check the values for different mode? The final results is total sky - total direct sky + direct sun. By checking each component we can figure out where is the source of the issue.

@mostapha By the way, there is another problem for using ASE component. In my building I have translucent glass, and I set them as transmaterial and opaque material seperately in two simulations to compare results. But the ASE resulats are always the same. Then I tried sDA component with 1000 lux as threashold, and the DA results are different. Would it be possible for you to check this issue as well?

Now I read your question again and I think I know why this might be happening and this is most likely different from @giorgio_butturini’s issue.

You should not set the -ab to 0 for calculating ASE. Honeybee[+] does 3 separate calculations for each run. You can read more about the workflow here but here is the summary.

As you can see in this diagram, Honeybee[+] calculates the total contribution from patched sky, then calculates the direct contribution from patched sky and finally calculates the direct contribution from analemma.

The calculation for part 2 and 3 are only direct and in a black scene. The reason we need all these 3 calculations is to remove the inaccuracies of contribution from direct-pacthed sky. For calculating ASE Honeybee[+] uses the results form part 3 (analemma) and doesn’t include the calculations from part 1 and 2 which is why I mentioned you should not set ab to 0 to calculate ASE. Your input for ab is only used for part 1 of the calculation.

So what’s happening in your calculation with ab 0 is that radiance underestimates the values for total contribution (part 1) and then since the parameters for part 2 is set by Honeybee[+] it overestimates the direct contribution and that is why you get negative values.

If we check the values separately for total, direct and sun then we will know if my logic is correct.

See my reply below. ASE is only calculated using the contribution from direct sun. There might be cases that ASE stays the same but DA changes. It’s not necessarily wrong.

The strange thing is that by subtracting the direct sky patches component from the 3phase scene, since the indirect lighting value remaining, I should have values close to zero but never negative

In the attached excel file, I had checked step by step the output *.ill files from simulation. The cells with negative value are automatically yellow colored.

@mostapha Thanks very mcuh for your quick reply! I try to understand your logic and guess I get your point, but I’m still a little confused from your graphs. For Daysim, is it not that diffuse + direct, but total + direct? In Daysim the part 1 means total or diffuse? Are the part 1 the same in Daysim and in “improved”?

If HB+ just uses the results form part 3 (analemma) to calculate ASE, that means it is not wrong with ab 0, right?

Is it possible in HB+ to read the three ill files seperately, not just the final one?

@mostapha I change ab from 0 to 1, and find the results in sun…scene…default.ill are still same in two simulation, which I mentioned before with transmaterial and with opaque. But in direct…scene…default.ill the results are different. I guess that’s why the ASE results don’t change when I change the material. Could you please give a simple try to see if I am wrong?

@giorgio_butturini Would there be some hints for me how to use your excel file?

Step1: Diffuse calculation with Monte-carlo raytracing where the user can control the number of bounces.

Step2: A direct diffuse calculation also with Monte-carlo ray tracing with exactly one bounce. This is to get the contribution from direct sun. The user cannot control this and it happens under the hood.

Step3: Finally, a direct-only calculation involving accurate sun. Which again, the user cannot control. Direct calculation does not depend on bounces as it is just shadow testing.

Now, the question is why is it that one can get negative values. So, lets examine the scenario for just one point:
Lets say you set the ambient bounces in Step 1 to 0. So you get 0 lux in from the diffuse calculation. Now you have no control over step 2, so whether you want to or not, you are going to get a value for direct sun which (lets assume) is 500 lux. So, from the first two steps, the resultant lux so far is -500 lux. Now, in the third step, lets say the accurate value of direct sun is 300 lux. Then your result will be -200 lux.

So, what should be done?
First of all, if this is a normal daylighting simulation dont set the ambient bounces to zero. Under any circumstance. Because your results will be wrong. @mostapha, I hope there is a way that users can calculate ASE directly without -ab 0. If that is the case, we have to fix the source code.

As I said before -ab is overwritten by Honeybee[+] for direct calculation. Direct illuminance calculation should NOT include ambient calculation. If you set ab to any number ASE stays the same and that is how it should be. The material change is a different discussion and I need to see your case.

We should have a check to recipe and overwrite -ab 0. Also it might help to take parameters out of the commands and put it in several *.opt files. That will hopefully make the workflow cleaner.

One can write their own recipe to do that but we don’t have it exposed. This is one of the reasons that I’m refactoring the code for the recipes.

If it is just shadow testing in Step3, is the material’s transmission taken into account? I test the transmaterial, which seems to be traded as opaque in this step.

And go back to the work flow. Step 1 is diffuse calculation, but Mostapha explains that is total contribution from patched sky, which for me sounds more makes sense. For step 2 you mean that is direct diffuse calculation, and Mostapha say that is direct. I have already understood the issue of negative values, just the explaination of total, diffuse and direct parts still confuse me.

Thanks again for your patient reply with Mostapha!

Hi @AufAlpen, Mostapha and I figured out why the error was occurring yesterday (outside of the forum). Anyway, the error relates to what I pointed out in my reply. About “direct-indirect” and “direct”, I dont want to confuse you with a separate jargon here, so I will let @mostapha handle this one. If you are a longtime Radiance user, I would suggest referring the paper on Dynamic Daylighting Simulations by Christoph Reinhart and also the Five Phase Method tutorial by Andy McNeil.

In step 3, everything except the window glazing is black and non-reflective. So, trans will be opaque too (right @mostapha? I assume everything that is not a glass material gets the void plastic black treatment?) .

It is most likely happening because of what @sarith mentioned above. @AufAlpen, how did you defined the Trans material? Honeybee looks for isGlassMaterial property which is set to True for glass and BSDF materials. This can be the source of the error.

Sorry for my late reply. I set first the surfaces as glass, then write files and change the glass material to transmaterial manually in the glazing folder, for example replace “glass” with “trans”, and give the 7 parameters. Should transmaterial be added to isGlassMaterial property? I have no knowledge how to do it…