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


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

Summary, Fri 29 April. People are encountering some more subtle problems now. Please read carefully.

  • 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.
  • Similarly, make sure you correctly spell the parameter names when you use them, and don't accidentally substitute the equivalent function names (TrueSolarTime instead of tst, or ZenithAngle instead of zenAngle).
  • There are some errors in the data on the Cities sheet or how it's used, affecting Anchorage and Adelaide (wrong formula), and Bangkok and Jakarta (wrong time zone). You can either fix them or use other cities for testing.
  • 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.
  • The shadow length should be calculated in full as long as it's positive. The MAX_LENGTH constant is only used in Part B.

Summary, Tue 26 April. Please read carefully.

The most common recent issue is a run-time error in SolarAzimuth, caused by using the built-in functions sin and cos rather than DSi n and DCos . Don't just blindly copy the formulas, interpret them in the context of the problem being solved. sin requires radians, DSin degrees. You will have to make one conversion, from the radians that ACos returns to the degrees required.

Summary, Fri 22 April. Please read carefully.

  • Getting started, hints here .
  • The statements in your functions may only use the function parameters and named constants in the Common module. If it looks like something's missing, you don't actually need it, such as seconds in the second equation , or you've misinterpreted what to do .
  • Reasons for the change of signs in the first equation.
  • The only way to test your functions is with the FuncTests sheet. The formulas will have all the required data, and only call up your function when you're ready (that's what the Calculate? column is for).
  • Things you must not do:
    1. Do not change the function headers. Ever. We have provided them so you can use the FuncTests sheet and we can assess everybody objectively.
    2. Your functions must not refer to anything on a sheet. If you do you can't use them in Part B and we can't test them. Part B is about getting values from the sheet.
    3. Don't try to test a function by pressing the blue arrow in the editor. That only works if the first procedure in the module is a macro (subprogram with no arguments). The result is a message telling you that there are insufficient arguments.
    If you don't follow these simple rules, we won't be able to test your assignment normally, the assessment will be delayed, and it will cost you marks.
  • Using formula functions (WorksheetFunction.ACos etc).
  • The solar azimuth can be in any direction, but the inverse cosine returns an angle between 0 and pi. Read the discussion , but you should try to resolve this one yourself, the hints are clear.
  • Checking answers against the web calculator.
  • Note: the Sydney coordinates have more decimal places than displayed on the FuncTests sheet, so make sure you copy them all to the web calculator.


Resource created Thursday 14 April 2016, 09:56:26 AM, last modified Friday 29 April 2016, 08:53:14 AM.


Back to top

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