EP Construction component issue after installing last release

Hello everyone,

After several days using the same definition with its energy simulation perfectly working, i have finally been asking yesterday night to update my instals of Honeybee and ladybug with no choice ( when components turn orange one after the other asking for the new version). I had been postponing this milestone to avoid instalation issues and here i am now.

When launching the simulation, the program pops up only a few seconds and finally exit before running anything.
The error messages seem to be related to the construction name of my floor which apparently is lost in the process and doesnā€™t appear in the IDF file :

" {0;0;0;0;0}
0. Current working directory is set to: C:\Users\Heavy\Dropbox\OSResultFiles\DDAYS\Test\0.winterDDay30.12PARISORLYFRA\OpenStudio

  1. Model saved to: C:\Users\Heavy\Dropbox\OSResultFiles\DDAYS\Test\0.winterDDay30.12PARISORLYFRA\OpenStudio\0.winterDDay30.12PARISORLYFRA.osm
  2. OSM > IDF: C:/Users/Heavy/Dropbox/OSResultFiles/DDAYS/Test/0.winterDDay30.12PARISORLYFRA/OpenStudio/0.winterDDay30.12PARISORLYFRA/ModelToIdf/in.idf
  3. Program Version,EnergyPlus, Version 8.5.0-c87e61b44b, YMD=2017.10.10 04:31,IDD_Version 8.5.0
  4. ************* IDF Context for following error/warning message:
  5. ************* Note ā€“ lines truncated at 300 characters, if necessaryā€¦
  6. ************* 224 BuildingSurface:Detailed,
  7. ************* indicated Name=floor
  8. ************* Only last 3 lines before error line shownā€¦
  9. ************* 225 floor, !- Name
  10. ************* 226 Floor, !- Surface Type

19 ************* 227 , !- Construction Name
20.
21. ** Severe ** IP: IDF line~227 Error detected in Object=BUILDINGSURFACE:DETAILED, name=FLOOR
22.
23. ** ~~~ ** Field [Construction Name] is required but was blank
24.
25. ** Warning ** IP: Note ā€“ Some missing fields have been filled with defaults. See the audit output file for details.
26.
27. ** Severe ** IP: Blank ā€œrequiredā€ fields found in input
28.
29. ** Severe ** IP: Out of ā€œrangeā€ values and/or blank required fields found in input
30.
31. ** Fatal ** IP: Errors occurred on processing IDF file. Preceding condition(s) cause termination.
32.
33. ā€¦Summary of Errors that led to program termination:
34.
35. ā€¦ Reference severe error count=3
36.
37. ā€¦ Last severe error=IP: Out of ā€œrangeā€ values and/or blank required fields found in input
38.
39. ************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).
40.
41. ************* Fatal error ā€“ final processing. Program exited before simulations began. See previous error messages.
42.
43. ************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
44.
45. ************* EnergyPlus Sizing Error Summary. During Sizing: 0 Warning; 0 Severe Errors.
46.
47. ************* EnergyPlus Terminatedā€“Fatal Error Detected. 1 Warning; 3 Severe Errors; Elapsed Time=00hr 00min 0.59sec
48.

After looking closer at the IDF, it is right that the material name isnā€™t filled at the needed line.
I first thought about a change in the naming logic of the component since i have an other one just above which is working well but sharing the same name between its EP_Window Material and the linked EP Construction component so i decided to try the same logic with my floor EPconstruction as well just to seeā€¦

However it hasnā€™t made any change and it didnā€™t brought my construction name back in the IDF file

Then i tried to update my components with the Ladybug_UpdateFile component wich asked me specifically to change the EP Construcion components manually which was prety weird since inputs/outputs remained unchanged and the proposed component added to mine was coming from the the same release exactly (0.0.62 JUL_28_2017)

Which i did once, then twice, then ā€¦ but each time the simulation fail remained and the Ladybug_update component asked me again to replace things manually with no change at the end ā€¦

I guess this is related somehow to components versions but i donā€™t know now how to deal with this and need to go back to work asap

here is a download link to a simplified version of the definition with the same issue:
https://www.dropbox.com/s/y1x7j6ox8k6sfxz/Simplified.gh?dl=0

Any help on this minor issue is welcomed !
Thank you very much in advance

For some reason the name of the construction of the floor is not written in the BuildingSurface:Detailed section, and this is a compulsory field. Can be a bug in your specific model (not having any walls).

But this happen with the exportToOpenStudio component. If i use the runEnergySimulation it is written and runs (i stopped since it will take a lot of time to finish. The model has 740 windows!!).
I assume @chris will check this, since it appears to be a bug.
In the meantime you can use the E+ component that works.

Another option, for now, that you may donā€™t like, is to install the stable released version from food4rhino. Or at least take from it the exportToOpenStudio and replace the updated one.
-A.

Thank you very much Abaraham,
You confirm my previous feeling of a simple stupid bug in the export. So it works also for me using directly the E+ component and iā€™m going to use it until @chris find some time to have a closer look on this issue.

It definitely may have something to do with the component version/update since this is the only one component that is systematically reloaded in my definition when using Ladybug_Update component and asked to be re-plugged manually.

But again thanks you very much, i can now deal with it without feeling crazy and go back to work without being stuck for nothing :wink:

@AbrahamYezioro and @edwinszabo ,

I apologize for this and it is likely a bug that results from me switching the OpenStudio component to use construction sets instead of assigning constructions to individual surfaces. I did this because assigning constructions to individual surfaces makes it nearly impossible to change constructions within the OpenStudio interface. More info on the reasons of this can be found here:

If you can post an example file that recreates the issue, I can fix this bug immediately. Otherwise, it may take me some time to recreate the error on my system since all of my OpenStudio models have been running correctly on my machine.

-Chris

Ah, wait you have an example file there. Sorry that I didnā€™t see it. Iā€™ll address it ASAP.

@edwinszabo ,
I see what is going on here. You have assigned the floor of your greenhouse to be a surface type ā€œ2-FLOORā€, which is really meant to be reserved for interior floors but OpenStudio still interprets this as an exterior floor. I have added some code that now catches this case and will make sure that the construction gets assigned:


Thanks for finding this case and you can find a working version of your file here:
Simplified_CWM.gh (635.8 KB)

Still, you should consider changing the parameters of your floor surface since the current values donā€™t make much sense. The way that you have set up your model right now has the greenhouse floating in the air (outdoor air can circulate underneath the greenhouse). If this is truly the case, you should set the floor to be surface type ā€œ2.75-ExposedFloor.ā€ I imagine that the real greenhouse is either sitting on the ground, in which case you should be setting it to be surface type ā€œ2.5-SlabOnGradeā€ or, if it is sitting on the roof of another building, you can keep the current surface type at 2 but you should probably set the EPBC_ to be ā€œadiabaticā€ to ensure no heat flow.

I hope this helps,
-Chris

1 Like

Thank you very much Chris for these informations.

Actually i will need to evaluate both the mentioned cases above : :

  • greenhouse on the ground,
  • greenhouse on the top of an existing building, and also
  • greenhouse with its own slab
    So it might be usefull to delve further into these various construction settingsā€¦

Besides, thanks also for the working file, but i still have a last practical issue for you : as i understood it you changed not only my current component but also the last github version of it to prevent further similar issues so i just have to update my old files with the Ladybug update component, right ?

However, even with your updated version of my GH file, when using the Ladybug_Update file component i still have the same previous issue of EPConstruction components added to my file and asked to be rewired manually although they are from the same instalation version : 0.0.62 of July.
Moreover, after doing so it lead my Create HBZone component to stop workingā€¦

I am quite a bit lost here on which Update component (Ladybugā€™s one or Honeybeeā€™s since the Ladybug Update file component seems to work now for both plugins) related to which version should i use as a daily updating routine to get the last updated Github components versions as i used to do before.
Your Honeybee update component from github has disappeared in this last version right ?
Do i have then to reinstall entirely the last version available on FoodforRhino to get rid of this EPConstruction component issue and benefit from your OS Component improvment ?

I currently have installed on my computer the latest version : Ladybug 0.0.65 and Honeybee 0.0.62, downloaded and installed the 9th of this month.
And also at the same time installed the HoneybeePlus and LadybugPlus.

Sorry for bothering you with what i guess are very basic instalation issues but i need to have it clear once for all and then keep going back to my work. Thank you in advance for dealing with these stuff :slight_smile:

OK, after updating things with the Honyebee component, my HBZone component is working back again.

So the only remaining issue is with the Ladybug_Update file component, still asking for a manual replacement of the EPConstruction components, even after having it done several times ā€¦

The component to use for updating is the LB_updateGHFile (or Ladybug_Update). Chris is considering to cancel the other 2 (updateLadybug and updateHoneybee).
The issue you mention with the EPConstruction is a bit annoying. The reason it happens is that the number of input/output items is different from the used component and the original/fresh one (say one input and three inputs respectively).
This happens with a couple of components more that change the names of the inputs/outputs in respect to the original one.

You can just ignore them when you are sure you have the latest in play.
-A.

Thank you Abraham for this pretty quick answer. Iā€™ll do it this way (ignoring it) from now.

If i understood well, the current logic of updating components directly from the github is about to be abandoned in favour of more frequent releases to avoid these so many small update bugs and compatibility issues betwen different components versions am i right ?

Not sure if i understood your question.
The update component allows you to update your scripts. So this is a Yes for your question.
What i do, if i want to be sure that i use the latest when inserting components or starting a new file, is visiting the github site and download the zip file with the updated files. I manually drop the in the UserLibrary folder.
-A.

Thanks @AbrahamYezioro for taking care of this and you were right to point out that these are all issues that arise when you try to keep oneā€™s components synced with the github. In fact, this whole issue of floor surfaces would not have been experienced in the last stable release. These are just the risks/rewards to staying synced with the github.

However, there are a few things that I have been thinking about changing to make it easier for those who want to stay synced with the github. Notably, I have started to get pretty annoyed with manually replacing the construction components, especially given that thereā€™s a zero chance that the inputs/outputs will ever change on the component. I think that I will add a list of components to exclude in the input check soon:

1 Like

@chris
Going deeper in the floor-greenhouse settings, i was wondering what is the best setting for taking into account a roof behaviour properly when the Greenhouse is air-insulated but l
How could i specify at the same time that there is no air flow coming from the outside of the GH, (which the Adiabatic does pretty well), but since it is just placed on the roof, manage to take into account the outdoor impact on the slab and thus on the indoor surface, since a roof slab is obviously impacted by weather conditions ?

Thinking about it, i asked myself if the propper setting couldnā€™t be something like that :

1- creating the ROOF SURFACE ( bigger than the greenhouse one) and setting it as an _ExposedFloor and Outdoors to get its thermal behaviour hourly

2- creating my GREENHOUSE FLOOR exactly the right size of the space, but with a custom tiny slab construction set as SlabOnGround and Adiabatic

3-Finding a way to assign the ROOF SURFACE as the referenced Ground for the GREENHOUSE FLOOR

Isnā€™t there a contradiction setting in 2_ my surface both as SlabOnGrade AND Adiabatic , should i rather left blanc the EPBC input ?
How could-i manage to assign the ROOF SURFACE as Ground ?

I hope my questions arenā€™t too bad explained and that you will understand what iā€™m looking for.
Thank you very much for spending your time on my case !

Hi

I have a similar issue: The export to openstudio component tells me this:

Current document units is in Meters
Conversion to Meters will be applied = 1.000
Current working directory is set to: c:\ladybug\unnamed\OpenStudio
Duplicate surface name! Name is changed to: Roof_Dup
Duplicate surface name! Name is changed to: Perimetral_adiabatic_walls_Dup
Duplicate surface name! Name is changed to: Perimetral_adiabatic_walls_2_Dup
Duplicate surface name! Name is changed to: Window_Dup
Duplicate surface name! Name is changed to: Roof_Dup_Dup
Duplicate surface name! Name is changed to: Perimetral_adiabatic_walls_Dup_Dup
Duplicate surface name! Name is changed to: Roof_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Perimetral_adiabatic_walls_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Roof_Dup_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Perimetral_adiabatic_walls_Dup_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Roof_Dup_Dup_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Perimetral_adiabatic_walls_Dup_Dup_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Roof_Dup_Dup_Dup_Dup_Dup_Dup
Duplicate surface name! Name is changed to: Roof_Dup_Dup_Dup_Dup_Dup_Dup_Dup
Model saved to: c:\ladybug\unnamed\OpenStudio\unnamed.osm
OSM > IDF: c:/ladybug/unnamed/OpenStudio/unnamed/ModelToIdf/in.idf
Program Version,EnergyPlus, Version 9.0.1-bb7ca4f0da, YMD=2019.02.26 17:32,

** Severe ** [BuildingSurface:Detailed][Window] - Missing required property ā€˜construction_nameā€™.

** Fatal ** Errors occurred on processing input file. Preceding condition(s) cause termination.

ā€¦Summary of Errors that led to program termination:

ā€¦ Reference severe error count=1

ā€¦ Last severe error=[BuildingSurface:Detailed][Window] - Missing required property ā€˜construction_nameā€™.

************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).

************* Fatal error ā€“ final processing. Program exited before simulations began. See previous error messages.

************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.

************* EnergyPlus Sizing Error Summary. During Sizing: 0 Warning; 0 Severe Errors.

************* EnergyPlus Terminatedā€“Fatal Error Detected. 0 Warning; 1 Severe Errors; Elapsed Time=00hr 00min 0.44sec

I have latest version of ladybug and honeybee.
As far as i understood, the problem is related to type of geometry, but it refers to the window, which is absolutely simple.

Which could be the issue?

Energy_Shade_Benefit.gh (737.5 KB)
Model.3dm (549.2 KB)

@kdm.nivek
This is the error

Double check where you created the construction, and set a name.

Hi. As you can see here i have assigned a name to it

So it seems to be exactly the same problem as the discussion.
@chris I wonder if itā€™s a geometry problem or an energy plus one.

From the image i wonder if you are not giving the wrong inputs: _HBObj and -childSurfaces?
Maybe they need to be swapped between them?
The HBObj is the thermal zone and the childSurface the window itself.
-A.

That was a test, because happend that sometimes this swap has solved my issues. anyway i stil get the same error.

Hi dear friend. did your problem solve? I have the same error in my construction ā€¦ and I do not know what should I do! could you please help me?