Since this happens across honeybee and it's extensions a lot, it seems worthwhile to have one method that all of honeybee and its extensions reference.

According to @mostaphaRoudsari , this is the most concise way of doing this:

dup = [t for t, c in collections.Counter(obj.identifier for obj in objects_to_check).items() if c > 1]

@AntoineDao FYI: https://travis-ci.org/ladybug-tools/honeybee-core/jobs/540818555#L616

Not sure why this is happening as the set-up here is almost identical to set up for other libraries. It happens when it tries to execute deploy.sh.

I checked file permissions and it looks right to me. I can also run the script locally.

See here: #10 (comment) and here: #10 (comment)

Use ladybug-geometry library to add self.geometry to Face.

I'll should just be a try/except that treats the absence of the object's energy properties the same way it does when object's energy properties are null.

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Yes, I can confirm that you broke the honeybee-core module in ironpython.

I realize this isn't quite a sensitive as breaking one of the ladybug modules since honeybee-core really isn't being used by the plugins yet. So I guess we don't have to immediately revert but we probably shouldn't let this be this way for that long (if only to still allow ourselves the ability to test the new honeybee in Rhino when we need to) so let me know how you want to proceed.

Originally posted by @chriswmackey in #19 (comment)

We should add a host of commands to generate models with typical floor plans like:

• L-plan
• 'H-plan`
• T-plan
• cross-plan
• regular-polygon-plan
• rectangle-plan-gable
• rectangle-plan-hip

Once I get some time and I have a better sense of how we should input lists of values to the commands, we should add the following:

• skylight-by-ratio
• skylight-by-ratio-gridded
• louvers-by-count
• louvers-by-distance
• extruded-border
• move-model
• rotate-model
• scale-model
• reflect-model
• merge-models
• generate-stories

I have realized that this will be useful for executing certain commands, particularly those used by queenbee luigi since there doesn't seem to be an entry point for the CLI other than the executable in the scripts directory.

I am running into a new question and I wonder about your thoughts?

Scenario:

A user builds a Rhino / Honeybee Model in IP units and writes out the model to HBJSON. Outside Rhino the user reads the file in, and then calls convert_to_units() or scale to change the model units to SI. At that point, if any extensions (such as Honeybee-PH) include any dimensional values, these do not get changed. So the user might end up with a Model in meters, but extension elements still in inches (or whatever they were built in).

So: I wonder how you would feel about adding a scale() function to model.properties, which then only calls out to any property extensions whenever Model's scale / rotate / reflect functions get called? So maybe roughly something like:

model:

def scale(self, factor, origin=None):
    ... # existing code...
    self.properties.scale()

model.properties:

def scale(self, factor, origin=None)
    for extension_prefix in self._extension_attributes:
        ext = getattr(self, extension_prefix)
        try:
            ext.scale()
        except AttributeError:
            pass

The goal being just to ping any extensions and say "hey: we're scaling" (or rotating, or reflecting, ...) and then if the extension wants to do anything with that, fine, or if not: fine. But at least to let them know somehow? So kind of similar to the way that properties' to_dict and from_dict call out to extensions during their operation?

Alternatively, perhaps there is a way to let extensions subscribe to a messaging protocol to get informed about these types of changes?

@chriswmackey, there is an implementation in honeybee already for room which is a good point to start but it needs several improvements. For instance it should be initiated from a list of Faces and not by length, width and height as is it right now. This is what I had in mind for rewriting it:

class Room(object):

    def __init__(self, faces, *args):
        """create from faces."""
        # ...

    @classmethod
    def from_plan_vertices(self, vertices, height, *args):
        """Create room from plan which is represented by a list of vertices."""
        # ...

    @classmethod
    def from_width_length(self, width, length, height, *args):
        """Create a box room."""
        # ...

This is required for honeybee-energy to move forward.

... and make sure that they are written into the Model dictionary and used to ensure Room volumes are closed upon re-serialization.

Face should by default accept a ladybug_geometry which should be used as default and then from_vertices should be a classmethod

There have been several cases that have arisen where a leaner, mesh-based geometry representation would be really helpful. In particular, if there was a Mesh-based Honeybee-core object that was translated to a Radiance Mesh, this would enable Radiance simulations to run much more efficiently and with much less memory in some cases. So we should add this object at some point soon.

in honeybee.typing clean_string
the hyphen is not being removed when running clean_string
changing re.sub(r'[^.A-Za-z0-9_-]', '', value) to re.sub(r'[^.A-Za-z0-9_(-)]', '', value) removes the hyphen from the string.

Hi @chriswmackey,

I believe we need better type checking here

a = (255.12, 255, 255)
b = tuple_with_length(a, length=3, item_type=int)
print(b)

The above will print
(255, 255, 255)

Here, I would expect an error to be thrown.

I am happy to send a PR if you agree that this needs to be fixed.

Someone recently explained to me why this is really important when people want to discount plenums in floor area calculations. I debated whether it should be a honeybee-core property or a honeybee-energy property but I think that it has a lot of uses beyond a particular simulation engine or honeybee extension.

So we should add it as a core property to Honeybee-core Rooms and Honeybee-schema. Then, we should:

1. Make sure it gets translated to this "part of total floor area" property on zones in EnergyPlus.
2. We should also integrate into the HB Plenum component along with also being exposed on one of the Honeybee 0::Create components like the HB Set Story component.
3. The Dragonfly methods that auto-generate plenums should make use of it as well.
4. Lastly, we should probably account for it in the recent "HB Geometry Properties" component, which gives floor areas for whole models (including net floor areas with construction thicknesses subtracted).

More information is here:
https://discourse.ladybug.tools/t/exclude-zone-from-floor-area/17605/2

I think this is a bug, but wanted to check before I sent a PR for it?

The newly added "is_equivalent" method now shows up when "_extension_attributes" property is called? (as does "apply_properties_from_dict" ?).

I do not believe this is the expected behavior though? But I wanted to make sure before I sent fix? Is it desired for these attributes to show up as part of the "_extension_attributes" list for some reason?

I believe both "apply_properties_from_dict" and "is_equivalent" should get added to the "exclude" list in the parent class, right?

If that is correct, I can make that fix and send along the PR.

The Search Construction component (and possibly others) allows for searching on multiple keywords. The descriptions suggest that constructions with any of the keywords will be returned, and the use of a function called any_keyword_in_string suggests that is the intent. However, that function actually uses the python all() function instead of any():

The result is that searching on multiple keywords tends to return no results instead of more results.

Given that many OpenStudio measures expect this, I think we should just add it as a property to the Room.

We can also add a staticmethod to the Room class to auto-assign stories based on floor height (overwriting any stories with None story_identifiers). We can also expose this as a method on the Model class and call it on the Grasshopper end of things before exporting the model to OpenStudio.

Hi Chris: This is a follow up from an email chain,
If these features are "thumbs upped" I can totally add them myself,
In the model you saw in the video: I had daisy chained the move HB obj components, in leu of using a "multiplied vector value list"
to duplicate a floor a number of times. I had also added a "suffix" _input to the HB Move to facilitate using a company determined naming convention.

Would either adding a feature to the existing HB move compo to facilitate DF esque 'floor to floor' rather that '10,20,30' lists of vector values to 'array' HB rooms be acceptable? and or creating a new component entirely to kind of 'blend' things together as to have a multiplier in which also 'duplicates' rooms for repeated floorplans/zoning data etc?

as well as: Can I add

@property
def suffix(self)

to the HB_Core room obj and related functions?

Hi,

I have a doubt about the writer/model module. I created in Windows a code to export DXF polylines to LB rooms. It worked great, but now I was trying to used it in Ubuntu 20.04 and found this Error:

AttributeError: module 'honeybee.writer.model' has no attribute 'idf'

I go to the model file and found a "note for developers". I understand that I have to add an "idf" method to this module, but I was comparing the same module in Windows and it's exactly the same. So, I can't understand what's the real problem.

def create_IDF_from_DXF(DXFfile, IDFname, level = 0.0, z = 3.0):
    dxf = ezdxf.readfile(DXFfile)
    msp = dxf.modelspace()
    zones = msp.query("LWPOLYLINE[layer=='M-ZONE']")
    print(len(zones))
    rooms = []
    for zone in zones:
        XYcoords = getXYCoord(zone.get_points())
        rooms.append(extrudeRoom(XYcoords, level = level, z = z, roomName = zone.dxf.handle))
        print("room " + zone.dxf.handle + " created")
    model = Model('Mymodel', rooms, tolerance = 0)
    idf_str = model.to.idf(model)
    with open(IDFname, "w") as file:
        file.write(idf_str)

AttributeError Traceback (most recent call last)
in
----> 1 create_IDF_from_DXF("prueba.dxf", "prueba.idf", 4.2, 3.2)

in create_IDF_from_DXF(DXFfile, IDFname, level, z)
10 print("room " + zone.dxf.handle + " created")
11 model = Model('Mymodel', rooms, tolerance = 0)
---> 12 idf_str = model.to.idf(model)
13 with open(IDFname, "w") as file:
14 file.write(idf_str)

AttributeError: module 'honeybee.writer.model' has no attribute 'idf'

As discussed in basecamp, it'd be great to remove these colinear points before triangulation.

I know that @mostaphaRoudsari brought up earlier that the word "Wall" in "AirWall" might be misleading because it can be used for all types of Faces (including ceilings + floors). At the time that Mostapha brought this up, "AirWall" seemed to be the clearest name that I could think of since just "Air" on its own was a bit too vague to identify it as a face type and the name that I know Design Builder uses for these surfaces (VirtualPartition) isn't really standard industry nomenclature.

But I just realized that EnergyPlus seems to be using the name "AirBoundary":
https://bigladdersoftware.com/epx/docs/9-2/input-output-reference/group-surface-construction-elements.html#constructionairboundary

The more that I think about it, "AirBoundary" might be clearer than "AirWall". If we are going to change it, we should do it now before I build out any more of this functionality. and it becomes harder to change. @mostaphaRoudsari , what do you think?