Having read Kimia’s comment, I made a new potential component that finds sunrise, sunset for anyplace on earth using equations from Astronomical Algorithms, by Jean Meeus. Besides these two output, it calculates the solar position (elevation angle and azimut) considering the atmospheric refraction. I saw the difference between solInitOutput (based on Radiance) and the script that I wrote (based on NOAA). Some formulas are the same, while others are different. for example “Julian day”, “solar altitude”… Anyway, they are two different models. At the moment the imputs are: 1) location 2) analysis period 3) year and the outputs are: 1) civil twilight 2) official sunrise/sunset 3) solar elevation angle 4) solar azimut This is an example where I used data of a real place.
and these are two photos that I took in this place.
SUNRISE (Civil Twilight) 06:44 AM
SUNRISE (Official) 07:14 AM Note that in the first photo the street lights are on, while in the second are off because of the good level of luminous energy. I hope that it could be useful.
Certainly! Thank you! The good thing is that you can change the year from -1000 to 3000. I was thinking to use some outputs of it to make artificial light schedules for Honeybee. But I don’t know if it is a good idea. What do you think about?
Antonello,
This component should definitely be integrated into the code base and you should feel free to send a pull request when you get the chance. I think it might be better to have this component as separate from the sunpath as the sunrise/sunset is at a higher temporal resolution than the typical hourly logic of the sunpath. If anyone has an argument to the contrary, please post here.
Along the lines of what Abrahm mentions, the current sunpath code is the same as the NOAA code and we verified it in this old github issue:
I know that the comments around the solinitoutput code say that the code is from the radiance sunpath but this is outdated and we should erase that comment. Accordingly, it would be great, Antonello, if your component could reference this NOAA function in Ladybug_Ladybug if it is possible. This way, we can avoid having several copies of the same code and together improve the same sunpath function instead of separate incompatible copies.
Also, I should note that the LB_LB NOAA function has an input for “year” but we always set this to the current year as the solar position is fairly constant from year to year and we have yet to encounter someone wanting to see the sun position a millenuim I to the future/past.
Thank you for your reply. I have to do the latest checks so I can send my pull request.
I have made other two component, I have studied a method to make HB schedules faster than the actual method.
Below, I descibe how they work:
drag “scheduleDay” onto the canvas
drag some Gene Pool lists onto the canvas and connect a number slider - from 0 to 3.
connect the Gene Pool list to _genePool input. The component change some important features of the Gene Pool list automatically. Now you have LB_GenePool!!
choose the template that it’s suitable for you.
disconnect LB_GenePool and if templates are not good, you can change them manually
drag “Ladybug annual schedule” onto the canvas
Connect LB_GenePools to inputs for the days of the week, Epw file and if you want to “_holiday” (in this way you consider holidays). Now you have your simple schedule.
a small workflow to visualize it into Rhino…
Connect “Ladybug annual schedule” to “Honeybee_Create CSV Schedule” to make your csv Schedule
You could make a schedule more complex than the one in the example above.
Thanks Antonello for creating this component. It’s great! I have a small suggestion for the component inputs. I suggest to change the input from AnalysisPeriod to DOYs. User can input values between 1-356. In this case user can match the number of inputs for days to number of output values. As you probably know Ladybug has a component to calculate DOY for any date.
I see that the components are already in the github. Thanks and good work.
Just a small remark: aren’t they supposed to be in the HB tab instead of LB?
And one suggestion: i would add in the DailySchedule component a couple of inputs more with minimum/maximum values of the schedule since not all of them are in the 0-1 range.
some changes are necessary: 1) move the components to HB, as you and Chris suggest me 2) do a small reseach about holidays and find a system to change them based on country. It’s almost impossible do that for each country. I have to make a couple of avarage-holidays data. 3) Optimize two components, perhaps combine the their functionality into one component. 4) Maybe, insert a “shift function”. For example I want my schedules start with Monday, or Tuesday and so on.
following your suggestions, I have already changed HB daily schedule and HB annual schedule.
They seem very useful now. I also wrote a big list of holidays by country that is compatible with names of EPW files. Thus users can generate holiday DOYs automatically. In addition, I wrote an overwrite function that let users change holidays DOYs list manually or write directly without importing EPW files.
I did not found holidays of these following countries: BLZ (CENTRAL AMERICA) BRN (SOUTH PACIFIC) GUM (SOUTH PACIFIC) MHL (SOUTH PACIFIC) PLW (SOUTH PACIFIC) UMI (SOUTH PACIFIC) https://energyplus.net/weather
Moreover, it is possible to connect daily schedule to Galapagos component, so it can also answer some strange questions. For example, what is the ideal daily occupancy schedule for this type of building in this specific country?
I have attached an example to have a look at HB daily schedule & HB annual schedule.
I have to modify it, I want to make it faster than now. And I need to write some parts differently.
Anyway, it can calculate sunrise/sunset time of HOYs without passing through sun path component (to increase the speed of calculation), and other important properties of the sun, especially if you want to consider minutes, seconds… (e.g. 13:58:05).
In fact, I should add sun vector output and, maybe, other specific functions linked to daylight schedules.
Yeah, sun vectors would be nice. First thing that comes in mind is these really annoying dawn/dusk sun rays that shine in your eyes if you are lucky to sit next to a window XD. Would like to be able to address this issue in a building design, less glare s always better. But I guess it is only applicable to rural areas in most cases.
Thanks for the work and the reply, I appreciate this.
Tim,
We should also clarify that Antonello’s component calculates the solar position to a higher accuracy than the function which drives all other solar position calculations in Ladybug (including the LB sunpath). However, Antonello’s component takes about 2 minutes to calculate 8760 values (a position for each hour of the year) and so it is not really practical to replace this primary function with Antonello’s higher accuracy one.
The difference in accuracy is on the level of seconds and so this discrepancy in position really does not make much of a difference for the vast majority of applications. The exception is the calculation of sunrise and sunset, where the difference of a few seconds can be particularly important. So I think that it is appropriate that we have Antonello’s component that is generally meant to calculate higher accuracy sun positions for special situations and for sunrise / sunset while the rest of Ladybug uses the quicker current function
Mostapha, let me know if you agree with this and I would be interested in hearing anyone else’s thoughts.
-Chris
Agree with Chris. Not much to add. The existing LB components are for the “heavy duty” needs, where you want good accuracy and fast results. Antonello’s is more the cherry on top of the cream, as for high accuracy is related. Can be very useful for very determined tasks.
and these are two photos that I took in this place.
SUNRISE (Civil Twilight) 06:44 AM
SUNRISE (Official) 07:14 AM
