Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Figures for the letter #7

Open
landmanbester opened this issue Jan 13, 2017 · 13 comments
Open

Figures for the letter #7

landmanbester opened this issue Jan 13, 2017 · 13 comments

Comments

@landmanbester
Copy link
Owner

I will post em here when they are ready
@landmanbester
Copy link
Owner Author

Ok something is not right here. Here is what I get for sigmasq*D**2

sigmasq

Look at the figure on the left (I haven't worked out perturbed FLRW on the inside of the PLC). The black line is the perturbed FLRW on the PLC0. The blue contours shows what the data gives and the magenta line is sigma^2D^2 for an LTB model if I compute it with the CIVP. The LTB model is constrained to tend to EdS at the boundary so I would expect sigma^2 to taper off to zero. Now either I have made a mistake in how I copied the formula from Maple or there is a mistake in the Maple formula. I have copied the formula twice and gotten the same result so I need to ask a favour. @julienlarena pls could you make the following substitutions in the formula and send it to me again?

R_{,nu} = S
R_{,w} = Q
A_{,nu} = Z

Its easiest for me to check if you also multiply through by R^2 and expand it. If you don't have time I will only be able to do this when I regain access to Maple (hopefully by the weekend)

@julienlarena
Copy link
Collaborator

julienlarena commented Jan 17, 2017 via email

@landmanbester
Copy link
Owner Author

Ok so we have to think carefully about what the physical significance of the uv cutoff is. For example in this figure

sigmasq

we can see that the data are compatible with a uv-cut of 20 or 50 but not 10 (I think units are Mpc). Here I didn't even use redshift drift data, only D(z), H(z) and a lower bound on t0 (all simulated, busy doing a run with real data). Here is a plot of the CDF of the marginal likelihood of the Gaussian process over rho as a function of the length scale

rholik

The CDF reaches 0.16 at about l = 1.45 Gpc and 0.025 at about l = 1 Gpc. @julienlarena if we set the uv cutoff to 1000 Mpc the perturbed FLRW shear is effectively zero. I am not sure how to interpret this in terms of the physics. Any suggestions?

@julienlarena
Copy link
Collaborator

Hi Landman.

In the Maple sheet, I wrote kUV= N/kH0 to get an adimensional integrand. N is the dimensional k in Mpc^{-1}. So N=1/UVCut-off in Mpc.

Is that what you did?

Why is the numerical result diverging at the z=1 boundary? Is it a numerical artefact?

@landmanbester
Copy link
Owner Author

Yep that's what I did. See this function

https://github.com/landmanbester/Copernicus/blob/master/genFLRW.py#L74

for how I compute the shear and this one

https://github.com/landmanbester/Copernicus/blob/master/Plotter.py#L163

for how I plot it.

As for the divergence, that is just what the data gives. The LTB shear computed with the CIVP agrees with the shear computed using a parametric specification (at least on the PLC0). If these curves look weird to you its because I don't plot as a function of redshift in these figures, I plot as a function of the normalised affine parameter v/v_max. I could redo them as a function of z for the letter but it won't change the discrepancy between the data and the models. The LTB shear for non-zero bang time models also seems to "diverge". I think if I went to a higher redshift we will see it re-converging. I will test this for simulated data and get back to you.

@julienlarena
Copy link
Collaborator

Hi Landman.

Yes, for the paper, we will have to plot as functions of redshift. How do you superimpose the FLRW shear then, as this is a function of z?

I agree that the FLRW shear is strongly dependent on the cut-off and that is a bit of a problem. However, if our stat analysis disregards features below a few 100Mpc, then that's it, that probably means we ought to neglect the FLRW intrinsic shear. That means we are effectively probing very large scale shear, which is a genuine non-FLRW feature.

@landmanbester
Copy link
Owner Author

No. To superimpose the shear I convert it to a function of v using the background FLRW v(z) relation. It was just easier to do this for the 3 FLRW shear relations than for the thousands of samples produced by the MCMC. I'll change that on the next run.

I am a bit worried about the comparison we are making. It seems like the better the data get's the larger the cutoff needs to be for the FLRW shear to compatible with observations. But does this have any physical significance? Maybe I am just being slow here but I don't see how we are going to use this to say something meaningful..

@julienlarena
Copy link
Collaborator

julienlarena commented Jan 24, 2017 via email

@landmanbester
Copy link
Owner Author

Well we always knew that we can't use this code to test for small scale effects, for that you would have to be fully 3D (and very careful about how you reduce your data). At least this time we can say that Lambda=0 void models (for arbitrary bang time) seem to be are ruled out. Well at least for the parametrisation we consider...

Where to from here? I can do a run with current data and superimpose the improvement that would result from using future D(z) and dz/dw(z) data? Which figures should I produce though?

@julienlarena
Copy link
Collaborator

julienlarena commented Jan 24, 2017 via email

@landmanbester
Copy link
Owner Author

Ok so this is what the shear looks like for D and dzdw data

sigmasq

And these are the Om0 v OL0 contours for the same data

contours

Ignore the figure on the right I put it there to check if my contour plots were coming out right. Here is the PLC0

plc0

The T1 and T2 contours

cp

The MCMC reports that we haven't quite converged so I am running it for a bit longer. I doubt the figures will change by much though. I thought it would be cool to plot the current data on the same figures since that would show the improvement we would get from future data. The current data is a nightmare though, I keep running into issues with the multiprocessing that I didn't have before. Hoping that I have dealt with all of them for the latest run. Will keep you posted

@julienlarena
Copy link
Collaborator

julienlarena commented Feb 3, 2017 via email

@julienlarena
Copy link
Collaborator

julienlarena commented Feb 3, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@landmanbester @julienlarena