Negative Values from Annual Irradiance!

[justinfmccarty]

I feel like I am losing my mind…

I have been working on some larger exterior annual irradiance assessments as a part of a photovoltaic pipeline. This recent cluster of buildings I have is turning up negative results in the total .ill file. My setup:

A cluster of buildings of buildings where I evaluate each face (facade, roof) individually. In all but one of ~200 surfaces assessed the .ill file had negative results. I have been debugging the problem using only one surface from now on. I have run many combinations of removing context objects from the simulation and it seems to be the context buildings that are causing the problem but I cannot entirely figure out if that is true due to stochastic processing. For instance sometimes I will run a simulation and get .ill files with no negative results. Then I will run it again to be sure and I will get some negative results. I have run the linked folder on 1.6.0 using both a MacBook and a Windows 11 setup.

problematic_results.zip

If anyone out there has ever encountered this sort of issue please let me know. Code below to process the results quickly.

ill_file = "~/results/total/radiancegrid_139103_340sensors.ill"
ill_df = pd.read_csv(ill_file, delimiter=' ', header=None).iloc[:, 1:].T.reset_index(drop=True)
print(ill_df.min().min())

[justinfmccarty]

EDIT 2: This does not seem to have been the problem. I renamed one of the face sets to “context2” and it still delivered negative values.

Here is a model screenshot. I am currently investigating if the problem comes from adding HB faces to the model with the same name using duplicated components…See the “context” blocks in the bottom left of grasshopper.
Edit, added a comparison of two of the face lists (see same context name).

[justinfmccarty]

I think it has something to do with the height of the nearby context. The top image has buildings that are set to the normal height in front of the sensor points. This leads to negative values. When I set the height of those same blocks (in the bottom) to the height of the highest sensor point, there is no negative value.

[mikkel]

Hi @justinfmccarty,

Can you try to increase the ad to 25000 and adjust lw accordingly? So something like -ad 25000 -lw 4.00e-07, and keep the other parameters the same.

[justinfmccarty]

Will confirm this as a solution after some more robust testing, but it seems to be working @mikkel. My background on radiance parameters is too limited to understand why. Change below led to no negatives in a model that had previously reported negatives:
adjust -ad to 25000 and -lw to 4.00e-07 from 15000 and 6.67e-07

What I don’t understand is why using these parameters with the other “high quality” settings of Honeybee yields negatives:
High Quality: -ab 6 -ad 25000 -as 4096 -c 1 -dc 0.75 -dp 512 -dr 3 -ds 0.05 -dt 0.15 -lr 8 -lw 4e-07 -ss 1.0 -st 0.15
---------------------VS
Medium Quality with suggested changes: -ab 5 -ad 25000 -as 2048 -c 1 -dc 0.5 -dp 256 -dr 1 -ds 0.25 -dt 0.25 -lr 6 -lw 4e-07 -ss 0.7 -st 0.5

[justinfmccarty]

Still testing, but also reading from http://www.jaloxa.eu/resources/radiance/documentation/docs/rtcontrib_lesson.pdf. From page 13:

For rtcontrib to be able to do its magic…it needs to disable the ambient caching… In order to compensate for the disabling of the ambient cache, it is advisable to increase the number of ambient division (-ad) option. Try doubling or quadrupling them. You should also adjust the -lw option to slightly more than the reciprocal of -ad.

I increased the grid resolution to 0.1m x 0.1m from the previous 0.5m x 0.5m and the negative values returned. I also found that setting ambient bounces to 0 leads to all sensor points being in the negative.

If anyone out there has read a good guide/study about setting parameters for large scenes using the 3/5 phase approach please drop it here. Runtimes and memory requirements aren’t necessarily a limit in this case either.

[LittleBuddha]

I’ve had some problems with Radiance parameters as well.

These are not easy to understand, and I’m still wandering in the desert.

This thread has been of some help to me:

Honeybee Radiation Analysis (Radiance-parameters)

Hi again @sarith, here is a model that I am testing. I’m examining 560 points on my facade that is based on a 3x6m grid. [context%20perspective%206] Thank you for the additional information, although I’m using the Honeybee Legacy “Run Daylight Simulation” this one https://rhino.github.io/components/honeybee/runDaylightSimulation.html. And as far as I know it should be based only on rtrace simulation only so I am a bit confused when it is okay to mix these different settings of different func…

[mikkel]

@justinfmccarty

I also found that setting ambient bounces to 0 leads to all sensor points being in the negative.

Though this is about daylight it explains why it happens. The AnnualIrradiance recipe does the same 3 steps. The figure also explains why it can happen when your ambient bounces are > 0, eg., if step 2 is larger than step 1.

Regarding parameters for rfluxmtx/rcontrib based recipes (such as AnnualIrradiance and AnnualDaylight) the most important parameters tend to be -ad and -lw (controlled by -ad).

[charlie.brooker]

Hey @mikkel, @justinfmccarty,

We’ve been looking into a simulation that is reporting negative lux values. Do you think a fair summary of this discussion would be that negative values should be minimised by using appropriate radiance parameters, but where they do occur they can be set to 0?

Image from Sarith’s work: https://www.radiance-online.org/learning/tutorials/matrix-based-methods

If the above returns a negative result I assume it is due to the stochastic nature of a radiance simulation and so can be assumed to be 0 (provided error isn’t due to radiance parameters)

[mikkel]

@charlie.brooker

Do you think a fair summary of this discussion would be that negative values should be minimised by using appropriate radiance parameters, but where they do occur they can be set to 0?

I think so. Of course you should try to crank up the parameters but if that does not help I think it is fair to set the negative values to 0.

[justinfmccarty]

This was my approach. I just checked my simulations for the attached urban scene. Each surface (roof or facade) was simulated with a 20cm sensor point grid. Very minimal negative results (at most 5 per surface). I got to that point by using the following parameters:
“-ab 5 -ad 50000 -as 4096 -c 1 -dc 0.75 -dp 512 -dr 3 -ds 0.05 -dt 0.15 -lr 8 -lw 2e-07 -ss 1.0 -st 0.15”.

The maximum sensor point count for any single scene was 65000. The surface that provided the most issues was the facade of B1391 facing B1390 (mostly East). I think this was due to a general lack of direct sunlight due to the shading from B1390.

However, I have written a backstop into my code just in case. This is how I ensure that my diffuse stream is non negative.

def calculate_diffuse_irradiance(total_irradiance, direct_irradiance):
     if total_irradiance < direct_irradiance:
          return direct_irradiance * 0.01
     else:
          return total_irradiance - direct_irradiance