openexoplanetcatalogue / open_exoplanet_catalogue Goto Github PK

http://arxiv.org/pdf/1402.0846.pdf

Double check the following planet identifiers:

KOI-370.01, Kepler-145c, 42.88, Xie et al. 2013
KOI-370.02, Kepler-145b, 22.95, Xie et al. 2013
KOI-523.01, Kepler-177c, 49.4, Xie et al. 2013
KOI-523.02, Kepler-177b, 36.9, Xie et al. 2013
KOI-806.01, Kepler-30d, 143.2, Sanchis-Ojeda et al 2012
KOI-806.02, Kepler-30c, 60.3, Sanchis-Ojeda et al 2012
KOI-806.03, Kepler-30b, 29.2, Sanchis-Ojeda et al 2012
KOI-1873.01, Kepler-328c, 71.3, Xie et al. 2013
KOI-1873.02, Kepler-328b, 34.9, Xie et al. 2013
KOI-2672.01, Kepler-396c, 88.5, Xie et al. 2013
KOI-2672.02, Kepler-396b, 42.9, Xie et al. 2013

http://iopscience.iop.org/0067-0049/210/2/25/pdf/apjs_210_2_25.pdf
http://www.nature.com/nature/journal/v487/n7408/full/nature11301.html

There was a paper on the arXiv today with a new catalogue of host star parameters: https://www.astro.up.pt/resources/sweet-cat/

Any opinions on that?

I was wondering if I/we should e-mail the authors and ask them if they'd like to contribute their data to the OEC directly...

http://www.nasa.gov/sites/default/files/files/arXivValidationMultisII.pdf
http://www.nasa.gov/sites/default/files/files/arXivValidationMultisIII.pdf

An easy to use task list for adding tasks to add new papers (or planets within those papers) to ensure we are always keeping up to date. Its very easy to skip a paper and think "someone else will catch it" but a task list means if they don't we know about it.

It would also be helpful when you don't have time to update the catalogue fully or convert some values within a paper to the catalogue standard, make a task and someone (or you) will do it later. In these big several planet releases, we could spread the load and do a few each.

I don't think issues are very good for this as it will clutter discussions like this. Personally i really like asana (and its super quick to add tasks) but i'm not sure how well it works publically.

Should HD 142 A c have a discovery year? I understand that the "discovery" is questionable, is that what the "-" in place of a year is meant to convey?

(Sorry for the additional "issue". I'm probably going to come up with a bunch of these as I move to the OEC as the data source for my very out of date Wikipedia figures.)

Some issues with the script for future reference

• if a planet doesnt have a star it will blank the file
• spectral type commented out
• use to fetch names aswell
• if name not found should try a second name

Kpler-413 has been announced by Kostov et al (http://arxiv.org/abs/1401.7275)

If you run cleanup when you've made a typo with a closing tag the cleanup script ie in kepler -33

change line 23 to 0.158566 and run cleanup

You will get
systems/Kepler-33.xml, mismatched tag: line 23, column 21
Name of system not the same as filename: systems/Kepler-33.xml

At which point the script replaces kepler 33 with data from kepler 32

We're somewhere in the middle in terms of "confirmed" planet count. I think it would be a good idea to keep track of the differences. Nothing to elaborate, just on a planet-by-planet basis.

Can we take the appearance of

A new statistical analysis led by a team at NASA Ames Research Center has validated...

in description to be equivalent to "verification by multiplicity"? If so will this be a stable equation or might it change in future as description is modified.

If it is not stable, should there be a tag (e.g. something like #113) indicating that this technique was used?

http://arxiv.org/abs/1311.4335

Decide on the names of these planets. David Kipping published them first, so he should get credit. He labeled them KOI-314. The Kepler team later assigned it the id Kepler-138. Also note that the letters are different.

Update the metallicity of HAT-P-13 star.

We should probably decide on a style for this and add it to the readme.

Should references be a URL to the DOI entry (this seems to be what we mostly do), just the DOI, name author date etc.

I think URL to DOI is fine but as the catalogue is maturing it may be a good idea to start a set of standard practises.

edit: hijacked this issue to discuss catalogue standards and to write them into a short guide

Open Issues

1. How to reference (url, doi etc)
2. Trump rules (ie you can only trump a paper value with a paper value, or how to decide whether a new paper should dominate the old one (both publication date and significant figures / errors arent perfect guides to the best value))
3. Acceptable sources

I have a moderate amount of money (~$800) left over from a grant that I could use on this catalogue. Does anyone have suggestions? Here are a few. I'm not sure about either of those, which is why I am asking for input.

• Pay contributor bitcoins, e.g. http://tip4commit.com
• Pay undergraduates to help maintaining the catalogue
• Design a logo

(I'm not an astronomer, so this may be a naive question.)

Should there be a way to indicate additional method used in verifying or adding significant data to a planet beyond the discovery/data provided by the value of discoverymethod? For example indicating 'RV' additionally for planets discovered using 'transit', but with confirmation and mass provided by radial velocity observations.

For example a supplementalmethod multiple element (as a child of planet) might do the trick.

Correct metallicity value in BD-10°3166 from discovery paper

http://arxiv.org/abs/1402.5850

How are transiting planets identified in the catalogue?

Is the discovery method a good tag for this (ie does a planet detected by RV become detected by transit or will it always be RV?)

Do we use a sudo tag (like radius)

Or does it require its own tag?

Currently names are given to the system, star and planet.

1. Do we need to name all 3, ie if its a none binary are we best naming all 3 the same (appending 'b' for the planet) or giving letters to planets which are always append to the system? same with the star all inheriting names from the parent?

2. if not should binaries also be named?

I feel like whilst the above is the simplest it may not be the most user friendly. If each child must be named should the cleanup script propagate these names upwards / downwards?

Some entries (e.g. those for distance in Kepler 48 through 60) have a newline at the end of the value which can result in some frustrating results that might be hard for some users to debug.

For example, in a simpleminded approach to grabbing some data such as

for filename in glob.glob("*.xml"):
    system = ET.parse(open(filename, 'r'))
    planets = system.findall(".//planet")
    for planet in planets:
        print(','.join(map(str,(
            planet.findtext("./name"),
            planet.findtext("./discoverymethod"),
            #...
            system.findtext("./distance") # << Creates blank line in the output
            ))))

the system.findtext("./distance") statement will add a blank line in the output.

It's a simple thing to fix in script, but is likely to trip up some naive users (like me).

Update masses of Kepler-24 b and c

http://arxiv.org/abs/1311.6559

Stellar mass of KOI-368 needs to be updated with value from Zhou and Huang 2014.

http://arxiv.org/abs/1401.6811

http://arxiv.org/abs/1310.4503

The Data Structure image tag description mentions an image directory but it is not in the download. Is this available?

I am playing around with Travis CI to automatically run the cleanup script on this repository and all pull requests. It seems to work really well. It should let us know if a new commit/branch/pull request contains any obvious (syntax) errors.

http://arxiv.org/abs/1311.6336

Is there any significance to the order of multiple name tags for objects?

Simple code that grabs the first name sometimes ends up with something unexpected or undesired — e.g,. "KIC 8435766 b" instead of "Kepler-78 b" — and I'm hoping to avoid writing code that searches among multiple names for desired ones.

http://arxiv.org/abs/1401.5525

http://arxiv.org/abs/1401.4195

I updated the KOI list as the Kepler team released a new version (there's no paper, it just appeared on the website). The candidates now include transittimes and errorbars. However, I lost the magB, magI... values in the process.

I wonder if the images might be better placed in a separate repository. What do you think?

http://arxiv.org/abs/1305.6494

I think that it would be helpful to use Unicode encoding in xml file to store characters like the greek letters in object names and other non-ascii characters in constellation names, perhaps in addition to the current version of the name fields.

http://arxiv.org/abs/1306.0904

Add:

Update:

http://arxiv.org/abs/1307.5874

http://arxiv.org/abs/1311.5271

The simbad_extractor.py file has a Latin-1 encoding declaration although it is an ASCII file.

I havent been using this, i think either the use of it needs to be enforced or it should go.

The last updated information is in the commit so it seems like an unnecessary tag most of the time. in addition the date at which it was last update can be misleading if your thinking about it in terms of how new the information is.

is i could update something today with values from 2009

It might make sense to convert the units at some point. I guess BJD would be the best choice. There's an online tool to do the conversion: http://astroutils.astronomy.ohio-state.edu/time/. They also provide the source code, but since it's written in IDL and requires many libraries, it probably doesn't make sense to include it in the cleanup script.

Correct the visual magnitudes of HAT-P-44, HAT-P-45 and HAT-P-46 stellar hosts.

The <longitude> element descriptions says:

Mean longitude at a given Epoch (same for all planets in one system)

So we should introduce an <epoch> elemente to specify the Epoch. Unit could be BJD as for <transittime>.

http://arxiv.org/abs/1402.1482

http://www.aanda.org/articles/aa/abs/2014/01/aa23067-13/aa23067-13.html