ladybug-tools / dragonfly-energy Goto Github PK

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.

This is good practice and will make it easier for third-parties to work with DFJSONs.

Hi there,

A suggestion for Dargonfly for Grasshopper is to move DF Reassign Energy Properties to the Create Tab. It is very confusing in the Energy tab.

Cheers
Dmitry

https://github.com/ladybug-tools/dragonfly-energy/blob/07431651bb2ec2cc8da004d26eb9d81c088ee6d9/dragonfly_energy/cli/translate.py#L305C24-L305C24

CLI fails to create gbxml

AttributeError: type object 'Model' has no attribute 'from_hbjson'

from dragonfly.model import Model

should be

from honeybee.model import Model

or better yet, why re-form the model while hb_model has already been created?

@mostaphaRoudsari ,

I just need you to put in the GH_TOKEN and PYPI_PASSWORD here:
https://travis-ci.org/ladybug-tools/dragonfly-energy/settings

This is an issue that we plan to address across several repos at once.

This is a bug but it will only appear in cases where a user edits the generic_default_construction_set in their standards library, serializes the model to a JSON, sends it to another machine that does not have the edits to the generic_default_construction_set, and then re-serializes it on that machine. In the current setup, any of these original edits to the generic_default_construction_set will not be preserved in the re-serialized model.

After mulling over a few ways that we can fix this, I think the best solution is one that doesn't try to edit the generic_default_construction_set on the re-serialized machine, which could have major unintended consequences. This means that we will have to find a way to merge this global_construction_set into the construction sets of individual Buildings of the model, which is do-able and shouldn't create that much of a mess upon re-serialization. So I propose the following:

1. Reserialize the model as we usually would.
2. Perform a check to see if a Model's global_construction_set is equal to the generic_default_construction_set.
3. If not, we loop through all of the buildings and assign the global_construction_set if there's nothing there already. Or, if there's already a construction set there, we add it to a special set of ConstructionSets.
4. We then loop though this special list, unlock the ConstructionSets, merge the global_construction_set into them, and lock it again. This should update all of the building-assigned construction sets.

@chriswmackey, I stumbled across this while running some dragonfly-energy simulations.

It looks like this EPW object:

Is no longer imported anywhere in the most recent dragonfly-energy version:

Which is causing the simulations to fail in cases where the dy_from_epw function is called.