Radiant Temperature Map °C too high during night

Hi all,

I have a weird error and am wondering whether anyone saw it before.

Running a single hour radiant temp analysis during the nighttime, highly glazed space, subarctic climate gives me the attached output- basically higher radiant temps near the glass than inside of the zone.

I don’t think this can be- advice on what I might have configured wrongly?

Thanks!

Max




MaxD,

The sun is up all of the time in December if you are below the antarctic circle.

If that does not explain it, please upload the GH file and the epw that you are using.

-Chris

Hi Chris,

I re-checked, but irradiance is nil in the weather file for that indicated date.

I’ve attached the script and EPW, maybe you can make sense of it!

Thanks a lot & kind regards,

Max

VM_CD_02_cond_origBuildups_lowGsky_veranda_mainframe_CMAP_HBEErev06.gh (1.15 MB)
RUS_Moscow.276120_IWEC.epw (1.48 MB)

Hi Chris,

I re-did the exercise with a simple box and have come to the same results- there’s either something wonky in my setup or something strange is going on.

See screenshots below; rad interior glazing surf temp output shows <= 14°C, however the radiant temperature at identical time step is shown as higher close to the glazing than to center of zone. Still does not tie in with my mental picture of how the calc works. Any thought what could go wrong here?

Best,

Max

Chris, sorry to continue spamming this thread- however, in the originally attached script, when you skip the zone ideal air loads etc. setting section and run it, you get a radiant temp distribution as expected. That is still weird, however, given the surface radiant temperature output as shown above.

Best,

Max

MaxD,

I am sorry that it has been taking me so long to get through your file. It’s such a big one and I have had it up on my machine for the last 2 days checking various parts of it in between new development. The fact that you have your cooling setpoint below your heating setpoint means that you will always have the cooling and heating system running at the same time, which is bound to give you weird results:

If you upload the simpler 2-zone file, I can look deeper into the issue but the old file is just so large that it would take me too long to track down the specific error.

-Chris

Hi Chris,

thanks for looking into this, really appreciated. I wonder what you mean, though- the cooling setpoint is above the heating setpoint in the file. That should not trigger coincident operation, no? Unless my brain is totally borked (maybe).

coolingSetPt [Optional]
A number or list of numbers that represent the thermostat cooling setpoint in degrees Celcius. The cooling setpoint is effectively the indoor temperature above which the cooling system is turned on.

heatingSetPt [Optional]
A number or list of numbers that represent the thermostat heating setpoint in degrees Celcius. The heating setpoint is effectively the indoor temperature below which the heating system is turned on. This can be either a single number to be applied to all connected zones or a list of numbers for each different zone.

I’ll upload the simple boxes definition tomorrow- or you will have convinced me by then that my logic is wrong! :slight_smile:

Best,

Max

Chris,

I’ve attached the box file with internalized data. Also see the screen shot below, simultaneous heating and cooling does not seem to be the problem. This continues to be a very interesting problem!

Best,

Max

VM_CD_02_cond_origBuildups_lowGsky_veranda_mainframe_CMAP_HBEErev06.gh (1.15 MB)
userCustomEPLibrary.idf (25.8 KB)

Hi Chris,

I am by now sure it has something to do with the set ep schedules component- in the ideal air / setting loads module part of the script, isolating it fixes the error. Don’t know yet what causes it, exactly, as the schedules come directly from the midRiseAppartmentSchedule.

Best,

Max

Hey Chris,

one final update on this for now- the error is with the MidriseAppartment Schedules- if you pick an office one, the error goes away.

Strange, as I can’t seem to figure out where it’s coming from within the MidRise Schedules, maybe you have an idea.

Best,

Max

Max D,

I ran your last box file and I did not get the same result as you. Everything seems to be making sense on my machine:

This is with the midrise apartment program. My guess is that it does not have to do with this shcedule but something else related to the matching of the data to surfaces by name. Let me know if you are able to get it to come up again. Generally, I think that cleaning up your GH file will help you error find the error or just get rid of it.

-Chris

Hi Chris,

ah, that’s good news then- I will probably have to update all components and re-jig the script completely;

did you change any of the workflow / arrangement of script hierarchy or just used as-is?

Best,

Max

Max. It was as-is. I’m not sure what was going on with your machine. It seems as if there were somehow duplicate surface names.

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

The reworked file is here attached!

VM_SD_01_cond_origBuildups_lowGsky_veranda_mainframe_CMAP_HBEErev07.gh (761 KB)

… 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

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

ComfMap_CWM.gh (781 KB)

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

userCustomEPLibrary.idf (25.8 KB)

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

-A.

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