Determine appropriate random rotational/translational dither scheme about ssim_dc1 HOT 37 CLOSED

@cwwalter , are the translational dithers you are referring to the ones that @humnaawan and @egawiser investigated in MAF? (I believe the correct MAF terminology is "Stackers")? Has anyone thought about how to do something similar for the rotator angle? I think this may be non-trivial to implement as a Stacker while still respecting cable-wrap limits, but maybe I'm not thinking about it correctly.

Regardless, my intuition is that randomly spinning the rotator after every filter change may be a reasonable way to improve the rotation uniformity while not over-stressing the rotator.

from ssim_dc1.

@jmeyers314 I actually mean the "afterburner" that @SimonKrughoff wrote that was used to make the current OpSim databases. I think this is just a simple Gaussian translational dither in RA and DEC applied ontop of the pointing. But, we also talked about the ones mentioned in the paper @humnaawan wrote. Eric felt that a really random dither probably would be good enough but wanted to touch base with you to see how that squares with your WL study.

For frequency of rotational dithers, I've been told that doing it very often will lead to problems with the rotor and also add to much time between the slews. @egawiser has suggested once a night, and your suggestion of after each filter change may also be reasonable. I don't know enough about the system to comment on the cable wrap constraints but we need to consider for this run whether we should try to come up with a realistic frequency plan, or just ensure that the coverage is random even it means doing on each exposure.

That's what @egawiser should be figuring out for this issue with everyone's help.

from ssim_dc1.

One reasonable strategy could be to use the baseline cadence rotational
dithering (ie only natural field rotation) and see how bad it is. This
would be consistent with the more general LSST scientist philosophy of
"first evaluate, then optimize." If we want one of the DC1 PhoSim Deep
astronomy papers to be a study of this issue, though, we might want to
divide the 10 year campaign into several sub-campaigns, and choose a
different rotational dithering strategy in each one.

On Tue, Aug 2, 2016 at 11:19 AM, Chris Walter [email protected]
wrote:

@jmeyers314 https://github.com/jmeyers314 I actually mean the
"afterburner" that @SimonKrughoff https://github.com/SimonKrughoff
wrote that was used to make the current OpSim databases. I think this is
just a simple Gaussian translational dither in RA and DEC applied ontop of
the pointing. But, we also talked about the ones mentioned in the paper
@humnaawan https://github.com/humnaawan wrote. Eric felt that a really
random dither probably would be good enough but wanted to touch base with
you to see how that squares with your WL study.

For frequency of rotational dithers, I've been told that doing it very
often will lead to problems with the rotor and also add to much time
between the slews. @egawiser https://github.com/egawiser has suggested
once a night, and your suggesting of after each filter change may also be
reasonable. I don't know enough about the system to comment on the cable
wrap constraints but we need to consider for this run whether we should try
to come up with a realistic frequency plan, or just ensure that the
coverage is random even it means doing on each exposure.

That's what @egawiser https://github.com/egawiser should be figuring
out for this issue with everyone's help.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AArY9-H8WYuFT2uAqiYGIjzo-OpyVg1tks5qb4o0gaJpZM4Javrb
.

from ssim_dc1.

Natural field rotation was actually my original suggestion but Eric said that it wasn't good enough. He will have to comment but my recollection was that it was based on the study they did for the paper.

I think I have a preference for a uniform strategy over the full simulated survey with either possible followup supplemental runs or MAF based studies of dithering. In addition to simplifying the book keeping etc of our first effort it means that we can add the whole sample together for co-adds etc without worrying about this extra effect.

from ssim_dc1.

from ssim_dc1.

For the moment, I think there's probably still more to learn about "enhanced" field rotation strategies just using OpSim/MAF. So for DC1, natural field rotation is probably fine.

from ssim_dc1.

Josh, I think you're saying this because WL people aren't currently planning to use the DC1 image simulations. But it's quite dangerous for WL to allow natural field rotation to become the best-studied - and therefore default - LSST observing strategy. And if we do try to simulate a realistic rotational dither pattern, it might turn out that somebody from WL becomes interested in DC1. I also see no reason not to include this, as it should be trivial e.g., to implement a random rotator angle at the beginning of each night. In other words, if you really believe the results you've shown at meetings, you should be pushing us to do this in DC1 and not just optimizing with OpSim. I suspect natural field rotation is good enough for LSS, so I'm just sticking up for WL science here.

from ssim_dc1.

Sure. If it's easy to implement, then I say the more spinning the better (without sacrificing duty cycle or rotator integrity).

I was only hesitant because we don't currently have a quantitative way to connect (lack of) uniformity of position angles to WL systematic uncertainty -- only the intuition that more uniform is better, and that random spinning every night/filter change/whatever will probably increase the uniformity.

from ssim_dc1.

Josh's analysis of the camera angle spread based on the latest OpSim run looks hopeful: we may be able to minimize the number of non-filter-change camera rotations by partially relying on revisiting a field at various hour angles. We do have the capability of simulating the impact on the shear-shear correlations for any residual CCD-based PSF systematic. We did a 100-visit simulation in 2015 and presented the results at the December workshop. I assumed that DM could take out 90% of the CCD effects and that dithering would attack the remainder. We found intelligent dithering may suppress the PSF shear residuals down to the science requirements. LSST Doc-18335 outlines the required levels of residuals and the precision needed for lab measurements. It is time to do a new x-y-theta dither simulation now that we have a better OpSim and propagate through to cosmological systematics.

from ssim_dc1.

For the purposes of this production (we want to define the parameters by the end of this month), I think we need to decide what to do now based on the information we already have. I hear:

• It's not actually necessary for LSS at this point
• But others (especially WL) might want to use the output for studies, so why not try now?
• We don't yet know how various strategies directly map to systematics but we have tools to do these studies. These take a bit of time.

So it seems to me we should just pick one strategy now and then we can see the result on the output. Natural choices are:

• Natural Rotation (we have heard a desire to not do this one from Eric)
• Random each night
• Random at each filter change

At this point I think we ignore constraints from cable wraps etc. We need to use @SimonKrughoff's "after-burner" module for this. Simon, could you comment on the relative ease of implementing the last two options?

from ssim_dc1.

In other news Tony and Josh's figure is now my iPad background :)

from ssim_dc1.

I talked to @SimonKrughoff, @jmeyers314 and several others in Tucson about this. Here are my conclusions:

• We can change the "after-burner" to make a random rotational dither after each filter change which we can carry until the next change. We will need to keep track of the current filter and rotational offset to do this.
• It is impossible after the scheduler calculation is done to restrict the change due to the cable wrap constraints. This needs to be done during the OpSim run itself. The calculation depends on the history of the pointing, so this must be ignored for now and assumed to not change the answer very much.

However, I believe there is an issue that needs to be considered. @egawiser says "I suspect natural field rotation is good enough for LSS, so I'm just sticking up for WL science here." This seems to be a good argument to me. Why not do this so we can look at it if it isn't hard but:

Currently (as far as I understood) there is no plan to apply shear to the galaxies in this sample. I believe this usually is done by raytracing in a mock. I'm not sure how this would be done for the Millennium simulation on FatBoy.

• Has this already been calculated?
• Is it something we want to do?
• Is it worth adding the extra rotation if we don't do this?

from ssim_dc1.

@egawiser Can you comment on my last entry here. I have a proposal for what we should do but as I mentioned without an applied shear I am not sure it is relevant for DC1 and that may require extra work.

from ssim_dc1.

Is it worth adding the extra rotation if we don't do this [shear the galaxies]?

I think there are still interesting questions about WL systematics we could potentially address without shear being applied to the galaxies. For example, we can still check that the PSF and PSF residuals are uncorrelated with the inferred galaxy shapes (rho statistics). So I think whether or not to apply beyond-natural (supernatural?) rotation is just a question of how easy that is to implement.

from ssim_dc1.

@egawiser Can you take a look at this. We want to have this wrapped up by Wednesday.

Thanks,

Chris

from ssim_dc1.

I agree with @jmeyers314 that studying PSF systematics in DC1 is worthwhile even if shear is not included, and I think that adding periodic random offsets in the rotator via an "after-burner" as described above makes sense.

from ssim_dc1.

OK, So assuming that it can be done reasonably easily in the afterburner, we will add a random rotational dither after each filter change.

Thanks all. I will close this.

from ssim_dc1.

I think random is not optimal and also over uses the camera rotator.
Discussion is in the WL chapter.
Tony

On 8/29/16 10:06 AM, Eric Gawiser wrote:

I agree with @jmeyers314 https://github.com/jmeyers314 that studying
PSF systematics in DC1 is worthwhile even if shear is not included, and
I think that adding periodic random offsets in the rotator via an
"after-burner" as described above makes sense.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACA6YmwlGXcF9tLpX63PXOyjBk5dFvrvks5qkxGXgaJpZM4Javrb.

from ssim_dc1.

Hi Tony,

Do you mean over extension because of the cable wraps? My understanding after talking to people is that we do not have the information to calculate the extent we can move after the scheduler calculation that was done in OpSim (which is what we need to do here).

So the proposal (just for this first test) is to add a additional random dither that carries after each filter change ( a few times a night). We know this isn't optimal but we think we know how to do it to start.

Is there already a concrete algorithm which we know how to do now instead of this?

Thanks!

from ssim_dc1.

With apologies for re-opening an issue, I went back through this thread and could not find a clear statement of what the plan for translational dithering is in DC1. The paper led by @humnaawan implies that repulsive random dither patterns perform best, but purely random is close enough and easier to implement. To be specific, DC1 should consist of 4 such hexagons (these are the tiles referred to as Fields by OpSim). We would recommend that each time LSST is to point within one of those hexagons, the pointing center is assigned by drawing random uniform RA and dec offsets until a point within the hexagon is obtained.

from ssim_dc1.

So for translational dithering the conclusion was that we would use the hexagonal scheme that is already in the after burner and then also add the column for rotational dithers. @SimonKrughoff is the person to comment on this. He can correct me if I am wrong and say if what is implemented now conforms to the request by Eric above.

from ssim_dc1.

Sorry. I didn't see this before. I only suggested the hexagonal dithering because it is what OpSim does now. If @humnaawan is willing to work with OpSim to get that implemented, or as an afterburner if that makes sense, I would fully support using something better.

from ssim_dc1.

Thanks, Simon. It would definitely be an "afterburner" since there's no point re-running OpSim. @humnaawan has already coded all of this in MAF, so it should be easy to add the translational dither pattern once we tell her which OpSim run we're using.

from ssim_dc1.

I'm getting confused :)

I think we might be going in circles here. Let me step back..

At the SSim meeting when we discussed this we decided that we would run the afterburner as before. I thought this afterburner already had @SimonKrughoff 's translational hexagonal dither. Then, in addition we agreed to add a new column (which the OpSim team has now agreed to) which would be a random +-90 degree additional rotational dither applied at every filter change when the angle resets to zero.

What am I missing? Is the point that the hexagon translational dither in the afterburner also not good enough and needs to be updated?

from ssim_dc1.

@cwwalter The problem is that I'm overusing the word afterburner.

Afterburner 1: OpSim runs a script after their simulations finish that adds the hexagonal dithering columns to their summary table. So, the hexagonal dithering columns come straight from OpSim, but they are calculated as an afterthought. I would add a rotational dither to the same script the OpSim team already run, so the effect would be the same from the perspective of CatSim and SurveySim. This would essentially require the OpSim team to rerun their sims (or at least the afterburner part) to get these columns added. This may add a little in terms of bookkeeping.

Afterburner 2: This would be a script that runs completely separate from the OpSim runs as either a part of the CatSim code to produce simulated catalogs (e.g. instance catalogs) or as a script that updates the sqlite files provided by the OpSim team. This would add another kind of bookkeeping, but wouldn't require us to employ the OpSim team directly. This second type of afterburner is the one @egawiser was talking about.

I'm happy with either and I don't think there's a particular benefit other than the fact that if we add it to the OpSim afterburner everyone can benefit from it.

I could add a rotational dither to either flavor of afterburner.

from ssim_dc1.

@SimonKrughoff OK thanks. I understand.

My preference is option 1 as that involves the OpSim team in this discussion and gets them thinking about how we eventually make the things like the rotational dithers part of the standard calculation going forward.

I talked to Kem about this at the simulation meeting a few weeks ago. He is on board with it but asked if we could give a presentation to them after we get a sense of what is really necessary/driving the requirements.

In anycase, I think in both of these afterburner cases we are using the translational dither @egawiser wants already though correct? Eric if you agree can you close this again? If not, let's focus down on that point. Thanks!

from ssim_dc1.

@cwwalter here is the plan as I understand it from the replies by you and @SimonKrughoff:

1. Contact OpSim team to let them know that we want to expand Simon's afterburner to add 3 additional columns with names like: RandomDithRA, RandomDithDec, RandomDithRotator (this would keep Simon's current HexDithRA and HexDithDec options in the OpSim output instead of replacing them)
2. Adapt @humnaawan 's MAF routine RandomDitherFieldPerVisit to produce the RandomDithRA, RandomDithDec columns (=random dithers within the hexagons used to tile the sky); implement a parallel code to produce RandomDithRotator.
3. If OpSim opposes expanding the afterburner for any reason, we can instead add these columns through a post-processing of the OpSim sqlite files. This is easy to do and could perhaps be called a post-afterburner to distinguish it from the afterburner.

I'm happy to see the issue closed unless you have corrections to note to this.

from ssim_dc1.

Sorry all.. I'm still having a slightly hard time following the details of this. Let me try to summarizing what I see:

• Simon's current HexDithRA and HexDithDec codes is not good enough. Is that right?
• We of course can add new columns to the output but we have to choose one to actually drive the pointing. Do we have a consensus on which one to use? I thought we did but now it sounds like we don't.

from ssim_dc1.

Correct - our published study found that hexagonal lattice dithering performs ok on some timescales and poorly on others and is outperformed by random dithering on all timescales. The columns we should use to drive the pointing are the new ones with Random in the name; that's why we need to add them.

from ssim_dc1.

@egawiser Thanks!

@SimonKrughoff Do you agree with all of this and are these changes something that can happen on a reasonable time scale?

from ssim_dc1.

@cwwalter I very much like and agree with the plan that @egawiser put together. My only concern is turnaround time with the OpSim team. It would be kind of nice if there were an OpSim member at the hack week.

In any case, here is the code that needs to be modified. I think we can just fork it and issue a pull request.

from ssim_dc1.

@egawiser Also opened issue #23 as a supplement to this issue.

I am concerned that we do not have people to do these two jobs (+ add the rotational dither) in the time scale necessary.

Eric, is there someone in LSS who can take the lead on this with @SimonKrughoff as a mentor?

from ssim_dc1.

I think we could assign @humnaawan to make this happen, as long as it doesn't have to be done before Oct. 28. But we'd need guidance on what format you need the answers in (an update to an OpSim database should be easy with help from @SimonKrughoff ) and when each item is needed by.

from ssim_dc1.

@egawiser OK that's great. @humnaawan, could you contact @SimonKrughoff and find out what items need to be done?

These need to be done before the actual full run starts in order to drive the pointing. I think @jchiang87 and @richardxdubois will have a better sense of that after the CI meeting tomorrow.

from ssim_dc1.

@cwwalter, yes of course!

from ssim_dc1.

@humnaawan Great. I am missing the CI meetings this semester due to teaching but perhaps @richardxdubois or @jchiang87 can update us (or give us a pointer) to the current schedule so we know when this needs to be done in order to get it in for the real run if it was discussed yesterday.

from ssim_dc1.

This job was completed and used in the DC1 production.

from ssim_dc1.