Parameter and Signal classes

[jellis18]

In terms of overall design I think that we should have a Parameter class similar to PINT Parameters with priors attached as they do there. We should then have a Signal class, again similar to PINT models which will have a setup method that reads in Pulsar class instances, or at least attributes. This way we can make a collection of signals independent of the pulsars. It is only when the signals are evaluated (or setup) that they interact with the pulsar.

In terms of the model, I think we should have a PulsarModel and a PTAModel where the pulsar model is for single pulsars (i.e., noise, timing model, etc.) and the PTA model is for common signals (i.e., GWs, ephemeris, clocks). We should probably focus on the PulsarModel first as a PTAModel would just be a collection of PulsarModel instances + some methods to compute PTA covariances and such.

For the PulsarModel class I think it should read in the Pulsar object and a collection of Signal objects similar to the PINT residual class. I haven't fully thought through how likelihoods would be incorporated into this. Of course they should be part of the PulsarModel but maybe that should be sub-classed for different kinds of likelihood (i.e., marginalized vs fully hierarchical).

For now I'm attaching a Milestone to have a basic working version of PulsarModel finished by the beginning of the busy week.

[paulthebaker]

The way PINT does it's parameter class is pretty cool.

As for the priors, I think we need to have a few primitive choices. We absolutely need a Gaussian prior with the mean and variance or standard deviation defining it and a uniform prior with a two parameter min/max. We might also want to include a log-Gaussian prior, a sum of Gaussians for multimodal distributions, and an empirical prior that's just the binned output of a previous run.

PINT defines a few special cases then relies on SciPy.stats to handle other cases. I think we can mimic what they do and add in our special cases.

[jellis18]

OK, since starting this issue we have changed the way we are doing things. Originally we were aiming for a PINT-like multiple inheritance signal builder. We have since moved to a class factory structure that allows us to create signal classes on the fly through clever use of meta classes. I really like this structure and we are able to do the standard noise analysis already as seen in my notebook. However there are still several outstanding issues and design choices that we have to make:

• Add support for "delay" type signals like wavelets or continuous or burst GWs. This should be pretty easy to do as it is similar to how we are doing ndiag or phivec now.

• Address Issue #30. I like this idea but we will still need a T or df in the free-spectral model PSD to get it to s^3. This also messes a bit with the idea that all gaussian process signals have unitless basis functions and amplitudes in seconds. Although the timing model doesn't follow this unless we do an SVD so we need to think about how we are going to put all of this together.

• Make parameters more flexible to be able to accept a Parameter into a new Parameter class. For instance, if we want to model Fourier amplitudes with a Gaussian prior with the parameter rho as the variance. The Parameters need to know that rho is also a parameter.

• Do we want certain signal methods to be classes themselves. For example, if Fmat were an object then we could easily set it on the fly, that way a DM GP signal would just be a FourierBasisGP with a different Fmat implementation. This is nice but the problem is that we would then need a way to re-name the parameters o the fly as well...

• How do we do multiple pulsar signals? Right now we can do this if there are no spatial correlations and the signals do not share an Fmat with any other signals; however, for something like a common red process we need the code to know how to share the Fmat from the red noise instead of creating a new Fmat. We could do this with some kind of registry but I'm not quite sure how to do it. We could also make a multi-pulsar signal class but then we still have the problem of how the common signals know about the individual signal Fmats.

I've been thinking about these things but don't have a good answer to any at the moment. I think until we can answer most of these questions we should just keep sandboxing in the dev branch.

Any ideas?

[jellis18]

This has basically been solved in PRs #89 and #54. I'm closing the issue.