Feature Requests: Custom User-Defined Features

[kecnry]

This is the place for ideas on what should be supported (what flexibility, what particular use-cases might be used, etc) in a possible future functionality to define custom features, with hooks to modify the mesh during internal calculations.

Current built-in features include:

• spots
• gaussian processes

[amiszuda]

One of the interesting features that you may find useful to add support to in Phoebe would be the way to model the accretion disks around mass transfer binaries.

[amiszuda]

It'd be useful to allow for dynamic setting upcompute_phases when adding a new dataset rather than setting up static phases upfront. The upfront setup may result in undersampling and creating artificial trends when inspecting the residuals. One can do it by checking the derivatives of included data to evaluate where the phase mesh should be finer (i.e., e.g. near the ingress/egress). This can be a bit misleading when the loaded data show big ellipsoidal variability, but in the worst case can lead to pseudo-constant sampling of phase space. Also, it may be useful if Phoebe would check how much the linear interpolation affects residuals by evaluating the distance to outliers in sigmas.
This of course can be done by manually tweaking compute_phases but this can become tedious at some cases.

[kecnry]

Do you think building this into the existing lc_geometry estimator would make sense? That already returns the measured edges of eclipses which are then proposed for eclipse masking and has machinery for fitting an analytic model to the phased data which we could use. The simplest version might be to use those estimated eclipse edges (and perhaps the analytic model slope) to generate the array to propose for compute_phases.

[amiszuda]

If we can get even rough phase estimates of contacts then that would be all we need, as lc_geometry also returns t0_supconj . Can this be linked with the lc_periodogram to get the orbital_period value automatically?

[kecnry]

lc_periodogram is intentionally separate so that the periodogram can be inspected and a factor applied, but its easy enough to run one after the other. If you have a proposed function that takes the eclipse edges and/or the analytic representation of the phased light curve and returns an array for compute_phases, I can try to put together a quick PR at some point.

[kecnry]

From @amiszuda (moving from a different thread so that its associated to this one): Archive.zip.

Thanks - I'm not sure how soon I can get to this, but will tag you on the PR (and put you as coauthor) once I do.

[kecnry]

I started porting this over to the lc_geometry estimator in #898 (still needs debugging/testing).

[kecnry]

#891 starts to build a framework for making it easier to write new features in the codebase, with user-defined features in mind (but not implemented yet).

We need to:

• figure out how these features are sent to remote servers (probably cannot just store the name and look in globals)
• further simplify built-in features so that the creation functions and allowed kinds logic draws from the classes directly, while still supporting available_features and docs-building
• consider coming up with a consistent interface for defining custom: compute backends, solver backends, dataset features, component features, likelihood functions, "observables" (see Feature Requests: Inverse Problem Solvers #407 (comment))