My team and I are new here and we’re currently exploring the various catalogs and tools available. Specifically, we’re working with DP0.3. While trying to integrate this simulation catalog with our phase curve codes, we noticed that there don’t seem to be any tables containing the solar elongation angle. Is that the case, or did we perhaps miss it?
This data is crucial for distinguishing between different apparitions of the object. Of course, we could run an ephemeris query (using, for example, Astroquery’s Horizons class) to retrieve this parameter, but those queries are rather slow. It’s a bit of a shame because DP0.3 is incredibly comprehensive otherwise, and we can obtain almost all the necessary information from it—except for the elongation angle.
Thanks for the note, Mili - I will consult the team which constructed the DP0.3 simulation, to see whether there is a simple workaround (in addition to the one you’ve mentioned).
Thank you, Greg. I also noticed that the ‘mpcNumber’ column in MPCORB is empty (at least in my sample). However, I’ve already verified using the ‘rocks’ package that they are indeed numbered.
Hi @milicolazo - I also wanted to point you to the DP0.3 Documentation if you aren’t already familiar with it. In particular, there is a “Known Issues” web page that covers some of the shortcomings of the DP0.3 dataset, including problems with some designations in the MPCORB column.
It looks like we didn’t include solar elongation – sorry about that! I’m not well-versed in these coordinate systems so the following might contain an error. Double check it before use!
Solar elongation (object-observer-Sun angle) = arccos( {object-observer unit vector} dot {sun-observer unit vector})
We do include the object-observer vector via three ssSource columns: [topocentricX, topocentricY, topocentricZ].
We do not include the sun-observer column, but between the topocentric and heliocentric coordinates, it can be calculated as: [topocentricX - heliocentricX, topocentricY - heliocentricY, topocentricZ - heliocentricZ].
Then, I believe that arccos of the dot product of the unit vectors of the above two vectors should be what you’re looking for. Again, my coordinate systems are rusty so please double-check this and test it out with some known objects vs JPL before using it, and let me know about any errors!
The algorithm you suggested is working fine. I checked it by comparing the elongation angle from JPL and the one calculated using your equations, with x, y, z (Sun and observer) from JPL vectors.
However, when I try to use the same method in the LSST MPCORB catalog, I found that the x, y, z (Sun and observer) are different from what we obtain when downloading the data using JPL, so it is also not possible to compare the elongation angle. I understand from the documentation that the vectors are not light-time corrected, so the difference might come from that. However, I didn’t see the light-time correction in the LSST MPCORB catalogs, so I would again need to query the Horizons system.
Anyway, I tried to apply the light-time correction to LSST vector, for example for x:
x_corr = x_LSST - (vx_LSST × light_time)
I expected that after applying this correction, the LSST vectors would match those from Horizons, but that was not the case either.
Additionally, in the documentation, the velocities in DP03 are only labeled as ‘AU.’ I assume this means AU/day?
I apologize for all these inconveniences. As I mentioned, we are new here and are just starting to manage all these tools. Perhaps some of this has already been discussed, but it’s difficult to stay completely up-to-date with all the material we have available. Thank you very much for your help.
I don’t believe the MPCORB catalog includes any (x, y, z) information. It’s a per-object catalog, so unlike SSSource, which has each object’s position at the time of each LSST detection, it only has orbital information at some fixed reference time. I believe that velocities should be AU/day, yes, though I’ll double-check with a teammate.
Hello Jake! Apparently, the difference has something to do with the Julian dates. But don’t worry, I will try to figure it out with my team.
So, in summary, the approach you suggest works, I think that we can obtain the elongation angle with the information already provided in DP0.3:
observer_vector = [topocentricX, topocentricY, topocentricZ]
sun_vector = [topocentricX - heliocentricX, topocentricY - heliocentricY, topocentricZ - heliocentricZ]
elongation_angle = arccos of the dot product of the unit vectors of the above → convert to degrees
Thank you so much for your patience and help!
Mili.
The linked example shows that the z component is way off, reaching ~1 au for an MBA when it should be near ~0. I suspect that somewhere along the lines there was a mix up between degrees and radians in a trig function when calculating the coordinates (because I’ve made this mistake before and it looked similar).
Yes, the heliocentric distance and (also) the phase angle are very different from the ones I found in ephemeris services. But, the topocentric distance seems correct. Thank you for your answer!