Inconsistency in Angular Conventions for CFS Modeling in WINDOW 8.0.33.0

[rw.h...@gmail.com]

Dear experts and heavy users,

I'm encountering an issue with angular conventions while modeling a CFS (Venetian blinds) in WINDOW 8.0.
Reference: Window 6.1 / Therm 6.1 Research Document (LBL)

According to this documentation, the angular coordinate system uses:

• x, y, z and θ, φ (theta, phi) for incident angles

• φ = 90° corresponds to above the horizon

• φ = 270° corresponds to below the horizon

---

Question / Problem Statement

The BSDF and MatrixReader appear to follow this convention, but the AngularData.csv file seems to break it. Why?

---

Observations

You can find a visual summary of the issue in the following slides:
Google Slides – Angular Convention Problem Description

The relevant files are available here:
Google Drive – Supporting Files

1. BSDF vs. MatrixReader – convention holds:
   In the screenshot, I compare the directional-hemispherical value from BSDF Viewer with that in the MatrixReader — both are consistent with the documented convention.

2. BSDF vs. AngularData.csv – convention breaks:

   • Case A: A beam coming from above the horizon is labeled φ = 270°, which is contrary to expectations.

   • Case B: Alternatively, a beam from below the horizon is labeled φ = 90°, which is also inconsistent.

In both screenshots, I compare the directional-hemispherical value from BSDF Viewer with the corresponding value in the *_0_AngularData.csv file.

---

I would appreciate your insights, documentation references, or clarification in case I’m misinterpreting something.

Best regards,
Robert

[D. Charlie Curcija]

Hi Robert,

Thank you for submitting a detailed explanation of the issue. We are currently dealing with the release of 8.1, so our response will be slower.

Charlie 

--
You can view the WINDOW forum online at:
https://groups.google.com/g/berkeley-lab-window
---
You received this message because you are subscribed to the Google Groups "Berkeley Lab WINDOW" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeley-lab-wi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/berkeley-lab-window/5a0e921b-2d58-4446-bd74-42716df4f80fn%40googlegroups.com.

--

-------------------------------------------------------------------------------------------

D. Charlie Curcija, Ph.D.                              Tel: (510) 495-2602

Lawrence Berkeley National Laboratory         Fax: (510) 486-4089

Windows & Envelope Materials Group           Cell:(510) 604-8668

1 Cyclotron Rd., 90R3147                           Email: dccu...@lbl.gov

Berkeley, CA 94720                                    Web: http://windows.lbl.gov/

-------------------------------------------------------------------------------------------

[Jacob C. Jonsson (LBNL)]

Dear Robert,

Looking at it, I think you have properly documented the inconsistency in notation. 

Do you have specific use cases for the AngularData.csv or is it possible for you to use the XML results?

Best,

Jacob

[R W]

Dear Jacob,

knowing the incosistency I can live with the data from AngularData.csv.
We are looking for absorption per layer, which I can't get from the xml file. Right?

Thank you for your response.

best regards

Robert 

You received this message because you are subscribed to a topic in the Google Groups "Berkeley Lab WINDOW" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/berkeley-lab-window/6BnMXlXBJic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to berkeley-lab-wi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/berkeley-lab-window/5dfe6eea-0aef-4f82-84b0-1e288cfdfbd8n%40googlegroups.com.

[rw.h...@gmail.com]

Dear Jacob, dear all, on a assisted deep dive I found a somehow relevant issue, worth posting: NatLabRockies-Energyplus-github 11831.

A follow-up with a different "which way round" question, this time about how EnergyPlus reads WINDOW's matrices. Since the complex fenestration code in EnergyPlus came from LBNL, I would like your view before or alongside the EnergyPlus issue: <link to the GitHub issue>.

EnergyPlus reads the front transmittance matrix of a `Construction:ComplexFenestrationState` with the columns as the incident direction for the beam (`WindowComplexManager.cc`, `WinDirHemiTrans`). It reads the same matrix with the rows as incident for the sky and ground diffuse averages (`WinSkyTrans`, `WinSkyGndTrans`). The pattern is already in the Fortran. For a symmetric matrix this makes no difference. For a tilted venetian blind it does. On EnergyPlus' own example `CmplxGlz_Daylighting_SouthVB45deg.idf` the sky transmittance comes out 0.0940, where the column reading gives 0.1122.

The attached figure shows the directional-hemispherical transmittance of that example's matrix per incoming Klems patch, read both ways, and the difference. An annual beam-only run follows the columns to 0.25 %. A diffuse-only run follows the rows to four decimals.

WINDOW's XML documentation says each column is an incident direction. pywincalc's direct directional-hemispherical transmittance equals the column sums. A layer-order check that needs no convention also agrees: the glass's angular transmittance sits on the index of the side the glass is on, and that gives the columns as incident for both layer orders. So I believe the beam path is right and the diffuse paths are transposed.

Two questions:

1. Does WINDOW's EnergyPlus IDF export write `Matrix:TwoDimension` in the XML's layout, columns = incident? The I/O Reference does not say, and the examples are the only evidence I have.

2. Are you aware of this in EnergyPlus, or of a reason why the diffuse averages should use the other index?

The same index order appears in EnergyPlus' BSDF daylighting (`DaylightingManager.cc`). We have not measured it there.

This is independent of the φ labelling in AngularData.csv from the earlier thread. The check matched each column to its own direction above and below the horizon, and the layer-order check uses only θ.

Best regards,

Robert

[Dragan Vidanovic]

Dear Robert,

Thank you for the careful write-up. I went through both the WINDOW source and the EnergyPlus source, and your reading is correct.

1. Does WINDOW's EnergyPlus IDF export write Matrix:TwoDimension in the XML layout (columns = incident)?

Yes. In both calculation engines (the legacy one and the current WCE-based one), the IDF writer and the BSDF XML writer take the same matrix and write it row by row, with no transpose on either path. The XML declares IncidentDataStructure = Columns, so the Matrix:TwoDimension objects in the IDF also have the columns as the incident direction. The front transmittance and absorptance matrices, CFS_Glz_<n>_TfSol and ..._Layer_<k>_fAbs, are the same data you see in the XML.

2. Is there a reason the diffuse averages should use the other index?

No. It is an index swap in EnergyPlus.

Matrix:TwoDimension is read row by row into an array addressed as (column, row) (MatrixDataManager.cc, GetMatrixInput). So inside EnergyPlus the first index of SolFrtTrans is the IDF column, which is the incident direction. In WindowComplexManager.cc:

The beam quantities index it as SolFrtTrans(incident, outgoing), which is correct. These are WinDirHemiTrans, WinBmGndTrans and WinToSurfBmTrans in CalculateWindowBeamProperties, plus the beam overlap in SolarShading.cc.
WinSkyTrans and WinSkyGndTrans in CalcWindowStaticProperties index it as SolFrtTrans(M, J), with J taken from SkyIndex / GndIndex, so the incident direction is on the second index. That is transposed.
WinDiffTrans and WinDiffVisTrans use the same (M, J) order. They are not affected, because the sum runs over all incident and all outgoing directions with the same Klems weights.
There is no "seen from the inside" or reverse calculation behind it. The loops are commented "Incident ray loop" and weighted by Inc.Lamda(J).

I reproduced your numbers from the CFS_Glz_1_TfSol matrix in CmplxGlz_Daylighting_SouthVB45deg.idf, using projected-solid-angle averages of the directional-hemispherical transmittance:

columns as incident rows as incident
Sky          0.1122      0.0940
Ground 0.4345      0.4576

Daylighting

You were right to flag DaylightingManager.cc. The BSDF daylighting code indexes the visible matrix as VisFrtTrans(outgoing, incident) throughout:

- DayltgInterReflectedIllumComplexFenestration: sky, ground and sun flux
- DayltgDirectIllumComplexFenestration
- DayltgDirectSunDiskComplexFenestration

It is at least consistent with itself, but by the same reasoning it reads the transposed matrix for sky, sun and glare. Like you, we have not quantified the effect there. I would expect it to matter for the same kind of strongly asymmetric BSDFs, such as tilted slats.

The EnergyPlus issue

Please do post the EnergyPlus issue. If it helps, feel free to quote the above, and we will add a comment there with the code references. The fix itself is small: swap the index order in the two diffuse loops and at the daylighting call sites.

Thanks again for digging into this.

Best regards, 

Simon