MicroclimateMap termination error

Replies to This Discussion

Permalink Reply by Chris Mackey on May 9, 2017 at 6:43am

Aris,

Your file is running perfectly fine on my machine (although it takes a good half-hour to run all of the way through).

My guess is that your issue happens because you might be trying to create HBZones separately from your EnergyPlus results and these two really need to be done together.  This is because the microclimate maps work by matching the names of the HBZones and surfaces to the results of the EnergyPlus model and these can get out of sync if you re-generate HBZones and don't rerun them through E+. So, if you run everything in your script together, it should work.

I also know that outdoor microclimate maps are time intensive and they are really built for cases where you need a lot of freedom to test different strategies and geometries (like all of the strategies E+ can run and all of the geometries that Rhino can create).  If you are ok with the simplification of ENVI-MET's pixel world, you don't need to test strategies beyond the usual ones, and your test area is small enough to be accommodated by ENVI-MET's free license (I forget how many pixels by how many pixels it allows), Antonello has built a connection from Ladybug to ENVI-MET that he posted here:

http://www.grasshopper3d.com/group/ladybug/forum/topics/lb-envi-met

Cheers,

-Chris

Permalink Reply by Abraham Yezioro on May 9, 2017 at 8:23am

Just to make Chris comment on ENVImet, it doesn't work on pixels but with grids. The free license allows 100*100*30. The size range for the grid can be from 0.5 to 10 mts.

ENVImet is also time consuming ...

May i ask here, what are the compromises you can allow from the Energy point of view if you are interested only in the external microclimate? Maybe instead of multiple zones per floor, per building, define only one zone per floor?

Maybe a wish for the future, input external wall temperatures from data, instead of calculating the whole energy model?

Makes sense?

-A.

Permalink Reply by Aris V on May 10, 2017 at 2:51am

Chris,

Indeed at some point I directly referenced the microclimatemap to the E+ results file to save time. I took a number of actions (deleted folder with generated files, updated HB,LB, reloaded grasshopper, deleted and added new microclimatemap component) and the problem persists. Meanwhile, surface temps are mapped in the correct order.
As a side note, an earlier version of the posted gh def. could run the component although the model was technically full of errors (eg: Building masses were not intersected). It also returned the same result when grid resolution was set at precisely 1m which is also weird.

I will also attempt the approach suggested by Abraham. Assuming that the internal spaces are always conditioned and we are only interested in the external wall heat balance, one could theoretically create one superzone and subdivide the surfaces of interest near the pedestrian level. This way the surface temp. results can also inform a CFD analysis using butterfly.

Aris

Permalink Reply by Chris Mackey on May 10, 2017 at 6:50am

Abraham,

Those are all very good points and you are right that my use of the term"pixel world" was very unscientific.  "3D" grid is much more appropriate.  All of those methods for simplifying the model are good ones.  The super-zone idea is actually probably good enough for most outdoor comfort situations but you likely want to assign internal loads that sum to the total internal heat gain over the number of floors of the building.

On a side note, you can actually plug in custom surface temperature data into the microclimate maps and I have done it before using surface temperatures that I measured form an experiment.  You just need to label all of your HBSrfs and coordinate that labeling with headers that you put on the custom data.

Aris,

Are you saying that you were not able to run the GH file that you uploaded here and get the same results as I did?  If so, maybe there's an error on your machine and we can try to investigate further.

-Chris

Permalink Reply by Abraham Yezioro on May 10, 2017 at 7:00am

Thanks Chris,

I think the "super zone" is not a very good idea, specially if you have a tall building. In this way you'll get only one temperature per surface out of E+. I believe that the MRT calculation can be a bit of erroneous for such cases ... or at least, too gross/coarse.

I suppose that a "mid super zone" can be better (maybe one zone per floor or every 2 floors).

Nice that measured temperatures can be customized and used. One day i'll try.

-A.

Permalink Reply by Aris V on May 10, 2017 at 7:25am

Chris,

Yes, even with no stored/internalized geometry and data the problem persists. I'm 100% sure that the component was able to run in an earlier gh definition (see pic) but only with grids with dimensions different than 1m precisely (or larger?...i don't remember). I will try to run the same definition in another machine if possible tonight.

Abraham,

You can subdivide any honeybee surface into smaller ones and then join them into a zone, like Chris' hydra examples with EP ground zones. Since conditions inside the superzone are stable, assuming an ideal HVAC system and schedules, each subdivided patch of zone surfaces will yield a different Tsurf result based on the external heat balance and internal temps. Theoretically this freedom to describe surface patches in more detail can speed up calculations and provide better results.

Attachments:

• Frame_00012.png, 175 KB

Permalink Reply by Abraham Yezioro on May 10, 2017 at 7:41am

Yes Aris,

I forgot about this option.

I guess the "best" solution will be per case. The openings in the facades make a difference with the hydra case (which was divided in the opaque surfaces. But this is a matter of thinking the best way to do it.

Great.

-A.

Permalink Reply by Chris Mackey on May 10, 2017 at 3:38pm

Abraham, Aris already pointed it out but you are right that I would not recommend modelling a tall building with one surface per facade.  You would want to at least subdivide the facade floor-by-floor and possibly within each floor facade if you want to capture the effects of sun falling in different parts of the building.  Also, as I mentioned earlier, one really should try to match the internal loads of the "one-zone building" with that of the fully detailed one.  Finally, it goes without saying that this "one-zone building" method is really only for outdoor studies.  Any time that you want info about the interior of a building (like heating/cooling or indoor thermal comfort), you should model the building with at least one zone per floor.

Aris, keep us posted as you try to recreate the error.

Permalink Reply by Abraham Yezioro on May 10, 2017 at 4:01pm

Yes Chris. Thanks.

You can stress this in tomorrow's webinar ... that i'll see on recording ... :-)

-A.

Permalink Reply by Aris V on May 12, 2017 at 10:48am

Chris,

Firstly, I would like to thank you for your informative webinar on microclimate analysis yesterday.

Regarding the problem in question I'm inclined to believe that it is not a system issue since both yesterday's street example and another very quick test I did on the same machine ran fine. It may have to do with:
(i) either improper geometry generation, as I already intersected some of the common surfaces manually in sketchup and then did the rest with the intersect masses tool.  E+ throws an error about 2 surfaces that do not calculate insolation properly which I have yet to detect. The updated honeybee openstudio component even refused to provide the resulting in.csv file address although one was generated (it returned null instead although the old one would be ok).

(ii) or perhaps an issue of mix and matching old and new hb components, which is just speculation till now.

Two other issues I detected:

1)  When using the PET recipe, MicroclimateMap produces the following error: Solution exception:global name 'PETComfMtx' is not defined. This happened on yesterday's street gh definition I tried to play with.

2) In both UTCI and PET recipes: the description of cloAbsorptivity that appears on rollover is misleading as it refers to radiation reflected off of the ground. I suppose the description in the code for clothingAbsorptivity_ is the correct one.

-Aris

Permalink Reply by Chris Mackey on May 12, 2017 at 4:47pm

Aris,

I am glad that you found the webinar informative and thanks for tuning in!

Your explanations sound very plausible.  I wouldn't worry too much about the E+ insolation surfaces as that should throw off your calculation too much and it's usually easy to correct once you look over your model for L-shaped surfaces.

Thanks for finding the incorrect cloAbsorptivity description in the comfort recipes.  I just fixed it:

https://github.com/mostaphaRoudsari/honeybee/commit/bf4ec8ee115e0c8...

I'll see if I can recreate the issue with the PET recipe now.

Permalink Reply by Chris Mackey on May 12, 2017 at 5:35pm

Aris,

I was able to recreate the issue with PET and it turned out to be a small typo.  It is fixed now:

https://github.com/mostaphaRoudsari/honeybee/commit/eba231d656d77dc...

Thanks again for finding and reporting these issue!

-Chris