Hi there!
I’ve experienced Ladybug tools but am a novice with pollination. For the first try, I want to use the new recipe to create the baseline for Appendix G. I created a project on Web App and loaded related recipes in my project. Still, for both the example file that @chriswmackey provided and for my own project, I get failed to run the project and get the results. I added an image from the debug page; can anyone help me understand how I can find the problem? I don’t get an error like “Ladybug” in the program, but I see this failure on the web.
I would be thankful if anyone could help me. 
If you see the last lines in the logs you should see this error:
[openstudio.Model.Model] The run did not finish and had following errors: RoofCeiling:Detailed="529_100_UNIT_B_BR_97603598..FACE1", Vertex size mismatch between base surface :529_100_UNIT_B_BR_97603598..FACE1 and outside boundary surface: 529_105_CLO_39EE495D..FACE7 The vertex sizes are 5 for base surface and 6 for outside boundary surface. Please check inputs.\nRoofCeiling:Detailed="529_105_CLO_39EE495D..FACE7", Vertex size mismatch between base surface :529_105_CLO_39EE495D..FACE7 and outside boundary surface: 529_100_UNIT_B_BR_97603598..FACE1 The vertex sizes are 6 for base surface and 5 for outside boundary surface. Please check inputs.\nGetSurfaceData: Errors discovered, program terminates
@eanvari, did you try to run the validation command? I can see several validation errors:
2 Likes
Thanks for checking that @mostapha . I would bet that the validation errors related to adjacencies are particularly responsible for that particular simulation failure. So fixing those might allow for the simulation to proceed.
@mostapha and @chriswmackey thank you kindly. Because I ran the simulation with the ModelToOSM component and there were no errors (just a non-convex warning), I think the model was error-free and didn’t re-check it with validate component. I’m going to fix any errors in the validation component and retest it.
just have a question. I know the validate component for LBT but how should I run the validation command in Grasshopper? also on debug page when I click on each red circle don’t see and extend log, such one you send to me, where I can see the log?
I fix the errors in the model:
now the baseline runs correctly but has an error for the proposed model. I would be thankful if you can help me to pass this one, also.
Hi @eanvari ,
I am not sure how you were able to get your original invalid model to simulate with the “Model To OSM” component since it fails for me with the same error message:
In any event, I am glad that you were able to get the model to the point that it is valid. If you are asking how you should run the validation command in the Rhino plugin, you should use the PO_ValidateModel command. It has a lot of nice features that the Grasshopper component does not have.
I can see that your new model isn’t really valid on my end (at least when I am using a tolerance of 0.01 meters or 1 cm):
… but I realize that you are likely using a different tolerance at which it is valid.
I’m also able to simulate your model with no issues locally. Let me try re-running it and see if I can figure out what happened. Something is failing in the translation process to OpenStudio for your model.
FYI, looking at your model, I see that there are a few spaces with an ideal air system and you should really be replacing these with a real HVAC if you want the Appendix G simulation to be meaningful:
2 Likes
Ah, I figured it out. The ideal air systems are also to blame for the simulation failure. It looks like I should probably add a check in the handler for the recipe to ensure that none of the assigned HVACs are ideal air. But, long story short, just change your ideal air HVACs to be PTAC or something like that and the recipe should succeed.
2 Likes
You’re very welcome, @eanvari .
I just added an extra check in the handler:
Now, you’ll get an explicit error if you try to simulate a model with ideal air systems:
This extra check should be in the next set of installers.
Also, I have a run going now where I replaced your ideal air systems with PTHP.:
If it succeeds, we’ll know that this was the last of the issues to getting your model to simulate.
1 Like
Hey @eanvari ,
So it would seem that there is still an issue that’s a little deeper than what I mentioned in the last post. It would appear that there might be a bug in the OpenStudio Standards gem when trying to apply the efficiency standard for ASHRAE 90.1-2019 to PTHP systems when the size of the system is very small.
I’m going to see if I can get it to go away by changing how ventilation in the PTHP system is assigned but this might be a bug that is too deep for us to address on our end and we may need to wait for NREL to push a fix to the standards gem.
In the meantime, I can get your model to simulate with any system other than PTAC-style systems. For example, using PSZ-HP runs without problems. So, if you are considering designing this building with any other type of HVAC system, I would try that first.
I also found that removing the eff_standard input to the recipe gets everything to work well but I’m not sure you want to do this given that it will drastically change the energy use of your proposed design.
1 Like
Hi again @eanvari ,
So nothing I tried was able to get the OpenStudio Standards gem routine to succeed except somehow increasing all of the loads during the sizing simulation such that the PTAC ended up being larger.
Long story short, I think this is pretty clearly a bug in the OpenStudio Standards Gem, which is out of our hands. I opened up an issue on their GitHub:
They are usually good with fixing bugs but it will likely take them a long time to ultimately get the fix to us.
For now, the best that I can offer is to just use a HVAC template other than PTAC/HP. Or you could use Ironbug to make some PTHP systems where you specify the efficiencies explicitly, allowing you to forgo the need to set the proposed-efficiency-standard as an input for your simulation.
I’m sorry that I can’t currently offer anything better but I guess this is to be expected with brand new functionality. Thanks for reporting the issue and, in the long run, I’m sure your reporting here will help prevent many others from experiencing this bug.
1 Like
Thank you @chriswmackey for your message and for letting me know about the issue that arose when trying to apply the efficiency standard for ASHRAE 90.1-2019 to PTHP systems in the OpenStudio Standards gem. It seems that this is a deep bug that may require NREL to push a fix to the standards gem.
You also said that I could simulate the model with other HVAC systems, like PSZ-HP, and you suggested that I use Ironbug to make PTHP systems whose efficiencies are clearly stated. These are both viable options, and I should select one after consulting with my team.
I know that taking out the eff_standard input could make the proposed design use a lot more energy, so it might not be the best choice for you.
Finally, thank you for your efforts to troubleshoot the issue and for reporting it. I appreciate your patience and hope this can help others as well.
1 Like
Hi @chriswmackey , do you know if this issue has been resolved? I got errors with other HVAC systems as well not just PTHP, I tested a few scenarios and it does not seem to follow a specific pattern, for instance, a VAV system threw an error while a PSZ-HP worked. All in all it seems that with native GH HVAC, the solution is always to unplug proposed_std_ from the recipe.
The error I get is "ERROR: “RunProposedSimulation” failed. See below for more information: no implicit conversion from nil to integer
- Solution exception: ERROR: “RunProposedSimulation” failed. See below for more information: undefined method `’ for nil:NilClass"
I have seen that on github the issues are supposed to be resolved. Should I update my Openstudio SDK to 3.6.0? please advise
Hi @moelsayed ,
Yes, the original issue with PTAC systems has been fixed by the OpenStudio team at NREL.
If you have another model that’s failing on the efficiency standard-setting part, then please send me the HBJSON and I’ll try to recreate it on my end.
There’s currently a bug in OpenStudio Standards related to setting efficiencies of VAV systems that the team at NREL is trying to fix now:
As far as I know, it only affects VAV systems and it may be the result of applying the VAV system to a room that has no outdoor air ventilation specification. I’ll plan to test this today and, if this ends up being the case, we should be able to work around your issue by putting in a dummy specification of outdoor air.
And you’re right that unplugging the proposed_std_ should get it to succeed since you’re basically telling OpenStudio that you don’t need the efficiency of the HVAC equipment auto-assigned with a sizing calculation. So that bypasses the part of the simulation that is currently failing. But it also means that your model probably won’t have very efficient HVAC equipment since it’s just going to use a generic VAV system without the efficiencies assigned based on the sizes of the equipment.
@chriswmackey Thank you for looking into that, by isolating the spaces with no internal loads I was able to run the measure on the VAV system. However, I am baffled with 25% energy and cost savings it is getting a massive negative PCI improvement Which I can’t examine, is there a more detailed output from the recipe on how the pci was calculated after the simulation? here is the file for your reference.
Proposed working measure.gh (1.4 MB)
Hi @moelsayed ,
The Grasshopper file is not the most helpful since I don’t have pufferfish or the other dependency installed. It would also be much cleaner if you worked from a HBJSON or a Pollination Model instead of trying to regenerate the model in the script. Did you run your study on Pollination? That would allow me to check the HBJSON.
In any event, I can tell you that negative PCI improvements are very common with the newer versions of the ASHRAE 90.1, which are pretty rigorous compared to what was done a couple of decades ago.
The three most recent versions of Appendix G (2016, 2019, 2022) are written such that you evaluate the energy savings of your building in relation to an equivalent Building constructed with ASHRAE 90.1-2004 criteria. Then, you apply a factor to the energy use of that 2004 version of your building to account for what the energy use of the building should be using a modern code like the 2016, 2019, or 2022.
So the recipe is telling you that the energy performance of your design is 25% better than what was done in 2004. However, the three most recent versions of ASHARE 90.1 typically result in buildings that use 50%-60% less energy than what was done in 2004, which is a pretty substantial achievement when you think about it. But that’s how you get a negative PCI even though you have energy savings over a 2004 version of your model.
This also probably makes you appreciate that, with modern building codes, you can’t get away with a lot of things that were done in the past. You really get away with glazing ratios above 40% anymore. Nor can strategies like heat recovery or demand controlled ventilation be ignored.
1 Like
Hi @chriswmackey thank you for checking it out, I apologize, did not notice that I had some dependencies in there. I have consolidated the model and attached it here
Forum question.gh (1.5 MB)
I understand that the PCI can be very stringent but I did not anticipate zero points on the 2016.
Hi @moelsayed ,
I’m just letting you know that I think a major reason why people were getting recipe failures with VAV systems was because rooms were assigned a HVAC without having thermostat setpoints. I’m adding in a routine that will automatically remove the HVAC in these rooms before OpenStudio simulation so that we don’t get failures like this in the future:
Also, I’m testing your model using ASHRAE 90.1 2019 efficiencies to see if you can get any better PCI. The run is here:
The reality may just be that it’s just really tough to do better than the baseline now unless you’re doing something really extraordinary. I can see in your Grasshopper file that your Ironbug HVAC is a pretty standard system 8:
If you want to get better PCI’s, I might recommend using one of the DOAS systems with all of the bells and whistles (eg. enthalpy wheels, demand controlled ventilation and maybe even a fan shutoff if there are certain rooms that are unoccupied at certain times of the day).
1 Like
Hey @moelsayed ,
The simulation I ran on pollination completed successfully and, when using ASHRAE 90.1 2019 as the standard to set the efficiency of the HVAC equipment, the PCI of your model is actually pretty good:
It seems like you get quite a lot of benefit from modeling a hospital in Climate Zone 1B, which has actually had its Target PCI increase from ASHRAE 901.1 2016 to 2022. I guess the fact that hospitals keep getting fancier equipment that raises plug loads has counteracted some of the expected energy savings expected by newer versions of the code. At least while you’re in such a hot climate.
In any event, that simulation I ran with your model would get you a PCI improvement of ~44% in 90.1 2016, which would correspond to 16 LEED energy points.
This is great, thanks a lot @chriswmackey , one last hiccup, the reason why I posted it, is that it seems no matter what I do I am not able to replicate what you posted here! I tried the most efficient systems and I tried ASHRAE 2019; 2016… you name it and here is what I still get:
If you still have the script, or remember what changed, that would help a lot