"Very High Reflectivity Surface" Causing issues

Hi! I’m working on a simple model


There is this material and construction causing problems as seen below:
image
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

There should be a way to remove the material/construction from the model.

This is what I am doing with the construction manager incase of user error. might want to open in new tab
tdd_pipe_cons_issue

1 Like

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.

1 Like

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.

There should be a way to remove the material/construction from the model.

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?

1 Like

Does this original prototype model actually simulate in EnergyPlus?

In my experience, materials like this with very high conductivity and very low thickness cause the EnergyPlus Conduction Transfer Function to fail.

{
  "roughness": "Smooth",
  "type": "EnergyMaterial",
  "thickness": 0.0005,
  "conductivity": 237.0,
  "density": 2702.0,
  "specific_heat": 903.0,
  "thermal_absorptance": 0.9,
  "solar_absorptance": 0.05,
  "visible_absorptance": 0.05,
  "identifier": "Very High Reflectivity Surface"
}

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?

1 Like

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.

1 Like

Hi Chris! I should have the .idf somewhere I can find, ill report back with results of if the file runs and also will upload the file.
best
-trevor

1 Like

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.

Meanwhile, I still think it would be great to perform this check in the validation routine as the last safeguard.

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”

Here is the idf if it is of use to anyone:
US+MF+CZ2AWH+elecres+slab+IECC_2021.idf (1.3 MB)
This is the original un-updated 9.5 *.idf

1 Like

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.

2 Likes

Thanks both,
I removed this check in the UI.
fix(Material): remove UValue <= 200000 check by MingboPeng · Pull Request #478 · ladybug-tools/honeybee-ui-dotnet

1 Like