Allow for loading data files

[rstub]

Currently only the internal calculations are used. To achieve higher precision, it is necessary to load external data files.

[vreijs]

I was thinking of putting these DE431 ephemeris files in a specific directory (as is normal with sweph: Public Declare Sub swe_set_ephepath Lib "C:\ARCHAEOCOSMO\AddIns\swedll32.dll" Alias "_swe_set_ephepath@4" ( ByVal path As String _ ) This directory will also hold the star information, by the way.

The ephemeris files are some 1 or 2 GBytes. By the way, for my work (archaeocosmology) the build-in ephemeris is accurate enough, but we need to include DE431 files.

[rstub]

Thanks for the input. The star information would be http://www.astro.com/ftp/swisseph/ephe/sefstars.txt, right? That file is reasonably small and could be included in the package itself. Also one or two current time periods of the Swiss Ephemeris.

The full JPL Ephemeris is really large (almost 3 GB), while the Swiss Ephemeris is supposed to be only 100 MB. That would be a great fit for an add-on data packages. Here an interesting case study: https://journal.r-project.org/archive/2017/RJ-2017-026/RJ-2017-026.pdf

[vreijs]

Indeed sefstars.txt is the file. Remember that one can add one's own data to this. In the past I had many 'stars' to check Ptolemy's findings and determine the sensitivity of (un)visibility. But most people might not change that file. Remember this star file has to be in the same directory as the Ephemeris files.

I don't know if one can only safely download a few centuries, I don't know what happens if one asks for a date outside the files present. So I think downloading the 3 GByte is better to leave to the user. By the way, the default ephemeris (Moshier) without any download is also quite good, within 10 arcsec for the Moon in the region 3000 BCE to 3000CE. Adding the 100MByte for the compressed Swiss Ephemeris in the R-package sounds a little large (of course one gets high accuracy, within 1/1000arcsec). See the section 3 ephemiri: swisseph.pdf

Just for my understanding, if we distribute the swephR package, we have to include the SE C-code, correct? And if we do that, then indeed we need consent from SE authors. If we add to that sefstars.txt and perhaps non JPL-ephemeris files we also need to ask consent. I personally would opt to add the sefstars.txt and nothing else. The only thing is that, we need to make sure that we can allow people to have their own path to sefstasr.txt (aka their own set_ephe_path).

We can test these things out and see what we need to get consent from.

All the best,

Victor

[rstub]

I have done a few experiments today. SE seems to be very flexible:

• Adding inst/ephemeris/sefstars.txt allows to use swe_fixstar without an external ephemeris directory
• Adding sepl_12.se1 allows for planet calculation on day 2400000 without "using Moshier eph." warning. On day 2200000 and 2000000, the fallback is used.
• Adding sepl_8.se1 to a different directory and setting the ephemeris path to "path1:path2" allows for planet calculation on day 2200000 and 2400000 without "using Moshier eph." warning. On day 2000000, the fallback is used.

So it seems SE can handle partially available ephemeris files really well! I will think about how to integrate that into the package(s).

[vreijs]

Great that SE is that flexible. Good you tested it.

On 14 August 2018 at 22:20, Ralf Stubner notifications@github.com wrote:

I have done a few experiments today. SE seems to be very flexible:

• Adding inst/ephemeris/sefstars.txt allows to use swe_fixstar without an external ephemeris directory
• Adding sepl_12.se1 allows for planet calculation on day 2400000 without "using Moshier eph." warning. On day 2200000 and 2000000, the fallback is used.
• Adding sepl_8.se1 to a different directory and setting the ephemeris path to "path1:path2" allows for planet calculation on day 2200000 and 2400000 without "using Moshier eph." warning. On day 2000000, the fallback is used.

So it seems SE can handle partially available ephemeris files really well! I will think about how to integrate that into the package(s).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/2#issuecomment-413019955, or mute the thread https://github.com/notifications/unsubscribe-auth/AQa6FtMJMwdJfI_zXferbSc7pl1ExGe1ks5uQz8CgaJpZM4V2K5c .

[rstub]

This has been handled by #16. What's possible now:

• If one want's to have their own set of files or use the (huge) JPL, one can still use swe_set_ephe_path manually. But for many use cases there is no need to do so.

• Install swephR and use the shipped sefstars.txt with the build in Moshier eph.

• Install swephRdata and use the full SE from that package or the build in Moshier eph.

• This is done transparently when the package is loaded, c.f. https://github.com/rstub/swephR/blob/65b103873d9e4d74af1cdcd2abefb31255b5e5cc/R/zzz.R#L2-L6

• Within tests one can distinguish between the different ephemerides and skip if one is not available, c.f. https://github.com/rstub/swephR/blob/65b103873d9e4d74af1cdcd2abefb31255b5e5cc/tests/testthat/test-misc.R#L32-L39 and https://github.com/rstub/swephR/blob/65b103873d9e4d74af1cdcd2abefb31255b5e5cc/tests/testthat/test-misc.R#L41-L48

• Since swephRdata (and swephR) is available from my drat repository, this setup is even possible for uploading swephR to CRAN.

[vreijs]

Thanks Ralf for all this hard work. I am back home, so next week I want to continue (by also using the proper workflow, so the minimum amount of work is needed!). I will also directly include my own test script in the proper script (as I test it, so why not do it in the proper way!). See in the coming days I will come back. Again thanks.

All the best,

Victor