EXOFAST Usage Tips and Troubleshooting

Where Can I Find More Information?

For a complete description of the workings of EXOFAST, see Eastman et al. (2013).

Time Standards

EXOFAST assumes the BJD_TDB time standard for the input parameters and RV/transit-photometry time-series files. Depending on the application, differences between time standards may be significant. The difference between geocentric and Solar System barycentric times can be up to ±8 min, for example. Note that although time system is always specified in time series data files served by the Archive, there is no required uniform time standard in archive time series files—including RV files imported directly into EXOFAST. Orbital parameters in the Exoplanet Archive are likewise always provided in the time standard as published in the respective reference. It is therefore important to be aware of your input time standards and make sure they are appropriate for your purposes; if necessary, you may need to make conversions. If you have highly constraining data in both RV and transit, for example, but both are in different time standards, EXOFAST may have trouble converging to a meaningful solution.

Jason Eastman has made available an online tool for converting UTC to BJD_TDB, along with a brief overview of different time standards.

Pulling stellar parameters from the NASA Exoplanet Archive

Note that the original implementation of EXOFAST imposed a minimum uncertainty of 0.05 in logg, 80 K in T_eff, and 0.08 in [Fe/H], when those parameters were automatically taken from the exoplanets.org site (i.e., when "Spec Priors" was set). This was because many published stellar parameters neglected large systematic uncertainties. We do not impose any such minimum when pulling parameters from the Exoplanet Archive; however, caution should be exercised where the uncertainties provided are below these thresholds.

Why do I need logg, Teff, and [Fe/H] at all?

logg, Teff, and [Fe/H] are used to derive the stellar mass and radius via the Torres relations. If there are no transit data, we use these both to derive additional information (e.g., msini). If we have transit data (alone or with RV data), we can derive the stellar mass and radius from logg by itself. However, since that constraint is poor, we add a penalty to the chi^2 equal to ((mass_derived - mass_torres)/err_torres)^2 + ((radius_derived - radius_torres)/err_torres)^2. The stellar parameters are required to fit RV+transit data simultaneously. If you really don't care about these, do the fits separately, enter a large width on the priors, and then simply ignore the stellar properties and anything derived from them.

Fitting a Single Transit

If you are fitting only the light curve of a single transit with no RV data, the data will provide very little constraint on the orbital period. In this case, it is strongly recommended you provide a period width in the input priors, as well as a period starting value. Without a width constraint, the period is likely to wander dramatically, and since many properties scale with the period, the results will most likely not be believable. It is also advisable to use a circular fit in these cases, since the eccentricity will otherwise be almost completely unconstrained.

My Fits are Failing!

When EXOFAST calculations fail early on in the process, this is often because the fit is under- or over-constrained, or because of problems with the orbital ephemeris for the initial guess. You may see errors along the lines of:

ERROR: Transit fit not constrained. Check your starting conditions.

or, e.g.:

EXOFAST_GETMCMCSCALE: Parameter 6 is unconstrained. Check your starting conditions

Here are a few pointers for such cases:

• Check the EXOFAST run log. Sometimes additional suggestions may be provided along with the error messages.
• If you provided orbital parameters on input, is the ephemeris too stale for the epoch of the transit/RV data? The transit midpoint will always be propagated to the epoch of the observations, but if the propagated value is too far off, then the code may have trouble converging. Consider using an updated ephemeris.
• If no starting Transit Midpoint is provided, then EXOFAST will use the center time of the input transit file as a starting guess. However, if there is a lot of out-of-transit data present in the light curve, then this guess may miss the transit, and EXOFAST will have trouble finding a solution.
• If you provided a period prior, is the value reasonable, and the width such that it is neither over- nor under-constrained? If you are providing RV data, consider removing the period prior altogether and allowing EXOFAST determine a period guess from pre-fitting of the RV data instead (this will happen automatically in the absence of a provided period prior). Note that you can also tune the period guesses in the RV pre-fit by setting appropriate constraints in the Period and Settings Inputs pane on the EXOFAST Inputs tab (i.e., Minimum Period, Maximum Period, and #RV Periodogram Peaks to Search). See the advanced EXOFAST walk-through for some guidance on how to work with these parameters.
• If using period guesses from the RV pre-fit, is the ephemeris from the selected period compatible with the transit data (if provided)? If not, consider adjusting the period constraints in the Period and Settings Inputs pane to explore more appropriate periods (see the advanced walk-through).
• Can you consider forcing a circular fit? If a circular orbit is a reasonable assumption, then the code will usually run faster, and stands a better chance of successfully converging to a reasonable solution.
• Are the time systems used in the input data files and the input parameters consistent at the level you need? Ideally,all should be in BJD-TDB. If the different time systems are used and the data are sufficiently constraining that differences in time system are important, then it may be impossible for EXOFAST to find a solution.

Differences Between the Exoplanet Archive and Original Implementation

In the original Ohio State University web interface, when requesting starting parameters from the exoplanets.org database, these were pulled in the background and used only as starting parameters. They were not applied as priors as such, and the values used were not available to the user. In the Exoplanet Archive implementation, parameters pulled from the Exoplanet Archive (using the Load Priors and Widths button) are instead pre-populated into the input Prior Parameters section in the inputs GUI panel. Here the user can see and edit those values. This results in slightly different behavior, but is essentially equivalent to that of the original OSU web interface with the option to "Use parameters from exoplanets.org" switched off:

• Where provided, prior values are used both as priors and as starting guesses for the pre-fitting process. In their absence, EXOFAST will not attempt to find archival values in the background, but will still attempt to make suitable starting guesses. These guesses are used for the pre-fitting, but not for prior constraints.
• Where provided, prior widths are also used as initial stepping scales for the χ² minimization process in the pre-fits. Where widths are not provided, EXOFAST attempts to make a suitable guess for the stepping scale, but will not seek archival values. These guesses are used only for the stepping scale, but again not for prior constraints.
• Any input prior values and widths are also used to provide constraining prior distributions for the fitting and MCMC runs, via a χ² penalty. If you do not wish to provide such a constraint for a given parameter, omit the respective prior width. This automatically passes an infinite width for the prior, so that any input value provides an initial guess (as above), but effectively applies no prior constraint.

Comparing to the original stand-alone IDL version of EXOFAST, this is equivalent to leaving the input string argument "PNAME" (planet name) unset, and entering priors via the "PRIORS" array argument.

Note that a minor modification to the OSU implementation of EXOFAST (both standalone and web interface) is that, in the absence of an input period prior width, we apply an initial step-size guess of 0.1 days for the orbital period in the χ² minimization. This avoids a step-size of infinity being used, which would cause the pre-fitting to fail immediately.

How Can I Acknowledge/Cite EXOFAST?

See Acknowledgments for information on citing EXOFAST in publications.

«Previous Accessing Previous Results Recipe: Run a Simple Fit Next »

Last update: 18 July 2017