Strange gendaylit behavior

I probably have an odd configuration on my machine, but I'm having trouble
diagnosing this problem.

If I call gendaylit with these parameters, I get junk in the output sky
description:

rgugliel$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m
-105.0 -L 0.0 1926.55187439894
# Ground ambient level: nan

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 nan nan nan nan nan nan nan -0.907109 0.416674 0.059465

OK, so where is my gendaylit?

which gendaylit
/usr/local/bin/gendaylit

OK, so if I call that specific executable, I get this:

rgugliel$ /usr/local/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# /usr/local/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
sky clearness or sky brightness out of range 1.000000
74434650220083800562091791272162503847257343566676277805826026351882917179884747180439543170910077023728890544527980267722524523537281630301534426272391252609311406925055899551665934885241866457242010167443382973430564036426324486211258871034413056.000000

which is much more useful, because those STERR warnings I can check for and
use an alternative sky generation method for that timestep, or double check
input parameters. The former method slips past my gendaylit STERR checks and
then oconv barfs on that bogus sky description.

I don't THINK I have any other copies of gendaylit lying around, certainly
not in my path, but it appears that either gendaylit behaves differently
when called with a full path (unlikely) or I have something else going on. I
have lost many hairs today grinding on this. This is stupid. Please help.

- Rob

Hi Rob,
by using your command I am getting error to, but slightly different.

David$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001
-m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m
-105.0 -L 0.0 1926.55187439894
Illegal instruction: 4

Is there any reason by using 0.0 as direct normal illuminance after -l
option. By using 0.00000000001 daylight works. I am not sure if this is what
you are looking for.

I am also getting same error "Illegal instruction: 4" when calling gendaylit
by full path.

# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m
-105.0 -L 0.00000000000001 1926.55187439894
# Ground ambient level: 4.7

void light solar
0
0
3 8.220e-13 8.220e-13 8.220e-13

solar source sun
0
0
4 -0.907109 0.416674 0.059465 0.533000

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 1.164e+01 9.485e-01 -0.836705 -0.013368 15.728716 -4.116213 1.003109
-0.907109 0.416674 0.059465

David

···

On 7 October 2011 15:42, Rob Guglielmetti <[email protected]>wrote:

I probably have an odd configuration on my machine, but I'm having trouble
diagnosing this problem.

If I call gendaylit with these parameters, I get junk in the output sky
description:

rgugliel$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m
-105.0 -L 0.0 1926.55187439894
# Ground ambient level: nan

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 nan nan nan nan nan nan nan -0.907109 0.416674 0.059465

OK, so where is my gendaylit?

which gendaylit
/usr/local/bin/gendaylit

OK, so if I call that specific executable, I get this:

rgugliel$ /usr/local/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# /usr/local/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
sky clearness or sky brightness out of range 1.000000
74434650220083800562091791272162503847257343566676277805826026351882917179884747180439543170910077023728890544527980267722524523537281630301534426272391252609311406925055899551665934885241866457242010167443382973430564036426324486211258871034413056.000000

which is much more useful, because those STERR warnings I can check for and
use an alternative sky generation method for that timestep, or double check
input parameters. The former method slips past my gendaylit STERR checks and
then oconv barfs on that bogus sky description.

I don't THINK I have any other copies of gendaylit lying around, certainly
not in my path, but it appears that either gendaylit behaves differently
when called with a full path (unlikely) or I have something else going on. I
have lost many hairs today grinding on this. This is stupid. Please help.

- Rob

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi David,

The direct normal has been zero for several other timesteps with no error, though. I did temporarily change the code to where if direct or global was zero, I reset it to one, but I'd like to pass in the actual values, if possible, ya know? Maybe I'll try (if 0.0 then 0.0000000001) like you tried, and see how the results come out. What platform are you on? I'm not seeing the "Illegal instruction: 4" error ever...

- Rob

···

On Oct 7, 2011, at 5:13 PM, David Appelfeld wrote:

Hi Rob,
by using your command I am getting error to, but slightly different.

David$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
Illegal instruction: 4

Is there any reason by using 0.0 as direct normal illuminance after -l option. By using 0.00000000001 daylight works. I am not sure if this is what you are looking for.

I am also getting same error "Illegal instruction: 4" when calling gendaylit by full path.

# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.00000000000001 1926.55187439894
# Ground ambient level: 4.7

void light solar
0
0
3 8.220e-13 8.220e-13 8.220e-13

solar source sun
0
0
4 -0.907109 0.416674 0.059465 0.533000

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 1.164e+01 9.485e-01 -0.836705 -0.013368 15.728716 -4.116213 1.003109 -0.907109 0.416674 0.059465

David

On 7 October 2011 15:42, Rob Guglielmetti <[email protected]> wrote:
I probably have an odd configuration on my machine, but I'm having trouble diagnosing this problem.

If I call gendaylit with these parameters, I get junk in the output sky description:

rgugliel$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# Ground ambient level: nan

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 nan nan nan nan nan nan nan -0.907109 0.416674 0.059465

OK, so where is my gendaylit?

which gendaylit
/usr/local/bin/gendaylit

OK, so if I call that specific executable, I get this:

rgugliel$ /usr/local/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# /usr/local/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
Warning : skyclearness or skybrightness out of range ;
Check your input parameters
sky clearness or sky brightness out of range 1.000000 74434650220083800562091791272162503847257343566676277805826026351882917179884747180439543170910077023728890544527980267722524523537281630301534426272391252609311406925055899551665934885241866457242010167443382973430564036426324486211258871034413056.000000

which is much more useful, because those STERR warnings I can check for and use an alternative sky generation method for that timestep, or double check input parameters. The former method slips past my gendaylit STERR checks and then oconv barfs on that bogus sky description.

I don't THINK I have any other copies of gendaylit lying around, certainly not in my path, but it appears that either gendaylit behaves differently when called with a full path (unlikely) or I have something else going on. I have lost many hairs today grinding on this. This is stupid. Please help.

- Rob

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi Rob:

I run it in Ubuntu. Please see bellow. It seems no errors. The error you
got says the sky_brightness is out of range, the upper range of
skybrightness is 0.6. I did check the code but can not figure out why you
have such errors. The skybrightness is calculated by:

diffusirradiance * air_mass() / solar_constant_e*get_eccentricity().

···

********************
double get_eccentricity()
{
double day_angle;
double E0;

day_angle = 2*M_PI*(daynumber - 1)/365;
E0 = 1.00011+0.034221*cos(day_angle)+0.00128*sin(day_angle)+
    0.000719*cos(2*day_angle)+0.000077*sin(2*day_angle);

return (E0);

}

jiahu@jiahu:~$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m
-105.0 -L 0.0 1926.55187439894
# Ground ambient level: 2.8

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 2.091e+00 5.556e-01 0.524236 -0.570392 0.832619 -0.637964 0.014613
-0.907109 0.416674 0.059465

===================================
# /usr/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o
-105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# Ground ambient level: 2.8

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 2.091e+00 5.556e-01 0.524236 -0.570392 0.832619 -0.637964 0.014613
-0.907109 0.416674 0.059465

=================================

Getting the error is a good thing, my problem is that depending on how I call gendaylit, I either get or I don't and it prints garbage. Gendaylit is a little fragile when the sun's near the horizon anyway; Axel Jacobs pointed this out in his "learning rtcontrib" tutorial as well.

Andy McNeil has a good idea that he illustrated in one of his talks at the Radiance Workshop, he looks for gendaylit errors and if thrown, he uses gensky instead. I'm trying to implement something similar here, but as I said the gendaylit STDERR is behaving unreliably, it seems. Maybe it's best to test for zero values in the weather input data and just default to gensky for those timesteps, or something.

I dunno, I have a headache. Happy weekend y'all.

- Rob

···

On Oct 7, 2011, at 7:00 PM, Jia Hu wrote:

Hi Rob:

I run it in Ubuntu. Please see bellow. It seems no errors. The error you got says the sky_brightness is out of range, the upper range of skybrightness is 0.6. I did check the code but can not figure out why you have such errors. The skybrightness is calculated by:

diffusirradiance * air_mass() / solar_constant_e*get_eccentricity().

********************
double get_eccentricity()
{
  double day_angle;
  double E0;

  day_angle = 2*M_PI*(daynumber - 1)/365;
  E0 = 1.00011+0.034221*cos(day_angle)+0.00128*sin(day_angle)+
      0.000719*cos(2*day_angle)+0.000077*sin(2*day_angle);

  return (E0);

}

jiahu@jiahu:~$ gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# Ground ambient level: 2.8

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 2.091e+00 5.556e-01 0.524236 -0.570392 0.832619 -0.637964 0.014613 -0.907109 0.416674 0.059465

===================================
# /usr/bin/gendaylit 7 19 19:00:00 -a 39.740000000000002 -o -105.18000000000001 -m -105.0 -L 0.0 1926.55187439894
# Ground ambient level: 2.8

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 2.091e+00 5.556e-01 0.524236 -0.570392 0.832619 -0.637964 0.014613 -0.907109 0.416674 0.059465

=================================

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi Rob,

I can replicate your error using the -L 0.0 parameter. However, as you increase the number of zeroes out to -L 0.000000000000 the results change to issue the warnings reported by David.

file ~/Documents/ray/bin/gendaylit reports on my Mac box:

    gendaylit: Mach-O 64-bit executable x86_64

Looking at the source version of gendaylit I have, it uses atof to convert a string to double. I would expect this to be where the odd behaviour is coming from with the precision of the -L parameter.

*Terrance Mc Minn
**Lecturer, Department of Architecture
Built Environment

···

*
*Curtin**University*
*Email |*[email protected] <[email protected]>

Hi Terrance,

Thanks for looking at this as well. Always nice to draw you out on to this list! =)

I was fixing to just look at the source myself, as I assumed the answer lied in there. I will revise my script to address this. Thanks all!

- Rob

···

On Oct 8, 2011, at 1:55 AM, Terrance Mc Minn wrote:

Hi Rob,

I can replicate your error using the -L 0.0 parameter. However, as you increase the number of zeroes out to -L 0.000000000000 the results change to issue the warnings reported by David.

file ~/Documents/ray/bin/gendaylit reports on my Mac box:
gendaylit: Mach-O 64-bit executable x86_64
Looking at the source version of gendaylit I have, it uses atof to convert a string to double. I would expect this to be where the odd behaviour is coming from with the precision of the -L parameter.

Terrance Mc Minn
Lecturer, Department of Architecture
Built Environment

Curtin University
Email | [email protected]
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Don't mess with The Source, Rob!

I get segfaults for both gendaylit and /usr/local/bin/gendaylit but I'm
chronically behind a couple of versions these days.

I looked at one source file I have around here (v2.3 dated 2009/06/20) but
didn't find anything that would explain a different behaviour depending on
the script name. However, I found that

if (skybrightness<0.05) skybrightness=0.01;

a few times. So you probably can save a few 0s in your input if that helps
you to produce the error message reliably.

Regards,
Thomas

···

On Sat, Oct 8, 2011 at 9:25 AM, Rob Guglielmetti <[email protected] > wrote:

I was fixing to just look at the source myself, as I assumed the answer
lied in there. I will revise my script to address this. Thanks all!

Hi Thomas,

THanks for your input as well! I have good news; in classic Radiance Community fashion, some cool shit has happened.

Greg told Ian Ashdown about my plight, Ian emailed me directly to tell me he completely re-wrote gendaylit and validated it a couple years ago for one of his clients, and just today decided to open source it! I will try and test it out this weekend, and Ian will get a link to it soon on his website (www.helios32.com).

Another fine example of the greatness of the people in this community, a fine bunch indeed.

- Rob

···

On Oct 8, 2011, at 8:39 AM, Thomas Bleicher wrote:

On Sat, Oct 8, 2011 at 9:25 AM, Rob Guglielmetti <[email protected]> wrote:
I was fixing to just look at the source myself, as I assumed the answer lied in there. I will revise my script to address this. Thanks all!

Don't mess with The Source, Rob!

I get segfaults for both gendaylit and /usr/local/bin/gendaylit but I'm chronically behind a couple of versions these days.

I looked at one source file I have around here (v2.3 dated 2009/06/20) but didn't find anything that would explain a different behaviour depending on the script name. However, I found that

if (skybrightness<0.05) skybrightness=0.01;

a few times. So you probably can save a few 0s in your input if that helps you to produce the error message reliably.

Regards,
Thomas
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

As promised, the following link has, uh, links to Ian Ashdown's updated gendaylit source code and the validation paper:

http://www.helios32.com/news.htm

- Rob G.