ladybug-tools/honeybee

:honeybee: A python library to create, run and visualize radiance studies. Core library of Honeybee[+].

honeybee

Honeybee is a Python library to create, run and visualize the results of daylight (RADIANCE) and energy analysis (EnergyPlus/OpenStudio). The current version supports only Radiance integration. For energy simulation you may use the legacy honeybee for Grasshopper.

This repository includes the core library which is the base for Honeybee plugins. For plugin-specific questions and comments refer to honeybee-grasshopper or honeybee-dynamo repositories.

Check this repository for the legacy honeybee plugin for Grasshopper.

Installation

pip install lbt-honeybee==0.1.16

Tentative road map

• Basic Radiance Integration.
• Support annual daylight simulation - daylight coefficient method [Nov 2016].
• Support three-phase daylight simulation [Dec 2016].
• Support five-phase daylight simulation [Aug 2017].
• Fix PEP 8 issues [Dec 2017].
• Code documentation [Dec 2017].
• Provide cloud service support for daylight simulation [Under progress]
• Basic EnergyPlus integration [Nov 2019]
• Support basic HVAC modeling.
• Full OpenStudio integration.

API Documentation

Citing honeybee

For the daylighting library cite this presentation:

Sadeghipour Roudsari, Mostapha. Subramaniam, Sarith. 2016. Automating Radiance workflows with Python. The 15th Annual Radiance Workshop. Padua, Italy. Available at: https://www.radiance-online.org/community/workshops/2016-padua/presentations/213-SadeghipourSubramaniam-AutomatingWorkflows.pdf `

Examples

Here is a Python example that shows how to put a grid-based analysis together. For more examples check one of the plugins repository.

from honeybee_plus.room import Room
from honeybee_plus.radiance.material.glass import Glass
from honeybee_plus.radiance.sky.certainIlluminance import CertainIlluminanceLevel
from honeybee_plus.radiance.recipe.pointintime.gridbased import GridBased

# create a test room
room = Room(origin=(0, 0, 3.2), width=4.2, depth=6, height=3.2,
            rotation_angle=45)

# add fenestration
#  # add a window to the back wall
room.add_fenestration_surface(wall_name='back', width=2, height=2, sill_height=0.7)

# add another window with custom material. This time to the right wall
glass_60 = Glass.by_single_trans_value('tvis_0.6', 0.6)
room.add_fenestration_surface('right', 4, 1.5, 1.2, radiance_material=glass_60)

# run a grid-based analysis for this room
# generate the sky
sky = CertainIlluminanceLevel(illuminance_value=2000)

# generate grid of test points
analysis_grid = room.generate_test_points(grid_size=0.5, height=0.75)

# put the recipe together
rp = GridBased(sky=sky, analysis_grids=(analysis_grid,), simulation_type=0,
               hb_objects=(room,))

# write simulation to folder
batch_file = rp.write(target_folder='.', project_name='room')

# run the simulation
rp.run(batch_file, debug=False)

# results - in this case it will be an analysis grid
result = rp.results()[0]

# print the values for each point
for value in result.combined_value_by_id():
    print('illuminance value: %d lux' % value[0])

honeybee's Issues

Implement Gensky in Radiance.

handle path with white space

see #58 (comment)

It's a major issue in the current honeybee and ladybug development and we need to address this before it gets out of control.

Add oconv parameters

Descriptors prototype

@mostaphaRoudsari
After some testing, a lot of reading (and an even more number of distractions over the last week or so), I finally have an initial prototype for descriptors that (I think) should clean up how classes can be coded in honeybee.
You should be able to download and run the code on your system. The key thing here is that the actual class is greatly simplified. Setters, Getters etc. have been replaced by single lines that do a lot more work behind the scenes. Once finalized these descriptors could be used everywhere.

Let me know what you think...

Should we test for command line options for radiance binaries during instantiation?

I guess the question is vague, so let me explain. Let's say we create a class for gendaymtx which has input options as the following:

gendaymtx [ −v ][ −h ][ −d|−s ][ −r deg ][ −m N ][ −g r g b ][ −c r g b ][ -o{f|d} ][ -O{0|1} ] [ tape.wea ]

My question is should we be checking if the -g is followed by r g b, or -v is not followed by anything etc. or do we just trust that the inputs will be entered in proper order ?

Make radiance/command/commandbase platform independent.

@mostaphaRoudsari I don't know if this is an abuse of the github Issues but I wanted your opinion on my last commit. I need it to move ahead as none of the perl commands will work the current file checking logic that we have. (sariths@e70fdef)

Implement daylight coefficients with matrix methods (aka 2-phase)

First step is the implementation of the following commands:

• epw2wea
• gendaymtx (mostly done).
• genskyvec (for point in time calculations).
• rmtxop
• rfluxmtx
• vwrays
• pcomb

Update: 13th June 2016: Added vwrays and pcomb to the list to support image based simulations.

make inputFiles private or read only

read more here: https://github.com/ladybug-analysis-tools/honeybee-core/pull/19/files/d1545fd570107b3a05c3e19c7ce8e0106a1b7c27#r57838757

RadianceNumericTuple returns a list and not a tuple

@sariths while writing the test cases I noticed that if I set the default value as a tuple it returns a tuple but if I set the value as a tuple it returns a list. I think it should be consistent and to match the name of the class I expect it to be a tuple.

viewPoint = RadianceNumericTuple('vp', 'view point', tupleSize=3, numType=float, defaultValue=(0, 0, 0))

print viewPoint
> (0, 0, 0)

viewPoint = (0, 0, 10)

print viewPoint
> [0, 0, 10]

rename .staticKeys and .dynamicKeys to addedParamters and defaultParameters

Also rename keys to parameters.

I named them dynamic vs static as default parameter are added as descriptors and static ones are added as string values. It's simply not a good reason and should be fixed.

Remove RadInputStringFormatter from datatype.py

@sariths I think we don't need RadInputStringFormatter anymore as it has been all implemented under RadianceTypes.

I leave this to you to review and act on.

Possible bug in genskyparameters implementation.

@mostaphaRoudsari I just wrote my first unittest and found something funny happening. Check this. When I instantiate a second gensky class the parameters set for that seem to carry over to the previously instantiated class for some reason.

Running unit-tests

This is a discussion on running unit-tests.

Import parameters from string and addParameterByNameAndValue should detect alias names for parameters

It can potentially be a bug if the user uses a combination of importing parameters and using default values. We need a dictionary to keep track of parameter names and their alias names. 🐛

Commands.py should probably be a package instead of a single file.

@mostaphaRoudsari ,

In the case of https://github.com/ladybug-analysis-tools/honeybee-core/blob/master/honeybee/radiance/commands.py, for the sake of keeping things manageable as this repository grows, it might be useful to have classes like Oconv, Rpict, Rtrace etc separated into individual files. The top-level script that creates recipes then could look something like:

from commands import Oconv,Rpict

oc = Oconv()
oc.addFiles([
r"C:\ladybug\unnamed\

Restructure testing framework and integrate to Travis

Cross-platform compatibility

@mostaphaRoudsari I took our library for a test-drive on Linux and I am surprised at how well most of the scripts test out. (I did do some monkey-patching to get everything to work).

I had a discussion with our IT admin yesterday. I will be getting some cluster resources to run my simulations. The fact that I can run those calcs on 100s of cores compared to my 8 core system make it a no-brainer for me to use them. As we discussed yesterday, most of the users are likely to get to HB through GrassHopper or Dynamo, so it probably doesn't make sense to push the cross-platform thing along with everything else right now. I am just adding some notes below for reference:

1. Paths for Python, Radiance, EPlus etc.: There isn't a fixed location on Unix systems for this based on the kind of access a person has to his/her personal or cluster system. So, hard-coding config.py is recommended.
2. Creating binary names for radiance commands : This os.path.join(str(radbinPath), '{}.exe'.format(self.__class__.__name__)) should be something like os.path.join(str(radbinPath), '{}'.format(self.__class__.__name__.lower())) over here. Linux and perhaps Mac systems are case-sensitive.
3. Hard-coding paths: Unix paths are usually something like '/home/userName/project/` etc. so any commands relying on paths like 'c:\ladybug' etc are going to crash.

I will add to this list periodically as I find things that work or don't work.

Write a run manager

I initially had the idea that an analysis class will take a recipe and write and run it and returns the results but then realized that write, run and read results should be implemented under the recipe itself which is the case at the case right now.

The current workflow will fine for single runs once at a time but does not support multiple runs at the same time and also more advanced workflows for running several jobs one after each other. This is why we need a runmanager.

This is a sketch of how I think it should work which is doomed to change!

rm.addJobByRecipe(gridBasedRecipe, type = "radiance", wait=True)
rm.addJobByCommand(oconv, type = "radiance", wait=True)
rm.addJobsByCommand([rpict, rtrace],  type = "radiance", wait=False)
rm.addJobByCommandline("copy *.res c:\ladybug", wait = True)

Not critical at the moment but something to think about.

A read only descriptor and some RfluxMtx prototyping.

@mostaphaRoudsari , I think we might need a read-only descriptor as the library grows to reduce the number errors occuring due to overwrite of attributes which need to be constant. Below is some code that I was testing. I think it might be handy to have the descriptor ReadOnly in the _datatypes folder. Any thoughts ? (Don't worry about the funny names starting with H right now. I do that to aid me in text completion).

class ReadOnly(object):
    def __init__(self,name):
        self._name = '_'+str(name)


    def __get__(self, instance, owner):
        return getattr(instance,self._name)

    def __set__(self,instance,value):

        #Let the value be set first time through constructor. Block all other attempts.
        try:
            value = getattr(instance, self._name)
            raise Exception("The attribute %s is read only. "
                            "It's default value is %s"%(self._name[1:],value))
        except AttributeError:
            setattr(instance,self._name,value)


class RfluxmtxSendRec(object):
    class __rfluxVariables(object):

        Huniform = ReadOnly('Huniform')
        HklemsFull = ReadOnly('HklemsFull')
        HklemsHalf = ReadOnly('HklemsHalf')
        HklemsQuarter = ReadOnly('HklemsQuarter')
        def __init__(self,Huniform='u',HklemsFull='kf',HklemsHalf='kh',HklemsQuarter='kq',
                     HreinhartTregenza='r',HshirleyChiu='sc2',Orientation='Y',
                     outputFormat=''):
            self.Huniform = Huniform
            self.HklemsFull = HklemsFull
            self.HklemsHalf = HklemsHalf
            self.HklemsQuarter = HklemsQuarter
            self.HreinhartTregenza = HreinhartTregenza
            self.HshirleyChiu = HshirleyChiu
            self.Orientation = Orientation
            self.outputFormat = outputFormat

        @property
        def HreinhartTregenza(self):
            return self.__HreinhartTregenza

        @HreinhartTregenza.setter
        def HreinhartTregenza(self,value):
            if value:
                assert value[0]=='r','The format for this input rN. Where N is' \
                                     'for sky subdivisions. Default r will result' \
                                     ' in standard Tregenza sky.'
                if len(value)>1:
                    num = int(value[1:]) #this will trip if this is not a number.
                else:
                    num = ''
                self.__HreinhartTregenza = 'r'+str(num)

        @property
        def HshirleyChiu(self):
            return self.__HshirleyChiu

        @HshirleyChiu.setter
        def HshirleyChiu(self, value):
            if value:
                assert value[:2] == 'sc', 'The format for this input scN. Where N is' \
                                        'implies NxN square to disk mapping with ' \
                                          'NxN grid over the square'
                num = int(value[2:])  # this will trip if this is not a number.

                self.__HshirleyChiu = 'sc' + str(num)

        @property
        def Orientation(self):
            return self._Orientation

        @Orientation.setter
        def Orientation(self,value):
            if value:
                assert value in ('X','Y','Z','x','y','z','-X','-Y','-Z','-x','-y','-z')
                self._Orientation = value

    RfluxVariables = __rfluxVariables()


    def __setattr__(self, key, value):
        if key in ('RfluxVariables','__rfluxVariables'):
            raise AttributeError("The class %s cannot be assigned."%key)
        else:
            super(abc,self).__setattr__(key,value)

y = RfluxmtxSendRec()


print(y.RfluxVariables.HklemsHalf)

#error as read only.
# y.RfluxVariables.HklemsFull = 'something'

Minimum implementation of Rcontrib

@sariths since I need Rcontrib for sunlight hours I start the minimum implementation for rcontrib.

Is ducktyping a go ?

@mostaphaRoudsari , Are we going forward with ducktyping ? I am asking because I want to implement toRadString by leveraging descriptor protocols. So, for the binaries that I am coding can I do them my way while still retaining all the outward appearances of toRadString ?

What is the recommended way to get dependencies from Ladybug ?

@mostaphaRoudsari We need epw2wea through ladybug. Right now if I do that on the test.py inside honeybee, it becomes a relative import one level over. ..(and we don't want to go there !) . So should we have a local copy of the epw code or should test.py be one level over the honeybee folder ?

Personally, I think copying a dependency, if it isn't too big, works well as that insulates the code from future breaks in compatibility.

Minimum implementation of HBZone

There are two reasons to implement HBZone now.

1. It will help @sariths with 3-Phase method as I think 3 Phase is more meaningful to happen for a zone (room). I can be wrong though.
2. It will help with the process of idf > HB > radiance which @sariths needs for his project and is fairly easy to do with current honeybee implementation.

Implement sunlighthours

It's long overdue. I have this started but never finished it. The implementation requires some changes to grid-based recipe to support both sky vectors and sky. Also it needs ladybug sunpath as a dependency which should be addressed through #50.

Possible bug/conflict in command/commandBase.py with respect to checking input files.

Hi @mostaphaRoudsari , I was implementing epw2wea (https://github.com/sariths/honeybee-core/blob/master/honeybee/radiance/command/epw2wea.py) when I noticed that the _checkFiles test that you have in the base class actually tests the length of a function https://github.com/ladybug-analysis-tools/honeybee-core/blob/master/honeybee/radiance/command/commandBase.py#L90-L94.

If this this was a property then this would be right, but since in our case as we are not calling the function, this will return an error. Replacing assert len(self.inputFiles) != 0, \ with assert len(self.inputFiles()) != 0, \ will work.

Is this a bug or am I missing something ?

Organize RadianceParameters to be reusable for all radiance commands

The current RadianceParameters is designed to work for rpict and rtrace and borrows the default values form this post by Greg: http://radsite.lbl.gov/radiance/refer/Notes/rpict_options.html

Now we need to modify the class to be customized for other commands. Read more here: d1545fd#commitcomment-16889133

I also need to use @sariths's work and replace the parameters with descriptors based on their types.

Implement Radiance view

This class lets you create a radiance view that can be used for image-based analysis.

Implement HBFenSurface

This goes hand in hand with #42.

Add read results to gridbased analysis recipe

This needs to be implemented together with #5

What is the data type for parameters lik -vt

@sariths I'm not sure if this has been implemented or we need to implement it.

How should I handle parameters like vt which accepts string values as v, h, l, c, a, etc? Should we have RadianceString type added?

Are files from honeybee-core being copied to the other libraries ?

@mostaphaRoudsari, I guess this is a question more than an issue. Are you creating local copies of honeybee-core scripts inside other , more specialized, libraries like honeybee-grasshopper ?

Add config.plarform to config.py

Based on @sariths's input the best approach is os.name.

I think it should return either 'windows' or 'linux' for windows vs the rest of options.

Add a test model to be used for writing unittest for radiance commands

This should be done before it gets late and we end up with a lot of development with no unittest files. That will be a disaster.

Add analysis type to daylight recipes

illuminance vs luminance vs radiation...

Implement gendaymtx in Radiance

#13 (comment)

Rfluxmtx stdin

Hi @mostaphaRoudsari, Do you have any idea why the stdin is invoked midway in Andy's rfluxmtx example ?
rfluxmtx -n 8 -I+ -ab 12 -ad 10000 -lw 1e-4 < points.txt - skies/sky.rad materials/testroom.mat objects/testroom.rad > DC.dmx

instead of

rfluxmtx -n 8 -I+ -ab 12 -ad 10000 -lw 1e-4 - skies/sky.rad materials/testroom.mat objects/testroom.rad < points.txt > DC.dmx

I am trying to figure out ways to add the control parameters for sender and receiver and found it odd that the stdin is employed earlier in the process.

PS: I think it's still early days to escalate this question to the mailing list as I think I might understand the working more if I figure out a solution here than getting a readymade answer elsewhere.

Implement Rcollate in Radiance

Nearly finished. Need to run tests now.

Test for existence of binary files through the base class

Since we don't have sc.sticky (do we have something similar ?) We should probably check the existence of binary files inside a the bin folder in the base class. https://github.com/ladybug-analysis-tools/honeybee-core/blob/master/honeybee/radiance/commands.py#L5-L10

Freezing the contents of room folder in honeybee\tests.

Hi @mostaphaRoudsari , I was just writing a unit-test when I realized that the code will be broken if the input epwFile that I am referring to isn't there in the future. Can we ensure that from now on, we only add to the test folder and not delete from it ?

re-organize radToString method for HBObjects

The arguments and returns should be the same for all the HBObjects : HBZone, HBSurface, HBFenSurface and HBShadingSurface. Currently there is minor differences.

Adding perl dependency

Hi @mostaphaRoudsari , based on our discussion today, I installed OpenStudio and hard-coded perl to my config.py. You can see the changes here, here and here.

The perl distribution folder has a funky name like strawberry-perl-5.16.2.1-32bit-portable-reduced which I assume would change everytime the perl version which is being distributed is changed. So I wrote some logic to guess where the perl.exe could be. Worst case scenario would be that perl.exe doesn't get found. I think we should raise an alarm for that in Radiance CommandBase as most of the vanilla Radiance commands don't require perl at all.

The way that I have found perl files to work for me is something like c:....perl.exe c:...genskyvec.pl ... input files . It results in some fairly long commands at runtime but works nevertheless.

Any thoughts on all this ?

Naming radiance libraries

I'm currently naming some libraries under radiance as radiance***. In specific the libraries are radianceparameters and radianceproperties. I'm wondering if I should remove the radiance part since it's already under radiance folder?

from honeybee.radiance import radianceparameters 
# can change to
from honeybee.radiance import parameters 

The reason that I currently named them like this is to avoid name conflicts down the road with similar libraries under EnergyPlus but I'm not sure if that's a good reason.

cc: @sariths , @chriswmackey

Value error due to attemped relative import with config.py

Hi @mostaphaRoudsari ,

I ran into this (notice the last two lines):

Traceback (most recent call last):
  File "C:/Users/Sarith/Projects/honeybee-core/honeybee/radiance/command/rtrace.py", line 2, in <module>
    from commandBase import RadianceCommand
  File "C:\Users\Sarith\Projects\honeybee-core\honeybee\radiance\command\commandBase.py", line 2, in <module>
    from ... import config
ValueError: Attempted relative import in non-package

Is this is a bug or is it just something that I can fix ?

Is having separate libraries for dynamo and grasshopper is the best approach for development?

This is a critical question to be answered before moving on with the development. Currently ladybug-core and honeybee-core are developed to some extend and for each of them one geometry library is created: ladybug-dynamo and honeybee-grasshopper.

Now that I want to start using honeybee-grasshopper in Dynamo for sunlight hours analysis I'm not sure if having two separate libraries is the right decision. It's True that geometry libraries for Grasshopper and Dynamo are different but the majority of the code which is not library-dependent is shared. Also many of the geometry operations in Grasshopper and Dynamo are very similar.

I'm thinking to try some duck typing instead and see if we can keep the libraries as a single library. My only concern is that it makes it for other developers to contribute to the code later on. If we want to go with dock typing we need to have a clear platform.

Should inputfiles be an abstractproperty ?

Hi @mostaphaRoudsari , Gensky doesn't accept input files. There are a few other commands that don't accept input files as well. Like genbox(surf/rev etc). I am not sure requiring input files and checking them always is a feasible idea. Your thoughts ?

My opinion is that the abstractproperty thing is a great idea but we should allow a way out. I guess if we do

    @property
    def inputFiles(self):
        """Input files for this command."""
        return None

then commandbase should just allow the operation to go forward.

Block adding dynamic attributes for subclasses of RadianceParameters and AdvancedRadianceParameters

As powerful as it is, it can be also frustrating for beginners who will use wrong keywords and then get frustrated not to see any changes.

One solution is to use __slots__ but it takes some extra development for dynamic setattr().

The other solution is to overwrite setattr but then it should be overwritten in all sub-classes. Right now this doesn't look like the best approach as it will make so much code duplication.

This is not high propriety at this point.

Here is an example:

rcp = RcontribParameters()
rcp.f = True
# RcontribParameters has no attribute as f and should raise an exception and suggest a solution

Convert idf files to radiance files using honeybee

I'm copying the sample code here for later reference:

from honeybee.energyplus import filemanager, geometryrules
from honeybee.hbsurface import HBSurface
from honeybee.hbfensurface import HBFenSurface
from honeybee.hbshadesurface import HBShadingSurface
from honeybee.hbzone import HBZone
import os


def idfToRadString(idfFilePath):
    """Convert an idf file geometery to a radiance definition.

    Radiance materials are assigned based on surface types and not from
    EnergyPlus materials or construction. You can create and map your
    own Radiance materials by adding a few number of lines to the code.
    """
    objects = filemanager.getEnergyPlusObjectsFromFile(idfFilePath)

    # if the geometry rules is relative then all the points should be added
    # to X, Y, Z of zone origin
    geoRules = geometryrules.GlobalGeometryRules(
        *objects['globalgeometryrules'].values()[0][1:4]
    )

    hbObjects = {'zone': {}, 'buildingsurface': {}, 'shading': {}}

    # create zones
    for zoneName, zoneData in objects['zone'].iteritems():
        # create a HBZone
        zone = HBZone.fromEPString(",".join(zoneData), geometryRules=geoRules)
        hbObjects['zone'][zoneName] = zone

    # create surfaces
    for surfaceName, surfaceData in objects['buildingsurface:detailed'].iteritems():
        surface = HBSurface.fromEPString(",".join(surfaceData))
        surface.parent = hbObjects['zone'][surfaceData[4]]
        hbObjects['buildingsurface'][surfaceName] = surface

    # create fenestration surfaces
    for surfaceName, surfaceData in objects['fenestrationsurface:detailed'].iteritems():
        surface = HBFenSurface.fromEPString(",".join(surfaceData))
        surface.parent = hbObjects['buildingsurface'][surfaceData[4]]

    # create shading surfaces
    shdkeys = ["shading:site:detailed", "shading:building:detailed",
               "shading:zone:detailed"]

    for key in shdkeys:
        for surfaceName, surfaceData in objects[key].iteritems():
            surface = HBShadingSurface.fromEPString(",".join(surfaceData))
            if key == "shading:zone:detailed":
                surface.parent = hbObjects['buildingsurface'][surfaceData[2]]
            hbObjects['shading'][surfaceName] = surface

    # export zones to rad files
    zones = hbObjects['zone'].values()
    materials = []
    geometries = []
    for zone in zones:
        mat, geo = zone.toRadString(includeMaterials=True, joinOutput=False)
        materials.extend(mat)
        geometries.extend(geo)

    # add shading surfaces
    for shading in hbObjects['shading'].values():
        mat, geo = shading.toRadString(includeMaterials=True, joinOutput=False)
        materials.append(mat)
        geometries.extend(geo)

    return "\n".join(set(materials)), "\n".join(geometries)


if __name__ == "__main__":

    epFolder = r"C:\\EnergyPlusV8-3-0\\ExampleFiles\\"
    targetFolder = r"c:\\ladybug\\idfFiles\\"

    epFiles = [f for f in os.listdir(epFolder) if f.lower().endswith(".idf")]
    # epFiles = ["HospitalLowEnergy.idf"]

    for f in epFiles:
        fullpath = os.path.join(epFolder, f)
        try:
            print "Exporting %s..." % f
            matString, geoString = idfToRadString(fullpath)
        except Exception as e:
            print "***Failed to convert %s.\n%s***" % (f, e)
        else:
            targetFile = os.path.join(targetFolder, f.replace('.idf', '.rad'))
            try:
                with open(targetFile, "w") as radFile:
                    radFile.write("\n\n".join((matString, geoString)))
            except IOError as e:
                print "***Failed to write %s.\n%s***" % (targetFile, e)

Disabling type checking in NumericTuple Descriptors.

Hi @mostaphaRoudsari, there are instances where are numerictuples might not be all numbers. Like gensky month day time and gensky 7 4 14:30EDT. We should either provide an option to disable type testing in numerictuples or create a new descriptor that is called datatuple or something .. What do you suggest ?

Sunlighthours analysis fails for modifiers >= 2048!

I posted the question to unmethours. Hopefully there is a way to change the maximum value otherwise I need to break-down the modifiers into separate files.

Unify method name for getting radiance definition

In many of the classes there is a method that returns the class in radiance language. For instance for radiance parameters it is something like -aa 0.25 -ps 8 -ab 2 -dj 0 -ad 512 -pt 0.15 -yScale 1 -dc 0.25 -st 0.85 -xScale 1 -lw 0.05 -as 128 -ar 16 -lr 4 -av 0 -pj 0.6 -dt 0.5 -dr 0 -ds 0.5 -dp 64

Currently I'm using .radianceDefinition method to get the radiance definition for this class. The same goes for materials, etc. Firstly Is .radianceDefinition a good choice?

Moreover for all the command classes we will have a method that returns the command line. In this case I'm using .commandline(). For instance

oc = Oconv()

oc.addFiles([
       r"C:\ladybug\unnamed\gridBasedSimulation\cumulativeSky_1_1_1_12_31_24_radAnalysis.sky",
        r"C:\ladybug\unnamed\gridBasedSimulation\material_unnamed.rad",
        r"C:\ladybug\unnamed\gridBasedSimulation\unnamed.rad"])

print oc.commandline(r"c:\radiance\bin")

will return:

c:\radiance\bin\oconv -r 16384 -f C:\ladybug\unnamed\gridBasedSimulation\cumulativeSky_1_1_1_12_31_24_radAnalysis.sky C:\ladybug\unnamed\gridBasedSimulation\material_unnamed.rad C:\ladybug\unnamed\gridBasedSimulation\unnamed.rad > unnamed.oct

Again is .commandline() a good choice?

Also is there a chance that we use same name for both of these methods? In a sense there are very similar to me or maybe they are not. I'm not sure.