[Difx-users] generate fixed JPLEPH calc9 file for calcif2? {External} {External}
Geoffrey B. Crew
gbc at mit.edu
Thu Jan 23 11:01:07 EST 2025
I gather you're still looking for suggestions. The answer depends on
how desperate you are.
If I was desperate, I'd consider reverse-engineering the CALC(9/11)
readers for the EPH files which effectively contain the file format in
detail. Then (since I rarely write fortran these days) I'd rewrite the
reader in C and add a writer (also in C) and then verify that I could
product bit-identical copies of the files. This tool would need to
accept the various DEXXX files you want to work with.
Theoretically, most of the file is data organized by object in time, so
you can produce what you want by doing some sort of concatenate or merge
(in the overlap). It gets more tricky if the epochs change (but I'm
guessing it's all still ICRF).
Another random thought is that NAIF spice
(https://naif.jpl.nasa.gov/naif/) needs to do the same sort of thing.
(SPICE is a general toolkit for working with geometry in space
missions.) Data is encoded in things called kernels and the SPICE
toolkit can read a variety of kernels to do whatever calculations the
user requires. There are such kernels for DEXXX at
https://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets and there
are toolkits in C, Fortran and other languages.
There is a small discussion of SPICE and DE here:
https://astronomy.stackexchange.com/questions/54110/what-is-the-difference-between-spice-kernels-and-jpl-development-ephemerides-is
On 1/23/25 10:01, Jan Wagner via Difx-users wrote:
> Hi David, Walter, all,
>
> that was a great amount of useful info from everyone! Many thanks!
>
> I tried out Walter's idea, but alas, not successful. Edited
> CALC5Server.c and increased the hard-coded limit of solar_target[5000]
> and associated for() loop to something bigger (I used 15000), modified
> one debug printout to ascertain the warning comes indeed from the
> edited copy of CalcServer, then recompiled and restarted CalcServer.
> The error is the same as before,
>
> "*** [wb_test] Requested JED, 2460688.77 not within ephemeris
> limits, 2442384.50 2460688.50 ***"
>
> The upper end JD of 2460688.50 (in January 2025) remained unchanged
> despite increasing the CALC5Server.c limit of 5000 entries to 15000.
>
> The data come from this JPL ephemeris file included in DiFX calc9.1:
>
> https://github.com/difx/difx/raw/refs/heads/main/applications/calcserver/data/JPLEPH
>
> The file is DE403. The header says Final Epoch = 2199 Jun 22. This is
> consistent with the info at
> https://ssd.jpl.nasa.gov/planets/eph_export.html which states
>
> DE403 : Created May 1993; includes nutations and librations.
> Referred to the International Celestial Reference Frame.
> Covers JED 2305200.5 (1599 APR 29) to JED 2524400.5 (2199 JUN 22).
> I'd imagine the DE403 file ought to have data up till year 2199, even
> if the model were already degraded/inaccurate for this particular
> January 2025 VLBI track on which calc9.1 fails.
>
> Editing the Fortran calc9.1 cpepu.f with newer subroutines from
> difxcalc11 cpepu.f such that it could read DE421, I tried that today,
> but failed miserably at it ...
>
> The cpepu.f files of the respective DiFX calc versions are under
>
> https://github.com/difx/difx/tree/main/applications/calcserver/calc9.1/
> https://github.com/difx/difx/tree/main/applications/difxcalc11/src/
>
> But is it worth the effort to merge cpepu.f updates to gain DE421
> support? It looks like a lot of changes would be needed...
>
> Wouldn't the easiest(?) be to have cpepu.f (or the DiFX JPLEPH file)
> accept VLBI observation dates up till the DE403 Final Epoch JED
> 2524400.5 (2199)? Regardless of quality of DE403? Erroring out with a
> "not within ephemeris limits" seems misplaced for non-planetary VLBI
> observations. For planetary VLBI observations, one would then just
> have to know and choose difxcalc11 which has DE421... :P
>
> kind regards,
> Jan
>
>
> On Wed, Jan 22, 2025 at 2:36 PM David Gordon via Difx-users
> <difx-users at listmgr.nrao.edu> wrote:
>
> Maybe I can help here. I haven't looked at calc 9 in many years
> and don't have a copy of it.
> If someone can provide me a copy of calc9/calcif2 I will take a
> look at it. The JPL ephemerises
> are made using software and ascii files from a JPL web site. I
> forget which JPL ephemeris is
> used by calc9 - DE405 maybe? I can look to see if that can be
> extended, but it's unlikely
> since DE405 is obsolete. Difxcalc uses DE421, which expires in
> 2050, so it will need to be
> replaced sometime also. Probably the best quick fix would be to
> replace the relevant subroutines
> in calc9 with the ones used by difxcalc (in file cpepu.f), and
> then use DE421. Some
> parameters would also need to be changed. Another issue is I
> believe calc9 is Fortran77
> while calc11 is Fortran90. Just renaming it cpepu.f90 might be
> enough though for the compiler.
>
> So, Jan, if you can send me calc9/calcif2 or where to get it, I
> will try to work on this in the
> next few days. Better to contact me at my USNO Email -
> david.gordon126.civ at us.navy.mil.
>
> Regards,
> David
>
>
> On Tue, Jan 21, 2025 at 4:28 PM Jay Blanchard via Difx-users
> <difx-users at listmgr.nrao.edu> wrote:
>
> Sorry Jan I don't know enough about the formats but just in
> case it is the same - here is JPLEPH.421 that we use for SCHED.
> I assume it is not the same?
>
> On Tue, 21 Jan 2025 at 09:58, Michael Dutka via Difx-users
> <difx-users at listmgr.nrao.edu> wrote:
>
> Hi Jan,
> We just updated the tables dfixcalc11 uses with more
> stations they're attached here. Hope these help!
> -Mike
>
>
>
> On Tue, Jan 21, 2025 at 9:49 AM Jan Wagner via Difx-users
> <difx-users at listmgr.nrao.edu> wrote:
>
> Hi list,
>
> the old CALC 9.1 model behind DiFX 'calcif2' comes
> with two data files, JPLEPH and Horizons.lis.
>
> Unfortunately, the file JPLEPH file is "broken" in the
> sense that the ephemerides data contained in it ended
> already on 12th January 2025.
>
> For VLBI experiments after that date, the calcif2
> processing needed prior to correlation does not work -
> not even for VLBI experiments without local planetary
> objects.
>
> Perhaps someone on the list would be able to generate
> a corrected file?
>
> John Benson created the current file at NRAO more than
> 10 years ago. Unfortunately, he is not at NRAO
> anymore, perhaps retired.
>
> A move to difxcalc11 to replace calcif2 is possible,
> but the ocean loading tables in it are incomplete.
> They are missing a lot of stations, difxcalc11
> complains. It'd be more convenient if calcif2 could
> work for a while longer - with a fixed JPLEPH file.
>
> Many thanks,
> kind regards,
> Jan
> _______________________________________________
> Difx-users mailing list
> Difx-users at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>
>
>
> --
> Dr. Michael S. Dutka
> US Navy (civilian)
> USNO Phone Number- 202-762-0242
> Cell- 301-996-3588
> _______________________________________________
> Difx-users mailing list
> Difx-users at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>
> _______________________________________________
> Difx-users mailing list
> Difx-users at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>
> _______________________________________________
> Difx-users mailing list
> Difx-users at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>
>
> _______________________________________________
> Difx-users mailing list
> Difx-users at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/difx-users
--
Geoff Crew
MIT Haystack Observatory
gbc at mit.edu
(Do not use: gbc at haystack ;gbc at alum.mit.edu should now also work)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/difx-users/attachments/20250123/e834210d/attachment-0001.html>
More information about the Difx-users
mailing list