Grasshopper

algorithmic modeling for Rhino

[solved] can honeybee read energyplus results file not generated via honeybee?

Can honeybee read EP results component be used to read any energyplus results files not generated through the honeybee+ladybug approach?

I try to link a EP results csv file generated in other place (via openstudio+EP) with the honeybee component, and it doesn't work...

Thanks!

Views: 2628

Replies are closed for this discussion.

Replies to This Discussion

Hi Grasshope,

I have not tried it yet myself but there is a component called smth like "Ladybug Header". Ideally you can use that to add the required header to the csv file that Honeybee requires to recognise it as its own.

P.S.: The InTable file report of Openstudio will not work afaik.

Kind regards,

Theodore.

Grasshope,

The answer is yes so long as you are requesting outputs from E+ in a CSV format (OutputControl:Table:Style,Comma;).  You can do this with Openstudio and with most other E+ interfaces as far as I know.

All that you have to do is make a GH panel with the file address of the CSV and plug it into the "Read EP Result" component.  If you request outputs that are non-standard in Honeybee, the data will be brought in through the "otherZoneData" or "otherSurfaceData" of the respective result-reading components.

Also important, make sure that the folder that contains the CSV result file also contains the .eio file output from E+.  This is necessary to build up the header information on the imported E+ data.

If this is not working for you, please upload and example GH file with the issue and we will make sure it is fixed.

-Chris

Dear Chris, thank you very much!

However, I still got the "Failed to parse the results file." warning on the "read EP result" component when plug-in my own csv file generated from E+ simulation ...

Appreciate you can kindly help to see if my csv file is missing something to be read:

1. gh file:

https://sites.google.com/site/oatcracker2013/home/files/error_read_...

2. my .csv file

https://sites.google.com/site/oatcracker2013/home/files/A01_c_new.c...

3. my .eio file

https://sites.google.com/site/oatcracker2013/home/files/A01_c_new.e...

Much obliged!

Grasshope,

I put in an extra check that should ensure that the result reader now works.  I noticed that you generated the CSV file with an older version of the Honeybee components and this older version was not requesting the correct outputs for heating and cooling among a few others.  For this reason, a bunch of the results are coming in under the "oterhZoneData" output in the attached GH file.  You should update your HB components to the version on the github and generate a new CSV file if you want to avid this and have everything run smoothly.

-Chris

Attachments:

Thanks, Chris! Update solve the problem.

Now the readEPSurfaceResult component is not working, even if the eio file is put in the same folder as the csv file. Appreciate your advice!

Also, one of the zone-based output variable "Zone Ideal Loads Zone Total Cooling Energy [J](Hourly)" is not shown in the otherZoneData component.

It'll be great if other non-zone/surface based output variables such as "DistrictCooling:HVAC [J](Hourly)" can also be visualized in HB.

Attachments:

I think I have the same difficulty with the readEPSurfaceResult component. The readEPResult is working just fine, tho. 

Could it be because I hijack the simulationOutputs component and stuff in a bunch of other variables to report? This is a great, perhaps un-intended feature of Honeybee;) I use the extra variables in my post-processing. Obviously they aren't getting read from the csv (on purpose) by the HB components, but perhaps they screw with the parsing routine?

Conveniently, the script is on Hydra:

http://hydrashare.github.io/hydra/viewer?owner=NENEN&descriptio...

Nick,

If you are experiencing the same issue as Grasshope, see my response below.  You have to request that surface data be written into the eio file if you are using an IDF not generated with honeybee.  Do this by typing the following at the end of your IDF:

Output:Surfaces:List,
Details; !- Report Type

I appreciate you using hydrashare but your file is so vast that I don't know where you want me to look.  Can you upload one that just focuses on the error you are having?

-Chris

Let's see. The IDF is generated by OS via the HB component. I checked the idf, and the output command is in there. 

Here's the point in the file where the component comes in (at the scribble "VIEW SURFACE RESULTS"):

Rather than chop down the file, I disabled the large swaths of stuff that don't directly apply...which means the file is too big to attach here. if it's not coming through hydra, here's an old fashion dropbox link:

https://www.dropbox.com/s/xgqpo64e5871m2i/Xmas%20_5.3.1.gh?dl=0

Thanks for taking a look!

Grasshope,

Sorry that I never got back to you 3 months ago.  Your surface result component was not working because you did not request for EnergyPlus to write the surface information into the eio file (the eio file only includes zone information).  By default, the run simulation component requests this info in the outputs section of the IDF and you will have to do the same with your IDF if you want it to work with the ReadEPSurface component.

The total cooling energy should be coming through but it is written in the csv as "ILAS_ZONE_01:Zone Ideal Loads Zone Total Cooling Energy [J](Hourly)".

Do you know why the ILAS is in front of the Zone Name?  this is causing it to fail at the moment and, if this ILAS is a common thing written into IDFs, I can code in a way to deal with it.

Importing building-level outputs will be easy once we get the SQL result parser off of the ground.

-Chris

Nick,

The issue is that the OpenStudio component does not (by default) request outputs to be written into a usual CSV file.  You have to make sure that you have these surface outputs requested by enabling your "Generate EP Ouptput" component, which you see I have done in the attached feile.

Let me know if I am understanding your issue correctly.  I notice that you have a bunch of other stuff next to the generate EP Output component that seems to be referencing stuff on your machine.

-Chris

Attachments:

Chris hello,

For the sake of debugging, I turned on all the options in the "Generate EP Output" component in the GH script version you sent back. I also disconnected my external feed-in file that calls for even more variable outputs. (I also deleted out non-relevant stuff to make the script relevant to the current question).

So after eliminating any "weirdness" I could see, the component still throws an error. It occurred to me earlier that it might not be expecting the output from the OS component...rather that it was designed for the EP component, and there isn't likely a perfect correspondence between the IDFs and CSVs generated by the two (although you've done a noble job with it as far as I can tell). could this be an issue? 

The error from the ReadEPSrfResult component is "1. Solution exception:name 'duplicate' is not defined."

Is this a name of an object in the python code? I opened up the code and found the first instance of "duplicate" at line 275:

.........

#Make a function to check the srf name and type Name.
def checkSrfName(csvName, dataType):
srfName = None
duplicate = False

.......

Does this definiton come from outside the component code (library, HB, etc...?) This is currently as far as my programming knowledge can take me(!)

I re-attached my stripped down debugging GH script here if you want to take a look. 

Attachments:

Chris, some progress:

Although I haven't determined if it's the only thing happening, I figured out a thing that, if I change it, makes my problem with the readEPSrfResult component goes away:

On the ExporttoOpenStudio component, when I remove the input I had into the "workingDir_" input node, the readEPSrfResults works!

I had had this plugged in as the working directory: "C:\ladybug\HBOSM\"

The readEPResult component has always worked fine, but until letting the workingDir node default, I couldn't get the readEPSurfs to work.

So that's something to chew on... 

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service