no. of enn to do mode ID on needs to be data driven

[nielsenmb]

At the moment it's manually set when doing jar.star.asymptotic_modeid(norders = X).

It should be data driven, at least as an initial rough estimate. The best-fit asymptotic relation can then probably be extrapolated to another 1-2 radial orders on either side of numax, subject to some H0 test?

[grd349]

This is an important issue. Are we able to take some guide from the stars that we are running through ASY_peakbag now.

This is probably a very strong function numax (& dnu?) and should probably be prior driven rather than data driven.

[nielsenmb]

It's also going to be a strong function of apparent magnitude and observation length I think, right? Even if we get a prior based on the targets we're running through now, so something that's a function numax/dnu/Gmag/Tobs, it'll still vary between missions. A Gmag = 10 star will have a very different SNR in Kepler and TESS.

[grd349]

Yes - you are correct. The detectable modes will be very different for different magnitudes.

I suggest a pragmatic approach ... As we know the modes are 'present', just not detectable, in all snr cases let's just fit the range as if it were high snr. This will be inefficient in terms of extra computation that isn't really necessary but a while lot easier to implement.

Doers that make sense (pragmatic sense)?

[nielsenmb]

Hmm...so we fit a low snr spectrum as if it was high snr, pass the output to peakbagging.py and then evaluate the detection probability of each mode? Or would you do the detection probabilities between asy_peakbag and peakbagging?

[grd349]

Judging by your Hmm ... you are sceptical :) That's OK. I'm not so hung up in the detection probability for each mode, maybe a little bit for PLATO but for now that can wait. For the most part we now the modes are there and so accounting for them in the model, even if they are not detectable, is no great pain for me. For the ASY_peakbag stage it's not a big deal if we fit too many modes - just some extra time on the CPU.

For the main peakbagging you are right - we need to decide what to include. We will already know something about whether or not a mode has been detected - the posteriors will be broad (basically only constrained by the pattern) and the SNR will be low. We could make decisions based on this (at least preliminary decisions).

We could also run the mixture model peak bagging as either an intermediate or perhaps even final step. For PLATO it is probably an intermediate step.

We should run some tests at some point to see if having too many modes in the final fit is a bad thing - my feeling is probably not so much if we have sensible priors (height/linewidth/frequency). The posterior we get back would just be the prior which sounds OK to me.

[nielsenmb]

It's mostly the computational time aspect I was worried about! I agree, throwing it through asy_peakbag will not cost us anything (maybe marginally, since we'll be fitting a slightly wider frequency range).

I think if we put in a white noise level term, then that in combination with the envelope height + width should take care of the cases where we have requested too wide a frequency range. The outlying cases will just have a very low SNR. Then we just set a threshold in SNR. And I'm guessing it won't really bias the fit either, the information gained from the mode near numax, will still dominate the likelihood function. I'm just going by intuition here though.

However, in a high SNR case won't the surface effect be an issue if we fit too wide a range? That isn't captured by the curvature term is it?

[grd349]

Surface effect - in data?

I guess you mean glitches (HeII & BCZ). The model we use does not capture this. These are relatively small perturbations on top of the current model.

[nielsenmb]

Hmm no, I might be getting things mixed up. I mean the surface term as in Ball & Gizon (2014, 2017). I realize that's looking at the difference between an actual structure model and the observed frequencies, but as I can't remember by heart how the asymptotic relation is derived I don't know if it's accounted for by the curvature term.

…

On Wed, 22 May 2019, 18:18 Guy Davies, ***@***.***> wrote: Surface effect - in data? I guess you mean glitches (HeII & BCZ). The model we use does not capture this. These are relatively small perturbations on top of the current model. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AEJWO35ONGGLEXY44QBWLZDPWVI3FA5CNFSM4HJT5CLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV7GMOQ#issuecomment-494822970>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJWO377B62MRY2FXL7UM3LPWVI3FANCNFSM4HJT5CLA> .

[grd349]

For the typically observed frequencies in other stars, a surface term (but that really only refers to the deficiency of the models) is not needed, or possibly more correctly is sucked up by a modified Dnu and a slight difference in curvature. The surface term at low frequency would probably be evident but we rarely see these low-frequency modes.

Have a look at Mikkel's Legacy paper to see how well the model we fit does with real data. I think the limit is much more likely the glitches.