Struggled visualize the surface results

Hi every one,

I have finished my first energy simulation using the Honeybee, Finally, I could run the simulation, and I have used the "color zones by EP results" successfully, but when it came to the surface results visualizing and making "indoor radiant temp map" I stick !!

the thing is, I hooked up the "srfsData" and "HB zones" to the "color surface by EP results" and it went good ,so, I used the same parameters to run the "surface data based on type" but it showed an error,

In addition, the "indoor view factor was OK but when I use it to generate the "indoor radiant temp map" it also showed an error as attached below.

I am a very bigger with the data tree structures,so I tried disparately to trail and error by grafting and flatten lists, in some instances, errors turned into orange instead of red !

I hope someone can guide me through this..

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Abraham Yezioro on June 14, 2015 at 10:35pm

Will be helpful if you upload the file.
-A.

Permalink Reply by Yasin Mohamed Ibrahim on June 15, 2015 at 6:20am

Many thanks Abraham,

please find the files, I hope its not so messy ;)

Attachments:

02 postl simulation - KAIT simulation BUp.gh, 870 KB
KAITmodel.3dm, 2 MB

Permalink Reply by Abraham Yezioro on June 20, 2015 at 11:19pm

Hi Yasin,

Sorry for the delay checking this. The truth is that it took me a while becouse what you said: it is a bit messy :-)

See attached with a lot of updates, most of them manually since there were plenty of components updated lately that changed the number of input/output items. I marked them with black arrows so you can notice.

Another thing is that some of your constructions/materials had space and number in the name (for instance MetalDecking 130mm). HB doesn't like the number after the space, so i added a "_".

But most important: i didn't check if the file works. Sorry. I tried but it takes a lot of time, so i stopped it. You need to check this at your end, an hopefully it will work fine.

Let know.

-A.

Attachments:

02postlsimulationKAITsimulationBUp_AY.gh, 926 KB

Permalink Reply by Yasin Mohamed Ibrahim on June 25, 2015 at 6:25am

Dear Abraham

Many deep thanks for your time,

I ran the simulation, unfortunately the surface results remained unreadable , eg

* this is an error msg "1. None of the connected srfData could be matched with the surfaces in the connected HBZones."

* in addition, the surface results could be red by the " Surface data based on type" but could not by the " detailed one". and it showed this Msg "1. Solution exception:'Brep' object has no attribute 'upper'"

* compared to the earlier model, I noticed that the new simulation results have changed a bit, the zones tend to be more "sensitive to sun" as if it have a lower thermal capacity/ less thermal mass, meanwhile the cooling load is reduced!

* although I was able to collect the CSV files form the Run E+ component, the IDF file was showing this error "1. Solution exception:'NoneType' object is unsubscriptable" I thought the IDF file is kind of a early check up for the geometry before running the simulation, as in Chris tutorial (Chris tutorial no 7)

sorry for the very long Msg, I hope I find a way to deeply understand these results.

Permalink Reply by Abraham Yezioro on June 26, 2015 at 7:39am

Hi Yasin,

I did succee to pass some of the errors but not all of them.

See attached. I set your old Adaptive Comfort to the new components and it is running fine. Hope the results make sense for you.

Did not succeed in understanding neither the IDF import issue nor the srfDataByTypeDetailed. Here probably Chris could have a look.

Runtime is about 7 minutes for the E+ and 4 for the IndoorViewFactor in my laptop.

-A.

Permalink Reply by Abraham Yezioro on June 26, 2015 at 7:45am

And now with the attachment

Attachments:

02postlsimulationKAITsimulationBUp_AY1.gh, 932 KB

Permalink Reply by Yasin Mohamed Ibrahim on June 29, 2015 at 6:06am

Dear Abraham

many thanks pal, I learnt a lot from you.

I don't know if the Srfs naming is causing the "Srfs data based on type DETAILED" to fail.

Dup

one last favor please ;)

could you show me the way you update the components, I searched the discussions but I had no clue how to do it manually, eg updating the "generate E+ output" component.

regards

Permalink Reply by Abraham Yezioro on June 29, 2015 at 9:39am

Hi Yasin,

I'm doing a debug process in your file. Found some "bugs" and fixed them.

To make it short, see attached for, i think, a working version (all but the HB_srfDataByTypeDetailed which is still complaining about "1. Solution exception:'Brep' object has no attribute 'upper'").

You gave me a hint about the possibility that the names are the cause of the problem. So i connected a HB_LabelSurfaces component to check that. The component became red at the final zone level definition. So i started to connect it to each zone in order to identify the one(s) that are making trouble. The one is the NorthEast. After checking different possibilities i solved it changing the tolerance in Rhino to 0.001, and disabling/enabling all zones (see blue arrows). That solved the problem (!!). See in the attached the big red arrow and comments for more information.

After that everything is almost working fine.

I disabled the context geometry which is making the simulation time to be so high. So you need to enable it.

That's it. Besides the HB_srfDataByTypeDetailed everything is working well. I flattened the data input. But the results you get are only for the airwalls. So don't know what to suggest here.

Regarding the update question. See the top left corner, yellow group. You need to toggle those elements to true. This should do the work most of the times. But it happens that some components change the number of input/output items or their names. For those cases you need to reinsert them. No work around for that.

Hope this helps,

-A.

Attachments:

02postlsimulationKAITsimulationBUp_AY2.gh, 1001 KB

Permalink Reply by Chris Mackey on June 30, 2015 at 8:04pm

Yasin and Abraham,

I am sorry for coming so late to the discussion and thank you, Abraham, for taking care of practically all of the issues thus far. You are truly the community guru :)

The issue with the HB_srfDataByTypeDetailed was a bug that I have just fixed in the attached file. Thank you for finding it.

I noticed that the GH file had some issues caused by having certain components in front or behind each other on the canvass in the incorrect sequence. This type of issue can usually be fixed by selecting the components that should be run first and hitting "Cntrl +B" and I think that I have fixed this in the attached file.

The issues with a mis-match between Rhino model tolerance and internalized geometry tolerance are, unfortunately, things that we don't know how to work around yet (I feel that the Grasshopper team at McNeel should put in a check for this when opening a GH file where this could happen). In the meantime, I commend your instinct in checking the tolerance, Abraham.

When we get to the next stable release, I will put up a video on syncing with the github since I have realized a lot of people want to do this.

-Chris

Attachments:

02postlsimulationKAITsimulationBUp_AY2_CWM.gh, 989 KB

Permalink Reply by Abraham Yezioro on June 30, 2015 at 11:39pm

Thanks Chris,

Regarding the tolerance: What about to code it in HBHB+LB_LB to be "always" 0.001?

It is kind of annoying. I didn't find a way to set this permanently in Rhino, so you don't have to set it every time.

Attached a bit updated version than Chris's.

Yasin, you need to update manually all the comfort maps at the bottom right of the file. All the components get changed yesterday and the automatic update can't deal with them.

-A.

Attachments:

02postlsimulationKAITsimulationBUp_AY3_CWM.gh, 991 KB

Permalink Reply by Chris Mackey on July 1, 2015 at 12:48pm

Abraham,

Having an official LB+HB tolerance seems to be a bit dangerous. From the perspective of Ladybug, this is clearly a conflict since we still want to support work in several types of unit systems and people are likely going to want a different tolerance depending upon the units used. In Honeybee, it is less of an issue but it still seems dangerous. Now I am wondering if EnergyPlus has a model tolerance and if we need to take this into account as well.

To deal with the mis-match between GH and Rhino model tolerance, I have started a discussion with the broader community:

http://www.grasshopper3d.com/forum/topics/mismatch-between-rhino-mo...

Once we get some thoughts from the GH gurus, I imagine that we can make a better decision. Do you know if E+ has a tolerance or if there is a way to set this?

-Chris

Permalink Reply by Abraham Yezioro on July 1, 2015 at 2:11pm

Hi Chris,

As far as i know E+ "eats" everything. No tolerance issues or settings to do. More than that you can have unattached walls in a zone, or even "flying" windows, and it still runs.

-A.