User-defined features#902
Conversation
1f2a352 to
a101841
Compare
6420a96 to
9507a2b
Compare
725206d to
0a9852a
Compare
8cb812a to
2ff5605
Compare
6ead7ab to
e150aae
Compare
e4ea7af to
9c6829f
Compare
|
Fantastic @amiszuda 👏 - thanks for these examples! Was anything particularly difficult to figure out or too restrictive (obviously we will need better documentation than we have in the PR description when this gets released)?
That's a very interesting idea... in theory I think it is possible to do now on a local installation (although it is not documented anywhere), but using this same framework to allow components themselves to be serialized in the bundle so they can be run on other machines would be super useful for some cases. Similar to this, the class would need to setup the parameters, and give instructions on how to build/modify/populate the mesh (and possibly where to put it in global space if it isn't attached to keplerian orbits), and then it should be able to slot in to use the eclipsing/observing algorithms built into phoebe. The huge benefit to this setup, in my opinion, is the ability to not have to modify source code and still have this flexibility within fitting on a server that has non-modified phoebe installed. I might take a stab at this if I have time, or we can try to sneak it in the release last-minute if its not ready in time. |
|
I think once you carefully go through the |



This PR adds support for defining custom features in-line that can either modify models after they are computed (but before they are fitted) or modify component mesh quantities.
Current restrictions:
superis not allowed and will result in an error.DatasetFeature:
ComponentFeature:
Example of a
DatasetFeature(SinusoidalThirdLight):Example of a
ComponentFeature(SinusoidalIntensities):Example of a
ComponentFeature(DifferentialRotation):Example of a
ComponentFeatureinheriting from a built-inSpot(MigratingSpot):TODO:
DatasetFeatureto handle modifying the comparison data (ie detrending)? Or should we split intoDatasetFeatureandModelFeature?can we be more consistent between returning values inComponentFeaturevs modifying parameters inDatasetFeatureLightCurveAdditiveFeatureandLightCurveMultiplicativeFeaturewhich allows just defining the functional form and handlesmodify_data_for_estimatorsandmodify_modelget_parameterstoadd_featureor similar?proto_coordsto something more user-friendly (and document better)feature_code, if possiblecomponent.spot,dataset.gaussian_process, etc)feature_codethrough parameteradd_feature(..., overwrite=True, **b.get_feature(...)), or should we split into two input arguments (if callable is sent tokindthen create the parameters and create afeature_codeparameter which can also be sent as a kwarg).entries need to show up inlist_available_features(at least if using registration)