[Radiance-general] Skyvector from gensky vs. gendaylit

[Gregory J. Ward]

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 <achim.geissler at intergga.ch>
> 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 <gregoryjward at gmail.com> 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" <achim.geissler at intergga.ch>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20160520/57700742/attachment-0001.html>