Solar Azimuth & Altitude - Incorrect Values

[TomJ]

Hi.

I am trying to create a solar position routines using Dynamo 1.3.1. I am successfully getting results from Dynamo but have sense checked them to ensure that they are accurate. Unfortunately, when comparing these values to the US National Oceanic & Atmospheric Administration (NOAA) and US National Renewal Energy Laboratory (NREL) solar positioning figures, there are large discrepancies. Both NOAA & NREL agree closely with each other. Attached are screenshots of the necessary information that highlights the differences between Dynamo & NOAA’s values.

The NOAA solar positioning website here: NOAA Solar Positioning:
The NREL documentation and code is available here: NREL Solar Positioning Documentation and Code

[Vikram_Subbaiah]

@TomJ Your site location is the screen shot is in the UK, while your link points to a location in the US.
Check if your site location is correct in the Revit project.

[TomJ]

Pretty confident that the Revit and dynamo project locations match (see attached image).

[TomJ]

The above images show that:

Source Azimuth Altitude
Dynamo 130.21… 52.42…
NOAA (exc DST) 140.71… 38.87…
NOAA (inc DST) 124.44… 32.02…

I feel that Dynamo should match one of the NOAA outputs.

[Yna_Db]

Your time zone should probably not be 0. On my side, I get identical results if DST is unchecked, which could reveal a limitation of the Revit analysis tool.

[TomJ]

Cheers for the input Yna.

I am confused as to why this the time zone would be anything other than 0, given the UK is based in Greenwich Mean Time (GMT), which is 0 too.

[Yna_Db]

Sorry, no idea about that, could be related to summer and winter time. Try with 1 to see if it matches, someone else could have an explanation…

[TomJ]

I should clarify that technically the UK is UTC/GMT between November and March (Timezone = 0) and UTC + 1 between April and October (Timezone = 1).

This is automatically incorporated within a “Daylight Savings Time” (DST) option. If a DST or similar option be available, then this should take precedent over the above paragraph or manual timezone adjustments.

[Yna_Db]

OK, it does not look like a Dynamo issue. Just for information, which number returns the correct result for you?

[TomJ]

NOAA (inc DST) 124.44… 32.02…given the reading was taken in British Summer Time.

As a side point, there appears to no link between the “Sun Settings” and “Site Location”. Is this correct?

[Yna_Db]

I have read this from here:
“When you create a project it is possible to specify the geographic location using the street address or the latitude and longitude. This is useful for generating location-specific shadows for views that use them, such as daylight studies. The location provides a basis for weather information, which is used during daylight analysis.”

But for a more accurate information, the best would probably be to ask real specialists such as Honeybee developers:

New packages for ladybug and honeybee are available!

[output_qqeMnL] The truth is that I personally was never happy with the current packages of Ladybug and Honeybee for Dynamo. Ladybug had major performance issues because of using Dynamo geometry libraries and Honeybee was limited to point in time analysis. The new packages address the performance issues in Ladybug and provides an extensive set of nodes for Honeybee. That said, there are a number of known issues in the current release which are mostly because of limitations in Revit and Dynamo: …

[Mostapha]

I’m not sure how can I help with this topic but just in case Ladybug has a node which you can use to create a location from your inputs and can be useful if one is interested to study the effect of each parameter.

PS: There is slight difference between Ladybug’s sunpath algorithm and NOAA’s algorithm in the current release (0.1.9) which has been addressed and will be fixed in the next release.

[M.Perez]

It seams that Revit doesn´t manage DST the way we expected:

https://forums.autodesk.com/t5/revit-ideas/wrong-simulations-daylight-saving-time-dst-summer-time-properly/idi-p/7937388

[TomJ]

All.

I know that I haven’t replied to this topic in nearly a year and therefore it may have been rectified in subsequent releases of both Revit & Dynamo. However, with the addition of “Zero Touch” nodes in Dynamo, I have been able to implement the solar positioning code that initially provided the results that spawned this thread.

The open source code file are available from the US National Renewable Energy Laboratory (NREL) with an accuracy of zenith/azimuth angle between 0.00003° and 0.00008°!!! Better than my possible efforts. The documentation supporting this is available via:

34302.pdf

I have excluded the Daylight Savings Time (DST) aspect given the complexities of which country actually uses it, the date at which DST is applied, the time shift applied due to DST. Issues exists in Revit as outlined by M_Perez. The DST can be manually altered by changing the “Timezone” input by the requisite figure.

My results align with the NOAA website to within 3 seconds (at worst). The NOAA website rounds some figures to the nearest minute and doesn’t allow for elevation, pressure or temperature change that the NREL does. Therefore I feel comfortable the results from NREL (and thus Dynamo node) are superior to NOAA.

I have published on the Dynamo Package Manager, named “Solar Positioning (NREL)”. Please let me know if this cannot be found or is not performing as expected. This only allows for a single result set to be returned, not nested, which limits it helpfulness a lot. I’m aware of the ‘ArbitraryDimensionArrayImport’ option but do not know how to apply this to a multi input & output nodes. I also tried a single nested version (commented out in the attached files) but again, lack the knowledge to achieve this. Anyone able to answer this?

The relevant C# source files are also attached for ease (you will need to change the file extensions from “.txt” to “.cs”).

Regards, Tom.

Positioning.txt (11.6 KB)
SPA.txt (48.8 KB)