Open paulthebaker opened 5 years ago
Here's a GWB amplitude chain from an IPTA cumulative UL run with 14 pulsars and BayesEphem
:
The first half used enterprise_extensions.model_utils.setup_sampler()
. The second half is setup manually.
stdev = np.array([10**np.floor(np.log10(abs(x)))/10 for x in x0])
cov = np.diag(stdev**2)
Nice work @paulthebaker ! I'm a bit confused about why the global draw is better overall. I can imagine that very early on it's useful, but (and this is an anecdotal memory) it seems like often many of our parameters burn in to their "usual" area of parameter space, but others are more autocorrelated or stuck. I would think that jump proposals in those parameter priors would be good. Are you saying that we just have the wrong weighting between them? Obviously the proof is in the pudding, in your test run above. I'm just curious about how one might know (say from looking at a chain) when to down weight various JPs in favor of others.
I really like your example because it is just tweaks to our already existent infrastructure. Is there as way to make enterprise_extensions.model_utils.setup_sampler()
more tunable? Or should we have different standard set ups?
Also, to your second bullet point, the pta.params
has a dictionary of enterprise.Parameter objects
. Can one use those?
I think we can both change the default behavior of setup_sampler()
and make it more tunable.
If you look at the gwb_analysis.py
and sample_utils.py
scripts in the IPTA_DR2_analysis repo you'll see how I set up my prior draws and groups and stuff
Also, to your second bullet point, the pta.params has a dictionary of enterprise.Parameter objects. Can one use those?
The problem is that the new Parameter
classes don't retain their initialization info (e.g. pmin
). They only have methods to calculate PDF and sample.
In @Hazboun6's solar wind PR (#18) he says:
Totally independently, I've been thinking about exactly this. My solution was a callable class, with class factories to generate specific instances. There are still a few snags. For instance I was working with the
PTMCMCSampler
param indexing (enterprise.PTA.params
treats vector parameters as one), and sampling vector parameters is tricky. The you would instantiate the class by giving it a list of parameters to work on or a signal name.The more I think about this, the more I think it's unnecessary. I don't think we need dedicated prior draws for every signal.
Some thoughts:
enterprise.PTA.params
member to move, which doesn't visit all sampling parameters equally (since some may be parts of vectors). We should fix this.LinearExp
are very inefficient, and we may not want to do them at all. This is why we put the dedicated log-uniform draw for GWB amplitude. We should consider doing this for RN amplitude when usingLinearExp
for them too.groups
. TheAM
andSCAM
moves will hit that parameter more often.enterprise_extensions
. When we have high acceptance moves (like empirical draws) we should sometimes move multiple parameters simultaneously.A few stray thoughts:
enterprise
Parameters
all have their ownsampler
method which draws from the prior. We shouldn't hard code ranges in prior draws, we should use thesampler
. (seedraw_from_dm1yr_prior
doing it the wrong way)Parameter
doesn't carry around it's prior properties (e.g.pmin
,pmax
). Those are hiding in the methods to calculate logpdf and to sample, but they are not accessible to us. This complicates autogenerating log-uniform draws forLinearExp
parameters.