So that we can break down the writing task into smaller pieces.

There were five that showed multi modal behavior

107, 110, 113, 114, and 118

just in case someone stumbles upon it, there's no confusion

This source has K2 EPIC ID here:

EPIC 211414597

RA, DEC: 08 51 13.354 +11 51 40.15

It appears to be in an M67 super stamp. Which campaigns is it in? C5, C16, and C18?

We have both Overleaf and an ms.tex file in the GitHub version control. The GitHub version is the master version. The overleaf link can be used to share with collaborators, or work interactively. You have to ask Natalie for the Overleaf link.

We need ranges in Teff, logg, and [Fe/H] for the emulator.

From the group Slack convo from Natalie:

Range in Teff: 5250 K down to the spot lower temp. Maybe 3000?
Log g: 3.0-4.0
[Fe/H]: -0.1 to 0.1

Since the Phoenix model grid is quantized according to Table ~1 in Husser et al. 2013, I will adopt:
Teff: [3000 - 5300]
logg: [3.0 - 4.0]
[Fe/H]: [-0.5 - 0.5]

Notes:

1. This is a big range in Teff. That is fine, it will just might take the spectral emulator a long time. We agreed in a verbal conversation last month to just try the spectral emulation on a large Teff range and see what we get, and then just run it longer if we have to.
2. The requested precision on [Fe/H] is much less than the model grid spacing. That's fine, the way around this is to use a prior on [Fe/H] that reflects the uncertainty in the metallicity. We could assume a Gaussian with mean 0 and standard deviation X. What do you want X to be?
3. The ultimate constraint on logg is likely to be insignificant, it's a weakness of full-spectrum fitting. We could choose to apply a prior here too if desired.
4. We can also choose to put priors on other values (v_z, vsini). I have an email from Natalie with priors for RV, although converting those into recessional velocity is a non-trivial task that I don't necessarily want to get involved in. My recommendation is to not put priors on these unless we find out later that our fits are bad.

We're reviving this project! Where do we stand?

Issues and proposed solutions

• We might not have corrected the A0V hydrogen lines properly last time.

Proposed Solution: I've since improved the reduction around Hydrogen lines, it might be worth spot-checking, but not critical (only affect some orders).

• We only ran one order last time.

Proposed Solution: Run more orders! Maybe all of them?

• The TACC time cap was frustrating, we had to restart every 12 hours.

Proposed Solution: Dunno about this! We could write some code that finds the most recent saved sample and starts from there?

• The version of Starfish I used had a bug in how it computed solid angle, which trickled down to a bug in how I computed filling factor.

Proposed Solution: We need to git pull Starfish on TACC, make sure we're on the intended branch, and always remember to source activate the correct environment.

• We have a plot of a spectrum that we should interpret

Proposed Solution Natalie and I look at the spectrum.

• There are duplicate project paths on the TACC Maverick super computer: /work/03342/gully/maverick/science/subsub/notebooks and /home/03342/gully/science/subsub/.

Proposed Solution: Use the /work/ path because it has more storage capacity. We should rename the $subsub alias to the work one.

I came up with 604921030968952832 as the Gaia DR2 source ID.
I checked to see if its in the (admittedly space, polychromatic) lightcurves that come for some Gaia DR2 sources. It was not.

We have copious photometry data! Let's make a figure with these elements:

1. K2 data from 3 campaigns, vertically registered to K2 zero-points.
2. ASASSN data
3. Vertical bar of IGRINS epoch
4. Celerite model fit threading through both the K2 and ASASSN data.

We've already done this for posters, so we should translate that work into a paper-sized version. We also need to describe in the text what we have done to create this figure and what we learn from it. In particular:

Can we assign the starspot coverage fraction at the global peak-and-valley?

The referee made a good point that we did not justify the similarity of the K2-bandpass and the V-band, the latter of which is much narrower than the former. What effect does that bandwidth play in our spectral analysis (principally the photometry and alignment)?

To explore this question I overlay the K2 and V-band bandpasses, and fetch a 5200 K (ambient) and 4000 K (spotted) spectrum (logg=4 for simplicity). I compare the two curves to these bandpasses:

The filter-curve weighted integral of the two curves spot and ambient curves yields the emergent flux as a function of spot filling factor:

We see that the curves are very similar. The slope of the K2 curve means a 1% change in filling factor results in an 0.78% flux loss. The V-band result is similar-but-not-identical: a 1% change in filling factor results in an 0.83% flux loss. This makes sense: the V-band is bluer on average than the wider and red-weighted K2-bandpass. So the starspots look like they have slightly more contrast in V than they do in K2-band. But the difference is relatively small. It means that for a fixed starspot areal coverage change from one say Eastern hemisphere to the next say Western hemisphere, we may perceive amplitudes of lightcurve modulation that differ by about 6%: the V band should have about a 6% higher amplitude than the K2 band. The ASAS-SN data quality is not adequate to discern a discrepancy of only a few percent. We therefore conclude that treating these bands as identical for the purposes of starspot contrast is justifiable given our available photometric quality and sampling.

I have code to do this now.

Orders 104 and 105 ran, but didn't actually work. Here is the terminal output:

104
/Users/ngosnell/anaconda3/envs/astroconda/lib/python3.5/site-packages/emcee/ensemble.py:335: RuntimeWarning: invalid value encountered in subtract
  lnpdiff = (self.dim - 1.) * np.log(zz) + newlnprob - lnprob0
/Users/ngosnell/anaconda3/envs/astroconda/lib/python3.5/site-packages/emcee/ensemble.py:336: RuntimeWarning: invalid value encountered in greater
  accept = (lnpdiff > np.log(self._random.rand(len(lnpdiff))))

real	0m11.095s
user	0m17.103s
sys	0m1.789s
105
/Users/ngosnell/anaconda3/envs/astroconda/lib/python3.5/site-packages/emcee/ensemble.py:335: RuntimeWarning: invalid value encountered in subtract
  lnpdiff = (self.dim - 1.) * np.log(zz) + newlnprob - lnprob0
/Users/ngosnell/anaconda3/envs/astroconda/lib/python3.5/site-packages/emcee/ensemble.py:336: RuntimeWarning: invalid value encountered in greater
  accept = (lnpdiff > np.log(self._random.rand(len(lnpdiff))))

real	0m10.826s
user	0m17.284s
sys	0m1.725s

The run.out file is exactly like successful orders and the and log.log files are two lines long:

04/22/2018 09:43:56 PM - INFO - SampleThetaPhi 0 -  Initializing model on Spectrum 0, order 0.
04/22/2018 09:43:56 PM - DEBUG - SampleThetaPhi 0 -  Loading stored Chebyshev parameters.

The emcee_chain.npy file has 5000 non-zero entries, but they are all identical, as if the walkers didn't walk:

Need to go back and figure out why these orders aren't working!