algorithmic modeling for Rhino
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!
Tags:
Replies are closed for 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
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.
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
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.
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...
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by