You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi Robin and Simon,
(hope I've picked the right audience - please forward if not)
You may be aware of this already, but it has just come to my attention that ISO 15099 specifies a numerical integration method for spectral averages that was not included in the Optics spectral averaging dll and is not covered in the WINDOW technical manual.
If you want to perform spectral averages exactly according to the method given in ISO 15099, you will need to use the midpoint rule for the numerical integration. The differences between the midpoint rule and trapezoidal rule integration methods are very small, but not zero...
Happy to discuss further and provide an update to the technical manual if required.
NFRC 300 does specify the calculation NFRC uses so keeping
that as de:
Use the trapezoidal (trapezium) method to numerically approximate the
integrals
I do not know where to look to see if they specify that if 15099 is being used for in-between blinds, then the wavelength integration should be done according to 15099 methods.
Extending the dll to have one more function seems reasonable, but it seems unclear to me where in WINDOW a decision should be made to use the new integration function if there is a shade or not. Future feature?
(The standards file allows you to specify one integration method for solar, but I guess it would be possible to add a new field in there solariso15099... ).
The text was updated successfully, but these errors were encountered:
Engine uses Trapezoidal as default. This should cover all possible inputs that can be found in the standard.
Simon
On Tue, Mar 2, 2021 at 10:31 AM Christian Kohler [email protected] wrote:
Rebecca
Thanks for flagging this. My guess is that NFRC will want to stick with the current trapezoidal rule for everything. We could consider making a pure 15099 mode that specifies mid-point integration if/when we implement these changes in the dll. Simon, is this integration implemented in WinCalc engine? Would it make sense to add this method only to wincalc and not to the dll?
My interpretation is that the integration method specified in ISO 15099 is different to any of the methods currently provided by WCE which were inherited from the spectral averaging dll - that is the point I was trying to make. The difference is very small, but if you want to match ISO 15099 exactly, you will need to add a new integrating method to the WCE that estimates the midpoint value of the source, detector and spectrum SEPARATELY before multiplying them together to get the midpoint weighted spectrum value that is used in the integration sum (what I call Midpoint Rule method 1).
If I have time I will go see how big a difference it makes across the IGDB.
This explains why I think a new integration method (Midpoint Rule) is required to exactly follow ISO 15099:
Email from Rebecca Powles, Wed, Feb 24, 2021
Hi Robin and Simon,
(hope I've picked the right audience - please forward if not)
You may be aware of this already, but it has just come to my attention that ISO 15099 specifies a numerical integration method for spectral averages that was not included in the Optics spectral averaging dll and is not covered in the WINDOW technical manual.
If you want to perform spectral averages exactly according to the method given in ISO 15099, you will need to use the midpoint rule for the numerical integration. The differences between the midpoint rule and trapezoidal rule integration methods are very small, but not zero...
Happy to discuss further and provide an update to the technical manual if required.
regards,
Rebecca
This file was attached
Midpoint_vs_Trapezoidal_ISO15099_to_LBNL.docx
Reply from Jacob, Thu, Feb 25, 2021
NFRC 300 does specify the calculation NFRC uses so keeping
that as de:
Use the trapezoidal (trapezium) method to numerically approximate the
integrals
I do not know where to look to see if they specify that if 15099 is being used for in-between blinds, then the wavelength integration should be done according to 15099 methods.
Extending the dll to have one more function seems reasonable, but it seems unclear to me where in WINDOW a decision should be made to use the new integration function if there is a shade or not. Future feature?
(The standards file allows you to specify one integration method for solar, but I guess it would be possible to add a new field in there solariso15099... ).
The text was updated successfully, but these errors were encountered: