Skyvector from gensky vs. gendaylit

Hi all,

a probably small and stupid (on my part) issue. I am generating sky patch vectors via genskyvec –m 1 (e.g.). Input is either a sky generated by gensky 6 21 12 (e.g.) or gendaylit <lots of options>.

Now, my problem is that genskyvec produces different output for these sky definition options which is quite a nuisance when trying to postprocess the sky vectors. For gensky, the output is a triplet (r g b) on an individual line per patch, 146 lines in total. For gendaylit, however, the output is a single line!

Of course, I can reorganise the output, somehow. However, I would be interested what I am doing wrong, here.

Thanks for any ideas!

Best
Achim

Hi Achim,

This is impossible to debug without your long list of gendaylit options. The genskyvec script should produce something for any valid sky input, so I suspect something is going wrong on the gendaylit side.

-Greg

···

From: "Achim.geissler" <[email protected]>
Subject: [Radiance-general] Skyvector from gensky vs. gendaylit
Date: May 20, 2016 1:01:30 AM PDT

Hi all,

a probably small and stupid (on my part) issue. I am generating sky patch vectors via genskyvec –m 1 (e.g.). Input is either a sky generated by gensky 6 21 12 (e.g.) or gendaylit <lots of options>.

Now, my problem is that genskyvec produces different output for these sky definition options which is quite a nuisance when trying to postprocess the sky vectors. For gensky, the output is a triplet (r g b) on an individual line per patch, 146 lines in total. For gendaylit, however, the output is a single line!

Of course, I can reorganise the output, somehow. However, I would be interested what I am doing wrong, here.

Thanks for any ideas!

Best
Achim

Hi Greg,

in the mean time, I have been experimenting quite a bit and the problem seems to have been that my approaches weren’t actually really identical (the stupid part). This is what I did:

···

===
Setting up:

# Assemble gendaylit command line components
month='6'
day='21'
time="12"
datetime="$month $day $time"
lat='47.5'
lon='-7.6' # west +, east -
meridian='-1' # "hours diff from UTC", west +, east -
diffhor='334'
dirnorm='541'
mer=$(echo $meridian |rcalc -e '$1=$1*15')
radiation="$dirnorm $diffhor"

# Build command lines ...
# ... for gendaylit / -O 1 is solar spectrum, -O 0 is visual spectrum
gdlcmd="$datetime -a $lat -o $lon -m $mer -W $radiation -O 1"

# ... for gensky
gskcmd="$datetime -a $lat -o $lon -m $mer -B $diffhor"

# and for genskyvec
#gsvcmd=" "
gsvcmd="-c 1 1 1"

===
Now use:

# Generate sky description with gendaylit and generate sky views
skyvec=$(gendaylit $gdlcmd | genskyvec $gsvcmd -m 1)
echo $skyvec > gendaylit_vec.skv

# Now generate sky with gensky and repeat view generation
gensky $gskcmd | genskyvec $gsvcmd -m 1 > gensky_vec.skv

===
… that was were I wrote below initial post. Now, if I either do

gendaylit $gdlcmd | genskyvec $gsvcmd -m 1 > gendaylit_vec.skv

directly or “indirectly” write the gensky-based output via “skyvec=$(…” both approaches behave the same, after all. However, with the “indirect” procedure, I end up with a single line. Luckily, I have found a way to re-order the data via sed (long live the net!).

Is there a logical explanation, why the “EOLs” get lost for the “indirect” procedure?

Thanks.
Best
Achim

On 20 May 2016, at 17:39, Greg Ward <[email protected]> wrote:

Hi Achim,

This is impossible to debug without your long list of gendaylit options. The genskyvec script should produce something for any valid sky input, so I suspect something is going wrong on the gendaylit side.

-Greg

From: "Achim.geissler" <[email protected]>
Subject: [Radiance-general] Skyvector from gensky vs. gendaylit
Date: May 20, 2016 1:01:30 AM PDT

Hi all,

a probably small and stupid (on my part) issue. I am generating sky patch vectors via genskyvec –m 1 (e.g.). Input is either a sky generated by gensky 6 21 12 (e.g.) or gendaylit <lots of options>.

Now, my problem is that genskyvec produces different output for these sky definition options which is quite a nuisance when trying to postprocess the sky vectors. For gensky, the output is a triplet (r g b) on an individual line per patch, 146 lines in total. For gendaylit, however, the output is a single line!

Of course, I can reorganise the output, somehow. However, I would be interested what I am doing wrong, here.

Thanks for any ideas!

Best
Achim

[email protected]

Hi Achim,

The "indirect" call is effectively an inlining method, and the EOL's get converted to spaces in case you are passing the output to another command. The subsequent programs don't really care, except that the header needs to have its lines preserved ahead of the data, so it knows how to interpret the latter.

-Greg

···

From: Achim Geissler <[email protected]>
Date: May 20, 2016 10:27:43 AM PDT

Hi Greg,

in the mean time, I have been experimenting quite a bit and the problem seems to have been that my approaches weren’t actually really identical (the stupid part). This is what I did:

===
Setting up:

# Assemble gendaylit command line components
month='6'
day='21'
time="12"
datetime="$month $day $time"
lat='47.5'
lon='-7.6' # west +, east -
meridian='-1' # "hours diff from UTC", west +, east -
diffhor='334'
dirnorm='541'
mer=$(echo $meridian |rcalc -e '$1=$1*15')
radiation="$dirnorm $diffhor"

# Build command lines ...
# ... for gendaylit / -O 1 is solar spectrum, -O 0 is visual spectrum
gdlcmd="$datetime -a $lat -o $lon -m $mer -W $radiation -O 1"

# ... for gensky
gskcmd="$datetime -a $lat -o $lon -m $mer -B $diffhor"

# and for genskyvec
#gsvcmd=" "
gsvcmd="-c 1 1 1"

===
Now use:

# Generate sky description with gendaylit and generate sky views
skyvec=$(gendaylit $gdlcmd | genskyvec $gsvcmd -m 1)
echo $skyvec > gendaylit_vec.skv

# Now generate sky with gensky and repeat view generation
gensky $gskcmd | genskyvec $gsvcmd -m 1 > gensky_vec.skv

===
… that was were I wrote below initial post. Now, if I either do

gendaylit $gdlcmd | genskyvec $gsvcmd -m 1 > gendaylit_vec.skv

directly or “indirectly” write the gensky-based output via “skyvec=$(…” both approaches behave the same, after all. However, with the “indirect” procedure, I end up with a single line. Luckily, I have found a way to re-order the data via sed (long live the net!).

Is there a logical explanation, why the “EOLs” get lost for the “indirect” procedure?

Thanks.
Best
Achim

On 20 May 2016, at 17:39, Greg Ward <[email protected]> wrote:

Hi Achim,

This is impossible to debug without your long list of gendaylit options. The genskyvec script should produce something for any valid sky input, so I suspect something is going wrong on the gendaylit side.

-Greg

From: "Achim.geissler" <[email protected]>
Subject: [Radiance-general] Skyvector from gensky vs. gendaylit
Date: May 20, 2016 1:01:30 AM PDT

Hi all,

a probably small and stupid (on my part) issue. I am generating sky patch vectors via genskyvec –m 1 (e.g.). Input is either a sky generated by gensky 6 21 12 (e.g.) or gendaylit <lots of options>.

Now, my problem is that genskyvec produces different output for these sky definition options which is quite a nuisance when trying to postprocess the sky vectors. For gensky, the output is a triplet (r g b) on an individual line per patch, 146 lines in total. For gendaylit, however, the output is a single line!

Of course, I can reorganise the output, somehow. However, I would be interested what I am doing wrong, here.

Thanks for any ideas!

Best
Achim

Hi Greg,

thanks for the clarification. The issue arose due to my trying to use a perl script from Wouter (found it in the archive from last December) and this script required the vector data to come in the “triplet lines” format.

while ( <$fh> ) {
  my @a = split /\s+/;
  push @sky_patches, ($a[0]*0.265+$a[1]*0.67+$a[2]*0.065);
}

By and by, I got the script up and running (thanks, Wouter).

Best
Achim

···

On 20 May 2016, at 20:18, Gregory J. Ward <[email protected]> wrote:

Hi Achim,

The "indirect" call is effectively an inlining method, and the EOL's get converted to spaces in case you are passing the output to another command. The subsequent programs don't really care, except that the header needs to have its lines preserved ahead of the data, so it knows how to interpret the latter.

-Greg

From: Achim Geissler <[email protected] <mailto:[email protected]>>
Date: May 20, 2016 10:27:43 AM PDT

Hi Greg,

in the mean time, I have been experimenting quite a bit and the problem seems to have been that my approaches weren’t actually really identical (the stupid part). This is what I did:

===
Setting up:

# Assemble gendaylit command line components
month='6'
day='21'
time="12"
datetime="$month $day $time"
lat='47.5'
lon='-7.6' # west +, east -
meridian='-1' # "hours diff from UTC", west +, east -
diffhor='334'
dirnorm='541'
mer=$(echo $meridian |rcalc -e '$1=$1*15')
radiation="$dirnorm $diffhor"

# Build command lines ...
# ... for gendaylit / -O 1 is solar spectrum, -O 0 is visual spectrum
gdlcmd="$datetime -a $lat -o $lon -m $mer -W $radiation -O 1"

# ... for gensky
gskcmd="$datetime -a $lat -o $lon -m $mer -B $diffhor"

# and for genskyvec
#gsvcmd=" "
gsvcmd="-c 1 1 1"

===
Now use:

# Generate sky description with gendaylit and generate sky views
skyvec=$(gendaylit $gdlcmd | genskyvec $gsvcmd -m 1)
echo $skyvec > gendaylit_vec.skv

# Now generate sky with gensky and repeat view generation
gensky $gskcmd | genskyvec $gsvcmd -m 1 > gensky_vec.skv

===
… that was were I wrote below initial post. Now, if I either do

gendaylit $gdlcmd | genskyvec $gsvcmd -m 1 > gendaylit_vec.skv

directly or “indirectly” write the gensky-based output via “skyvec=$(…” both approaches behave the same, after all. However, with the “indirect” procedure, I end up with a single line. Luckily, I have found a way to re-order the data via sed (long live the net!).

Is there a logical explanation, why the “EOLs” get lost for the “indirect” procedure?

Thanks.
Best
Achim

On 20 May 2016, at 17:39, Greg Ward <[email protected] <mailto:[email protected]>> wrote:

Hi Achim,

This is impossible to debug without your long list of gendaylit options. The genskyvec script should produce something for any valid sky input, so I suspect something is going wrong on the gendaylit side.

-Greg

From: "Achim.geissler" <[email protected] <mailto:[email protected]>>
Subject: [Radiance-general] Skyvector from gensky vs. gendaylit
Date: May 20, 2016 1:01:30 AM PDT

Hi all,

a probably small and stupid (on my part) issue. I am generating sky patch vectors via genskyvec –m 1 (e.g.). Input is either a sky generated by gensky 6 21 12 (e.g.) or gendaylit <lots of options>.

Now, my problem is that genskyvec produces different output for these sky definition options which is quite a nuisance when trying to postprocess the sky vectors. For gensky, the output is a triplet (r g b) on an individual line per patch, 146 lines in total. For gendaylit, however, the output is a single line!

Of course, I can reorganise the output, somehow. However, I would be interested what I am doing wrong, here.

Thanks for any ideas!

Best
Achim

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

[email protected]