There is this material and construction causing problems as seen below:
Now I’ve tried manually removing the offending construction and material from the *.hbjson as well as using the construction manager.
The construction is called "TDD Pipe" and the mat is called "Very High Reflectivity Surface"
The *.hbjson can be found below with the offending constr and mat.
Any insight or help would be appreciated! USMFCZ3BelecresheatedbsmtIECC_2021.hbjson (320.9 KB)
edit: manually removing via editing the hbjson is working
Now I am thinking this again, it might be better for @chriswmackey to catch this error in the validation command so that it can be shown as a validation error instead of an exception error.
Ah, sorry that I somehow missed seeing this topic 6 months ago.
There are some cases where I understand that it makes sense to switch an Exception over to a ValidationError and accept all of the new lines of code, new maintenance, and increased runtime of the validation command that come with this type of change. However, this is one of the cases where it just seems so much easier to catch the issue on the interface end when creating the material rather than letting the material stick around and cause E+ simulation failures and ValidationErrors.
You can see the code for the check that runs here requires a division operation so it may not be as simple as a “less than” statement but it’s still relatively straightforward, @mingbo.
Do you think you could just perform this check on your end as the user creates the material and assigns thickness and conductivity, @mingbo ? This would just save me form having to add a few hundred lines of code on my end. And it would probably result in an overall better user experience because, instead of having the user wasting their time running extra validation checks and digging into their model to change invalid material layers, they just don’t create such invalid materials in the first place.
Question for learning purposes, the ‘very high reflectivity surface’ came from a prototype building’s idf when I imported it. Why is this material an issue, but not for PNLL folks who made it?
Granted, the last time that I checked this was probably around 2022 and it’s possible that the E+ team has made some changes to make this more forgiving. Can you upload the original IDF, @tfedyna ? Or, better yet, run a test to see if the IDF actually simulates?
Also, now that I know that you didn’t create this material yourself, I can probably just add a routine into the OSM/IDF importer that imports these invalid materials as EnergyMaterialNoMass, which is the right way to do it if you are only creating a material for the purpose of changing the reflectance.
Thank you @chriswmackey, I added the check in the material’s dialog. I am thinking if there is a better way to include this kind of checks in the Honeybee Schema so that the UI doesn’t need to perform this specific checks.
Hi! @chriswmackey
I ran the unadulterated PNLL model (E+ v9.5), and it was able to run
Simulation to completion, there were some severe error but no errors about the “Very high reflectivity surface”. The severe errors were from check warmup convergence. (alot of warnings too, all hvac stuff).
BUT it does run with the “very high reflectivity surface”
Thanks for checking that the simulation runs, @tfedyna . I ran some more tests on my end and, to my surprise, it seems that this limitation in EnergyPlus has been removed. In fact, it seems to have been removed 2 years ago in version 9.5, which is when your IDF is from and this was right after I first found the issue with low thermal resistance materials (at the start of 2021). I think Michael Witte fixed it all with this PR to E+:
So I’m now removing this check in honeybee-energy given that it’s no longer relevant. I made this change with this PR:
I’m sorry that I should have run the tests with E+ before asking you to implement the check, @mingbo . It’s obviously not urgent but you can revert it given that we have not used E+ 9.5 in quite some time.
And, for future reference about this:
Pydantic has these @root_validator decorators that can be used to describe more sophisticated validation logic. You can see an example of one here for checking that the fractions of different gasses in a GasMixture material match:
The main issue is that I don’t think any of these root_validators make it into the OpenAPI specification, which is really what you need @mingbo. Still, maybe we can find a way to include a list of these cases for you in the future so you can make sure your UIs create valid objects.