Hi (@chris),
I’m having issues implementing the WindowConstrShd component and simulating with the AnnualLoads.
I’m changing the schedule of the shades and it doesn’t matter what i define, the results are always the same.
Simulating with the ModelToOSM shows differences in the results.
Checking the IDF file i can see in the ShadingControl section that the assigned schedule is omitted from the definitions. That explains that there are no differences in the results.
If i’m reporting here, another issue that is worth to fix is regarding the names of the constructions with and without the shades in the IDF created with the **ModelToOSM** component.
The simulation results are fine but the construction with shades takes the name of the one without shades, as defined in GH, and viceversa.
Sorry that I have been away from the forum for a few days.
For the first issue, are you sure that you are looking at the right IDF? Remember that the Annual Loads component doesn’t take a model as input (and it doesn’t use the model name to set the simulation folder). So all Annual Loads IDFs get written to:
C:\Users\[USERNAME]\simulation\Annual_Loads
In any case, I took a closer look and I found a bug in the schedule of window shades, which might explain why you were getting the same results. I just pushed a fix for it:
The second issue is not a bug and is the unfortunate consequence of having to work around idiosyncrasies of EnergyPlus and limitations of the OpenStudio SDK. As you said, it is all simulating correctly and, if I could have easily switched the names, I would have done so. If it really becomes an issue, I can try to add some post-processing into the OSM translation process to switch the construction names but it’s going to add a little overhead to the translation process. Would you be ok with me placing a low priority on it for now?
Yes. I’m sure. Now i can see, after your fix that the schedules are been taking into account. So thanks for that.
Absolutely. This one is “transparent” and no one will notice, as long as the results are fine. I wouldn’t check if it wasn’t for the first issue.
If i’m here with the AnnualLoads component, i want to report another (bug) issue. Running a parametric construction (changing the thickness of the insulation layer), when the thickness is 0.0 the component fails with the following error:
Program Version,EnergyPlus, Version 9.5.0-de239b2e5f, YMD=2021.07.28 07:44,
** Severe ** [Material][Cls_Ins_Mat_0cm][thickness] - “0.000000” - Expected number greater than 0.000000
** Fatal ** Errors occurred on processing input file. Preceding condition(s) cause termination.
…Summary of Errors that led to program termination:
… Reference severe error count=1
… Last severe error=[Material][Cls_Ins_Mat_0cm][thickness] - “0.000000” - Expected number greater than 0.000000
************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).
************* Fatal error – final processing. Program exited before simulations began. See previous error messages.
************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
************* EnergyPlus Sizing Error Summary. During Sizing: 0 Warning; 0 Severe Errors.
************* EnergyPlus Terminated–Fatal Error Detected. 0 Warning; 1 Severe Errors; Elapsed
I can understand that, but the same simulation with the ModelToOSM comes through fine.
I remember some other discussion (maybe related to radiance) where it happened the same (0.0 thickness value) and you solved it. Can’t find it though…
I wonder if this is fixed. If no, maybe a warning can be in order saying that a 0.0 thickness is not allowed.
Sorry again for another late response, @AbrahamYezioro . A material thickness of 0 is illegal in EnergyPlus and I should add a probably add a check for it. I will check what OpenStudio is doing but I assume it’s probably something implicit (the thickness is probably getting set to some default value that we have no way of knowing unless we check the IDF or OSM). Explicit is better than implicit so I’d rather avoid the OpenStudio behaviour.
