mikeireland / chronostar Goto Github PK

Currently convergence of a component is a bit haphazard, and shortsighted; only comparing current fit to the one most previous. This imposes limitations.

For example, one criterion is that the lnlike must worsen from the previous one, thereby ensuring the lnlike isn't still improving. Problem is, this guarantees the final fit is only ever the 2nd best fit.

Also, the convergence thresholds that work well for 2 or 3 component fits start to breakdown for higher component numbers, as there is a higher degree of stochasticity and therefore a lower chance that all components will satisfy convergence criteria simultaneously.

Comparing the final (say) 10 fits will give greater control and reliability. Can start talking about memberships and model parameters not fluctuating outside some dynamically determined range. Also, once convergence is determined, can take the best fit of the recent few.

Also: with a set of recent fits, stable components can be flagged, and be skipped in the next iteration, thereby reducing the amount of computation required when only a small subset of components still require iterations.

To do:

• Keep track of 10 most recent fits
• Establish convergence checker that uses each component's history as context
  Extensions:
• Flag certain components as 'stable', ignoring them for a few iterations
  • Need to work out how and when to refit a stable component and how to check for deviations

• Marusa to put in integration test
• Polish Marusa's integration test

During some reruns on BPMG, a walker would get separated from the pack with a very large likelihood. Chronostar gathers the worst walkers and places them at the posiiton fo the best walker. So as a result, eventually all walkers get put alongside this stuck walker.

To do:

• investigate why this high lnlike position is so problematic (truly a better fit, or is something broken?)
• implement a stuck walker detector that collects all stuck walkers and puts them with the best not stuck walker?
• just put walkers at... say 5th best position instead of 1st best position

Recent bug fix prevents the 'par_log_file' being reusable as an input .par file, as results_dir will be recursively prepended. Easy fix is to prepend results_dir to the log file path only when writing to file.

In deciding whether to re-write a simpler chronostar or salvage, there are the following issues.

1. Although the docs say that galpy isn't needed, it still is for pytest.
2. A new install of line_profiler is needed.
3. pytest is failing: 10 failures on MacOS and 6 failures on linux.

This is a lot! A lot of this appears to by python 2.7 versus python 3 issues still in the code.

Derive equations for epicyclic approximation and email to Marusa and Tim

BIC is behaving oddly for large number of components.

Closer inspection of how the "overall likelihood" function has revealed some issues in the implementation. Though fixing these issues does not remove the strange BIC behaviour.

Need to reimplement how Z is calculated such that component amplitudes (which have a circular dependency on Z) are consistent. Maybe then try refitting all scocen data from one component, now that fitting is 100 times faster.

Tim: To ensure the emcee parameters are always initialised in a valid way when calling compfitter.get_init_emcee_pos I hacked in a little loop that goes through each initial walker’s position, and forces dx>dy and du>dv. It’s not super tidy. Much nicer would be a way to edit EllipComponent.SENSIBLE_WALKER_SPREAD such that, if an init component already has dx > dy and du > dv, then getting a swarm of walkers centred on this init_comp’s emcee_pars should rarely yield an invalid component. But I don’t know enough about how Neelesh’s ellipcomponent is implemented to recommend how to do this (or even if it would work).

With the introduction of multiple (i.e. 2) different orbit tracing functions with slightly different results, it is maybe important to store with a component which function was used to fit it.

Make epicyclic traceback method the default usage.

Potentially at the same time remove the requirement of having a galpy installation.

• Performance of compfitter when some stars don't have radial velocities available: In process (Beta Pic)
• How does a missing radial velocity affect component overlaps? Do we get any false positives/false negatives?
• Check Gaia's radial velocities for M dwarfs.

It seems that we deleted a bit too much when separating Chronostar and Individual projects.