glazing modelling

Hi,
I have few questions about accurate modeling of different glazing. I've read all previous discussions on this list, and now I'll try to summarize my thoughts about this subject.
Suppose we want to simulate the behavior of some single or multiple layer glazing in Radiance, and the data of available glazings can be found in Optics5 database (actually IGDB).
These are few possible procedures how to define and use this material:

PROCEDURE1
1. convert glazing (all layers) data from Optics5 to Radiance.
2. use output glass material for glazing definition.

Problem:
*Glass reflectance is calculated implicitly, and values from Optic5 database don't have any effect.
This can be solved by using trans.cal functional file, and changing index of refraction to obtain appropriate reflectance.
*Dependence between light incident angle and transmittance/reflectance is implicit and it is calculated using the algorithm for common glass material.

PROCEDURE 2:
1. convert glazing (all layers) data from Optics5 to Radiance.
2. adjust BRTDfunc data, like Jack de Valpine suggested:
void BRTDfunc GlzSys_front_and_back
10
    if(Rdot, <r_front_refl>, <r_back_ref>l) if(Rdot, <g_front_refl>, <g_back_refl>) if(Rdot, <b_front_refl>, <b_back_refl>)
    <r_trans> <g_trans> <b_trans>
    0 0 0
    .
0
9 0 0 0 0 0 0 0 0 0
3.Use this BRTD definition for glazing.

Problem:
*No transmittance/reflectance dependence of incident angle is taken into account!

PROCEDURE 3:
1.convert glazing (all layers) data from Optics5 to Radiance.
2.Use BRTD definition and glazing.cal file to define angular dependence of transmittance/reflectance values. Definition would look like:
mod BRTDfunc my_glazing
10 rrho grho brho
        rtau gtau btau
        0 0 0
        glazing.cal
0
18 0 0 0
        0 0 0
        FRRHO FGRHO FBRHO
        BRRHO BGRHO BBRHO
        RTAU GTAU BTAU
where:
    FRRHO FGRHO FBRHO is front normal spectral reflectance
    BRRHO BGRHO BBRHO is back normal spectral reflectance
    RTAU GTAU BTAU is normal spectral transmittance

3.Use this definition for glazing material.

Problem:
*glazing.cal calculate these functions ONLY for coated and clear glass with the cut- off point transmittance=0.654. Below that value it is supposed that glass is coated, and above that it is clear.

PROCEDURE 4:
1.convert each layer of glazing from Optics5 to Radiance.
2.Create input file for glaze.csh script (see question below)
3.Call glaze.csh script and define 1 or 2 panel glazing, and all its surfaces.
4.Use BRDTfunc created as output of the script, as glazing material.

Problem/question:
*Is it important what kind of glazing user defines? I know the main goal of this script is to define fritted glass, but is the calculation OK for user defined types of surface.

QUESTIONS:
1.Which of this procedures should be used in which real case? I suppose for single pane clear glass we could use only glass primitive. Can glazing.cal be used for all coated glazings, and glaze.csh for fritted ones?
2.What is the format of input file for glaze.csh script?
3.What if glazing have more than 2 layers?

Thanks,
Marija.

Hi Marija,

This is a good summary here with a lot of questions. I am not sure that I can answer all of the questions, I will try to address a few items though

Marija Cvetkovic wrote:

Hi,
I have few questions about accurate modeling of different glazing. I've read all previous discussions on this list, and now I'll try to summarize my thoughts about this subject.
Suppose we want to simulate the behavior of some single or multiple layer glazing in Radiance, and the data of available glazings can be found in Optics5 database (actually IGDB).
These are few possible procedures how to define and use this material:

PROCEDURE1
1. convert glazing (all layers) data from Optics5 to Radiance.
2. use output glass material for glazing definition.

Problem:
*Glass reflectance is calculated implicitly, and values from Optic5 database don't have any effect.
This can be solved by using trans.cal functional file, and changing index of refraction to obtain appropriate reflectance.
*Dependence between light incident angle and transmittance/reflectance is implicit and it is calculated using the algorithm for common glass material.

As I read "trans.cal" this is for converting from transmittance to transmissivity, the latter value is used for the radiance "glass" material type. I believe that the "glass" material that is output from Optics accounts for this translation. I think that maybe Chas Erhlich could confirm this?

Note though, quoting Greg from the file, that trans.cal is for an "infinite series solution for an uncoated pane of glass." This is a solution for a single pane only. I am not sure that adjusting the index of refraction is a valid way to "adjust" the reflectance and it still would result on the same reflectance on both sides of the material. Most glass systems that use coated glass have different reflectances on the outside and inside.

PROCEDURE 2:
1. convert glazing (all layers) data from Optics5 to Radiance.
2. adjust BRTDfunc data, like Jack de Valpine suggested:
void BRTDfunc GlzSys_front_and_back
10
   if(Rdot, <r_front_refl>, <r_back_ref>l) if(Rdot, <g_front_refl>, <g_back_refl>) if(Rdot, <b_front_refl>, <b_back_refl>)
   <r_trans> <g_trans> <b_trans>
   0 0 0
   .
0
9 0 0 0 0 0 0 0 0 0
3.Use this BRTD definition for glazing.

Problem:
*No transmittance/reflectance dependence of incident angle is taken into account!

This is just a hack to combine the two separate BRTDfunc definitions output from Optics into one definition. You correctly note the problem with this hack.

PROCEDURE 3:
1.convert glazing (all layers) data from Optics5 to Radiance.
2.Use BRTD definition and glazing.cal file to define angular dependence of transmittance/reflectance values. Definition would look like:
mod BRTDfunc my_glazing
10 rrho grho brho
       rtau gtau btau
       0 0 0
       glazing.cal
0
18 0 0 0
       0 0 0
       FRRHO FGRHO FBRHO
       BRRHO BGRHO BBRHO
       RTAU GTAU BTAU
where:
   FRRHO FGRHO FBRHO is front normal spectral reflectance
   BRRHO BGRHO BBRHO is back normal spectral reflectance
   RTAU GTAU BTAU is normal spectral transmittance

3.Use this definition for glazing material.

Problem:
*glazing.cal calculate these functions ONLY for coated and clear glass with the cut- off point transmittance=0.654. Below that value it is supposed that glass is coated, and above that it is clear.

I think that another important issue with this is that it is really accounts for only one type of coating and I do not think that it accounts for multi-pane assemblies.

PROCEDURE 4:
1.convert each layer of glazing from Optics5 to Radiance.
2.Create input file for glaze.csh script (see question below)
3.Call glaze.csh script and define 1 or 2 panel glazing, and all its surfaces.
4.Use BRDTfunc created as output of the script, as glazing material.

Problem/question:
*Is it important what kind of glazing user defines? I know the main goal of this script is to define fritted glass, but is the calculation OK for user defined types of surface.

Actually, I think that at the time we were interested both in coated and frit glass, multi-pane assemblies, so I would not say the main goal of the script if frit glass only. However I am not sure what you mean by your question: "is it important what kind of glazing user defines?" Yes, you need to correctly assemble a glazing system in Optics, and export each individual layer (up to two panes). I think that one can obtain 100% coverage reflectances/transmittance for frit glass if you talk with the manufacturer. The other thing that is important is the orientation of the geometry that the material is applied to, the normal needs to point into the space. Note also that while the material may represent a multisurface piece of real world geometry, the representation in Radiance is a single surface piece of geometry.

If you are going to use this script I highly recommend that you export your own data and use the -f option of the script so you can use a data file that defines your own coated glass and frit glass (if needed) options.

For frit glazing systems, one problem with this script is that it cannot account for systems where the frit and coating are on the same surface. Also currently the scrip depends on the "clear" glass data hard wired into the script.

QUESTIONS:
1.Which of this procedures should be used in which real case? I suppose for single pane clear glass we could use only glass primitive. Can glazing.cal be used for all coated glazings, and glaze.csh for fritted ones?

I think that the short answer is that glazing.cal does not account for all coated glazing and is only for a single pane glazing system. Glaze.csh is currently the only thing that creates some opportunity to use data from something like Optics in a more functional way. Glaze.csh is not only for fritted glass.

2.What is the format of input file for glaze.csh script?

The input file should look something like the following it has a header line followed by one line per glazing material type:

Surface Tr Tg Tb Rcr Rcg Rcb Rgr Rgg Rgb Part
<surface name> <r trans> <g trans> <b trans> <r coated refl> <g coated refl> <b coated refl> <r glass side refl> <g glass side

  <b glass side refl> <boolean switch [0 or 1] to indicate if

material can have partial coverage, such as a frit>

As I recall this file is pretty sensitive to spacing of the values!

3.What if glazing have more than 2 layers?

You should contract Greg to extend the script to account for more layers...!

···

Thanks,
Marija.

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

Hi Jack,
Thank you for the fast answer.
I just have few comments:

PROCEDURE1
Problem:
*Glass reflectance is calculated implicitly, and values from Optic5
database don't have any effect.
This can be solved by using trans.cal functional file, and changing index
of refraction to obtain appropriate reflectance.

As I read "trans.cal" this is for converting from transmittance to
transmissivity, the latter value is used for the radiance "glass" material
type. I believe that the "glass" material that is output from Optics
accounts for this translation. I think that maybe Chas Erhlich could
confirm this?

Yes, this conversion is taken into account when glazing is exported.
I meant trans2.cal, not trans.cal. My idea was to use a trick I've found in
some Greg's mail:
To define glass with transmittance .85 and reflectance 0.5, run "calc
trans2.cal" in the ray/src/cal/cal directory and enter:
       Tn = 0.85
       Rn = 0.05
Typing in "n" and "tn" will give you these results:
       n
       $1=1.39992615
       tn
       $2=0.894736842

Note though, quoting Greg from the file, that trans.cal is for an
"infinite series solution for an uncoated pane of glass." This is a
solution for a single pane only. I am not sure that adjusting the index of
refraction is a valid way to "adjust" the reflectance and it still would
result on the same reflectance on both sides of the material. Most glass
systems that use coated glass have different reflectances on the outside
and inside.

You are right, so I suppose this 'simply glass' option is definitely not for
use.

2.What is the format of input file for glaze.csh script?

The input file should look something like the following it has a header
line followed by one line per glazing material type:

Surface Tr Tg Tb Rcr Rcg Rcb Rgr Rgg Rgb Part
<surface name> <r trans> <g trans> <b trans> <r coated refl> <g
coated refl> <b coated refl> <r glass side refl> <g glass side refl>
<b glass side refl> <boolean switch [0 or 1] to indicate if material can
have partial coverage, such as a frit>

As I recall this file is pretty sensitive to spacing of the values!

Yes, I've already had that problem, and that is the reason why I've asked
for the format definition.
The other problem occurs when I put only one glazing definition into the
file. Glaze script doesn't report error, but new material isn't added to
list of available surfaces!? Do you have an idea why it is happening?

Thanks again,
marija

Hi Marija,

2.What is the format of input file for glaze.csh script?

The input file should look something like the following it has a header
line followed by one line per glazing material type:

Surface Tr Tg Tb Rcr Rcg Rcb Rgr Rgg Rgb Part
<surface name> <r trans> <g trans> <b trans> <r coated > <g
coated refl> <b coated refl> <r glass side refl> <g glass side >
<b glass side refl> <boolean switch [0 or 1] to indicate if material can
have partial coverage, such as a frit>

As I recall this file is pretty sensitive to spacing of the values!

Yes, I've already had that problem, and that is the reason why I've asked
for the format definition.
The other problem occurs when I put only one glazing definition into the
file. Glaze script doesn't report error, but new material isn't added to
list of available surfaces!? Do you have an idea why it is happening?

I have attached a file that should (highly dependent on non-munging by email) contain the correct spacing of the header portion of the file. The data needs to have the same spacing.

I suspect the problem with the (1) definition is that you do not have the header in the file or the file is not correctly formated.

···

Thanks again,
marija

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

--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

Hi Marija,

Yes, I've already had that problem, and that is the reason why I've asked
for the format definition.
The other problem occurs when I put only one glazing definition into the
file. Glaze script doesn't report error, but new material isn't added to
list of available surfaces!? Do you have an idea why it is happening?

Make sure you have a final end-of-line character in your file. A lot of editors don't bother with it, but most Unix utiliities require a final EOL (linefeed). I checked the script, and I think this is the most likely problem.

Regarding more than two layers, the math gets exponentially more complicated with each layer, so I'm not likely to add capability in this area any time soon....

-Greg

Sorry forgot to attach the file. Here it is.

Jack de Valpine wrote:

header.dat (46 Bytes)

···

Hi Marija,

2.What is the format of input file for glaze.csh script?

The input file should look something like the following it has a header
line followed by one line per glazing material type:

Surface Tr Tg Tb Rcr Rcg Rcb Rgr Rgg Rgb Part
<surface name> <r trans> <g trans> <b trans> <r coated > <g
coated refl> <b coated refl> <r glass side refl> <g glass side >
<b glass side refl> <boolean switch [0 or 1] to indicate if material can
have partial coverage, such as a frit>

As I recall this file is pretty sensitive to spacing of the values!

Yes, I've already had that problem, and that is the reason why I've asked
for the format definition.
The other problem occurs when I put only one glazing definition into the
file. Glaze script doesn't report error, but new material isn't added to
list of available surfaces!? Do you have an idea why it is happening?

I have attached a file that should (highly dependent on non-munging by email) contain the correct spacing of the header portion of the file. The data needs to have the same spacing.

I suspect the problem with the (1) definition is that you do not have the header in the file or the file is not correctly formated.

Thanks again,
marija

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

--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

Hi,

Jack wrote:

I have attached a file that should (highly dependent on non-munging by email) contain the correct spacing of the header portion of the file. The data needs to have the same spacing.

I suspect the problem with the (1) definition is that you do not have the header in the file or the file is not correctly formatted.

Greg wrote:

Make sure you have a final end-of-line character in your file. A lot of editors don't bother with it, but most Unix utilities require a final EOL (linefeed). I checked the script, and I think this is the most likely problem.

Thanks Jack and Greg.
Header was OK, but I suppose the end-of-line was the problem!

Regarding more than two layers, the math gets exponentially more complicated with each layer, so I'm not likely to add capability in this area any time soon....

OK. My question was more hypothetically.

Marija