Radiant Temperature Map °C too high during night

Replies to This Discussion

Permalink Reply by Max D on July 27, 2016 at 1:38am

Hi Chris,

I completely rebuilt the script by hand without copying any components, using the latest github synch'd files. - and I still get the error on two different machines. Even when I just use one single box brep from the test file.

You said it might have something to do with duplicate surface names, could you point me to how I can diagnose and bug fix this, as I'm unsure about what's going on in the backend of things?

Best,

Max

Permalink Reply by Max D on July 27, 2016 at 4:29am

The reworked file is here attached!

Attachments:

• VM_SD_01_cond_origBuildups_lowGsky_veranda_mainframe_CMAP_HBEErev07.gh, 761 KB

Permalink Reply by Max D on July 27, 2016 at 8:30am

.. and yet another update; tested it on a third machine, completely different OS (Vista) and setup- same error. Once you omit the programme assignment part of the script, it seems to work- definitely something to look into, here, or I have an error in the setup.

m

Permalink Reply by Chris Mackey on July 27, 2016 at 4:37pm

Max D,

I appreciate the effort in updating and for sticking with the issue.  We will get to the bottom of it somehow.

There were a few things incorrect about your file:

1) You did not intersect masses before solving adjacency.  As a result, you got adjacent surfaces that did not match in area and a simulation where conservation of energy was not obeyed.

2) The 'Set Ideal Air Parameters has been phased out as per this discussion:  .  I have implemented all of your specifications correctly using the new components in the attached file.

3) You specified a solar distribution of 1- FullExterior and this is not suitable for detailed comfort studies where you really want to know how the solar energy is distributed through the space. 

I corrected all of this in the attached file but, even without changing all of this, I still got the same result that I did earlier:

I just cannot reproduce your error on my machine.  The images that you post seem different from that which is int he GH file that you sent.  Are you sure that you are sending me the right version of the file.  Also, could you send me your userCustomLibrary again (I was using your old one from here)?  Finally, do you have any other GH files open when you expereince this error?

-Chris

Attachments:

• ComfMap_CWM.gh, 781 KB

Permalink Reply by Max D on July 29, 2016 at 3:37am

Dear Chris,

many many thanks for looking at the file again- ah yes, sorry, I had no idea the ideal air system component was going to be phased out. My bad for not intersecting first- script was originally used on the pre-intersected multizone file, which also needed the full exterior distribution only.

Running your revised version now on these machines here, the result is identical to the one you posted above (below screenshot from run on my machine; and yes, the last GH file I sent is the one from which the previous screenshots originated)

(CMap result from your attached script ComfMap_CWM, ran on MD machine)

That is, incidentally, identical to what my script produced even before your changes!

In an earlier post, you showed a result image that comes much closer to what I would expect the output to be (so, in fact, you have already produced two different results):

(screenshot from your earlier post on July 11, 2016 at 10:05pm)

The "error" I was/am hence chasing is in the difference between these two results. The last screenshot from your earlier results shows a radiant temperature dropoff that is much more in line with the contribution of the cold glazing temperatures as evident in the E+ results. What do you think?

Apart from that, I am glad that now, at last, our outputs from the same script are identical on both machines. The usercustomLibrary has not changed, I have however attached it again. Other GH files are usually not open, no; the last results all came from single open file GH instances.

Thank you for your help again Chris- it's an interesting issue. I owe you a beer (or a few) should you stop by in Berlin one day!

Best,

Max

Attachments:

• userCustomEPLibrary.idf, 9 KB

Permalink Reply by Abraham Yezioro on July 29, 2016 at 6:24am

Just pay attention that the hour(s) of the simulation are different. Then the results are different, of course.

-A.

Permalink Reply by Max D on July 29, 2016 at 8:08am

Hi Abraham,

true, but comparing the outputs of either at 4 am or range from 4 to 6 am, there is actually no difference, that's why I disregarded that and did not bother to update the actual range in the comparison images.

m

Permalink Reply by Chris Mackey on July 29, 2016 at 9:38am

Max,

I remember checking and the reason why the window was not so cold seemed to do with the fact that you had a very low U-Value for the window in your userCustomLibrary.idf.  You also had a somewhat poor R-value for the wall, resulting in more of a wash of temperature.

Please check this and let me know if you agree.

-Chris

Permalink Reply by Max D on August 1, 2016 at 2:07am

Hi Chris,

the window U value is 0.85; walls are at 0.17.

E+ constructions - windows and wall 

So the windows are, in fact, colder than the walls (by roughly 4°C) - see image below.

E+ data of average inner face temperatures (from 4 to 6; at 4 is similar)

I checked this early on to cross-reference it with the comf map outputs, and that's what led me to suspect something weird may be going on with them. 

When you once again omit the schedule, air change and system setting assignment part of our script, you get the below comf map results:

Comf map output of CMAP script with ideal air / OS system, schedule and ac/h script section bypassed

When you set the programme in the CMAP script to Office:OpenOffice, you get an similar output:

Comf map output of CMAP script with ideal air / OS system, schedule and ac/h script section included, with Office:OpenOffice programme set

Once I switch to the MidriseAppartment:Appartment programme, even with the ideal air / OS system parameters bypassed in the script, I get the following:

Comf map output of CMAP script with ideal air / OS system, schedule and ac/h script section included, with Appartment schedule set (same output whether ideal air part settings excluded or not).

Having stared at this "the men who stare at goats" style for quite some time now, I think I see the pattern now; the difference between the apartment and office programme is in the loads, etc. which mods the surf temps, which changes the distribution (and that one result you had that looked totally different did not reappear).

As for the 'wash' of temperatures- yes.. granted, the U value of the glazing is pretty good; the spread of temperatures we are looking at is only about 0.3 degrees, on average.

Maybe that simply *is* the distribution, and the E+ radiance temp output snapshot leads me down a false cognitive avenue, priming me to expect a different distribution than actually present?

Best,

Max

Permalink Reply by Chris Mackey on August 1, 2016 at 2:18pm

Max,

I am incredbily sorry that it took so long for me to get to this point but I think what I am about to say will come as good news.

I dug a deeper into the code and I found a major bug from before the time when Mostapha standardized the naming of glazing surfaces.   In the early days of Honeybee, Mostapha did a lot to enable the running of very complex glazing surfaces through E, which involves the breaking up of the window into smaller triangles and quadrilaterals (since the core of E+ does not understand window geomtries other than rectangles and triangles).  It took a while for us to standardize the names of the glazing pieces such that we can take all of those small windows and assemble the results back into the one window in Rhino.

As a workaround at the time, I added in this very hacky code, which caught (what I thought were) all of the cases where the surface names did not match perfectly.  In your case, however, it completely backfired and confused the window surfaces with the corresponding wall surfaces that they are a part of.

We didn't notice the bug until now because it affected so few cases.  Needless to say, I have fixed it now and all of the results that I get during the night time make sense:

I attached the fixed file and let me know if this clears up everything on your end.

Thanks again for you persistence with this.  Because of your efforts, many people were saved from a difficult-to-detect bug.

-Chris

Attachments:

• ComfMap_CWM_FIXED.gh, 780 KB

Permalink Reply by Max D on August 2, 2016 at 5:45am

Dear Chris,

many many thanks for digging into this so deeply, that result does indeed look more like the real thing. It also works as advertised on the local machines here :)

I will try to run it on the 40+ zone model as well, will share that with you once it's done. Very happy the time and effort (much more yours than mine!) has paid off for both of us and the community! I'll be in touch soon & thanks again,

Best,

Max

• ‹ Previous
• 1
• 2
• Next ›
• Page