-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error in Standards.AirLoopHVAC - no implicit conversion from nil to integer #1590
Comments
@chriswmackey Lots of possible reasons why this could be failing. I do consider it a bug that it's not failing gracefully and pointing out the error. First off, which version of openstudio-standards is this? Some things to check:
|
Thank you for the response, @mdahlhausen. This issue is happening with OpenStudio Standards 0.4.0 (the version of standards that shipped with OpenStudio SDK version 3.6.1). I can say confidently that numbers 1 and 3 are not the issue since they all have AirTerminalSingleDuctVAV objects and, thanks to the validation that we have built in Ladybug Tools, all of the geometry is closed with a correct floor area and volume. Let me see if item 2 could be to blame and some rooms are missing an outdoor air specification. Just so I understand the limitations here, is it alright if the outdoor air specification is zero as long as there is an outdoor air specification object? Or could a specification of zero outdoor air also trigger this error? This might answer my last question but, judging from that issue you linked to, I would guess that maybe a zero outdoor air specification is ok as long as there is some thermal load to be met? So maybe I just have a zone with zero outdoor air and zero thermal load. I'll see if setting a non-zero outdoor air specification for the rooms fixes it. |
Hey @mdahlhausen , I just realized that I said that we were using OpenStudio Standards 0.4.0, which is true, but the traceback that I posted has file paths that reference OpenStudio Standards 0.3.0. I have NOT been able to recreate the issue in 0.4.0 so far and let me see if re-running the large model using 0.4.0 results in no errors. |
You can disregard my last staement, @mdahlhausen . It seems the issue is still present in OpenStudio Standards 0.4.0. Here is the full traceback using OpenStudio Standards 0.4.0 in case it is helpful:
I will continue to work towards building a minimal sample file that recreate the issue (at the moment, the only file I have that recreates the issue has more than 700 zones). I think I can rule out the lack of an outdoor air specification as the reason for failure since I have several models succeeding through the whole process when they do not have an outdoor air specification. Maybe it could still be this issue (#1488) but I have put together a few models that have no heating/cooling load and no outdoor air specification and they still run fine through the whole OpenStudio Standards routnie. |
@chriswmackey Do you have terminals with 0 minimum airflow fraction and 0 design air ventilation? |
Hi @mdahlhausen , I don't know if the model with over 700 zones has terminals with 0 minimum airflow fraction and 0 design air ventilation but I'm not able to create a small scale case with 0 minimum airflow fraction so I think the answer is no? |
Hey @mdahlhausen , Sorry to revive this again after so much time but I have been able to recreate this type of issue with a somewhat simpler test case and I think I know exactly what is causing it. The OSM and SQL files from the sizing run are pretty large but I think they still help debug what's happening: Also, the error is admittedly a little different than the initial error at the top of this post but I sense the type of error is fundamentally the same. Here is what the log file says for the sizing run with that OSM model and the SQL:
And here's the full log file if you want it. Clearly, this is the line of the standards gem where it's failing: And the failure at that line seems to be because Is this something that you think the standards gem might eventually be able to support? Or do you have a proposed workaround so that the whole process does not come to a halt when there is one zone that has a zero load? |
Actually, forget the test case that I included above. I was able to recreate the exact same HeatingCoil error with a single-zone OSM, which is going to be much easier to debug. Here is the OSM: And just try running the following standards gem operations on it (where
That should allow you to see exactly what is failing here. |
Thanks for highlighting this. As for a preferred solution - do you think we should remove the piece of equipment if sizing is zero? I'm not sure EnergyPlus handles zero capacity equipment well. |
Thanks, @mdahlhausen . Actually, if you run the sample file and code from my last post, I now think this particular With that said, I think the original bug I posted about the I'll keep trying to produce some minimal sample files so that you can recrate the bugs on your end since that seems to be the best way to get to the heart of the problems. |
@mdahlhausen @chriswmackey I'm pretty sure the source of the heating coil COP error is that standards data has no value for 'pthp_cop_coefficient_1' (and _2) for a coil that size (>14999 Btu/h): openstudio-standards/lib/openstudio-standards/standards/Standards.CoilHeatingDXSingleSpeed.rb Lines 133 to 134 in 7fd7a7b
|
Ah, I think you're right, @eringold . Thank you for pointing this out and sorry that I misdiagnosed which variable was Is this something that you'll be able to push a fix for? Or is the reason why these coefficients are |
@chriswmackey no worries, I'll talk with Matt and work out a fix. It seems that prior standards vintages used the same coefficient values for all capacities, which would be one way to address it. |
@eringold and @mdahlhausen , I was just digging into this issue again and realized that the most recent issue I brought up about PTHP systems was actually fixed back in March in accordance with this other issue that I opened and Matt addressed. I had just gotten confused because the issue was fixed in March but it was not included in the OpenStudio 3.6.1 release that happened at the end of May this year. Now that OpenStudio 3.7 was released 3 weeks ago, I can see that this PTHP issue has been fixed in this version. Sorry for the confusion. I am going to see if I can recreate the initial issue I experienced with |
Hey @mdahlhausen and @eringold . I was able to recreate the issue with With all of this said, I was able to make another case that produced this issue with just two zones that both have an HVAC and a thermostat. It's just that the loads in one of the Rooms were so low that we hit the Here is the model with 2 rooms that you can use to recreate the issue: You'll see that you can simulate it as is using the EPW here: ... but running the following code with produce the failure on this line of the standards gem:
So my preferred solution would just be to leave the model as it is if you get something sized to zero since E+ is still able to simulate it. Granted, if it's easier to deal with it on your end by just removing the piece of equipment, I would also find that acceptable. And sorry again that it took to much time and back and forth to get you a minimal sample file that recreates the issue. Hopefully, you should now have everything that you need to fix it. Or, at the very least, you can now catch the exception being thrown and give a better message than "no implicit conversion from nil to integer" |
This issue raised several different bugs. I think they've all been addressed:
Please let me know if you encounter any other issues. I'll close this once #1804 is merged. |
I know that I'm 2 weeks late but I just wanted to say thank you, @mdahlhausen . I'm very much looking forward to testing this again in the next release. |
Hello All,
I have been debugging a fairly large model for which I am trying to perform a sizing run and then set the efficiencies and controls of a VAV air loop based on them. The process is failing in the stage of
air_loop_hvac_adjust_minimum_vav_damper_positions
and I'm trying to figure out if there is something that I can change about my model to get it to succeed.I am struggling to get to a minimal sample file that recreates the case and I will post it here if I get there since I know that would be valuable to you for debugging. But I was hoping that maybe the full traceback might be more legible to someone here. Or, in the event this is a recognizable bug or an exception that can be caught, it would be really nice to have the method proceed in future versions of the standards gem.
Here is the full traceback:
Do you have any thoughts on what might be going on to result in a Nil value at this stage of the process? Is the sizing calculation returning zero load or something like that?
Any advice would be appreciated and, again, if I manage to narrow down the problematic zones amid this 760-Zone model, I will post a minimal sample file here to recreate the issue.
The text was updated successfully, but these errors were encountered: