DCR corrections likely won't be ready in DC2. Can we turn the effect off in all simulations?

[cwwalter]

I talked to @isullivan about the DCR correction he is writing for DM (Advertisement he will be talking about it in this Thursday's SSim meeting and welcomes your input and questions!). It sounds like it will not be ready for DC2. So this means we should probably not turn DCR on.

@johnrpeterson: In PhoSim, do you introduce a separate refractive shift that can be turned off (and is it exposed in the UI)? Or do you do it is as part of the kick calculation in the ray-tracing?

[johnrpeterson]

i don’t really understand this. basic DCR, even if uncorrected, is often smaller than other non-DCR shifts. so although its good to correct this, the DM pipeline would already be able to associate sources with uncorrected DCR. then there are some uncorrectedable aspects that i would hate to remove as they are quite important for DE systematics.

john

[cwwalter]

i don’t really understand this. basic DCR, even if uncorrected, is often smaller than other non-DCR shifts.

My understanding is that DCR is not a very small effect at high air masses. So, it can cause astrometric shifts. We might want to leave it on even with no correction for DC2 but we should discuss it and understand the options.

How is it implemented in PhoSim now?

[cwwalter]

@jmeyers314 Do I remember right that you (and Pat?) wrote a paper on DCR systematics? We have some concerns about things like airmass dependent astrometry for DC2. Did you have estimates for the size of the effect across bands and pointings there?

[johnrpeterson]

its typically less than 0.5” of astrometric shifts. but there are other effects on psf size and shape which are more interesting.

in phosim it is done ab initio physically to the photons (of course!)

[cwwalter]

in phosim it is done ab initio physically to the photons (of course!)

Right... but I am wondering in the code if it is included in an integrated way in the wavefront/diffraction calculation as the photons hit the atmosphere and as you pass through each region of differing index of refraction, or if you have a separate angular shift that you apply based on the source angle/airmass and frequency to each photon and where that is applied.

[jmeyers314]

Yes, Pat and I wrote a paper on this (http://adsabs.harvard.edu/abs/2015ApJ...807..182M). Here's the summary table:

The rows with \Delta R and \Delta V are the ones relevant for DCR. The summary is that multiplicative shear biases due to DCR are more or less under control. We were only able to set upper limits on additive biases. If reality is close to the upper limit, then we're in trouble, but my intuition is actually that these are very conservative limits and we are probably still okay. Of course, testing that may be something we could do with something like DC2.

FWIW, I don't think the work @isullivan is implementing now will have an immediate effect on PSF analysis for WL. I think it's more for improving image subtraction. Is that fair @isullivan?

[SimonKrughoff]

The correction being talked about here is for template generation for optimal image subtraction. When DCR is a significant fraction of a pixel, we can see lots of subtraction artifacts without correction.

0.5" is 2.5 pixels, so is definitely something we need to worry about.

That being said, it is strongly band dependent. It is the worst in g-band because of the width of the filter. It is bad in u-band and possibly negligible in r and definitely negligible in i and redder.

We could potentially plan the survey to observe u and g bands at preferentially high airmass, or just deal with ratty DIASources in those two bands. Chris do you know what the default approach for making the templates is?

[johnrpeterson]

there are lots of things that cause astrometric shifts other than DCR though. lots of other causes of subtraction artifacts. DCR, i think, is often smaller.

john

[isullivan]

FWIW, I don't think the work @isullivan is implementing now will have an immediate effect on PSF analysis for WL. I think it's more for improving image subtraction. Is that fair @isullivan?

That depends, since I don't know the details of the weak lensing analysis. Using the DCR correction I am implementing will give you matched templates for improved image differencing, but also a deep coadded image as though all observations were taken at zenith. I am not sure if that coadd is suitable for WL studies.

[cwwalter]

@isullivan Just to make sure I understand: are you saying that coadd will be a different product? I was thinking it would be a correction to the main coadds we already produce.

[cwwalter]

Chris do you know what the default approach for making the templates is?

I do not.. I thought this was part of the pipeline. Is it in fact a responsibility of the SN and SL groups?

[isullivan]

Just to make sure I understand: are you saying that coadd will be a different product? I was thinking it would be a correction to the main coadds we already produce.

@cwwalter I don't believe that's been settled, or even much discussed. Now that I have my prototype code working and dmtn-037 is out I am beginning to work on a design proposal. The DCR corrected templates require significantly more computation than any of our current coadds (and it's not just a correction that can be applied to them), but it's trivial to make those coadds once we've done all the work necessary to build DCR matched templates for image subtraction.

[SimonKrughoff]

@johnrpeterson

there are lots of things that cause astrometric shifts other than DCR though. lots of other causes of subtraction artifacts. DCR, i think, is often smaller.

This has not been our experience working with real data. For the data we've looked at, DCR is dominant at moderate airmass.

[johnrpeterson]

DCR is the dominant astrometric error? i’ll double check, but off the top of my head, i don’t think this can be right.

[SimonKrughoff]

DCR is the dominant astrometric error? i’ll double check, but off the top of my head, i don’t think this can be right.

No, the problem is that it is the dominant residual. At least this is true on chip scales. If we change how we solve for the astrometry this could change, I suppose.

I'm also talking about relatively short time baseline data. I don't know when proper motion begins to dominate.

[johnrpeterson]

ok, you mean that if you use a particular method that doesn’t DCR corrections then the DCR is the dominant residual. so that’s a method-dependent statement, but i see what you mean.

but i’m still surprised that with how i think astrometry calibration are done in DM, that DCR is even the dominant residual. i can imagine that’s true in u & g band at high airmass, but there are plenty of other effects that don’t even have names that would cause some differential astrometric residuals at at least the same order. I’d think in the r,i,z bands, for sure. How do you know its the dominant residual? Wouldn’t you have to finish the correction to know whether or not you got rid of the residual?

regardless of this, the point still remains that removing this kind of physics could make the DM differencing pipeline work better at the moment for the transient folks but then it would lead to less realism in shape measurements for the lensing folks. so there may be a science conflict here.

john

[rmandelb]

@johnrpeterson - it depends what you mean by less realism for the WL people. For WL, we don't think we're ever going to try to do science in LSST without correcting for DCR, I believe. So "realism" for weak lensers would be to include DCR in the sims while having some correction for it in DM (that you are then testing the fidelity of). If there is no DCR correction at all, then this is not actually a realistic scenario for how weak lensing analysis will be done. We run the risk of having other effects the weak lensers are interested in testing being dominated by uncorrected DCR.

So I think for the weak lensers we'd either want "no DCR in sims + no correction for DCR in DM" or "DCR in sims + attempted correction for DCR in DM", but we don't want "DCR in sims + no correction for DCR in DM", as it corresponds to an unrealistically worst case scenario.

@jmeyers314 , @rmjarvis - do you agree with my assessment here?

[johnrpeterson]

but not just talking about the astrometry though. also chromatic psf details from the atmosphere.

[jmeyers314]

So I think for the weak lensers we'd either want "no DCR in sims + no correction for DCR in DM" or "DCR in sims + attempted correction for DCR in DM", but we don't want "DCR in sims + no correction for DCR in DM", as it corresponds to an unrealistically worst case scenario.

@jmeyers314 , @rmjarvis - do you agree with my assessment here?

That's an interesting question. Putting aside the possibility of using @isullivan's DCR-corrected template for WL (which I don't have good intuition about), I think the worst case scenario when including DCR in the sims but not in DM is that if we have problems mitigating DCR as a systematic, we then restrict ourselves to low airmass and possibly to i-band where the effect is much weaker. The summary table I posted above also was evaluating the size of the incurred systematic in comparison to the statistical power of the whole 18,000 sq. deg survey. For a smaller survey footprint like DC2, the relative systematic-to-statistical uncertainty will be smaller.

[rmjarvis]

So I think for the weak lensers we'd either want "no DCR in sims + no correction for DCR in DM" or "DCR in sims + attempted correction for DCR in DM", but we don't want "DCR in sims + no correction for DCR in DM", as it corresponds to an unrealistically worst case scenario.

@jmeyers314 , @rmjarvis - do you agree with my assessment here?

Actually, no. If we can, I'd be in favor putting DCR in the sims regardless of what DM plans to do about it. Uncorrected DCR is basically what everyone has done to date in WL, so it's certainly not a show stopper in terms of shear measurement. And even Ian's DCR correction that we just heard about probably isn't all that relevant for shear measurements anyway, since we're probably not going to measure shear on coadded images.

So I'd favor putting in all the physics we can at this point, and process it as well as we can. When we see systematic errors (since we will!), we can regress against things like airmass to determine that yes, indeed, we have a systematic error that looks like DCR, so we have to work on finding a way to deal with it. Sweeping it under the rug for now doesn't seem helpful to me.

[johnrpeterson]

I was talking with Eric, and we could be wrong but there might be some confusion about what “DCR” is corrected or not or will be.

There are four observable things from one piece of physics:

1) One is the effect that sources are all refracted according to the average wavelength of the band and there distance from the zenith (which does vary accross LSST’s field). I don’t think this matters much because its mostly a common mode shift to the astrometry. 2) The second is that some sources are shifted relative to others (i.e. differentially) because they have different spectra and therefore their positions are off depending on the relative distance to the zenith and their exact spectra. 3) The third is that the light from objects are shifted towards the zenith in a chromatic manner which doesn’t just change the centroid but all the light so that there is an effective wavelength-dependent varying-ellipticity PSF. 4) The fourth is that if you have an extended object the morphology each part of the spectra matters as well, so it messes up the shape in an even more complicated way than a wavelength-dependent varying-ellipticity PSF.

Most people would call #1 CR and #2 & #3 both DCR. But if you think through these, they are really all the same physics and then just one command in phosim that can be turned off with “atmosphericdispersion 0”.

Now as for DM:

I’m guessing that only #1 and #2 are actually even planned to be corrected because those matter for templates, but Simon can you answer what is actually planned?

I’m also guessing that Josh+Rachel+Mike are more talking about #3.

john

[rmjarvis]

I'm assuming 1 is trivially already dealt with by DM's astrometry solution.

I think 2 is not dealt with currently, although this is the kind of thing that Ian's code will probably get right. For WL shear measurement, we can deal with this by having each exposure have a free centroid, although doing so will reduce the effective S/N, since we will have to use some of the S/N in fitting the 100 centroids, so we'd like to take the output of something like Ian's code to get an accurate estimate of the real centroid of each exposure of the galaxy.

Josh's stuff mostly dealt with 3, and that requires WL-specific code to deal with, which I don't think Ian's code directly helps with. Although, the WL-specific code would probably use very similar math to what he presented, so there may be some code sharing opportunity here.

I'm not sure what you mean by 4 that isn't just 3, but presumably whatever you have in mind could be folded into the WL-specific code I just mentioned.

[isullivan]

My code attempts to build a model of the sky with the effects # 3 and # 4 taken out. If you do that right, when you run source detection and measurement you will hopefully get # 2 "for free". If WL calculations have to be done on individual exposures then my algorithm won't be able to help with # 3 or # 4, but it might be able to improve the catalog by iterating with jointcal and improve # 2 indirectly. I'm not sure if it helps, but you might be able to run your WL code on the DCR-matched templates as well, and at least estimate the level of contamination from DCR.

[johnrpeterson]

oh also, in DC1 PhoSim was run with all of this ON. so does anyone know if there were any problems with that?

[cwwalter]

oh also, in DC1 PhoSim was run with all of this ON. so does anyone know if there were any problems with that?

Basically, because of the problems with the sky level and rotation no one was able to look at the PhoSim data at that level of detail.

[cwwalter]

Basically, because of the problems with the sky level and rotation no one was able to look at the PhoSim data at that level of detail.

Oh, Also, because of the proper motion not being considered in DM issue, even aside from other problems we had quite large astrometric errors and we were only looking in one band.

[egawiser]

@cwwalter that's a fair summary, but just to be clear, all 4 effects that @johnrpeterson helpfully listed will occur in a single band. r-band has weaker effects than u or g, but slightly stronger than i-band, so if WL systematics are tolerable in the DC1 data, then we would already know that it's ok to keep DCR on for proto-DC2 (where we can check again to see if this is causing the kind of systematics that we'd rather avoid rather than quantify at this time).

[johnrpeterson]

Chris-

i don’t know any of these issues are. what are the sky level, rotation, and proper motion problems?

john

[cwwalter]

i don’t know any of these issues are. what are the sky level, rotation, and proper motion problems?

The sky level is the one that was reported to you and you said is now fixed

https://bitbucket.org/phosim/phosim_release/issues/32/functional-dependence-of-sky-brightness-on

This caused most of the PhoSim exposures to have a sky background of about 1/8 the correct level. The run time was also about 5 times faster than it other wise would have been without the bug.

The other two issues are described in more detail in:

https://github.com/LSSTDESC/SSim_DC1/issues/43 and https://github.com/LSSTDESC/SSim_DC1/issues/36

[johnrpeterson]

what does the sky background have to do with this though?

[cwwalter]

Oh.. well it was just with the sky background varying and being off by so much, everything that was checked looked wrong (number of detected sources etc etc). So, no one was doing more careful checks that would have been sensitive to things like DCR (especially with the confusing astrometric errors from the proper motion not being considered by DM). It is quite hard to use that dataset.

Knowing what we know now, If someone particularly went looking for the effect, understanding all the surrounding issues, they might be able to study it.

[johnrpeterson]

On Nov 3, 2017, at 3:46 PM, Chris Walter notifications@github.com<mailto:notifications@github.com> wrote:

Oh.. well it was just with the sky background varying and being off by so much, everything that was checked looked wrong (number of detected sources etc etc).

what do you mean “varying”? why is this a big deal? what about adding noise to them?

So, no one was doing more careful checks that would have been sensitive to things like DCR (especially with the confusing astrometric errors from the proper motion not being considered by DM). It is quite hard to use that dataset.

Knowing what we know now, If someone particularly went looking for the effect, understanding all the surrounding issues, they might be able to study it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1DW1ec6UOSl4fJhyP7uS5tK-ea-ymG46lWcgDO4YSc0hUCVWx2jd902jYEXwUCz_eMOE5fHqEXu7TjxmPf1cbN_c7Cy796XEfiJX7tHLlwjcJeLRTasto1lfp6z6gC2WugbNV1FtBkqD8r9_xEJo-mpRt12QVjklEQsDzk3xqOjzpy3dfb47Z3f437TbaF7z3GvzxLgAJthvJz8V-6pu3pZVXT1LfLd0EDms0Xz0U0kIo0eXASWAbvGgu3LR4pAQP-MhiO8K844oH7gLwKxuOvdHmxWRo-fNg5QbWNYKmq-G6l8EB2fijH6Cs6AUhYfHrjXNQOQqSv8oUUW0DCoTCPrpn3QtfmOL0BwSyHUCmNXA/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341807891, or mute the threadhttps://secure-web.cisco.com/1bfS562AU26jZqfN51pXgQBRydv4bGwRpD7nxQHDUj_4cGRXeImgFUX4Zqd69b01ApuRGsBtC3Cb_4GlfXYuk9UhzSznETHaTcA0rc3i-1c54SmWKrMnQykaLVyphrX6i0cGE6y2L-PNCyh4MqqyJ5tjdHQxwnl_NjKQXNIcD3wqHONyDrmpB_F9ekRPGHwOJv9QO3mIBt7s2cTV-NH2LG9SMujWdMGi5Ec2XeXHaNf9-XYiF7TA4CAlg0eaVOP_9pubbBXKEinxVnotgttYyr3GbxY-Slc5n6pnqEcyJd35xvzW_lm8Wdw6bv9WcX_uSemb0YoG_h340TWL9e_ymFMc6zRliU1oUzWLIPPlp24Q/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8vnQq--z-yfFwx3p8g_aTDWStmiDks5sy22GgaJpZM4QL1tu.

[johnrpeterson]

The run time was also about 5 times faster than it other wise would have been without the bug.

this is misleading. the background is not dominant in the run time using quickbackground, and therefore increases in runtime are small since its a minority of the run time (probably only a few % increase)

[SimonKrughoff]

Catching up, so don't know whether this is still useful to respond to...

How do you know its the dominant residual? Wouldn’t you have to finish the correction to know whether or not you got rid of the residual?

You are right it's the worst in g-band and is completely gone in i-band. We know it's dominant because we've done image differencing of DECam data and we see dipoles that correlate with the direction to zenith.

You're also right that we haven't closed the loop to show that these dipoles are completely removed, but Ian has shown that in test cases doing the correction results in fewer dipoles.

[rmandelb]

@johnrpeterson - Chris was making a factual statement about what happened in DC1, which was not run using quickbackground mode, and hence his statement is not misleading. We all appreciate the fact that quickbackground mode is an option for DC2, and that you and your group are all helping to explore what this means for timing of the DC2 simulation generation. But it is not relevant for DC1.

On that note: this discussion has gone far afield. Our goal was to decide whether we want to have DCR in DC2. What I'm seeing is that some groups want it on, and other groups did not object (or were also supportive of having it on) when I asked if they wanted to object to having it on even if corrections are incomplete or even missing entirely. So it seems that this issue has achieved its purpose: we have converged to keeping DCR on for DC2. I propose that we write this decision up in our design document that we'll show the working groups, and consider this decision final unless we get push-back (which I don't expect to happen since many of the people I wanted to ask have already spoken up here). If there is no push-back on this issue thread, I will close the issue on Monday.

[johnrpeterson]

Chris was making a factual statement about what happened in DC1, which was not run using quickbackground mode, and hence his statement is not misleading. We all appreciate the fact that quickbackground mode is an option for DC2, and that you and your group are all helping to explore what this means for timing of the DC2 simulation generation. But it is not relevant for DC1.

kind of it is, because we could have used quickbackground for DC1. so we made two mistakes. chris is saying if you made one mistake and not the other then it would be slower. doesn’t really mean anything.

but i am making the more relevant point that the overall timing for the future is very insensitive to the background level, since the background is now not the dominant run time component. this is the important point. and this is very different than all of our collective past experiences, so its very important that that point is not lost.

[SimonKrughoff]

@rmandelb that sounds good to me.

[rmandelb]

Closing #28.