lsapost creates an HDF file that crashes the GUI

[John Donovan]

In an exercise to get my head around some of the math behind LSA, I went back to basics and copied example 16.1 from the Ghilani book. When I run it through SALSA (1.15), lsapost runs then the GUI crashes. Trying to reopen the project crashes SALSA immediately, but after deleting the HDF file, it opens properly.

The HDF file itself is valid, in that I can open it in an HDF viewer and look at the contents.

Running the GUI from the command line and opening the project with the HDF, it exits with "terminate called after throwing an instance of 'gpstk::GeometryException'", I've not looked at the coredump yet.

Despite the simplicity of the project (4 fixed points, one float, two distances, and three horizontal angles), SALSA diverges at the 3rd iteration, so I may have got the input data wrong (although I have double-checked it). I've attached the project file and config file.

Also, any news on the 1.16 release and a github repo?

Regards,

John

[Clark Hughes]

Hi John,

Thank you for this report. We'll take a look promptly.

We are indeed on the cusp of completing 1.16 (we determined it was necessary to update the marble dependency which yielded significant "discovered work"), and that will start the public release approval process which typically takes 30-60 days. So, I believe we'll be able to provide that to the community by around 1 December.

I'm afraid I don't have progress to report on the GitHub migration. We only control one half of that process...

Thank you again; we'll take a look and follow up.

Clark

[Clark Hughes]

Hi John,

Ok a couple of us laid eyes on this project. What you're trying to do is tricky - get a 2-D example set up to solve in a 3D solver. SALSA is inherently 3D, so 1D and 2D networks generally require some extra care, i.e., to provide information to address the additional dimension(s). Additionally, the conventional axes labels for a 2D toy problem (x, y) mean something quite different in an ECEF Cartesian frame, i.e., this would be a plane on the equatorial plane with its origin at the center of the Earth. So in your example, you're setting these points on that plane which is resulting in unexpected behavior.

That said, it is possible to set these problems up. When I've done so, I find it most convenient to use Lat=Lon=Ht=0 as the origin. That is, a point at the equator and prime meridian with ellipsoid height of zero. The ECEF Cartesian coordinates of this point are XYZ = [R_e, 0, 0]. Then, instead of working in an xy plane, we're going to work in the YZ plane. I'm attaching a screenshot of what the Ghilani 16.1 example looks like when you set it up like that (well it looks like the textbook).

I chose to set this project up using meters, since all the intermediate and final outputs from SALSA are going to be in SI units anyway. Solving the network yields a solution for point U that is consistent with the text:

 Final Adjusted Positions XYZ
 Position         X(m)         Y(m)         Z(m)       Xadj(m)  Yadj(m)  Zadj(m)     
 Q        6378137.0000    1000.0000     800.0000  FIXED
 R        6378137.0000    1000.0000    1000.0000  FIXED
 S        6378137.0000    1223.0000    1186.5000  FIXED
 T        6378137.0000    1400.0000    1186.5000  FIXED
 U        6378136.9874    1173.0886    1099.9872       

I've attached the SALSA project in case you want to play with it.

All that said, crash bugs are bad, so we appreciate you sending this example. Since the example you crafted had all the points concentrated near the center of the Earth, it appears some of the geodetic transforms blew up, the horizontal angles are undefined, and one or both of those issues caused a chain reaction that leads to the crash. There's probably more than one bug in that chain; clearly there are code paths here that we'd not thought to test previously.

I hope this helps. Reach out with any questions, and thank you again.

Clark

Created by SALSA version 1.15.0 -- Backward compatible to 1.1.0
#New project created 2023-09-26 11:29:06
#──────────────── ─ ─────────────────────────────────────────────────────
#Example modeled off Ghilani 16.1
#First, create the four fixed points.
#By using POSC records and specifying X=R_e, we're essentially working in a
#YZ plane with the origin at the geodetic location lat=lon=height=0
POSC Q Fix 6378137.0000 1000.0000 800.0000 m
POSC R Fix 6378137.0000 1000.0000 1000.0000 m
POSC S Fix 6378137.0000 1223.0000 1186.5000 m
POSC T Fix 6378137.0000 1400.0000 1186.5000 m
#──────────────── ─ ─────────────────────────────────────────────────────
#Now the unknown point U. The Ghilani example is 2D; however SALSA is 3D; therefore
#we must do something to address the third unknown dimension.
#While we could provide that information by faking an additional measurement
#(e.g., a VANG of 0.0 from site R), that approach complicates this example; I'd rather just
#specify approximate coordinates for U and then constrain the height to zero.
POSC U Flt U 6378137.0000 1100.0000 1100.0000 m
#──────────────── ─ ─────────────────────────────────────────────────────
#Now the measurements
DIST R U 200.00000 0.05000 m
DIST U S 100.00000 0.08000 m
HANG Q R U 240.0000 30.0 soa
HANG R U S 150.0000 30.0 soa
HANG U S T 240 1 0.0 DMS 30.0 soa