{"action":"created","issue":{"url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/issues/150","labels_url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/issues/150/labels{/name}","comments_url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/issues/150/comments","events_url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/issues/150/events","html_url":"https://github.com/mostaphaRoudsari/ladybug/issues/150","id":88088246,"number":150,"title":"Suggestions for improving set of Photovoltaics components","user":{"login":"stgeorges","id":4411411,"avatar_url":"https://avatars.githubusercontent.com/u/4411411?v=3","gravatar_id":"","url":"https://api.github.com/users/stgeorges","html_url":"https://github.com/stgeorges","followers_url":"https://api.github.com/users/stgeorges/followers","following_url":"https://api.github.com/users/stgeorges/following{/other_user}","gists_url":"https://api.github.com/users/stgeorges/gists{/gist_id}","starred_url":"https://api.github.com/users/stgeorges/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stgeorges/subscriptions","organizations_url":"https://api.github.com/users/stgeorges/orgs","repos_url":"https://api.github.com/users/stgeorges/repos","events_url":"https://api.github.com/users/stgeorges/events{/privacy}","received_events_url":"https://api.github.com/users/stgeorges/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/labels/wish","name":"wish","color":"e102d8"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-14T00:12:14Z","updated_at":"2015-06-14T13:34:07Z","closed_at":null,"body":"Hi @chriswmackey , @mostaphaRoudsari , @antonszilasi \r\n\r\nAs Mostapha suggested, I am continuing an email conversation in here, related with suggestions on improving Photovoltaics components.\r\n\r\n\r\nHi Chris,\r\n\r\nThank you for the reply and all the thorough comments and suggestions.\r\n\r\nI can not commit new files to github, as I can not install github application. It requires Windows XP >, and on my PC I have Windows XP.\r\nI tried using other github client (older version of smartgit) but without success. Mostapha suggested using Tortoise git, I see if I could wrap my head around its way of working in the next period. So I have no problem with you (or Mostapha) committing the files.\r\n\r\n> 1) I would strongly suggest just condensing all of these epw inputs into a single \"_epwFile\" input and you just parse the epw file inside the photovoltaics surface component\r\n\r\nYes, your recommendation definitively has a point. As you remember I had _epwFile input for the \"Wind boundary profile\" component last year. Then I realized that it is much quicker (in terms of component solution speed) to have separate weather inputs than unpacking the epw file weather data inside the component. On my PC \"unpacking\" epw file within the component added 2.6 seconds to the overall component solution time. If I remember correctly your PC was a couple times faster than mine. I know you mentioned that it was a couple of years old. Still I imagine that this is according to USA standards. Out of USA, there may be more people with PC speeds like mine.\r\nNevertheless I replaced all weather inputs with single epwFile one, as you recommended. Maybe we won't get any speed complaints, let's see how it goes.\r\n\r\n> Along the lines of minimizing inputs, I question whether anyone is going to want to input a numeric tilt angle and azimuth angle\r\n\r\nThese two inputs are for advanced users. Instead of surface, (or numeric value input of surface area), one can input system size/nameplate rating of a PV array/module instead. This is in fact how PVWatts works, it does not take surface area as an input. When system size/nameplate DC rating is inputted, tilt and azimuth angles have to be defined manually.\r\n\r\n\r\n>2) A lot of your outputs on the \"photovoltaics surface\" component are just taking the same data and expressing it in different ways and we already have Ladybug components to help users parse through data as they wish so these outputs are a bit redundant.  I understand if you want to provide both an hourly and an annual output for the AC energy as I know this energy is the most important output and users might want a quick-access total of the energy.\r\n\r\nRadiation values are also part of the AC energy analysis. To keep the results consisted, I have to use the Michalsky and Perez position/solar radiation results, not the ones implemented by other components. Still I will listen to you. I would still keep the \"totalRadiationPerHour\" as it is required for \"Photovoltaics performance metrics\" component.\r\n\r\n>However, users can get the monthly values by using the other LB components and so I do not think it is necessary to have them as outputs. \r\n\r\nI would say it is far better to have a single output calculating monthly values than having to use the Ladybug's \"Average Data\" component along with \"Analysis Period\" component just to extract a single monthly value. Monthly values are a significant part of AC energy analysis.\r\n\r\n>Also, if a user really wants the total or average daily radiation for the year, they can use the native GH mass addition or the Ladybug Average Data component so these outputs are really redundant.\r\n\r\nI would comment the same on this, as with upper suggestion: It is much more convenient to have them as an output than requiring the user to use the upper mentioned two Ladybug components.\r\n\r\n>Furthermore, the surface area of the PV is really not too helpful as users can use the native GH area component to calculate this. \r\n\r\nThis is actually a result of multiplication of \"PVsurface\" with \"PVsurfacePercent\" input parameters, not the actual area of the \"PVsurface\" alone. I fixed the description and the actual name of this input, thank you for noticing the mistake. \r\n\r\n>Finally, I don't think that you need quite so many dividers for these outputs once you narrow down the number of outputs.\r\n\r\nThis is a personal preference, to divide different types of output parameters, but then again I removed 2 out of 4 of them, due to your suggestion and removal of some of the mentioned previous outputs. Thank you.\r\n\r\n>3) You might want to put in a check on the \"Sunpath Shading\" component to make sure the component does not run with null values connected for geometry (see attached GH file).\r\n\r\nFixed it. Thank you.\r\n\r\n>4) I am guessing that the black in the \"SunpathShading\" component refers to areas of the sky blocked by the context geometry but it would be great to see exactly what this means in the legend (does this mean the annual AC percentage is 0?)\r\n\r\nCheck the \"sunWindowMesh\" output explanation. Black areas represent the 100% shaded portions of the sun(solar) window. It does not matter whether or not that particular part of the sky dome \"generates\" AC energy or not (or solar radiation if you are using the component for other non-Photovoltaics purposes).\r\nI added three new blocks to the legend: Shading from \"context\", \"coniferous trees\", \"deciduous trees\". Inserting transmission indices would require differentiating between deciduous inleaff and leafless trees, which is something that would cause confusion in the sunpath diagram. I would rather not add these, and keep the present edited state.\r\n\r\n>5) The way that you have setup the workflow in the example file causes a recursive loop, which Grasshopper intrinsically hates (see the second GH file).  \r\n\r\nYou skipped the steps 4, 5 in the old \"B_shaded_analysis_PhotovoltaicsSurface.gh\" file.\r\n\r\n>Is there any reason why we could not just get an adjusted ACenergyPerHour output from this component instead of having to plug it back into the old workflow?\r\n\r\nNo, the annual shading value has to be returned to the losses component.\r\n\r\n>Reducing all annual shading to a single percentage seems to be an oversimplified way of accounting for shading effects anyway.\r\n\r\nThat is the way PVWatts works, it accounts for all the losses (age, wiring, soiling, shading...) in a single loss parameter. A more precise shading data would be using \"beamShadingPerHour\" (I changed its name to \"beamIndexPerHour\" as it is in fact transmission index).\r\n\r\n\"Sunpath shading\" basically uses two methods: one hourly - to analyse for sun position blocking, and all the rest ones (annual, autumn-winter, spring-summer) by using the Sunpath diagram method described in the mentioned paper, in components description.\r\nSunpath diagram method described in the paper, essentially tries to replication what [Solar pathfinder tool](http://www.solarpathfinder.com/PF) and application does - it takes a snaphot of the sky dome, and checks for the obstructions within a sun(solar) window, based on blocking of particular sun window's active quadrants.\r\nI am not an engineer, nor this was my field of study. Reading a book or two, and a couple of papers does not make one an expert in this field. Maybe Anton could explain more on the shading issue in detail. In general shading of Photovoltaics is a complicated area. It depends on a lot of factors.\r\nIt depends on the time and position of shadows from nearby context objects traveling across PV array. Cloud cover, air pollution and haze. The way modules or arrays are connected. Whether or not PV panels have by-pass diodes, micro-inverters, power-optimizers. \r\nNeither PVwatts, PhotovoltaicsSurface component (based on PVWatts), Solar pathfinder, nor [SunEye](http://www.solmetric.com/buy210.html) address this issue. I doubt we will ever have something this sophisticated for Ladybug+Honeybee.\r\n\r\nSo the final conclusion is that \"beamIndexPerHour\" method underestimates the shading. It can be used though as more precise when one considers a PV array to be \"unshaded\". The annual version on the other hand is a bit conservative meaning it yields a bit larger shading results. In general it can overestimate the shading of \"unshaded\" PV arrays. But in real life world, unless you are constructing a PV array in the middle of Salar de Uyuni, you will always have some percentage of annual shading, ranging from 3-5%. That is why we decided to stick with the conservative method for Photovoltaics. And to use an hourly (\"beamIndexPerHour\") for Solar hot water collectors and shading analysis of any other Ladybug+Honeybee components.\r\n\r\n>BTW, I noticed that I get a null output for the beamShadingPerHour when I plug in the ACenergy.  Is this supposed to happen? \r\n6) I also noticed that I get null outputs for most of the other shading outputs on the \"SunpathShading\" component when I do not plug in an ACenergyPerHour.  Maybe a tutorial video or something could clarify how I am supposed to use the components because I feel like I am doing it wrong now or at least not understanding  why I only get certain outputs in certain cases.\r\n\r\nYes it is suppose to happen. At least I thought so.\r\nI tried to differentiate between shading data for Photvoltaics and for Solar hot water and other purposes. Now that you have mentioned maybe this is a bad idea. I included \"You need to input ACenergyPerHour\" to all outputs which require this data to be inputted, in order for them to be calculated.\r\nYes of course, video tutorials are going to follow, once the components are released, and I get some spare time.\r\n\r\n>7) Again, it seems like you have a lot of redundant outputs on the \"SunpathShading\" component.  Users can calculate a Sep21toMar21Shading using the native GH components if they want.\r\n\r\nYou can not get it by using native grasshopper components, due to differences in methods used to generate the shading values.\r\n\r\n>They can also get the WindowCentPt with the native GH components.  \r\n\r\n\"sunWindowCenPt\" output resembles the \"sunPathCenPts\" output of the Ladybug \"Sunpath\" component. I do not see an issue with this principle, of having a center point for the overall geometry as an output.\r\n\r\n>Finally, I don't think that we are gaining all that much form the hours and hour positions here that users could not get by using the Ladybug Sunpath component.\r\n\r\nAre you suggesting using Ladybug \"Sunpath\" component along with \"Sunpath shading\" just to mark the solar time hours of \"Sunpath shading\" sunpath diagram? That sounds a bit exaggerated, at least to me. I do not see a problem in marking solar hour positions, they are actually beneficial.\r\n\r\n\r\n>8) The analysisPts and quadrant centroids are useful for understanding how the component runs but I imagine that users do not really want to see it all of the time.  I would hide them as an output such that users only see them if they connect them to a grasshopper Point component.\r\n\r\nThe whole \"Sunpath shading\" component is hidden (\"Preview\" turned off) by default, so neither of these two are seen. I personally think this is a better, universal solution than hiding particular outputs.\r\n\r\n>9) The sunWindowShadedArea output is really misleading because it seems to be a percent - not an actual area in rhino model units.\r\n\r\nYou are right. I will change its name to \"sunWindowShadedAreaPer\". Thanks.\r\n\r\n>10) as recommended previously, take out the hourPositionsScale.\r\n\r\nI do not see a need for its removal. Increase the \"scale\" input parameter of the \"Sunpath shading\" component and you will see why having \"hoursPositionScale\" input is important.\r\n\r\nHere are the newest revised example files according to suggestions:\r\nhttp://www.megafileupload.com/8ODX/Ladbybug_Photovoltaics_exampleFiles.zip\r\nMostapha, I send you the .ghuser and .py files to your email few minutes ago.\r\n\r\nOne more time, thank you for the advices and suggestions Chris. They have really been helpful in making these components far better and useful.\r\n"},"comment":{"url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/issues/comments/111827348","html_url":"https://github.com/mostaphaRoudsari/ladybug/issues/150#issuecomment-111827348","issue_url":"https://api.github.com/repos/mostaphaRoudsari/ladybug/issues/150","id":111827348,"user":{"login":"stgeorges","id":4411411,"avatar_url":"https://avatars.githubusercontent.com/u/4411411?v=3","gravatar_id":"","url":"https://api.github.com/users/stgeorges","html_url":"https://github.com/stgeorges","followers_url":"https://api.github.com/users/stgeorges/followers","following_url":"https://api.github.com/users/stgeorges/following{/other_user}","gists_url":"https://api.github.com/users/stgeorges/gists{/gist_id}","starred_url":"https://api.github.com/users/stgeorges/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stgeorges/subscriptions","organizations_url":"https://api.github.com/users/stgeorges/orgs","repos_url":"https://api.github.com/users/stgeorges/repos","events_url":"https://api.github.com/users/stgeorges/events{/privacy}","received_events_url":"https://api.github.com/users/stgeorges/received_events","type":"User","site_admin":false},"created_at":"2015-06-14T13:34:07Z","updated_at":"2015-06-14T13:34:07Z","body":"@mostaphaRoudsari \r\n1. I should have googled first. I apologize. Looks like it was Rhino 5 SR <10 that was causing the issue. Versions 10 >= [do not show this behavior](http://www.grasshopper3d.com/forum/topics/losing-internalised-data?id=2985220%3ATopic%3A1007892&page=1#comments).\r\nStill for us with older versions (I have SR 9 and SR5) wouldn't it better to skip all the hassle about reporting, and just ship both .gh and .3dm files altogether, but having breps internalized in .gh files?"}}