ASE

[sariths]

Hi @mostaphaRoudsari ,

The workflow for ASE has two additional dependencies in the form of a binary file and a dll. Is there a specific location where they should be placed ? I don't think src and userObjects folders could be used (or can they?).

Thanks, Sarith

[mostaphaRoudsari]

You're right. They should be copied under resources in github: https://github.com/mostaphaRoudsari/Honeybee/tree/master/resources

You can either ask users to download it manually or download it for them if the file doesn't exist.

https://github.com/mostaphaRoudsari/Honeybee/blob/master/src/Honeybee_Glare%20Analysis.py#L147-L153 or https://github.com/mostaphaRoudsari/Honeybee/blob/master/src/Honeybee_Honeybee.py#L449-L457

[sariths]

Okay, thanks ! I am keeping this issue open for the time being as I think I might have a few other clarifications/questions.

[sariths]

@mostaphaRoudsari I have pushed some files on to a separate branch that are all the files required for ASE. I think it's still not ready for the main branch.

https://github.com/sariths/Honeybee/commit/5869c37ebb1216bb3330839e52d26257881f7388

[sariths]

@mostaphaRoudsari ,Some additional notes:

1. The binary file and dll file should be placed in the radiance bin folder and be available through path.
2. I have added somewhat of a hacky copyright notice for the STADIC stuff. Any comments ?
3. I am currently using subprocess for calling the binary files. Depending on how it plays out, we could use os.system instead.

[mostaphaRoudsari]

@sariths my first test. It can't find the points file.

Back to number 2 we should add it to the Honeybee license.

[mostaphaRoudsari]

Once I added the pts file it gives me an error that it can't find sunmat.rad

For some reason it still runs the batch file which makes dxanalemma.exe to crash:

Looks like dxanalemma needs some defense code to check for input files.

[mostaphaRoudsari]

Turns out one of the libraries are missing>

BTW do we really need this for the component we can use Ladybug's sunpath to get all the sun positions/vectors for rcontrib.

[sariths]

@mostaphaRoudsari Thanks for testing this...Let me see if the results between Ladybug's sunpath and dxAnalemaa are compatible. We have tested dxAnalemma internally so I was leaning on that. However, I am all for having zero external dependencies. If Ladybug doesn't work out, I think I can write a Grasshopper or Cython implementation of dxAnalemma.

[sariths]

By the way I have added additional dependencies here: https://github.com/sariths/Honeybee/commit/fe6736e68fd546e3f4d98f145afd4130988f9d78

[mostaphaRoudsari]

@sariths Thanks! The comparison sounds good to me.

Just FYI ladybug's sunpath algorithm is based on NREL's algorithm which is more accurate than Radiance's sun.c algorithm. It might be a good chance to give the new sunpath class a try: https://github.com/ladybug-analysis-tools/ladybug-core/blob/master/ladybug/sunpath.py#L23-L27

Let me know if I need to me to create a better sample code. Can you copy the structure of sun*.rad files here. I might be able to write that part faster.

[sariths]

@mostaphaRoudsari Here you go : https://www.dropbox.com/s/gp1w1ox7mgdg6zw/ASECal2.zip?dl=0 . This is an entire run of ASE calculations with dxAnalemma, rcontrib etc. I have stored the end result as a csv file in the rm1_East folder.

The files skydef_geo.rad, skydef_mat.rad and skydef.smx in the root folder were created by dxAnalemma. Then if you follow the script in the python component, you'd see that I extract the skydef_mat_sunlist.txt from the skydef_mat.rad file. After that it is pretty much all Radiance.

By the way, do you have a use-case for https://github.com/ladybug-analysis-tools/ladybug-core/blob/master/ladybug/sunpath.py#L23-L27 this inside Grasshopper ?

[mostaphaRoudsari]

@sariths thanks for sharing the files. Seems all you need is sun vectors for sunuphours. I imported the values from skydef_geo.rad and recreated the points in Grasshopper and then used the ladybug library to create sun positions as you can see them next to each other in Grasshopper.

The main difference is the number of suns which I assume my lack of understanding about how dxAnalemma works. Am I Are you generating sun positions for every 3 days? If we figure that out the rest seems to be pretty straight forward to generate the files that you need for rcontrib.

The code inside python component is:

import sys
sys.path.append("C:\Users\Administrator\Documents\GitHub\ladybug-core")

try:
    import ladybug as lb
except ImportError:
    raise ImportError("Download Ladybug core from github and add path to sys.path")
else:
    import os
    import Rhino as rc

def main(epwFile):
    location = lb.epw.EPW(epwFile).location
    sp = lb.sunpath.LBSunpath.fromLocation(location)

    suns = (sp.calculateSunFromHOY(hoy + 0.5) for hoy in xrange(0, 8760))

    # get vectors for suns if it's during the day
    return (rc.Geometry.Vector3d(*sun.sunVector[:]) for sun in suns if sun.isDuringDay)

if __name__ == "__main__":
    a = main(_epwFile)

Also I'm not sure why skydef_mat.rad is creating the same light material for every single sun. Can't we just create one?

Here is the grasshopper file.

[sariths]

I didn't realize adding the "-core" scripts was so simple ! Anyways, thanks for the new file. I need to figure out a couple of things before I can update this one...shall keep you posted.

[mostaphaRoudsari]

Thanks! Looking forward to the day that we can say the same for honeybee-core very soon. :D

[mostaphaRoudsari]

@sariths I'm studying your workflow to create a prototype of this workflow for the new library. I'm mainly interested to use this method for sunlighthours analysis which is slightly different from this calculation but I think I can create that if I understand this method.

I have two main questions.

1. In the first step which you use dxanalemma.exe it outputs 3 files which you use to create sunlist.txt later. I understand the material and the geometry files but what is .smx? Is it solar matrix? Why all the values are 0 0 0 in the file that you shared. I can't get dxanalemma.exe to work on my computer even after copying all the libraries and unblocking them so I'm using your shared folder on dropbox.

Inputs: weather file

Outputs: material file: sunmat.rad void light 0 0 3 1.0 1.0 1.0 geometry file: sungeo.rad source 0 0 4 0.533 solar matrix file(?): suns.smx I'm not sure what this file is represnting sun list file: sunlist.txt List of

1. If I understand the batch file correctly you're re-calculating the annual analysis for the points using what Andy calls two-phase method. Is that right? Are you thinking to replace this with the current daysim workflow?

[mostaphaRoudsari]

@sariths I could successfully modify this workflow to calculate sunlight hours. I didn't need suns.smx but I still like to know what it really is.

I also found the answer to my other question:

I'm not sure why skydef_mat.rad is creating the same light material for every single sun. Can't we just create one?

I was wrong and the answer is no. rcontrib returns the values for each modifier (material in this case) separately and since each material is representing a different sun position we need to have them all one by one.

[sariths]

Hi @mostaphaRoudsari, If I remember correctly, the .smx file contains rgb triplets for the radiation of the sun at 1619 positions for each hour of the year.The rationale behind using 1619 is that the overlap of suns will be minimal in that case.

The total number of lines is 8760 x 1619 = 14182440. The arrangement of lines is 1619 sets of 8760 numbers. So, the first 8760 lines should have one rgb triplet corresponding to the the first sun position(out of the total 1619). We find that triplet on line no. 2669. Then the next 8760 lines should have a rgb triplet corresponding to the next sun position. We find that one on line no. 11477. (and so on etc...).

Was this clear ? If not let me know, I will try and explain again. I, like 99.99% people in the daylighting simulation community, am not very well versed in all things rcontrib. But, Dr. Mistrick knows his way around it.

[mostaphaRoudsari]

Hi @sariths, Thanks. That's definitely helpful.

Back to your comments about rcontrib I think that is exactly the reason that Greg wrote rfluxmtx. Once I finish sunlight hours workflow I'm thinking to give it another try for radiation analysis for Ladybug. I have done it once using rfluxmtx by following Andy's tutorial and getting so much help from Andy and Rob but I remember almost nothing about the details of the workflow right now. I should have the files though. It's just too many parameters that you need to take care of at the same time. You just have to finish it once you have it working otherwise it's starting from the scratch.

Just thinking about the fact that very soon people can create a 3Phase recipe from Honeybee API, add Honeybee objects to it, and run the analysis in a couple of lines of code makes me very excited! We are very close to make that happen.

PS: It's great to see Andy started to move the tutorials to a gitbook: https://andymcneil.gitbooks.io/three-phase-method-tutorial/content/01_introduction.html

[sariths]

@mostaphaRoudsari That twitter example was 2014 ! #respect !!

I don't think the recipe concept works well for what I am trying to do in my research but I think I can pitch in with creating the classes for radiance binaries and defining/testing the workflows (and radiance coding in general). If you are starting a new binary class, just let me know in the issues through the new-development tag (as you suggested) so that we don't duplicate our efforts !

[chriswmackey]

@sariths and @mostaphaRoudsari , Is this issue still relevant now that we have ASE running on HB+ and we have a method for calculating ASE with Ladybug? If not, perhaps we should close out this issue.

[mostaphaRoudsari]

I think we should close this issue and also remove the component if we have ever added it to honeybee.

Finally I have been waiting to run a comparative study between ladybug and honeybee[+] solutions. If we have two solutions we should have a clear statement about why and what are the differences.

[chriswmackey]

Ok. Let's close this issue after doing a test, then. The only possible source of differences between Ladybug and HB+ that I can think of is if HB+ is producing sky vectors that are not on the hour mark but the half-hour mark (for the sake of aligning with the epw illuminance data). In the Ladybug example that I cite above, I use sun positions that are on the hour mark and I have to interpolate the epw illuminance data to get illuminance values that match these sun positions. @mostapha or @sariths , do you know off the top of your head whether the sky vectors that you are using are on the hour mark? If not, I can change the Ladybug example to match (although I'm not sure if the definition of ASE states which types of sun positions should be used).

Once you let me know this, I can run a test and we can close this issue.

[mostaphaRoudsari]

@mostapha or @sariths , do you know off the top of your head whether the sky vectors that you are using are on the hour mark?

It's the half-hour mark: https://github.com/ladybug-tools/honeybee/blob/f2d8a4d61a4d00cd8346531b7b27a3ddf43dca2d/honeybee/radiance/sky/sunmatrix.py#L177

The other source of difference is how Ladybug calculates the intensity of the sun for each hour. Honeybee[+] uses gendaylit which we should compare with Ladybug method.