Gendaymtx -5 for deterministic PV assessments

radiance-general
1

Hi all,

I’m trying to do a deterministic PV assessment with no inter-reflected light. My idea is to create solar sources whose intensity is equivalent to the direct sun AND the diffuse sky intensity. I don’t need to know the relative contributions from the sun and sky, only the total.

This would be similar to the 5-Phase method, except that there won’t be any sky patches at all.

The undocumented gensky -5 diam option works for the sun component, but does not account for the solid angle of the sky patch, since it was never meant to be used for this kind of exercise.

I suppose I could write some python script that converts the diffuse patch intensity of the sky matrix into an equivalent ‘diffuse solar source’ intensity by adjusting for the difference in solid angle between the sky patch and the solar disk.

Is there a better way of achieving this with some clever combination of Radiance tools?

Thank you for your help

-Axel

2

Hi Axel,

Nice to see a question coming from you for once – usually you are the one answering people!

Unfortunately, I can only respond with more questions. What form do you want the sky contribution in, exactly? Are you looking for a 180° source with a distribution like you would get from gensky, or do you just want an average, uniform value over the hemisphere? Or, do you not want a hemisphere glow at all, rather something concentrated?

Related to the previous two questions, how do you plan to account for the cosine factor on the incident radiation?

Cheers,
-Greg

3

Hello Greg,

since my PV assessment needs to provide per-month (and eventually also per-hour) sensor irradiance data, I would like to use a straight-forward rfluxmtx/dctimestep approach, but without sky – only ‘solar disks’. I’ll probably go with a Reinhart of 4, i.e. 2305 suns.

With the very simply 2-Phase method, we smudge out the sun’s intensity across the 3 or 4 nearest sky patches.

I’m trying instead to do the reverse, and assign the intensity of a sky patch to the sun at the same location. No smudging, since the sun is at the centre of the sky patch already.

In other words: The Tregenza/Reinhart sky dome is represented by discreet suns, so I get exactly the same result every time I run the same assessment.

gendaymtx -5 dim will give me the solar contribution. I guess technically speaking, the full invocation would be gendaymtx -5 dim -d, but it seems the -d isn’t actually required.

If I could run gendaymtx -5 dim -s, and the output would be adjusted to the much smaller solid angle the sun at this spot vs the solid angle of the sky patch, this would work nicely. However, running it this way does not account for the solid angle of the sky patch. So the -d works, but the -s doesn’t. Well, not for this particular niche-application.

I am therefore running a normal gendaymtx (without the -5 dim option), and now need to adjust the sky matrix, which is meant to represent patches, so that it accounts for the much smaller solid angle of the solar disc.

To reply to your second question: The cosine factor and everything else would be taken care of by rfluxmtx -I+. It really is an almost-normal 2-Phase method, just without the sky dome.

Is this making any sense?

Many thanks

-Axel

4

OK, I admit to struggling a bit to understand. Sounds like you are trying to avoid the randomness of rfluxmtx with a standard Reinhart subdivision, but if you reuse the calculated matrix, why would you see any variance? Or are you rerunning rfluxmtx for different configurations, and trying to avoid any sampling noise? Because it seems to me like the standard 2-phase DC method would work fine with the tools as they are.

That said, I’m thinking you could get where you want to go using light primitives whose RGB values are the Reinhart patch solid angle over the solar solid angle. So, using the conveniently supplied “reinsrc.cal” file, your suns would be generated by:

cnt 2305 | rcalc -e "MF:4;ss:0.5" -f reinsrc.cal -e "Rbin=recno;ss:0.5;ssa:PI*(ss*DEGREE/2)^2;sr=Romega/ssa" -o solar.fmt > mysuns4.rad

where the file “solar.fmt” contains:

void light solar${recno} 0 0 3 ${sr} ${sr} ${sr}
solar${recno} source sun${recno} 0 0 4 ${Dx} ${Dy} ${Dz} ${ss}

Then, when you run rfluxmtx -I+, add the -V+ option so the ratios you’ve computed are applied to the contribution coefficients. You can create a list of modifiers to use with rfluxmtx -M with this:

cnt 2305 | rcalc -o 'solar${recno}' > solarmods.txt

Is this what you are after, or am I still confused?

Best,
-Greg

P.S. I have used 0.5° for the solar disk size, but you can obviously adjust this by changing the “ss” constant if desired.

5

Hi Greg,

Yes, this is exactly the reason. We don’t keep the DC matrix around, but need exactly the same results on a re-run, when the DC matrix is calculated again. Hence my insistance on using discreet suns (even for the sky contribution), as opposed to sky patches.

I think I need to break this down a bit:

a) Am I right in saying that gendaymtx -5 does two things:
– Disable ‘smudging’, so for each timestep we have exactly one discreet sun? I guess this is mostly for visualisation purposes.
– adjust brightness for the much smaller solid angle of the sun vs sky patch

$ gendaymtx -d -m 4 GBR_Gatwick-0321-1130.wea |getinfo - |grep -v '0 0 0'
1.99e+03 1.99e+03 1.99e+03
2.53e+03 2.53e+03 2.53e+03
2.61e+03 2.61e+03 2.61e+03
3.51e+03 3.51e+03 3.51e+03
$ gendaymtx -5 0.533 -d -m 4 GBR_Gatwick-0321-1130.wea |getinfo - |grep -v '0 0 0'
4.44e+05 4.44e+05 4.44e+05

b) gendaymtx -5 is only meant to work for the direct solar component. This seems to be where I’m trying to get it to do something it wasn’t meant to do.

Here is a very simply one-timestep wea file:

$ cat GBR_Gatwick-0321-1130.wea
place LONDON/GATWICK_GBR
latitude 51.15
longitude 0.18
time_zone -0
site_elevation 62.0
weather_data_file_units 1
3 23 11.500 57 287

Now I run all combinations of [‘exclude nothing’, ‘exclude sky’, ‘exclude sun’] and [‘not 5-phase’ and ‘5-phase’]. I would, of course, need the -O1 as well for PV assessments:

wea=GBR_Gatwick-0321-1130.wea
$ for five in '' '-5 0.533'; do for excl in '' '-d' '-s'; do echo -n "excl: '$excl'; five: '$five' -> "; gendaymtx $five -m 1 -g 0 0 0 -c 1 1 1 $excl $wea |sed -n '105p' |cut -d' ' -f1; done; done
excl: ''; five: '' -> 657
excl: '-d'; five: '' -> 425
excl: '-s'; five: '' -> 232
excl: ''; five: '-5 0.533' -> 4.44e+05
excl: '-d'; five: '-5 0.533' -> 4.44e+05
excl: '-s'; five: '-5 0.533' -> 232

The not-5-Phase results (sky patches) look convincing: direct and diffuse add up to global.

The 5-Phase results are odd. Both ‘exclude nothing’ and ‘exclude sky -s’ don’t account for the solid angle of my deterministic suns. Because this is not what the -5 option was ever meant to do.

Therefore, I seem to be better off with a straight-forward genskymtx (sun and sky component; no 5-phase), and account for the much smaller solid angles of my discreet suns some other way. Also because I like the ‘smudging’ for this kind of cumulative PV assessment.

Is this what you suggest with the on-liner that creates mysuns4.rad? It adjusts the brightness of the solar discs according to the solid angle of the sky patch, which is base on the altitude of the ‘band’.

Here is one of your suns:

void light solar2 0 0 3 48.2247 48.2247 48.2247
solar2 source sun2 0 0 4 0.0523161 0.99825 0.0275543 0.5

Following both Andy’s and Sarith’s tutorials, this would be:

void light solar 0 0 3 1e6 1e6 1e6
solar source sun 0 0 4 0.0523161 0.99825 0.0275543 0.533

Andy’s suns all have a high brightness of 1e6, and they all use the same material ‘solar’.
Your suns all have their own modifiers, but a low brightness (accounting for the solid angle of the sky patch).

Would I be using your mysuns4.rad file with a non-5-phase gendaymtx?

Sorry it’s taking me so long to get there. Many thanks for your help

-Axel

6

Hi Axel,

Your assumptions in (a) are correct regarding the -5 option and what it does. I guess it is usually applied together with the gendaymtx -d option to set non-solar sky patches to 0, correct? I could modify the gensky behavior instead to apply the same solar-disk-vs-sky-patch-solid-angle correction to every patch, then without the -d option it should produce the sky values you need for your 2305 suns.

However, the one-liner I supplied should also work if you apply the rfluxmtx/rcontrib -V+ option as suggested. Normally, the actual color value of the suns is ignored with the default -V- option, producing only coefficients. The reply above is a method to get the factors you need back into the calculation.

The gendaymtx -5 option was always a hack, so hacking it up a bit more to suit your purpose wouldn’t bend my nose too much. On the other hand, having these undocumented behaviors accumulating in the code does nothing for posterity, if you catch my meaning. We were lucky that Andy and Sarith took such time and care in explaining what to do and why. Your contributions to Radiance documentation and how-to’s has likewise been invaluable over the years. From that perspective, which solution would you prefer?

Cheers,
-Greg

7

Hi Greg,

this is clear now. No need to hack gendaymtx even more. The one-liner will do nicely. Much appreciated. Thank you so much for all your help

-Axel