Building program workflow

Replies to This Discussion

Permalink Reply by Abraham Yezioro on October 18, 2014 at 8:59am

I would add that the midRiseApartment program is faulty (in the case i'm testing). The simulation fails using this program. Changing to any other it runs ok.

It says:

1. Failed to find NONE in the Honeybee schedule library.

1. Solution exception:'NoneType' object has no attribute 'lower'

Permalink Reply by Chris Mackey on October 18, 2014 at 4:31pm

Abraham,

I know why this happens and I will say that it is intentional but I also think that it might as well be a bug since I have seen so many people mess this up (including myself in the public videos that I put up) such that I think we should change it.

The Mass2Zone component has traditionally required you to input a full list of values for the zoneProgram, the zoneNames, and the isConditioned, that matches the length of the zoneMasses list.  However, everyone who uses this component expects to be able to plug in a single value for the zoneProgram and have it apply to all of the connected zones.

Accordingly, I have just re-written the component and posted it to the github.  The component will now assign the zone program to all zones when a single value is connected and, if you plug in a longer list of values that does not match the length of the zoneMasses list, the component will give you a warning to let you know that it is assigning a default zoneProgram, zoneName, or isConditioned value.

This is such a serious issue that I think it merits changing all of my example files and changing this component in the userObjects folder at the app.box link.  I am going to do this now.

Thanks for reporting this, Abraham.  I had known about the issue but the full magnitude of how serious it is did not hit me until you posted.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 18, 2014 at 9:44pm

Thanks Chris!

Abraham, We went back and forth on this couple of times. I assume what Chris just did should make it work as expected.

Back to None problem for residential that look like a bug in OpenStudio JSON file. I am far behind of updating the JSON file and I assume they have already fixed that as I reported the issue few months ago. For now you can use setZoneSchedule and fix the issue by applying your own schedule for the NONE schedule.

Mostapha

 

Permalink Reply by Abraham Yezioro on October 19, 2014 at 2:52am

Hi,

Thanks for your both replies.

I get it to work. I added a NONE schedule in my custom definitions.

I have a couple of issues, not exactly related to the discussion subject, but still, i'll write them here.

Attached the file i'm using and my custom definitions IDF, so you can test also.

1. In the isConditioned input i gave a list where one zone is not conditioned and the other 5 are. The ColorZones component is failing (1. Solution exception:index out of range: 5) - see point 5 in the file. The reason is that it is expecting that all zones are conditioned. When i input temperatures (for instance) it works fine. How you suggest to work out this (very) possible situation?

2. Naming and assigning a list for the zones (point 1 in file) in certain order is not consistent with the order i can show the different zones (for instance point 7 in file). Is there a way to have more control in the naming and programing a zone (besides doing one by one)? Or any other suggestion you have for this file wil be welcomed.

Thanks,

-A.

Attachments:

• H_Bldg1.gh, 416 KB
• userCustomEPLibrary.idf, 26 KB

Permalink Reply by Abraham Yezioro on October 19, 2014 at 7:42am

Hi again ... and sorry for asking so much.

I have another issue here. I'm changing the construction materials with the setEPZoneCnstr component (according to video 16, i think) (see point 4 in attached). So far so good. Simulation is fine.

The issue happens with the RadiantTempMap component when i connect the HB_Zones with the output of the setEPZoneCnstr component. Then i get the following message (see point 8 Bad):

1. For one of the meshes in the _viewFactorMesh, the number of faces in the mesh and test points in the _testPtsViewFactor do not match.
This can sometimes happen when you have geometry created with one Rhino model tolerance and you generate a mesh off of it with a different tolerance.
Try changing your Rhino model tolerance and seeing if it works.

When the connected zones coming from the output of point 3 in file it is OK.

(You need the Custom file from my previous message).

Any ideas?

Thanks,

-A.

Attachments:

• H_Bldg1.gh, 446 KB

Permalink Reply by Mostapha Sadeghipour Roudsari on October 19, 2014 at 1:00pm

This is also a question for Chris. I think you guys have been through this issue once. Chris, let me know if you want me to take a look at this.

Permalink Reply by Chris Mackey on October 23, 2014 at 12:55pm

Abraham,

Sorry for getting back so late.  Very busy week with midterms here.  I have this whole weekend blocked off for updating, though :)

1. I just fixed the bug in ColorZones such that you can now connect up lists of data that do not include values for all connected zones (and vice versa).   Everything should be good now in these cases (see attached image of my parent's house with an unconditioned attic).

As for the issue with the MRT temperature map, I am looking into it now.  Will post back shortly.

Attachments:

• Fixed Unconditioned Zones.PNG, 81 KB

Permalink Reply by Chris Mackey on October 23, 2014 at 12:59pm

Ah I read a bit more in the discussion and realized why the Viewfactor component was not working correctly for you.  I just uploaded a new user object that always flattens the zones by default.  This should prevent future users from experiencing the same problem.

Permalink Reply by Abraham Yezioro on October 23, 2014 at 2:55pm

Thanks Chris,

The ColorZones is ok now but ... ColorSurfaces and RadiantTempMap

complain about:

1. Solution exception:'tuple' object has no attribute 'startswith'

-A.

Permalink Reply by Chris Mackey on October 24, 2014 at 12:09am

Oh gosh.  This was because of some new code that I put in to deal with a stream of raw data that I was bringing in from a field study.  I just uploaded a version of these two components that is fixed now.  I think that I am going to make a new component for Ladybug that allows you to construct a custom Ladybug header for any data set.  This way we get easy compatibility with other GH tools and raw data that people might bring in from instruments.  I tried to make something to accommodate this inside our current components and this was not the right way to go.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 19, 2014 at 12:59pm

Hi Abraham,

1. This is a bug in ColorZones. It happening because when you read the results no result will be available for branch 1, and the component doesn't consider this and fails mapping the values on the zones. Chris is the one who really knows about the component so I leave it to him.

2. I can't see the issue. The naming is consistent on my system. You need to help me with this to get it right! :|

Mostapha

Permalink Reply by Abraham Yezioro on October 19, 2014 at 1:30pm

Thanks Mostapha,

Yes, we discussed the RadiantTempMap before. It was related to the model tolerance. But i don't think it is the problem now, because what i wrote above.

As for point 2. Let's take for example the zone named "Core". It is the 3 in the list of the names at point 1 in file (the same for all other properties there). But it is the second in the brep list. It is like all zones are shifted by one, geometries and properties. I just played wit the order so it will fit.

-A.

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