Recent changes to bugs

Outdated config.guess and config.sub file in the source of project libnova.

Yuluo — Wed, 17 Jul 2024 03:21:26 -0000

I am trying to build libnova for riscv64 architecture.
But got a build error, it caused by outdated config.guess and config.sub file.
Could it be updated and have a new release?

ln_lunar_next_phase() pathological behaviour

Rob Norris — Fri, 25 Mar 2022 17:10:51 -0000

I've been using the latest source code - since ln_lunar_next_phase() was added after the v0.16 release.

I found that for various dates, my program in looking for the next full moon would either be very slow, give strange dates, or even nonsensical dates. I traced this into the behaviour of the function ln_find_zero() as used by ln_lunar_next_phase(). Since the ln_find_zero() function doesn't protect itself as it uses a variable division term - so in particular when '(f - func(x, arg))' becomes small then x2 becomes very large, causing ln_lunar_next_phase() to sometimes return NAN.

I tried improving the ln_find_zero() function but did not find a robust solution. Ultimately I gave up and found it was simply better if ln_lunar_next_phase() did not bother using ln_find_zero() at all.

Possibly if one was concerned about the initial calculation giving a time in the past, then simply adding 29.530588861 should be sufficient.

I note the lntest/test.c doesn't exercise ln_lunar_next_phase(); so I brute forced it to run various dates over the next 20 years (for full moons). For the original function, found that for various dates it returned either obviously wrong answers (e.g way beyond +/- 29.5 days) or NANs.

//struct ln_date ld2022 = { 2022, 1, 22, 0, 0, 0.0 };
//2022-12-10 --> 2022-12-24 is giving 2022-12-25 when it should be around 2023-01-07

struct ln_date ld = { 2041, 1, 17, 7, 11, 0.0 };
/* Initial result = "2041-02-01 10:58:00" */
 /* Actual answer should be around "2041-01-20" */

// IIRC these failed badly
 //JD = 2459977.0; // 2023-02-01
 //JD = 2462533.0; // 2030-02-01
 //JD = 2462563.0; // 2030-03-02

Similarly the ln_lunar_previous_phase() can go badly wrong to.

Does not cross build under x86_64 system

Rob Norris — Mon, 21 Mar 2022 20:21:02 -0000

This is cross building on openSUSE tumbleweed on x86_64 with gcc version 10.2.1 + x86_64-w64-mingw32-gcc version 9.2.0

First failure is in src/julian_day.c

In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/crtdefs.h:10,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/time.h:9,
from julian_day.c:23:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/corecrt.h:133:2: error: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
133 | #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
| ^

Then there is the same issue present in lntest/test.c

I was able to fix it (for both) files by explicitly avoiding using "_USE_32BIT_TIME_T" on MINGW 64bit systems like this:

#if defined(__MINGW__) || defined(__MINGW32__) || defined(__MINGW64__)
#define _USE_32BIT_TIME_T
#endif  //__MINGW__
-->
#if defined(__MINGW__) && defined(__MINGW32__)
#define _USE_32BIT_TIME_T
#endif  //__MINGW__

segault in ln_get_dec_location

Leo Cacciari — Wed, 09 Feb 2022 18:20:30 -0000

Calls to ln_get_dec_location segfault.
This happens at line 575 of utility.c, where a spurious call to strtok (with NULL first argument) is present. Replacing the call to strtok with one to strtok_r solves the problem (see attached patch).

Did you forget to create a 0.16.0 tarball?

Yuri — Sat, 14 Jul 2018 08:17:04 -0000

The project is tagged with 0.16.0, some systems already have a 0.16.0 package. But where are sources comeing from? There is no 0,16.0 tarball.

#19 ra/dec to alt/az conversion

Andre Moutinho — Thu, 19 May 2016 15:04:22 -0000

Here is the example code:
struct lnh_equ_posn hobject, hequ;
struct lnh_lnlat_posn hobserver;
struct ln_equ_posn object, equ;
struct ln_hrz_posn hrz;
struct lnh_hrz_posn hhrz;
struct ln_lnlat_posn observer;
struct ln_date date;
double JD;

/*
        * observers position
        * longitude is measured positively eastwards
        * i.e. Long 5d36m30W (Leon, Spain) = 354d24m30
        * Lat for Leon = Lat 42d35m40 N
        */
hobserver.lng.degrees = -5;
hobserver.lng.minutes = 36;
hobserver.lng.seconds = 30.0;
hobserver.lat.degrees = 42;
hobserver.lat.minutes = 35;
hobserver.lat.seconds = 40.0;
/* Alnilam */
hobject.ra.hours = 5;
hobject.ra.minutes = 36;
hobject.ra.seconds = 27.0;
hobject.dec.neg = 1;
hobject.dec.degrees = 1;
hobject.dec.minutes = 12;
hobject.dec.seconds = 0.0;
/* UT date and time */
date.years = 2004;
date.months = 4;
date.days = 25;
date.hours = 12;
date.minutes = 18;
date.seconds = 49.0;
JD = ln_get_julian_day(&date);
fprintf(stdout, "JD %f\n", JD);
ln_hequ_to_equ(&hobject, &object);
ln_hlnlat_to_lnlat(&hobserver, &observer);
ln_get_hrz_from_equ(&object, &observer, JD, &hrz);
fprintf(stdout, "(Alnilam) Equ to Horiz ALT %f\n", hrz.alt);
fprintf(stdout, "(Alnilam) Equ to Horiz AZ %f\n", hrz.az);
ln_hrz_to_hhrz(&hrz, &hhrz);
fprintf(stdout, "ALT %d:%d:%f  AZ %d:%d:%f\n",
        hhrz.alt.degrees, hhrz.alt.minutes, hhrz.alt.seconds,
        hhrz.az.degrees, hhrz.az.minutes, hhrz.az.seconds);
ln_get_equ_from_hrz (&hrz, &observer, JD, &equ);
fprintf(stdout, "(Alnilam) Horiz to Equ RA %f\n", equ.ra);
fprintf(stdout, "(Alnilam) Horiz to Equ DEC %f\n", equ.dec);
ln_equ_to_hequ(&equ, &hequ);
fprintf(stdout, "RA %d:%d:%f  DEC %d:%d:%f\n",
        hequ.ra.hours, hequ.ra.minutes, hequ.ra.seconds,
        hequ.dec.degrees, hequ.dec.minutes, hequ.dec.seconds);

ra/dec to alt/az conversion

Andre Moutinho — Thu, 19 May 2016 15:03:01 -0000

Dear support,

I am trying to run the transform example code that is included in libnova distribution.
I also have made the same ra/dec to alt/az conversion using Stellarium and an online conversion tool but unfortunatelly I have got different results.

Here is libnova example result:
JD 2453121.013067
(Alnilam) Equ to Horiz ALT 24.410553
(Alnilam) Equ to Horiz AZ 247.293709
ALT 24:24:37.991195 AZ 247:17:37.352136
(Alnilam) Horiz to Equ RA 84.109089
(Alnilam) Horiz to Equ DEC -1.200000
RA 5:36:26.181311 DEC 1:12:0.000000

Please se attached picture showing different result: ALT 26:34:34.9 AZ 119:26:56.9

I have also used this online calculator
http://www.convertalot.com/celestial_horizon_co-ordinates_calculator.html.
Its result was consistent with Stellarium but also different from your
LIBNOVA example:
Online tool result: ALT 26.65 AZ 119.55

Notice I had to put my local computer time (GMT -3) to get the correct JD time.

Hope you can help me.

Best
Andre

#16 autoconf error

Petr Kubanek — Fri, 27 Nov 2015 20:51:11 -0000

status: open --> closed-fixed

#16 autoconf error

Petr Kubanek — Fri, 27 Nov 2015 20:50:48 -0000

You need to run ./autogen.sh first.

#18 Getting Az/Alt for planet

Petr Kubanek — Fri, 27 Nov 2015 20:47:44 -0000

No, and I don't reccomend integration TLEs to libnova.

See Project Pluto, http://www.projectpluto.com/source.htm. I integarted that to RTS2 (http://rts2.org, http://github.com/RTS2/), so you can see that for an example how to Project Pluto sources.