LightDensityPerAreaCalculator (new)

[ayezioro]

What do you think? https://www.dropbox.com/s/bv6uwz38y2yp6uv/LightDensityPerAreaCalculator.gh?dl=0 -A.

[chriswmackey]

@ayezioro , this looks like a great and very necessary component!

I am having a bit of trouble understanding what the efficiency factor and the maintenance coefficient are. Could you write a more robust description for these inputs? Also, how are you accounting for the distance of the light fixture to the desk plane where you want the light level? If I was to move the lights away from the ceiling and closer to my desk, I could get 500 lux with a lot less energy. Lastly, is there any way that you could put in an option for an LED fixture? It seems almost all lights in the US are going to be that way within the next few years (by 2020).

[ayezioro]

Hi Chris, I also think this is a good one. I will write something in the description. I'm not accounting to the distance. Is just for the E+ loads calculator. Unless there is something i'm not aware of, E+ also doesn't take this into consideration. So you are only asked for the desired light level and the lighting characteristics, then the component will calculate the load. BTW, this is what we do for our research here, ... manually, so i decided to write this finally into something we all can use.

[chriswmackey]

@ayezioro , That would be great if you could write out some descriptions. Also it would be great to get a some sources in the component description, which also sounds like it might be a good opportunity to cite your own research :)

I am not sure if I was clear enough in my explanation of the distance. I know that 12 W/m2 of ceiling -mounted lighting that is 5 m above my head will be dimmer on my desk plane (maybe~350 lux) than a 12W/m2 desk lamp that is just 1 m above my head (maybe ~500 lux). If we want to claim that a certain W/m2 will deliver a certain light level in lux on the desk plane, it seems like we need to take this distance into account. Maybe you are already taking care of this in the efficiency and maintenance, though. I will wait for your component descriptions to discuss more.

And again, great work!

[chriswmackey]

@ayezioro , I have been thinking about this more over the last couple of days and realized that I should re-phrase what I mean again about the distance because I realize that the lighting in E+ is divided by the floor area.

A 60 W light fixture that is immediately above my desk (like a desk lamp) is going to help me light my desk a lot better than a ceiling-mounted 60W light fixture. Ultimately, a design that emphasized lighting at the desk level would thus probably save a lot more energy than one that emphasized ceiling lighting. Also, this might mean that someone is able to achieve 500 lux on the desks of the room for a much lower energy intensity than the one that your component gives. However, I realize that the average lux over the desk level of entire room might be close to what your component gives.

If the above is true about your component, I think that it is perfectly fine to commit it as long as you are clear about this assumption in the component description. So you might say something like "A value of 500 lux input to this component means 500 lux everywhere on the room floor plan and, while this is not the most efficient strategy for lighting the desks of a room, it is useful for getting a sense of the connection between lighting power density and desk light levels."

Let me know when you have the descriptions refined and I will show you how you can make a custom icon for your component so that you can commit it.

[ayezioro]

Hi Chris, I was/am also thinking about this issue. And your conclusions on the last comment are exactly mine. I will refine the descriptions accordingly to your suggestions. Saying that, i want to have some thoughts regarding the influence of the room's height on the load ...

[ayezioro]

Hi Chris, An updated version was uploaded into DB (same link). Definitions more sustented and documented. Need to say that my research don't deal with those definitions, just use them to define loads. I also added there an ACH to InfORventRate, just for the fun of it.

What do you think? -A.

[chriswmackey]

Hi @ayezioro , You are the man! The descriptions of the lighting density component are looking awesome. The only thing is that I get a bug when I try to run it now:

As for the ACH component, this is definitely something that is needed but I was imagining that people could input their HBzones instead of a number for volume and floor area. So the component would automatically calculate the volume and floor area of the zone (or maybe the average volume and average floor area of them if they input multiple zones) and then just spit out the m3/s-m2. I can add this capability onto your current component but this might be a nice opportunity to familiarize yourself with the structure of HBZones if you want to tackle it. You probably have a bit of a sense of how to calculate the volume of the breps using the stuff in RhinoCommon and I would look at the "Separate based on Type" component to see how you can call just the floor surfaces from the hive to get the floor area.

Also, I shared the grand dropbox illustrator file that has all of the icons in it. There you can make an icon for your components, which you can then bring into Photoshop to make a png to assign to the userobject. Let me know if you have any questions about this process.

[ayezioro]

Hi Chris, The bug is fixed now (same link). i will give the ACH issue a try ... but it will take some time. The priority is for the bioclimatic chart. I'll check the icons thing. Don't expect much problem, but i'll let you know.

Just for my curiosity, why inputing ACH is/was not the prefered option, and/or why not to define this as an option? In my research/development work i use it since it is much easy to comprehend. But also most standards use this measure to set the infiltration or ventilation rates. BTW the windows specifications describe the ACH they supply (I believe also in the US is the same). Thanks, -A.

[chriswmackey]

@ayezioro , I'm glad that the bug is fixed and I will check it out soon.

ACH is unquestionably the prefered option internationally across the entire building and construction industry. It is much easier to understand than liters/sec and way way easier to understand than this incredibly abstract m3/s-m2. I know the reason why E+ does it, though, and it has to do with the underlying mathematical means by which the energy model works.

It is very hard to do unit conversions in the middle of a dynamic energy simulation because, as soon as you get one value, you usually want to immediately multiply or add it to another one. For this reason, EnergyPlus uses the same units for everything to keep the units consistent while these dynamic operations are performed. So all spatial dimensions are in meters. All energy units are in Joules. All mass units are in kg. All time units are in seconds. All power units are in Watts. Any place where you do not see these units are areas where HB has intervened (for example the fact that the results of the energy simulation appear as kWh is something that the ReadEPResult component calculates from the raw E+ output, which is in joules). Deviating from these units to perform unit conversions in the middle of a dynamic energy simulation can increase the run time by an order of magnitude and this is why E+ chooses not to do it. Of course, this makes things very difficult for people like us trying to put correct inputs into the model but, if we can find opportunities to simply convert units before or after the simulation (like in the kWh of the ReadEPResult or your components), we can make this process a lot easier for us.

[ayezioro]

I added an icon. Not sure it is very clear ... suggestions == welcomed. I get all you explain but ... you can input ACH in E+ as one of the calculation methods (see below). That's why i wonder what is the reason of this m3/s-m2. I feel i'm missing something here. I assume HB is not accessing results in the middle of the calculations but only at the end. So the definition of the calculation method for infiltration/ventilation is not affecting the calculation. For instance: ZoneInfiltration:DesignFlowRate, basementZoneInfiltration0, !- Name BasementZone0, !- Zone Name InfiltrationAllTime, !- Schedule Name AirChanges/Hour, !- Design Flow Rate Calculation Method , !- Design Flow Rate {m3/s} , !- Flow per Zone Floor Area {m3/s-m2} , !- Flow per Exterior Surface Area {m3/s-m2} 1.5, !- Air Changes per Hour 1, !- Constant Term Coefficient 0, !- Temperature Term Coefficient 0, !- Velocity Term Coefficient 0; !- Velocity Squared Term Coefficient

[chriswmackey]

@ayezioro , You are correct that E+ allows you to input ACH and thank you for reminding me:

I guess that, for static variables like this, E+ just converts the ACH values to m3/s before running the calculation and this doesn't increase the simulation time much. However, for the OpenStudio libraries, the design flow rates that are assigned based on the zone program templates are all in m3/s-m2 and this is why our components are currently like this. I guess that, When OpenStudio adopted these validated libraries, the field studies all measured flow rate in m3/s-m2. Or maybe they measured it in m3/s and then divided it by the floor area of the zones. For our components, we can change the design flow rate over to ACH if the user puts in a value in the "SetEPLoads" component. The only issue is that, to keep things consistent, we need to output ACH from the setLoads component currently. If we have the zone geometry from the HBZones input, we should be able to do this. @mostaphaRoudsari , what do you think about this?

[ayezioro]

Ohhh, Open Studio i don't know. So maybe there is nothing to do but translate to units they understand. Thanks for the explanations. -A.

[chriswmackey]

@ayezioro, I am just letting you know that we intend to include the lighting density per area calculator in the upcoming stable release and I have committed a preliminary version. I hope you don't mid that I added some of the information that you had gathered in the neighboring list component to the description of the component input. I also put in a default bulb type of florescent tubes and default maintenance values that correspond with information that you had in the descriptions (Since I imagine that I will not know these values exactly until the end of a project, more often than not). If the component in this file looks ok, we should be all set: https://www.dropbox.com/s/d8wi93w9ee5lkf6/LightDensityPerAreaCalculatorCWM.gh?dl=0 -Chris

[ayezioro]

Great. If you see the file in: https://www.dropbox.com/s/pkiw2rvrjkvn9vt/ACH2m3_s-m2%2BLightDensityPerAreaCalculator.gh?dl=0 I updated the file according to your new defaults but there is also a component ACH2m3/s-m2 Calculator, so you can give ACH and it will calculate for you the m3/s-m2, which i find much more complicated to know. If you find this component useful you can include it also. -A.

[chriswmackey]

@ayezioro , Excellent job! I committed both components to the "08 | Energy | Set Zone Properties" tab and they are good to go for the next release. As such, I am closing out this issue. -Chris