true_azimuth is not implemented for sub-surface

[souliane]

"FenestrationSurface:Detailed" objects expose a "true_azimuth" property, but calling it you get an exception "BadEPFieldError: unable to find field Zone_Name".

Example:

In [42]: w
Out[42]:

FenestrationSurface:Detailed,
    B538CA,                   !- Name
    Window,                   !- Surface Type
    Exterior Window,          !- Construction Name
    96170A,                   !- Building Surface Name
[...]

In [43]: w.true_azimuth
---------------------------------------------------------------------------
BadEPFieldError                           Traceback (most recent call last)
/mnt/d/BST/bst/thesis/bstools/epluslib/scenario.py in <module>
----> 1 w.true_azimuth

~/.local/lib/python3.8/site-packages/eppy/bunch_subclass.py in __getattr__(self, name)
    301         try:
    302             func = self["__functions"][name]
--> 303             return func(self)
    304         except KeyError:
    305             pass

~/.local/lib/python3.8/site-packages/eppy/function_helpers.py in true_azimuth(ddtt)
     64     coord_system = idf.idfobjects["GlobalGeometryRules"][0].Coordinate_System
     65     if coord_system.lower() == "relative":
---> 66         zone_name = ddtt.Zone_Name
     67         bldg_north = idf.idfobjects["Building"][0].North_Axis
     68         zone_rel_north = idf.getobject("Zone", zone_name).Direction_of_Relative_North

~/.local/lib/python3.8/site-packages/eppy/bunch_subclass.py in __getattr__(self, name)
    323         else:
    324             astr = "unable to find field %s" % (name,)
--> 325             raise BadEPFieldError(astr)
    326
    327     def __getitem__(self, key):

BadEPFieldError: unable to find field Zone_Name

I use eppy version 0.5.53.

[santoshphilip]

I'll take a look

[santoshphilip]

@airallergy , Would like to take a look at this. This is mostly your code. I had forgotten what we did here. I think there were some limitations to true azimuth.

[airallergy]

Sorry for the late reply, I have been extremely busy lately. @souliane, can you confirm if or not .azimuth works on your end?

I managed to run a few tests myself and found that this error does exist because the codes were trying to identify the zone name of the surface in order to get the zone orientation. But subsurfaces do not directly linked to its zone, but its parent surface instead, meaning there is no zone name field in a subsurface object to be found, hence the error.

However some further tests reveal on my end that a bigger issue probably lies in the original .azimuth function, which somehow fails to calculate the subsurface's own azimuth. I am not quite familiar with that part of codes, so I am not sure whether .azimuth has some minor bugs, or it cannot be used to calculate the subsurfaces in the first place, or maybe it is just some issue that is only on my end. I need your feedbacks on this.

@santoshphilip, despite if there is indeed an issue with .azimuth to subsurfaces, a universal solution might be to somehow redirect subsurfaces to their parent surfaces, when they call .azimuth or .true_azimuth.

[santoshphilip]

@airallergy , It needs a solution to track the parent surface. I had put some thought into this a long time ago (a generic method for finding any parent)

I'll start to take a look into this. For the moment, let us say that azimuth does not work for subsurfaces.

[souliane]

Hello, .azimuth is working for me, but I have tested with only 1 model.

[airallergy]

@souliane, thanks for your reply, can you provide us a minimal working example idf file to run some tests? You can change .idf to .txt in your filename and then simply drag and drop it into the dialog box.

[airallergy]

@santoshphilip, may I ask what your current thinking on this is? I happened to run into some work just now that needs to track some sub sub objects to their zone name, a lot of loops seem a bit messy to do so.

[santoshphilip]

@airallergy I have some ideas on this. Would like some feedback. Give me a few days to think it thru so that I can present it with some clarity.

[santoshphilip]

@airallergy , I opened a new issue #337 to work this this topic. Take a look

[souliane]

I am sincerely sorry I didn't reply earlier and didn't send the sample IDF to reproduce the bug (I will spare you the details...).

But I think it is reproducible on any FenestrationSurface:Detailed, because it looks like the interface that exposes true_azimuth is not implemented at all for FenestrationSurface:Detailed.

For my project, I dealt with it this way: https://gitlab.com/souliane/bstools/-/blob/master/src/bstools/epluslib/edit_idf.py#L226 So I am basically returning the true_azimuth of the wall that is holding the sub-surface.