Recent

Author Topic: (SOLVED) tmoon_laz bug  (Read 4488 times)

Bert_Plitt

  • Jr. Member
  • **
  • Posts: 62
(SOLVED) tmoon_laz bug
« on: December 24, 2019, 04:37:24 am »
Hello Folks --

I am a novice Pascal coder working in Windows 10, Lazarus v 2.0.6, FPC v 3.0.4.  I plan on writing an application for which the Laz package called "delphimoon" (tmoon_laz.lpk) is perfect for my use.  The original package was written for Delphi by Andreas Hörstemeier.  I downloaded from this site [https://github.com/Ahoerstemeier/delphimoon] the latest available version (The latest I could find, 13-Feb-2018, which includes a translation from Delphi to Lazarus/FPC).

Before using the package in my application, I compiled and began testing the demo "NewMoonTool".  I think I discovered a bug in the demo in the calculation of "Sun Transit" for certain date/location combinations that I have not been able to track down.  Can anyone find the problem and provide a fix?

Here is the issue:
Package:  tmoon_laz.lpk
Application:  "NewMoonTool" or moon.pas
Example Location:  W 77° 0' 0",  N 39° 0' 0"
Example Dates:  2019 Dec 7 through 10

ERROR:  Sun transit displays "---", should be approx "17:00 UTC"

Most other Date/Location combinations produce correct results.
(There may be other Date/Location combinations that fail.)

Any assistance would be greatly appreciated.
« Last Edit: December 24, 2019, 06:19:13 pm by Bert_Plitt »
Windows 10, Lazarus 2.2.2, FPC 3.2.2

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: tmoon_laz bug
« Reply #1 on: December 24, 2019, 08:49:48 am »
You should report that bug with a description and minimum compilable project showing the error to the bugtracker. What you can do, is to try to debug a little. Like searching for a location of those --- in package units, looking at code that executes before that, and putting some breakpoints in order to try to understand why some dates produce correct results and some produce '---' string results. Hopefully that would lead to a bug fix which could lead to your first Lazarus patch. Or... you can just sit and wait with your fingers crossed in a hope that package maintainer will see your forum message.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

wp

  • Hero Member
  • *****
  • Posts: 11857
Re: tmoon_laz bug
« Reply #2 on: December 24, 2019, 10:05:30 am »
What did you do with the NewMoonTool to get the error? As far as I can see the location is determined by the selection of cities, there is no way to enter gps coordinates directly.

[EDIT]
Ok - this code reproduces the issue:
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. uses
  4.   SysUtils, moon;
  5.  
  6. const
  7.   lon = 77.0;
  8.   lat = 39.0;
  9. var
  10.   dt: TDateTime;
  11.  
  12. begin
  13.   dt := EncodeDate(2019, 12, 7);
  14.   WriteLn('   Sun rise: ', FormatDateTime('yyyy-mm-dd hh:nn:ss', Sun_Rise(dt, lat, lon)));
  15.   WriteLn('Sun transit: ', FormatDateTime('yyyy-mm-dd hh:nn:ss', Sun_Transit(dt, lat, lon)));
  16.   WriteLn('    Sun set: ', FormatDateTime('yyyy-mm-dd hh:nn:ss', Sun_Set(dt, lat, lon)));
  17.  
  18.   ReadLn;
  19.  
  20. end.
« Last Edit: December 24, 2019, 10:31:26 am by wp »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: tmoon_laz bug
« Reply #3 on: December 24, 2019, 10:21:33 am »
If this is the astronomical New Moon, i.e. relative to the centres of the Earth, Sun and Moon, and if the timing is UTC, then I don't even see why the location is relevant.

If on the other hand it's related to observation of the New Moon to determine the start of the Jewish month, or is for eclipse calculations... can't you find something easier to torture yourself with? :-)

I've done a bit of this stuff (transcribing code which I think ultimately originated from Meeus). One of the problems was that the maths was sufficiently hairy that the results were platform specific... not grossly so, but things like a seasonal offset of ~3 mins for Sunrise/Sunset after correction for refraction etc.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Bert_Plitt

  • Jr. Member
  • **
  • Posts: 62
Re: (SOLVED) tmoon_laz bug
« Reply #4 on: December 24, 2019, 06:20:41 pm »
Found a fix for the bug.  There appears to be a problem with the default version of the function "Calc_Set_Rise" (or one of its sub-functions) in Unit "moon".  When I added the directive (*$define meeus *) to Unit moon, the problem went away.  I did not investigate any further.
Windows 10, Lazarus 2.2.2, FPC 3.2.2

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: tmoon_laz bug
« Reply #5 on: December 24, 2019, 06:41:26 pm »
If this is the astronomical New Moon, i.e. relative to the centres of the Earth, Sun and Moon, and if the timing is UTC, then I don't even see why the location is relevant.

If on the other hand it's related to observation of the New Moon to determine the start of the Jewish month, or is for eclipse calculations... can't you find something easier to torture yourself with? :-)

I've done a bit of this stuff (transcribing code which I think ultimately originated from Meeus). One of the problems was that the maths was sufficiently hairy that the results were platform specific... not grossly so, but things like a seasonal offset of ~3 mins for Sunrise/Sunset after correction for refraction etc.

MarkMLl

Sideric and synodic moon - everyone should have learned that in school.

And as a hobbyist it should be enough to take the first 19 to 23 equations to get an exact result.
The NASA has a very lot more!

Winni

 

TinyPortal © 2005-2018