updated epsilon values for prior_data.csv

[nielsenmb]

I've been refitting for epsilon, to update the prior_data.csv file, to homogenize the RG, SG and MS stars from the various different samples. I've only gotten through the RG stars so far.

For the most part the median values seem to fall fairly close to the original values, but the errors seem substantially larger. Is this something to worry about? Errors are mean(diff([16th,50th,84th]))

The fits only take the previous epsilon values (and dnu, numax etc.) as initial starting points, and the errors to define the bounds.

I'm using the pre-bp_rp implementation of PBjam to do the fits.

[grd349]

@nielsenmb - This looks great!

That looks like it has worked very well!

The uncertainties being larger is somewhat expected. The previous uncertainties are from fitting to the mode frequencies. When we fit the asy model it is harder for the code to deal with any Helium glitches etc. So I would not worry about this.

Have you stored all the other info - particularly d02, linewidth, envelope witdh, ..., etc etc?

and the errors to define the bounds.

You presumably use N times the uncertainties to set the bounds right?

[nielsenmb]

You presumably use N times the uncertainties to set the bounds right?

yep

[nielsenmb]

Have you stored all the other info - particularly d02, linewidth, envelope witdh, ..., etc etc?

Nope

In hind-sight, I probably should have.

Considering I'm doing this on an older version of PBjam which doesn't use bp_rp, I should probably run it again...

[grd349]

I'm going to look at Bjam now. I'll see if I can get BlueBEAR to run 100 stars or so. I'll put in some way of stoing the output (also a KDE perhaps but pickled).

@nielsenmb - have you added your new epsilon values into the prior file (and if which one and which branch).

@ojhall94 - From a Git stand point what is the best way to update the file. I guess this is a standard pull request scenario?

[nielsenmb]

I'm in the process of adding in Gaussian priors on Teff and bp_rp at the moment, just checking it's running and the results look reasonable, I'll submit a pull request soon with the update.

I have recomputed the the epsilon values (fig above) but I haven't merged them yet. I'm not sure I should though, since they were computed without the Gaussian prior on Teff and bp_rp.

[grd349]

If you send me the results I can take a look and and see if they look sensible. We can always run again with the updated teff/bp_rp constraint.

I'm working on the BlueBEAR run right now. I should be able to make this run 100 stars by the afternoon. :)

[nielsenmb]

Have sent them now.

[nielsenmb]

I'm just running a few tests with the Guassian prior now, then I'll submit pull request.

[grd349]

Perfect!

[nielsenmb]

submitted pull request

I'd like to start making some diagnostics plot outputs, mainly just in the form of 'best-fit plot' and a corner plot. And then set them as optional flags in the asymptotic_modeid() method call.

I think if we mainly use Seaborn for this, it'll add some bling-factor to PBjam.

[grd349]

Cool - If I make this pull-req are we up to date from your side?

Do jam sessions (jar.py) use bp_rp as well now?

[grd349]

We could do with updating all the examples (well the one example we have).

We should probably have some other lower-level examples too.

[nielsenmb]

Yes, jam session now take bp_rp as well, and everything should be updated from my side.

I've already updated the Example.ipynb (also in this pull request) so you can see how it should be used.

There a few different examples, and I only tried the top one just now.

[grd349]

Excellent!

On Tue, 21 May 2019 at 11:32, nielsenmb notifications@github.com wrote:

Yes, jam session now take bp_rp as well.

I've already updated the Example.ipynb (also in this pull request) so you can see how it should be used.

There a few different examples, and I only tried the top one just now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/grd349/PBjam/issues/36?email_source=notifications&email_token=ADQZOCOUHWZD3ZY6LXODKR3PWPFVFA5CNFSM4HNT6VCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV3PQXA#issuecomment-494336092, or mute the thread https://github.com/notifications/unsubscribe-auth/ADQZOCI2ZDXXNJAO4USM4Y3PWPFVFANCNFSM4HNT6VCA .

-- ​Dr Guy R. Davies ​Lecturer in Astrophysics​ School of Physics and Astronomy The University of Birmingham Edgbaston Birmingham B15 2TT

Tel +44 (0) 121 414 4597 ​G.R.Davies@bham.ac.uk​ grd349@gmail.com davies@bison.ph.bham.ac.u davies@bison.ph.bham.ac.ukk davies@bison.ph.bham.ac.uk

The contents of this e-mail may be privileged and are confidential. It may not be disclosed, used, or copied in any way by anyone other than the addressee. If received in error please notify the sender then delete it from your system. Should you communicate with the sender by e-mail, you consent to The University of Birmingham monitoring and reading any such correspondence.

[grd349]

I have created a new file - prior_data2.csv

This new file is the combination of the old and the new data. In terms of the KDE this doesn't present too much of a problem that the data are used twice. If you want to use this file you will need to update the self.data_file in epsilon and the asy_peakbag Prior class.

At some point we should select only the stars that have a unique ID (but we probably will continue to add to this dataset so perhaps let's just make a new file before TASC/KASC)

[nielsenmb]

With Oli's bp_rp values (you should be in CC) and the download all setting as default, I think we can update the LC data stars. I ran into some weird astropy fits error with SC data though, apparently a fresh install of anaconda and lightkurve fixed this, but something to keep in mind.

[grd349]

Use the updated output for 1000 red giants.

Need to run MS/SG and possibly Serenelli sample.

[grd349]

I have added ~900 red giants that have been passed through asy peakbag. I checked each one and then threw away a small number of potential outliers (there might still be a few bag eggs left).

I removed all the main sequence/SG stars. We will need to use a different KDE for these. This is easily done. My main problem is that most of the MS/SG stars failed in the latest run. We will need to have a proper look at the MS/SG results. I think a number of the targets fail because #93 but there are also others where some thing else is happening.

One candidate to look into is the band width of the KDE. Because our sample is so RG heavy, it might be that the BW is only appropriate for RG in the current setup. A separate fiel for the prior of the MS/SG and a switch to move between the two would be a sensible idea until we can redress the numbers imbalance (which might be never).