Open vallis opened 1 year ago
codecov[bot]
commented
1 year ago Attention: 25 lines in your changes are missing coverage. Please review.
Comparison is base (
c49646c) 88.37% compared to head (ab7ef2b) 87.97%. Report is 54 commits behind head on dev.:exclamation: Current head ab7ef2b differs from pull request most recent head a98e6c7. Consider uploading reports for the commit a98e6c7 to get more accurate results
vhaasteren
commented
1 year ago I have a semi-related question because you are introducing prior_variance in TimingModel. I have also run into the need to use values for the prior_variance for the timing model parameters. Either for simulating data, but I also need it for analysis purposes. Problem is that the prior on timing model parameters is highly specific for each timing model parameter, and we have different parameters per pulsar. I ran into this challenge also when writing code to solve pulsars
What I don't like about using prior_variance in this particular way is that it is not flexible enough (I think, it's hard to see what BasisGP really can accept for priorFunction) to tailor the prior per timing model parameter per pulsar. I have an application in mind that requires that, so I have an interest in getting it right from the start.
In my previous work, my solution was to use the information in the par-files for this. The uncertainty column in the par-file is currently only used as output, even though libstempo and PINT do read it in. Actually, I'm not sure whether PINT can use it for anything else. But it's a perfect place in the par-file to write the prior width as input. I mean, the parameter values in the par-file are in reality also just the means of the prior in the analysis. People just haven't been thinking about it like that, but that's what it is. I'd also love to have a discussion about this with the timers. Ideally the timing group(s) would create data releases with more physical priors included on all parameters.
So my suggestion is to use the uncertainty column in the par-file to specify the prior width.
vhaasteren
commented
1 year ago Two more questions:
1) Regarding caching of residuals. When doing non-linear timing models, you can't cache the residuals like normal either. Those come from the timing package when you change parameters. How (and where?) is that implemented? Somehow we should be able to tell the caching descriptor that the residuals have changed and related quantities like TNr should be recalculated.
2) Will it still be faster with GP ECORR if you use my FastShermanMorrison code? I saw somewhere in here that it depends on the rNr solve of ShermanMorrison, which is super slow
simulatewill draw random residuals for all pulsars inptaby sampling all white-noise and GP objects for parametersparams.combine=False, and will run faster with GP ECORR.ptaincludes aTimingModel, that should be created with a smallprior_variance. Note that the variance applies to the entire design-matrix vector, and should be multiplied bylen(psr.toas)if it is understood as the variance per individual residual.utils.set_residualsto replace residuals in aPulsarobject.parameter.sample(pta.params)to sample from the prior.Pulsarmay nevertheless cache residuals internally, so it is safer to rebuild the PTA with the modifiedPulsar.