Use the forum to ask or answer questions about Part B. Please check the current contributions and any summary below before asking a new, possibly duplicate question.

Q&A about Part B: solution approaches, problems, programming issues.

Getting started. Part A was about building and testing the components for an application, Part B puts it together. This time data is on the SolarPos sheet, and when the Calculate and Show button is pressed your CalculateSolarPositions subprogram is called. That's where you start. As a first experiment, try to store the contents of the cell named latSP into a variable of the same name, and prove you've read it right with MsgBox. The comment before the subprogram tells you about accessing cells by name, and the names are listed at the bottom of the sheet. Then do the same for all inputs. See this post for what to do next.

Summary, Tue 03 May.

  • The most common reasons for getting the sunrise/sunset times wrong are (a) forgetting to change the sign of the longitude value [see yellow box in NOAA document], or (b) forgetting that ACos returns radians, but we need degrees.
  • The sunpath loop is effectively, NewSunPath, then for a range of times: calculate solar position for that time and pass them to ExtendSunPath. After the loop, ShowSunPath will display the positions as a dash-dot line.
  • In formulating the loop to draw the sunpath, you should use minutes as your counter, as SUNPATH_INTERVAL is in minutes
  • If you intend to do a full recalculation of solar position, you'll have to convert minutes back to days to add it to the date.
  • However, you don't need to. You can keep the old decl and eqtime values calculated for the time on the sheet, they're close enough for plotting purposes. That means the first calculation to do is true solar time, and you can pass the whole time in minutes to TrueSolarTIme along with zero hours: that function converts hours and minutes back to minutes anyway!
  • Of the 2.5 marks (out of 20) for the sunpath, only 0.5 relates to the near-polar midsummer case (sun always visible). If you want to display all possible paths, your loop should try all times over 24 hours, and decide from the calculated elevation whether or not the sun is visible. Otherwise sunrise to sunset will work for "normal" cases.
  • Display the sunpath regardless of the animation status. Animation is not assessable, if you're short of time or bored with this assignment (surely that's not possible :).

Summary, Fri 29 April. Some of these (*) are common to Part A, but read carefully anyway.

  • * Be very careful about variable names, they must not be the same as function names , or you will confuse the interpreter about what you mean. Use a shortened form.
  • The daylight saving value should be used to adjust the effective time zone, not the time itself.
  • * If you compare results with the web calculator, Sydney's coordinates have more precision (6 decimal places) than shown on the sheet by default, expand them before copying.
  • * At extreme latitudes there will be slight differences in elevation angle between the web calculator and your answers.
  • * You will get a better match with the spreadsheet version , except that it normalises true solar time to the range 0 to 1440 (24 hours), you should not do so.
  • Calling the drawing procedures .


Resource created Thursday 14 April 2016, 09:58:59 AM, last modified Tuesday 03 May 2016, 10:37:59 AM.


Back to top

ENGG1811 16s1 (Computing for Engineers) is powered by WebCMS3
CRICOS Provider No. 00098G