Construction Library doesn't open due to missing Material

After learning quit a bit about materials in the past days I tried to move on with my project.

When I was about to open Energy Constructions it didn’t happen.
I received the Message:

Failed to find the Material in the library source

This is related to the creation and deletion of custom Materials and a Construction I defined earlier.
I recreated the Materials request by request and the Manager finally starts again.

1 Like

Hi @martin6,

Please take a look at the latest developer version of the Rhino plugin, and let us know if the issue remains.


Hi @mingbo

I’ve removed a .json, containing some of the materials, out of the constructions folder before start.
Everything is now working when working in Rhino. Materials are kept within the Model.

When I change for instance conductivity of a previously defined material in my user library it’s not updated anymore with the next reload. Why is that?

And user materials don’t affect Model materials?.

Although in this case it would be wrong because the Model material is the right one (to be precise I adjusted it already, but since it’s not loaded…)

I think this leads here

You may haven’t had the time yet to solve this part also?
So what is best practice regarding which one User or Model should be superior?
Maybe the origin of creation with an option to save it either way?

The user’s library is cached in Rhino and only is loaded when Rhino starts. So you change the user’s library won’t affect the data while Rhino is open. You will have to close the Rhino and reopen it, and then it will try to load the new user’s library.

The source column indicates where the model is saved or from. In this case, you have one material named “Holz100 …” is loaded from the user library, and you have another one “Holz100 …” is saved in your current model file. They are independent and changing one material won’t affect another one.

Just to ensure that others might have the same question about the source of libraries, here are all possible sources:

  1. Model: items are saved into your current Rhino file, which is only available in your current model. Meaning you won’t be able to find these library items when you start a new model.

  2. LBT: Ladybug Tools’ default library items. They typically are named as “generic XXX” and serves as a safeguard for places that are missing a required material/construction/modifier etc.

  3. DoE-NREL: energy standards from OpenStudio Standards, They are loaded from the folder: ladybug_tools\resources\standards\honeybee_energy_standards

  4. User: user’s custom library. They are loaded from: ladybug_tools\resources\standards\honeybee_standards

Note: only the #1 model’s library items are editable from the UI, and the items from the rest sources are all locked.

(Hi @jankivyas, do you think we should document this in the user menus?)

Thats what I tought too @mingbo. Starting my computer this morning it worked like you wrote. I think the first restart also.
I thought it may have been to late last night for me to realize what is going on :zzz:
But this isn’t the case. I kept changing the material in different ways (File, out of Grasshopper).

After several restarts the material isn’t changed anymore?

That’s a really helpful information

I still don’t like the fact there are two materials with the same name and different parameters in a file.
Working in teams or over time this sooner or later goes wrong somewhere.

Maybe you can add a warning if there is a Material with the same name but different parameters in the model?

Some more confusion, maybe due to the fact the model has grown with the plugin being developed?


This one shouldn’t exist because it has the right conductivity

here is the User Material with the wrong conductivity although its stated right 0.079 in the user file.
So the first one in this list is maybe still loaded somehow but doesn’t replace the wrong one in the Materials Manager?

It would be useful to have an indication of the source in the Construction Manager too. What do you think @mingbo ?

I agree that this can be helpful.

Thanks @martin6, this is might be a bug in this Construction Editor. This UI hasn’t been updated since the very first version, and it is on my to-do list in the next round of refactoring.