Grasshopper

algorithmic modeling for Rhino

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

Views: 1376

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

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

Attachments:

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! :)

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

Attachments:

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.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service