I've written some Python 3 scripts to extract the exoplanet data from the NASA Exoplanet Archive.

The project is at https://github.com/ajtribick/celestia-exoplanets

Still something of a preliminary version, there's quite a few possible improvements that could be made (particularly with regards to handling systems as systems rather than independent planets), and at the moment I'm not doing anything with texturing.

Hopefully this is of some interest, would be open to suggestions on how to improve it.

(As an added bonus there's a parser for .stc files which converts the .stc into a list/dictionary structure, this is rather "overkill" for the current usage but maybe will be useful in future)

Great! Thanks, Andrew, for sharing it here. I seem to remember also an earlier related project by you and someone else?

Regards,
Fridger

_________________

Are you thinking of the KOI candidates add-on? I guess it has disappeared into the void left by the disappearance of shatters.net. I may have the source code for it lying around somewhere but I'm not sure whether its worth resurrecting now that so many Kepler candidates have been validated.

---

One thing I'd like to put in is textures, but I feel that the system used by Celestia is due a bit of an overhaul, it's been a long time and there is more observational data, particularly for hot Jupiters. Any thoughts on this, bearing in mind for some objects you may only have one of mass and radius... (maybe also worth considering whether there are better mass-radius relationships to use than the solar system-derived M=R^2.06)

Regarding orbits, I'm thinking for objects with unknown orientation things like coplanarity with binary star orbits (which would make having the stc parser more useful!) or the invariable plane of other planets in the system might be a good start. What happens when the masses of the other planets are unknown?

Probably...


Well, a few points without being an expert (yet) on EXO planets:

i) As to EXO textures, a possibly useful and scientific approach could be to use a set of standardized textures in analogy to Hubble type textures for galaxies. The underlying idea being to use such a limited texture set mainly for visualizing characteristic sets of catalog data, rather than trying to be individually photo-realistic somehow...

ii) You may have read that Dawoon (DW) recently completed his Master of Space Studies degree at ISU in Strasbourg. The subject of his thesis work was Visualizing Gravitational Lensing Phenomena in Real-time using GPU shaders in celestia.Sci. Well besides a Prof. from ISU, I was his official co-advisor...

The result from this struggle is a really nice graphical implementation of strong lensing with lenses ranging from individual stars (including our Sun of course or also multiple star systems) to galaxy clusters. What is still missing for reasons of time is an implementation of Microlensing for EXO planets! This is definitely planned with high priority...

DW is currently in the US working for NASA in the EXO planet dept. during a 3 months internship!

iii) Since for Microlensing there is no perceptible geometric deflection of light we need to first implement the QT plotting tool library Qwt 6 (http://qwt.sourceforge.net/). It perfectly integrates into Qt (and qt-designer) and offers a huge amount of dedicated plots as needed for a sensible visualization of Microlensing (and plenty of other things!).

iv) Still challenging is the important task of visualizing measurement uncertainties e.g. in form of missing orbital parameters e.g. for EXOs, multiple star orbits etc. The main danger here is of course to mess up the entire scene with uncertainty contours or even surfaces

Regards,
Fridger

_________________

Long time no update!

I've now put in mechanisms to read the data into per-system structures, at the moment this is only used to ensure the planets are output in order of increasing semimajor axis, but should allow more possibilities in the future, e.g. using mean angular momentum plane for non-transiting planets in transiting planet systems.

This will also make it easier to support other data sources because of separation of logic between parsing the source data and outputting the Celestia data.

Great! This effort of yours fits perfectly into our celestia.Sci implementation of Microlensing.

[Click on image for a larger display!]

See our IAC2014@Toronto conference paper
based on DW's Master Thesis.
More info here:
viewtopic.php?f=11&t=715

Fridger

_________________

Aha very nice! Unfortunately it seems that none of the microlensing planets get through the checks on whether enough parameters are available to represent the system, will be interesting to see what other sources will allow.

I got my microlensing data from peer-reviewed papers, but also cross-checked with http://exoplanet.eu. OGLE-2012-BLG-0026L b and c were verified by several different ground-based observatories.

We could also consider Hanno Rein's http://www.openexoplanetcatalogue.com. Hanno Rein is an expert in simulation of particle systems such as rings and protoplanetary disks, and his database also contains microlensing exoplanets.

Orbital elements are typically not very well-defined, so when making my microlensing addon I had to make some sensible, but arbitrary choices of orbital phase, plane angle, etc.

Minor update: looks like at some point NASA removed the symmetric parallax error field and replaced it with asymmetric errors. The new code/README will handle this.

I've also added Python 2.7 compatibility. (Checked with Python 2.7.10)

I've created a new release of the output, unfortunately GitHub doesn't allow creation of multiple releases on the same tag so this one replaces the last one (in the TRAPPIST-1 thread).

It includes the TRAPPIST-1 system and the 1284 new Kepler planets that were just announced.

Hopefully will be able to work on some further improvements to the code in the near future...

Thank you!

_________________
Never at rest.
Massimo

One of the enhancements needed for this add-on is to put some textures on the exoplanets. Celestia's exoplanets are divided into a few categories, depending on the mass and for gas giants the temperature.

For gas giants, Celestia used the five-class system from Sudarsky et al. (2000) and Sudarsky et al. (2003). Since that time many transiting hot Jupiters have been discovered and had measurements of albedos, phase offsets and transmission spectra, so probably the classes IV and V in the earlier system need to be revised.

One reference I have come across is Parmentier et al. (2016), who look at planets in the 1000–2200K range. Going by figure 13, it looks like there are several ranges worth considering.

At 1000K the prediction is for the dayside to be covered in Na₂S clouds. This is in line with Sudarsky et al. (2003) who predict various sulfides and chlorides in the 700–1100K region (Na₂S/NaCl, KCl). Around 1100K there is a minimum in the dayside clouds, though the limb and nightside remain cloudy. From 1200–1400K the prediction is for bright MnS clouds, and another minimum near 1500K–1600K. Bright silicate clouds (MgSiO₃) are predicted from 1600K–1700K though the dayside fraction is still quite low, then another region of cloudy planets from 1700–2000K (CaTiO₃, Al₂O₃). Above 2000K there will be TiO gas playing a role in the appearance, possibly also some influence of Fe and CaTiO₃ clouds.

The models suggest that the western limb and the nightside are nearly always cloudy, while the hotspot should usually be cloudless.

Going to cooler temperatures there is less data available so probably makes sense to keep the ~150K and ~250K boundaries for class I and class II, though maybe having an intermediate class for NH₄SH condensation at ~200K may be interesting, also the start of class III is usually given as 350K, so maybe some "cirrus-like" water clouds in the 250K-350K region may be appropriate?

This suggests to me that the following temperature/texture classes would be needed for giant planets:

• Extremely hot Jupiter >2000K (TiO, not sure what this would look like...)
• Hot Jupiter 1700-2000K (relatively dark CaTiO₃/Al₂O₃ clouds)
• Hot Jupiter 1600-1700K (bright MgSiO₃ clouds on western hemisphere)
• Hot Jupiter 1500-1600K (mostly cloud-free except nightside and western limb)
• Hot Jupiter 1200-1400K (bright MnS clouds)
• Hot Jupiter 1000-1200K (mostly cloud-free except nightside and western limb)
• Hot Jupiter 700-1000K (chloride/sulfide clouds, maybe cirrus-like?)
• Warm Jupiter 350-700K (cloud free, Sudarsky class III)
• Temperate Jupiter 250–350K (small amount of water clouds? Or just keep as class III?)
• Temperate Jupiter 200-250K (water clouds, Sudarsky class II)
• Cool Jupiter 150-200K (yellowish from NH₄SH photochemistry? Or just keep as class II?)
• Cool Jupiter <150K (ammonia clouds, Sudarsky class I)

Possibly also add a methane cloud class somewhere around 90K, though internal heating would likely keep Jupiters above this level... so far the script doesn't handle the microlensing planets so we don't have any Uranus/Neptune-analogues around. Further question is how to fit Neptunes into this scheme, maybe for now just use the same scheme as the jovians?

Thoughts?

i had started on making a few for each of the 5 groups , but there was really not that much interest other than the 5 people here that regularly post

--------

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

and these

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

Aha nice, looks like those would work for classes I and II. I'm going to have to get out my graphics software again and have a shot and some of the other ones.

I'll also look at extending the generation script to output texture rules for the various classes of objects, will have a look how these textures work.