ladybug-tools / dragonfly-legacy Goto Github PK

Right now, I don't expose these parameters, which are inputs in the .uwg file:

uwg.autosize = 0.
uwg.sensOcc = 100.
uwg.LatFOcc = 0.3
uwg.RadFOcc = 0.2
uwg.RadFEquip = 0.5
uwg.RadFLight = 0.7

I feel that people would prefer to have the ability to customize the actual internal loads and schedules before I expose these things but, if I am mistaken, please comment on this issue and let me know.

I think I will add some code in the Dragonfly "Run WUG" component that automatically overwrites the glazing ratio of each typology after init_input_obj() is run. This way, it will use the facade-area-weighted glazing ratio across all typologies in the "infinite urban canyon" calculation but it will use the glazing ratio of each individual typology when running the BEM for each typology.

See more info here:
ladybug-tools/uwg#18 (comment)

Things like building height, facade area, etc. It can be useful for early design cases where we have no idea what the final geometry will be and we just want to make a generic typology.

Hello,

unfortunately I have troubles running the install.gh file. I followed the instructions regarding ladybug/honeybee and dragonfly installation but -apparently- the copying from the userobjects to C:\users\zentr\AppData\Roaming\Grasshopper\UserObjects does not work.

This error message appears: Runtime error (ArgumentOutOfRangeException): Der Index lag außerhalb des Bereichs. Er darf nicht negativ und kleiner als die Sammlung sein.
Parametername: index

(Index was out of range. Must be non-negative and less than the size of the collection. parametername:index)

However, looking into the folder C:\users\zentr\AppData\Roaming\Grasshopper\UserObjects there is a new folder Dragonfly which contains the following 20 userobjects

Any suggestions/ ideas how to solve this problem?

Thanks very much in advance!

Isabel

Dear chris @chriswmackey
I just wondering how to set the the output interval in the dragonfly workflow.As we can see in the old ladybug version（VER0.0.65）the output interval can be set. But I can't find the option in the dragonfly workflow.So how can I set this in the dragonfly?Looking forward to your reply.

Hey @chriswmackey,

I was testing out the example file for the UWG from Hydra, and found that the Dragonfly_Dragonfly component isn't running due to outdated links to the UWG_Matlab repo. I forked the repo and changed the links/made a new userobject, and it's loading correctly now.

Here's the changes to the source file:
saeranv@bd0d13f

Edits:

1. Updated the updatedLink path to current repo.

2. Updated the UWG download link, and commented out the unzip function as the file from the repo is no longer a zip.

3. Updated the error message for not finding MRC 9.0 to reflect current requirements for R2015b version. I can't find any installer for MRC in the new repo, so I changed the message to direct users to "http://www.mathworks.com/products/compiler/mcr/index.html" . This is the process I ended up following. However in the UWG installer: https://github.com/hansukyang/UWG_Matlab/tree/master/UWGv4.1/for_redistribution there is an option (I think) to download the MCR, so we can also change the message to reflect that. What do you think?

If these changes looks good I'll send a pull request.

S

Currently dragonfly assumes the urban area is a circle:
https://github.com/chriswmackey/Dragonfly/blob/master/newPlugin/src/Dragonfly_Dragonfly.py#L1389
.., but the UBLDef assumes a square:
https://github.com/ladybug-tools/urbanWeatherGen/blob/master/UWG/UBLDef.py#L29

Hi,

I’ve been looking through the code for various Dragonfly components, and I’ve run into a few lines of code that I think might have been meant to be written differently. Apologies if I am mistaken.

The first occurs in the code behind the DF Dragonfly component, in the Vegetation class’s init method. Line 1880 initializes self._s_trees = is_trees, but there are no getter and setter methods for the property _s_trees, only for is_trees. I’m wondering if self._s_trees was meant to be self.is_trees?

https://github.com/chriswmackey/Dragonfly/blob/182da9a6c18315e2f35465b0bd403109f3e6f6a5/src/DF%20Dragonfly.py#L1877-L1880
https://github.com/chriswmackey/Dragonfly/blob/182da9a6c18315e2f35465b0bd403109f3e6f6a5/src/DF%20Dragonfly.py#L1911-L1919

The second is also in the DF Dragonfly code, in the VegetationPar class’s setter method for self.vegetation_start_month. On line 2115, self._vegetation_start_month is always set to 0 regardless of whether or not the user entered a valid vegetation start month. Should there be an else before line 2115 like there is for the vegetation_end_month setter?

https://github.com/chriswmackey/Dragonfly/blob/182da9a6c18315e2f35465b0bd403109f3e6f6a5/src/DF%20Dragonfly.py#L2110-L2115

The third is in the code supporting the DF Run UWG component, in the set_uwg_input method. On line 170, if DFCity.vegetation_parameters.vegetation_start_month == 0, uwg.vegEnd = vegEnd, but according to the logic used in lines 166-167, shouldn’t uwg.vegEnd be initialized to the epw default value only if the user entered a 0 for DFCity.vegetation_parameters.vegetation_end_month (check for end month instead of start month)?

https://github.com/chriswmackey/Dragonfly/blob/182da9a6c18315e2f35465b0bd403109f3e6f6a5/src/DF%20Run%20Urban%20Weather%20Generator.py#L164-L173

Lastly, I just had a quick question. I noticed that in the code for the DF Run UWG component, in the autocalcStartEndVegetation method, on line 94, vegEnd is initialized to 12. However, vegStart is not initialized to any value. This means that if we’re looking at weather data for an area for which no month’s average hourly temperature is above 10 degrees Celsius, returning an uninitialized vegStart value would raise an error? I ask this because I’m unsure whether or not we can trust that every location for which epw files exist definitely have average hourly temperature greater than 10 for at least one month.

https://github.com/chriswmackey/Dragonfly/blob/182da9a6c18315e2f35465b0bd403109f3e6f6a5/src/DF%20Run%20Urban%20Weather%20Generator.py#L93-L104

Thanks so much!

Hi,

I am trying to use Envi-met with dragonfly and having hard time with "DF Envimet Buildings" function.

My buildings do not have Naked edges but, as you can see, it keeps saying "1. Please provide closed geometries"

this is an object description of my building, and it says "closed solid with 14 surfaces"
Please help me!!

I have come to realize that my current method for extracting building footprints really isn't that good and, while it's fairly accurate, it always produces invalid breps. So I am thinking of switching it to the following:

1. Project all floors of the building into the XY plane
2. Boolean union these floors together.
3. Duplicate the edge curves of the unioned floors
4. Use the edge curves to create a new, clean footprint surface

after update the old version didn't remove as see in pic

It seems that they do play a role in the sensible heat calculation as @saeranv notes here:
ladybug-tools/uwg#18 (comment)

Hi Chris,

I'm noting an issue I found in the installation of the UWG. The UWGEngine executable looks for files in .\UWG\UWGEngine_mcr\.META\; however, the directory in UWG.zip is named .\UWG\UWGEngine_mcr\META\ (missing the dot). It needs to be manually renamed using the command prompt's Rename command or a non-Windows Explorer tool to fix this. You might want to automate this for users.

Best,
Alstan

Hi Chris,

See the referenced line of code, https://github.com/chriswmackey/Dragonfly/blob/3ab5f7553987a1da31622ad88cb2b6ebca716f4d/src/Dragonfly_UWG%20City%20from%20Typologies.py#L378

This is incorrect, because totalGrassCoverage is the ratio of the grass area to the (grass area + paved area). Total terrain area should be totalBuiltArea + totalPavedArea + totalGrassArea.

Separately, I think there are some other funky area things going on in your script, (like that you presume buildings have pavement underneath them in the model).

Best,
Alstan

That copies the UWG files into the right directory and copies all relevant userobjects.

Including:

Glazing Ratio
SHGC
Wall Albedo
Roof Albedo
Roof Vegetation Fraction

More info can be found here:
ladybug-tools/uwg#18 (comment)

Such that people can easily stay synced with this github.

@chriswmackey

As mentioned by Joseph, changing the default simTime.dt to 200 seconds will fix the FATAL ERROR mistake (at least for the version of this we've encountered thus far on the forums).

I've changed the default to 200 seconds (in the initialize.uwg) in the UWG, and I think it would be a good idea to do the same thing for the DF components.

Also, I've revised the error handling on the simTime and uwg.building code so that if users run into the FATAL ERROR, they are instructed to try and reduce the timestep, and the code catches any incorrect timestep inputs (i.e should be a factor of 3600, or else the timestep won't divide evenly per hour).

I'm just waiting for some instructions on how to commit my changes with correct semantic versioning and I'll add the new UWG code to this repo as well.

I can get away with not doing this before the first release. It just has to be done some time before I pull everything out into standalone .py files that will go under the Ladybug Tools organization.

I am sure that LANSDAT 8 has a different format than the LANDSAT 4-5 data that I have historically used. I'll have to check this soon and make any necessary changes.

@chriswmackey ,

I think the latAnth parameter isn't defined in Dragonfly.

It's one of the required parameters In the Run UWG component it should be defined in the urban characteristics along with the sensible anthro heat:

https://github.com/chriswmackey/Dragonfly/blob/220e5c11de084b9963cb28d0fe278b74e68e59a1/src/DF%20Run%20Urban%20Weather%20Generator.py#L142-L149

i.e here is default used in the singapore paramters file:

# Urban characteristics
bldHeight,10,     # average building height (m)
bldDensity,0.5,   # urban area building plan density (0-1)
verToHor,0.8,     # urban area vertical to horizontal ratio
h_mix,1,           # fraction of building HVAC waste heat set to the street canyon [as opposed to the roof]
charLength,1000,  # dimension of a square that encompasses the whole neighborhood [aka. characteristic length] (m)
albRoad,0.1,      # road albedo (0 - 1)
dRoad,0.5,        # road pavement thickness (m)
kRoad,1,          # road pavement conductivity (W/m K)
cRoad,1600000,    # road volumetric heat capacity (J/m^3 K)
sensAnth,20,      # non-building sensible heat at street level [aka. heat from cars, pedestrians, street cooking, etc. ] (W/m^2)
latAnth,2,        # non-building latent heat (W/m^2) (currently not used)

Also, the uwg checks to make sure all the inputs are defined correctly here : https://github.com/ladybug-tools/uwg/blob/master/uwg/uwg.py#L435-L482, but I don't think the Run UWG component in DF is calling this method because it's using an alternative method of inputting values. I can make this into a separate method so DF can use it, so we don't run into this issue again.

The components should not start with "Dragonfly_" as it makes it hard to search for components. Rather it should be "DF " with a space.

While only some urban areas have fully-detailed 3D models available, nearly all have some sort of 2D representation as polygons.

Because the new dragonfly API is fully object-oriented, I just need to add a fromPolygons() method to the building typology class to have this capability available.

I'm realizing that we don't really gain anything by plugging in the geometry as a solid. Just plugging in the canopy seems a lot more effieicent and takes less time to generate.

Hi,

I have Rhino 6, and I was trying to install Dragonfly following instructions from this link: https://github.com/chriswmackey/Dragonfly/wiki. To install Ladybug, I followed the link on the previous site to the following link: https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/Installation_Instructions.md. The third step is to install GHPython 0.6.0.3 using the following link: http://www.food4rhino.com/app/ghpython.

I downloaded the file using the download button in the first row. However, after dragging the file titled ghpython2 onto the Grasshopper canvas opened in Rhino6, I get the error depicted in the picture below. I found that GHPython.gha is a file that comes with Grasshopper, which comes with the installation of Rhino 6.

I'm relatively new to Rhino and Ladybug Tools. Sorry if there is something obvious that I'm missing.
Thanks so much!

From @annasong20 here: https://discourse.ladybug.tools/t/dragonfly-ladybug-potential-bugs-and-question/3265/17, we may not be area-weighting the SHGC values when inputted by the user. I'm looking into this now, and hopefully an send a PR soon.

Hello,

I am trying to follow the same steps as the ones in the tutorials of Envi-met for creating an INX file.

So the task at hand is, I have several Rhino files which are actually the 3d models of a built area. I would like to convert that file into an INX file and eventually
recreate the same structures inside Envi-met. However, at the start of the procedure, when I use the "DFEnvimetlocation" component I get the error:

"1. Solution exception:Input string was not in a correct format."

What could I be doing wrong?

Sorry for the inconvenience. I am new at both Rhino/Grasshopper and Envi_met. :?

Thanks for any help!!

P.S.: I am attaching a screenshot of the steps

Re: the 2nd question from @annasong20 here: https://discourse.ladybug.tools/t/dragonfly-ladybug-potential-bugs-and-question/3265/21?u=saeranvasanthakumar

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?

In the UWG code characteristic length is the edge of a square encompassing the urban area. This is what the UWG assumes when it calculates total urban area, built area etc, i.e here: https://github.com/hansukyang/UWG_Matlab/blob/master/UBLDef.m#L28

However, I just downloaded, and ctrl-F-ed my way through Michael Street's thesis, which @chris references for this 500m radius value, and it does look like Street is using a radius value, of around 500m for charLength.

More discrepancies:

• Nakano specifies this value as the city diameter of 1000m.
• Jiachen specifies this value as 1000m, but is not clear if it is a diameter/radius/square length.
• The original initialize.m file from the UWG_Matlab is defined as 1000m, and is not clear if it is a diameter/radius/square length.

@chriswmackey , any idea of why there is this seeming discrepancy between the UWG code (assumes charLength = square edge at 1000m), and Street's thesis (assumes charLength = radius of circle at 500m)?

S

Because we already have code to read in the image, it shouldn't be that much more work to add support for NDVI images and True Color images. I'l try to test this out soon.

@chriswmackey

In the Run UWG component, the floorHeight parameter is being incorrectly assigned to the BEM object, it should be assigned to the building object.
https://github.com/chriswmackey/Dragonfly/blob/220e5c11de084b9963cb28d0fe278b74e68e59a1/src/DF%20Run%20Urban%20Weather%20Generator.py#L195

i.e uwg_typology.building.floorHeight = df_typology.floor_to_floor

I vaguely feel like Anna found this mistake at some point, and we just never got around to correcting it. At any rate, noting it here so we make sure to address this.

As reported here there is a mistake with the name of .epw file. See the link above for more details.

As seen here: http://www.grasshopper3d.com/group/ladybug/forum/topics/dragongfly-boundary-layer-parametrization

The input for the Dragonfly_Boundary_Layer_Parameters says 800m which is causing confusion and leading to too large heights to be set for the night boundary layer height. Change to 80m.

Also as work progresses on UWG_Python and translation efforts on the RSMDef.m and UWG.m proceed, this might be a good error test to understand if we need to put upper/lower bounds on inputs, and better warning/error messages.

Hello

According to the article: https://www.envi-met.com/first-envi-met-plugin-for-rhino-grasshopper/ .
I read on the above article, that this plugin could convert 3d model (e.g. .3ds) into envi-met model area (.inx) and run the envi-met simulation without opening the software. Is that correct?

I am attempting to put envi-met simulation on supercomputers where we don't have any user interface. Part as automation to simplify multiple simulation using different scenario (3d models).

I would like to ask different opinion if this idea is feasible. Open and appreciate for different opinion. Thank you very much.

... as this causes the UWG to crash.

Not everyone is going to go through this whole process of making building typologies and then the whole city for the UWG.

Because I have built the new Dragonfly as an object-oriented API, it's easy to add in a component to make a DF city from raw numbers (site coverage ratio, building height, etc) and a single building typology. I'll do this soon.

Hello All,

This issue has been started in order to lay out the full path that the dragonfly must follow for a first public release to occur. This plan of action is adapted from conversations that I have had with @mostaphaRoudsari , @antonszilasi , as well as many others.

This is the full list of components that I have planned for the first release, organized by tab, sub-tab, and component name. People who have expressed interest in developing certain components have their name next to the component in parentheses ():

0 | Dragonfly
Dragonfly_Dragonfly

Dragonfly_Download Satellite Image
Dragonfly_Download SRTM Elevation Image
Dragonfly_Download Precipitation Data (Panagiotis)

Dragonfly_Unzip Satellite Image
Dragonfly_Import Precipitation Data (Panagiotis)

1 | VisualizeSatelliteData
Dragonfly_Import LANDSAT Image
Dragonfly_Import ASTER Image
Dragonfly_Import SRTM Image

Dragonfly_Get Satellite Value At Point
Dragonfly_Get Point from Latitude/ Longitude
Dragonfly_Crop Image With Polyline

Dragonfly_Align Images
Dragonfly_3D Image Based on SRTM

2 | GenerateUrbanClimate
Dragonfly_Run Urban Weather Generator

Dragonfly_UWG Parameters from HBZones
Dragonfly_UWG Parameters from Typologies

Dragonfly_Building Typology from HBZone
Dragonfly_Building Typology from Parameters

Dragonfly_Vegetation Parameters
Dragonfly_Pavement Parameters
Dragonfly_Generate Urban Geometry

Dragonfly_Call From UWG Material Library
Dragonfly_Reference EPW Site Par
Dragonfly_Boundary Layer Par

3 | GenerateEPW
Dragonfly_Run Climate Change Weather Generator (Anton)

Dragonfly_Run Satellite Air Temp Weather Generator
Dragonfly_Surface Temp Diff to Air Temp Diff

Dragonfly_Interpolate Between EPWs

4 | Developers
Dragonfly_Update Dragonfly

This is by no means an exhaustive list and I am positive that it will undergo many revisions before the first release. Still, it maps out the key objectives of the Dragonfly project within the broader stated goal of climate data generation and manipulation.

If anyone browsing this issue has any suggestions for other ways in which the Dragonfly project could fulfill this goal or other climate-related data sets that should be linked to, please post here with a comment.

Also, if anyone would like to develop any of the components or features listed here or know of anyone who might like to develop them, please post.

Thanks to all who have helped in the early discussions about this. Without you, this insect never would have made it to the pupa stage!

I am just pasting here my rough outline of the inputs for the Urban Weather Generator (UWG) components so that I do not loose track of them. I will close out the issue once I have finished setting up the basic components (without full functionality yet):

Dragonfly_Run Urban Weather Generator
epwFile
UWGParams
analysisPeriod
epwSitePar
boundaryLayerPar_
_writeXML
_runIt

|

Dragonfly_UWG Parameters from HBZones
    _HBZones
    _treeBrepsOrCoverage
    _pavementBrep
    grassBrep_
    vegetationPar_
    pavementPar_
    nonBldgAnthroHeat_

Dragonfly_UWG Parameters from Typologies
    _buildingTypologies
    _typologyRatios
    _buildingBreps
    _treeBrepsOrCoverage
    _pavementBrep
    grassBrep_
    vegetationPar_
    pavementPar_
    nonBldgAnthroHeat_

|
|

Dragonfly_Building Typology from HBZone
    _HBZone
    _flr2FlrHeight
    coolingCOP_
    heatingCOP_
    heatFrac2Canyon_

Dragonfly_Building Typology from Parameters
    _flr2FlrHeight
    _wallConstruction
    _windowConstruction
    _roofConstruction
    _intMassConstruction
    _window2Wall
    _nightIntGains
    _dayIntGains
    _infiltration
    _ventilation
    coolingSetPt_
    coolingSetBack_
    heatingSetPt_
    heatingSetBack_
    coolingCOP_
    heatingCOP_
    heatFrac2Canyon_

Dragonfly_Vegetation Parameters
    vegStartMonth_
    vegEndMonth_
    vegetationAlbedo_
    treeLatentFracton_
    grassLatentFracton_

Dragonfly_Pavement Parameters
    pavementConstr_
    vegCoverage_
    nonBldgHeatLatentFrac_

Dragonfly_Generate Urban Morphology
buildingHeight_
siteCoverageRatio_
blockLength_
treeCoverage_
grassCoverage_
nonBldgHeatLatentFrac_

|

Dragonfly_Call From UWG Material Library

Dragonfly_Reference EPW Site Par
    pavementConstr_
    vegCoverage_
    avgObstacleHeight_

Dragonfly_Boundary Layer Par
    daytimeBndLayerHeight_
    nighttimeBndLayerHeight_
    referenceHeight_

I am starting this issue specifically because @antonszilasi us beginning work on a python version of the current Excel-based 'Climate Change Weather Gen' (CCWeatherGen) Tool. This is tool that almost everyone uses to warp EPW files to future climate change scenarios projected by the Intergovernmental Panel on Climate Change (IPCC).

This issue is where anyone should feel free to post ways in which they think the current excel-based tool could be improved by a translation to a python Grasshopper component. @antonszilasi will take into account all comments in his development of the component. I will start by listing a few improvements that I see happening with this python version:

1. Any new user of the CCWeatherGen tool needs to download the entire HADCM3 database file-by-file (there are 76 files in total) and copy them into the CCWeatherGen folder on their machine. Any new user also needs to change the file names of three of these downloaded files. All of this results in an installation time of almost 20 minutes.

2. It takes a long time to run the CCWeatherGen tool (around 20 minutes per weather file) and this at least partly because of inefficiencies of Excel as compared to an full computer language

3. There seem to be some bugs in the CCWeatherGen tool as evidenced by this GH discussion here: http://www.grasshopper3d.com/group/ladybug/forum/topics/impossible-to-visualize-weather-data-from-epw-ipcc-scenario-a2?commentId=2985220%3AComment%3A1183831&groupId=2985220%3AGroup%3A658987

4. The current CCWeatherGen tool does not work with the current 2013 version of Excel, forcing users who are using the latest version to revert to old software.

I have already aimed at mitigating the first item that I have put on this list by uploading the entire HADCM3 database to the 'resources' folder of this repository. @antonszilasi , when you begin to develop your component, I imagine that the automated downloading and unzipping of this database from the github will be one of your first goals.

I am looking forward to this future component really rocking my workflow and for generally raising awareness about the impact of climate change on the design of the built environment.

Certain Breps, or possibly combinations of Breps, is failing with the following error. This appears to a be a similar error to past Ladybug tools. Can anyone explain situations they have had this happen?

{0;0}
0. Runtime error (ArgumentTypeException): Multiple targets could match: Compute(Surface), Compute(IEnumerable[GeometryBase]), Compute(Brep), Compute(Curve), Compute(Hatch), Compute(Mesh)

Traceback:
line 451, in getFloorBreps, ""
line 644, in calculateTypologyGeoParams, ""
line 1061, in from_geometry, ""
line 71, in script

I can narrow the issue down to only occurring at specific breps, but am not certain what about the breps are causing the issue.

Originally posted by @paulleondrake in #1 (comment)

Maybe @AntonelloDN could find a solution to this issue:
I defined new wall in the envimet database manager (ENVi v. 4.4.5) :

Then I opened my .gh file and applied this wall to breps:

I generated the .INX file:

Opened in ENVI spaces but all the three buildings have the base material applied to the walls:

In this case, I have to apply the customed material from spaces by selecting all single building:
And then save the modified file.

What's that depend on?

I should do this now before any official release. It will be a true pain in the neck later

At the moment, some of the critical facade parameters are being overwritten when the inputs are being read in.

Input mentions value from 0 to 1 to input fraction of vegetation on surface but code checks for value between 1 and 8.

Error output:"VegFraction must be between 1 (warmest) and 8 (coldest)"

Worth either correcting input requirements or input hint (whichever is incorrect).

Look forward to beta testing this further! :)

Any chance the install instructions could be in the wiki? I was showing a colleague how to install and it took us forever to find it in the resources folder :)

hi dear chris

i follow Instructions install ccweathergen and dragon fly but i got still this massage error
i do the fallowing error but still problem not solved
rhino 6 grasshoper v1 win 10

Dragonfly_AMY from NCDC Data component error
i download data from https://gis.ncdc.noaa.gov/maps/ncei/cdo/hourly for one year and i had this error !!

Hi,

EDIT: It seems, that the problem only occurs if I change the input for telescope/ starttelescopeheight.

I am having problems converting closed polysurfaces in Rhino to buildings in ENVImet Spaces.

After running my .gh file, a Spaces File is created. However, in ENVImet it shows that z bottom of the buildings z0=2m (and it should be z0=0m).
I am not using any topography information.
The preview of the Grid in Rhino shows already the problem: the red markers are not on the ground/ the level where the buildings & soil area are located.

Have you already experienced this effect?

Thanks in advance.
Isabel