Dragonfly/Ladybug: Potential Bugs and Question

@SaeranVasanthakumar,

After looking at the DF Dragonfly component code some more, I have a few more questions.

  1. Through the DF Typology component, users can enter a value for the average height between floors, which is then passed into the Typology class’s from_geometry method under the argument floor_to_floor. I was wondering if this input is expected to be in meters or match the units that the Rhino file is in?

If floor_to_floor is expected to be in meters, in the geometry parameter calculation process, should we first convert floor_to_floor to match the units the Rhino file is in? I say this because in the Geometry class’s getFloorBreps method, where floor_to_floor has been renamed floorHeight, there exists the lines

fullRange = massBB.Max.Z - massBB.Min.Z
numCrvs = int(math.floor(fullRange / floorHeight))

In this case, I assume that fullRange is in the units that the Rhino file is in and floorHeight is in meters, but we want them to be in the same units. numCrvs will affect the floor breps extraction process, which will change our values for floor area and footprint area.

On the other hand, if floor_to_floor is expected to be given in the same units as the Rhino file, in the case that no floor_to_floor is entered, the default value of 3.05 is given to floor_to_floor. However, the units behind 3.05 is meters, so would we have to adjust 3.05 be a conversion factor to get it to be in the same units as the Rhino file once again?

  1. Instances of both the City and Terrain classes have the attribute characteristic_length. When a City object is created, its characteristic_length attribute is the same as its Terrain object’s characteristic_length attribute.

In the Terrain class’s area attribute’s setter method, characteristic_length is calculated as follows

self._characteristic_length = math.sqrt(self._area)

In this case, characteristic_length is the length of one side of a square with the same area as the actual terrain. However, in the City class’s building_typologies and update_geo_from_typologies methods, the site area is recovered by assuming that the characteristic_length is the radius of a circle that has area matching the terrain area.

site_area = math.pow(self.characteristic_length,2) * math.pi

Does this mean that when calculating characteristic_length in the Terrain class, the terrain area should be divided by pi before the square root is taken?

  1. In the City class’s update_geo_from_typologies method, there is the code
totalWeight = sum(floorAreas)
typologyRatios = [x/totalWeight for x in floorAreas]
self._building_typologies = {}
for i, key in enumerate(fullTypeNames):
      self._building_typologies[key] = typologyRatios[i]

In this case, _building_typologies is a dictionary that matches string descriptions of typology program, age to that typology’s floor area coverage fraction. However, in other references to _building_typologies, it is a list of Typology objects in the current City object (for example, in the building_typologies and from_typologies methods in the City class). Was self._bldg._type_ratios meant here instead?

Thanks.

@annasong good finds as usual!

For #1: I think you’re right. I actually assumed that Ladybug always just expects the Rhino doc to be in meters, but I did a search of the code and it looks like Chris has included a linear conversion factor here which means that’s not the case:

The conversion factor is for converting everything into meters, so in this case we just have to use the self.linearConversionFac on the fullRange variable.

Do you want to send this correction in as a PR to the DF repo? Otherwise I can do it as well.

S

For # 2: I looked into this, and the problem here is slightly more complicated then it appears. There seems to be a discrepancy from how the characteristic_length is described and how it’s used in the uwg, that we need to investigate further. More details here:

For #3: I think Chris would be the best one to take a look at this one, as I’m not that familiar with this method. Thoughts @chris?

S

@annasong and @SaeranVasanthakumar ,

Thanks for all of the detective work here. For 1, I tried to make it so that all core Dragonfly objects have properties in SI (meters) and all conversion to meters happens in the geometry class with all if the Rhino API calls. It seems like I might have missed this for the floor-to-floor parameter so we should fix this soon.

For 2. I put a response on the github issue, @SaeranVasanthakumar.

For 3., It might be best to see if this issue still persists after I clean up the DF code into it’s own pure python library. While I’ll be a bit busy in the next 3-4 weeks, I have managed to secure a good excuse of investing more time in the Dragonfly core so I should be able to finish cleaning it up soon after.