Comparison of the results of pyWinCalc and WINDOW

[christoph-maurer]

I have cloned https://github.com/LBNL-ETA/pyWinCalc and run five examples. Then I have modeled these five glazing systems in WINDOW 8.0.6.0 and compared the results to the results of pyWinCalc. I found good agreement for the examples single_clear.py and triple_clear.py. I was not able to reproduce the results of igsdb_double_clear.py, interior_bsdf.py and igsdb_interior_bsdf.py in WINDOW.

I attach the five glazings systems as a WINDOW database, screenshots of the settings and the files of the comparison. How can I reproduce the examples from pyWinCalc in WINDOW?
comparison_pyWinCalc_WINDOW.zip

[Fan-Feng]

I have the same issues.

[vidanovic]

@christoph-maurer and @Fan-Feng We are aware that some of the results are not exactly the same but they are close enough. As for BSDF, that is currently under examination since we have realized that WINDOW is not doing wavelength by wavelength calculation correctly. We are currently working on consolidating procedure between two engines for BSDF case.

[RebeccaPowles]

Can I please revive this issue to ask if there is any documentation or commentary about the differences in calculations between TARCOG and WinCalc so I can understand them better? I am trying to validate pyWinCalc results against WINDOW simulations and I would like to understand the points of difference. I am familiar with the technical documentation for WINDOW which I assume describes the TARGCOG method.

Sample differences:
4Clr/8Air/4Clr
UCOG(TARGCOG): 2.941
UCOG(WinCalc): 2.954
comparing WinCalc and TARCOG engine options set in preferences in W8.1.6
pyWinCalc gives identical results to WINDOW with WinCalc engine as expected

[vidanovic]

@RebeccaPowles I can help you with that. I see above that you have compared two IGUs that have only clear glasses. The difference in the U-value is way too much.
I did similar comparison with NFCR 102-102 (double clear) and got these results:

NOTE: All results that I am presenting are output of the Windows-CalcEngine unit tests. However, they should match with what you are running in pyWinCalc.

We have issues for most of these in Windows-Tools repository for which we have to give you an access (which can be done). However, I can try to explain some of the differences here. The above results are obtained with full spectral data and Non-BSDF case. I have also run NFRC 102-103 with BSDF Quarter Basis:

So as for clear glasses, you should be getting similar differences. When you wrote 4Clr/8Air/4Clr, what is the glass (NFRC ID) that you were using?

As for general differences I found out the following:
Using condensed spectrum in WINDOW will generate T, Rf, Rb zero for wavelength 0.3 which is not what pyWinCalc is doing. Because of this, I have seen bigger differences between WINDOW and pyWinCalc when using condensed spectrum.
When using full spectral data pyWinCalc will merge wavelengths between all the samples and then perform integration. For example, when using 102 (111 wavelengths) with 31100 (441 wavelengths), pyWinCalc will use union between these two thus creating 521 wavelengths in total, while WINDOW will using 441. However, this tends to produce very small differences.

One more thing that you sholud be aware of is this:

(This is my validation of venetian blind but it will serve the purpose since the same is happening with glasses)
In the above venetian validation there is a big difference between WINDOW and pyWinCalc because of the emissivity values (solar and visible are pretty decent). The difference is coming from the interpretation of the emissivity values from the input data. When we get the spectral data either from the OPTICS for from the database they might contain wavelenght values above 2.5 and also they might contain (and usually do) precalculated emissivities in the header file. If that is the case pyWinCalc will always calculate emissivities if there are the data above 2.5 and it will take header emissivities ONLY if those data are missing. WINDOW is doing the opposite, it will take header values and will not calculate emissivities. This is the reason why emissivites differ in the case above thus producing different thermal values (U-value and SHGC). This could very well be the problem you are seeing for your example.

Additional note for you. In previous weeks I was working on validating shading devices vs WINDOW and found some problems that are fixed. However, that version is still not available in pyWinCalc but we are hoping to release it soon. I am still trying to catch time and do additional comparison of various shading devices but had to divert to different project at this time.

[RebeccaPowles]

Thanks, @vidanovic -for now I am just checking specular glazing. I thought the difference was surprisingly large which is why I thought there would be an explanation.

Here is what I am doing:
In WINDOW 8.6.1 Glazing System library
layers 9706 4 mm clear / 8mm Air / 9706 4mm clear

Case 1: Set in preferences: Simulation Engine : Tarcog Ufactor = 2.941 (I confirmed this is the value from earlier WINDOW versions as well)
Case 2: Set in preferences: Simulation Engine: WindowsCalc-Engine Ufactor = 2.954
(Note: press Calc button after switching Simulation Engine, values do not show ? to indicate recalc required)

Using pyWinCalc, I get U= 2.954, matching the WINDOW WindowsCalc-Engine result but not the Tarcog / earlier WINDOW versions result.

Hmm... OK - maybe it is something weird with layer 9706 as if I change to 9705 or 9707 there is no difference between the two Ufactor results. Looks like I just got lucky with the layer I chose to start testing with.

As you suggested - it is the case that layer 9706 has data up to 25 micrometers and 9705 and 9707 only have data to 2.5.
If I delete the spectral data for 9706 above 2.5 micrometers from the json layer data that pywincalc uses, the deviation disappears. If I select another 4 mm clear layer that also has IR data (NFRC ID: 25501), I get a similar difference in Ufactors switching between WinCalc and Tarcog. So it looks like that is the origin of the difference.

But why is there such a large difference?
option 1 - there is something wrong with the IR data for these layers. Seems unlikely that two unrelated layers 9706 and 25501 would have similar errors - looking at the data nothing stands out but I can't rule this option out entirely

The emissivity of 9706 according to pywincalc is 0.845/0.846 (default value for uncoated glass is 0.84) If I delete the IR spectral data and use these values for precalculated emissivity, I get U=2.954, which is consistent. U is sensitive to the emissivity values. So are these emissivity values 'real'?

option 2 - There is a bug in the emissivity calculation and the values should be closer to the precalculated value of 0.84 - unlikely, I know you have tested but it never hurts to recheck
option 3 - There is a 'real' difference between the precalculated and spectral average IR data

If it turns out to be option 3 - I understand some reasons why you might want to prioritise spectral data, but these differences in UCOG are pretty large - . These deviations could occur for any database layer with IR data if there is a difference between the precalculated values and the spectral data. It is not possible for 'regular' WINDOW users to see which database layers have IR data to note where these differences may appear. To manage this it could be useful to have the option to continue to use the precalculated emissivity values - this option could be made accessible through WINDOW preferences. That way you could expect good agreement across WINDOW versions and pywincalc for all database layers with the appropriate options selected, but it will still be possible to use the spectral data when required.

[vidanovic]

@RebeccaPowles I am guessing that somewhere in the process there is something like this:
if value between (0.85 and 0.83) -> make it equal to 0.84, which pyWinCalc is not doing.
Idea for predefining emissivity values by the user could be doable. I am including @StephenCzarnecki and @jcjonsson since they might have some input regarding this issue. @StephenCzarnecki we could take a look about the possibility of user predefining emissivity values which would resolve this problem, however, I would rather have stable procedure on determining and pre-calculating the emissvity values where calculation would produce the same number that is given in the header file.
@RebeccaPowles I will be out starting tomorrow and will be back sometimes mid January. However, I will probably respond to some messages if they are short (especially when dealing with jetlag)

[jcjonsson]

My guess is that WINDOW/tarcog prioritizes the precalc value coming from the header value (0.84) and pyWinCalc prioritizes the spectral data.

We have tried to make everything consistent that the spectral data has highest priority in all cases (since that is the only way you know that you are calculating the emissivity according to the standard you are expecting). The old world always involves two steps of sleuthing, 1. Figure out what data in the file was used - {Emissivity}, {Material}, or spectral data, and then the second step if the precalculated value is used or if a new emissivity is calculated according to the selected standard.

Exporting 9706 from Optics gives a header that suggests the spectral data is ignored in IGDB.
{ Emissivity, front back } Emis= 0.84 0.84
{ Ef_Source: Text File }
{ Eb_Source: Text File }
I was not aware there was a step to round to 0.84 in WINDOW, but trust Simon if that is the case.

[vidanovic]

@jcjonsson WINDOW is definitely taking header values over the integration. Also, I am guessing about rounding since 0.84 is such a round number :)

[dccurcija]

I would recommend doing nothing about this in WINDOW 7.8. As W8 starts reading directly from IGSDB and checker tool rejects emissivity that is not consistent with IR data, this will take care of itself. The question is what to do with existing data, which may require going through database with checker tool.

[RebeccaPowles]

Thanks @vidanovic and @jcjonsson for your comments - now I understand what is going on I am happy to manage it in my own code for now. Enjoy your holiday break.

[dccurcija]

Thanks @rebecca Powles ***@***.***>. Enjoy your Summer break. Charlie

…

On Wed, Dec 11, 2024 at 2:34 PM Rebecca Powles ***@***.***> wrote: Thanks @vidanovic <https://github.com/vidanovic> and @jcjonsson <https://github.com/jcjonsson> for your comments - now I understand what is going on I am happy to manage it in my own code for now. Enjoy your holiday break. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJULFAICHWF2PEDK3LULRL2FC4WPAVCNFSM6AAAAABTKCP3BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZXGMZTSNZVG4> . You are receiving this because you commented.Message ID: ***@***.***>

--

------------------------------------------------------------------------------------------- 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: ***@***.*** Berkeley, CA 94720 Web: http://windows.lbl.gov/ <http://btech.lbl.gov/>

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