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

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?

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
On Oct 30, 2017, at 4:54 PM, Chris Walter <notifications<EMAIL_ADDRESS>wrote:
I talked to @isullivanhttps://secure-web.cisco.com/1oZo6U_dm46DXKTT216XJIF66Z-pMK-n0wDR0d5vnJkPuQIMkMBxN9OrPz5jVBazePf2Yrc16qaAo5pxALiVyai_Ma5zjHlKK58yBfylfJvlCRrfNwC2VZyllYAjg3q5QiHckeaPb32wGu1BQVtAU5LvPLhASi25O1xAadtyd73nou9UOTb4f6xv0-oayEl0Af3Q_cGeUqQQuXRByLZS0nX5fyil8UuDX09x-VLaP_FkBe1sFB_CjEkf_YFlbfyTr8yRoTL4jL_pmKM5dwu6gX8-ulKB8rJRRHtC-DXJRKLholANsNsoNpF_aqkZ9PyYevJf9UUYbtqMJn-YZ2nPlQd_-wvWsj6TUv1dwbxpDuTA/https%3A%2F%2Fgithub.com%2Fisullivan 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.
@johnrpetersonhttps://secure-web.cisco.com/18bXvk_JGmnnUdLq-SOW5uL3jWYRSdFvzhAFvd19n_GgpnbjFFRO3ESN-4jqL1baUfDyEubiG2D0lpufYnWqdzHryAlIdfu0rbxLKza2ORhPozcoOJAaq0AxBZvXK77UK1Q287mCw-hVnx4ztitp72-xlfqpbF3Fe-buMlveGXK0_Jrhau6i-K1qycG7D0EUBf_o87cXmQL3KAQMST4GAGtXkfVetLYa_33V4monShbcyn6F8Zug8HGbTWBWr3DaerICaOi4E0e35wWVtMn5bGluKFzTRyMl50J9tXVidroBHPAIzId9P16rtTb4VzejOXAVlM9FmMTfItEVNcu1vlGo8fcIJkI37dCJILRxgG7w/https%3A%2F%2Fgithub.com%2Fjohnrpeterson: In PhoSim, do you introduce a separate refractive shift that can be turned off (and is it exposed in the UI)? Or do yo do it is as part of the kick calculation in the ray-tracing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1vuW1CAPMX_bNs01irME8arGbiJgdh_t5JXflugRUvKX4R69RvVnFal0VE0Mj79Rn-P4MtTRukbf3ulH9OhKCJRcTXlg5xB63J_i0eA4aqMBZ6k6XTj_Mt7HtM_Nv8g706FpMtFL7CgtKAO8MSPu_D5qFav9nqFwgqpbbIZvxK6iF7IA2Erg86PqnYolq8aBI5gzi0Ng1U-M2dQPcEuRuFgJg8wBDR0j63StCYNeWt1OtJFy34EKqrD2rOCKhZdUW7d3O5dEX6OxmI-NxKhFqBbdsqweqfOZ2YSgR1IfK-ZyiXTXQrPM7g68R5wtCqy-hZBzU8M3BWiCRDbp_I_CasNDu4Hjhd7l3jt2mxwFm7ig/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28, or mute the threadhttps://secure-web.cisco.com/1z1SfTuu2QjHn9A7G_yhGodKeFt_fB7nH6G4cnMm2nhf2zKzjjCQ2YKIs_QluyJht4fycSNWzIlYWE6JMtRVtp7jWQGHIVhBUcZmg4FLqjMZQqk6wW_q8o053R91gEDnr7KWuPBl3W_mq8p0J7S5ba_VNNmGHzcV0pcV6Pn-7MCX0rwhdHkS5C5uOrK7WsMIX8DGHwBgJlJMw1OzW6iuKx3w8OwnXYeXvxbtFMeIsnWGiHLa3ilmyvyByJg7vG9buSYyfkmgUlVBICikOhy9A-HMbSYreDXESx16uMEmK0goYq3xAsh2V0KGiZnowgJ25__lAu09Drg7BPoqh4NtvVK9UTqzqbJ1_-YWI_rTtsag/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8lRbtHh6cq3ziC10lkDfmYur4gMXks5sxjeXgaJpZM4QL1tu.

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?

@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?

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!)
john
On Nov 1, 2017, at 11:39 AM, Chris Walter <notifications<EMAIL_ADDRESS>wrote:
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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1z1peQP5Kcv2lNw3qvGRMap7j35EwXhm4dlL1SydhnB9RuieoQBZ0sB9xdx90oWZ9vBE1Shp0wwIsYQ-RHEYyIH3ASMpsZ-I5Qo44wxa0ZNrcm75P0eA98sYrPBQgWNezK-qqzh4jloNpnw0bh0OGpvmNgDvAU5qCF_1QJbkTyuv5vB5Lo8TTqCT5pGtTZsQlio5qWD2UaeYKsZZibzSsdH7lEO_aHev4tc1Pkkl3rDm5P0y2rH49r6qOqdnmfAfKqZEQ7U_xnbgf5BW0shs00Di9LQ3iV51btA5VG368q0lvdGwszFpeO2QcUiCHcA3Eq6pFAOekrKgCtAyeKTknYJ_CCsJcyOUQ-z5UE7K0Sbk/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341144219, or mute the threadhttps://secure-web.cisco.com/1lIhye2-uoYPZyiFWRj5RhEW2nPkzRpOovrSRYqBzdoPK-NxZO4kthxIPyvzMwLSV3R0fqx7mBU8nor_CXllI1lW4h11MlGwmn6EQCegUrwa7M_tx62E2ouxyXHPpDGaz8XBkVXmPPFN0ixfjAOU8nMXbJJS4Caej9_K2rRfcYrbp72MDWF6ebU_assuioLAIZfDGr5jwJily7AtI-9HqjqibG8WUF9rgPPHicFctMnc8P7XnDPxMarZBf9dLwSeYfyqTVHCmRRldNX0gB2HbayKLVRd70uQsR5AhM280Hu_Ua1WPtr6wdDzeEpbdoQPoXuUp_AuaFNcRQ-UkdHftR_1WKjMMgNeg0obseEqWM_U/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8mBPtNxJ5CSIC3HU-ZAEkTxCY1Itks5syJC6gaJpZM4QL1tu.

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.

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?

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?

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
On Nov 1, 2017, at 2:19 PM, Simon Krughoff <notifications<EMAIL_ADDRESS>wrote:
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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1NOQcRMUAIC6uO5B67_7lBirakYx91MEVGyHtmZHz_vpdv3b93s67MmeUO5n9rcd22pt9MU1vZwltTDybzghK69hQxxZ8rYIB9GyPRLbBkHZ_BdZ8lXXYC9vy-9yusrtgebCRmlVBXuafR0Fzwd3t7CRmGRFQdGlDUVusmwHqXQ6IyPeLdN12JkUa9tfQixiAmzgpRrpXhn55SLBu4oxAQcVBUKxX1l_SHXR1mYWMNkQu1IGBHR-764pcIC4W8U2KDwzOQBVfDov8hYdI5sEWlfJOobU0MbpeYm6Bh5XuP4EdZf23vS2qw8HdwEs9ZS8ST_bIxSrE4RCT_p32U22Fwh8wbaOvEB0rbGR-n_khJnU/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341194202, or mute the threadhttps://secure-web.cisco.com/1gWDeFlnYM_zfWziCu7zJIcw-DClkTQjMIjW2qDjVeXuVAweBTLfwIBpojbemDiA5IkND0Mwov0hxRGRlNTicSr1CdwxtAeJAFWWav4XJtI3bf4Qjiw-5VbLETz_t2eSlXLuI-qlEqvlBe0zhI9wQShgUGG42eNHrHeJKXDqd5iCFykAjkWW1Q18qLcS3hZwS2Uyz3wthObBlNSCUk076-xE5KXee3tTWWDTieZ22zkaWR_R2olER2JXX1Ap--KGrDpEn3-G0Klc6m4j9PMYcMCMIrVp_uEFHwErDlOkHPe7S4zNLWpzZ7Qedv4GIVF6ZPvdxGvSqxO-WdFfrq7KrZJUhD_YCEMKIrPgVviLzdbE/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8iNuqhSrdSXUjgCHRFxtsmfYw41oks5syLYzgaJpZM4QL1tu.

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.

@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.

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?

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.

@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.

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.
On Nov 1, 2017, at 3:21 PM, Simon Krughoff <notifications<EMAIL_ADDRESS>wrote:
@johnrpetersonhttps://secure-web.cisco.com/1Bntu1sWJyntWmQLJXss1DZ5Azh4E3bBoHJYeZM4LzqxqEgfueeHWlqTu_Tp94BSv6g6Vz_Kq4eSedg0IogIHzW48vbqkCBHOszEemq6L3_pt5US1tBjRMu9-POZRAptnRLt9yhJCSO2KvX6Up4-SDZ1oWrVrG_kSDzuVkc6G5dxQQFrm6y1wjD3i5BPxLtsUt8glLPIP_Z7KdXwHCbnOdBQob7VFNuuiUJIBmLGXQQxJjNcAfQhVGT2jGmNM_nqxZDS1wTPkQJ0FRLMAGqhweEdGg7qal8pUmXolzkMAXbBsaVDSW-oVyUNT9A0YELnlDKalG0pypJmWEQ32l4K7vxY-NaVVNRp5WDmhmKixmmU/https%3A%2F%2Fgithub.com%2Fjohnrpeterson
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1WUCP2yh7B2uax9ai4Hy4Iu57gAeLCz4cifSd4ycuTNa7iIGLTJylpx4fgWjw13Hprw_pv8ZEo9BO9y9xjRBoz2XzfOBPSowLXUYk-kzutT1qkvHoy304GukdGB4SBiFt7kb-vhBN03YsDOgLkJV0VPnBAVEUC25FJYzATiWV88lwWeIj8WtcFOEHpPsXf1NiHs2m1fQP-O7bIUtF7NSRRVpfUGnyB3U--fxtFQoyScg9uDD-DMuCNdsSu2F-bU9rvMAwpqLI8wyrrc-dlhvYIpbjWvromWqbPqfmKeDT_afl-t-AC6QjAr51i2fpVL6MLaaDH5GxDXLcjJZU_CE0MytabBk8NR0s6GrjLrTHmLo/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341211574, or mute the threadhttps://secure-web.cisco.com/1amJS9QY28X68NDlle4EUdCJzMf8_BK50r-_lccx-fdE2L2s5tBKq9Lr7wjklQpM3LxwJ8qDyGFsR0pZzPw5uIbhsWBJqNfKjWvZ0ncvJCBi1XLNA3tSOQxxW2C88tf1Yhv179Jcr6NacmY90ezHBixUbzSCviRuN9GQZ4TJfTZqLDP78DkDcaZQUOHI35m0rqGUqynzPRRD-_GlCGh0jbx2GMXcNfIjXUbj_HPL0KXlY1ikHY8lSt8MGNLSgGzYVrQGKf4xioVM-09hyBItKzZ6AsCmOYHlbaDAfuKMme7wx6uXy_iChdlYN626oMNnZizhW0vrleLJ1LjYqe6P9lb8lg68HMjifQxcLlVnEIJs/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8sA1PfISYC_d3WgWnwrMLn7o8kQPks5syMStgaJpZM4QL1tu.

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.

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
On Nov 1, 2017, at 3:26 PM, Simon Krughoff <notifications<EMAIL_ADDRESS>wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1ZanmDwglqlEuuAtEGkRcSWhw-8yhmANM30hNC0hPZrZGo3-sOxJn_ZLv4pvFcnmEWySWePIVaQiA9Y4I_pklyoGh1tVdd7oV6URL3WJC94LATc0DqmVvmrL5Yv4yWHov_LIcmD9uBKTxPubiAmAzlMD684ZC-nnmOQvQXpFYW9bsneE8IiGVSULeRJWrIa-eIfhAHg6JvXd7RZU-VhjJLr6soW4-CKY3BdhWLU0nWhZ7wQdqSXKrR_XxWo-jpjd74363Z2asD0a3W5OY0yujBuy_WITmul8Gjzej-Bu3-Xp2hg_zdeniV8eNRX7Do_Y43hDNtFzeSGj4QhDv7nLKxpwEY3EZgZ23nHFEniqzRds/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341212944, or mute the threadhttps://secure-web.cisco.com/1DuxcGEuROa5SSaRx9v9YOtHVlrstPITBp83LuVtdpns0Ckyw6A6Xyi1mlNYLXwyzE7zdbaiTPtRgz2hJl1xyzCPLd2RXydHr-V60G-PaEb5Q9ZBRu-pl6fsi8R-L6550_lufEuy0ejk8ZKmCdZYw7iYbrlyRdWT9_TuNO7l_GEXRol9DFIqs_OrJWJ3kd8W0o1a2K8m0Xyy6JAylkxYrU8Wzh5LPSCfKMGUxX-xN_nHejNM9eHL8Tmm8pjhBUL__pivCQJ2_drKsDYOX2WBgB7S-201d3ieLOKcm8yJ2v8V56CcBmCF97mENJX8eYG__Hfek8_89DoCSypw543jC-w-lQBOOiSh8bN6O_RgX0bI/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8o7o9Lo5qxz83-Qkj51KhCKkw5PDks5syMXagaJpZM4QL1tu.

@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?

but not just talking about the astrometry though.  also chromatic psf details from the atmosphere.
On Nov 2, 2017, at 9:37 AM, Rachel Mandelbaum <notifications<EMAIL_ADDRESS>wrote:
@johnrpetersonhttps://secure-web.cisco.com/1HmaNc-Vbrgb0l0ia77s3VSn3DT0zTWJlH62LXkjP9onEUsR9w2hS3arM96HaUy0cMShLIAMBPkyqS0-_XFm5S6zsAyWx2tIo_DBW1g4D5MAZdWGB5n4vCimkTGal210d11p9xHhaRrSbttIQsLlHJDF-1rEu91zJ6Q3DV9kSUA3P2wqLi85Dsoer_-Rad9dbuXRWgqvAIb9Y2vRiDvGbjWbXCz-NdUnjN6sYeqlecQY5s6F7gGoMYzwqCG1rm1u5Gm-SykAr26ZrnYIWXvAAuKS8S8d1u43-Djt6uqFgDfJ1pfCcx_RM6H-kLKgbyxny6VMDbTT4hMj5rpCjQljnYAM_mknhh4v3_NzeaUrh8_g/https%3A%2F%2Fgithub.com%2Fjohnrpeterson - 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.
@jmeyers314https://secure-web.cisco.com/1phxbDsUiKj8g5za84P-1W2pbYt_JXLTYBzlk1xw9_VUr5XpSgoSrdbu-dyta6_cpXC7LQGO4PP63cm6BRsVLMjvmXaEhZ3fmSRWR7rsqKBlhb8bLiJGUm8iGZqMPbEpg1mkPaDyBcueg15ogwXQf_T2WwDtCnujlvoHQY5bX2G-91EQvsJafVQswGLGyZ9l5fU1hPvzNU8BSntzjJhFCnqki_izSK5j6cY-f3V55WMuIdpImfnO4D6iOXGjyMEdSGD7uKHchorVKa7CZlQsFG6_LXhaZvQnRF0LBw4Gk4YyqDag8V5NsarDxkidfRDxjAuz3mCagG1YQez0-fOtiROaDh_pycCmY0gGO4dsqoy8/https%3A%2F%2Fgithub.com%2Fjmeyers314 , @rmjarvishttps://secure-web.cisco.com/1DNSZY4H14bTHenP57kr26xCyuUTBGgd_TiENNJnmlG1XHlUpFQnU0uxTDI12Y1q24iD_RMoGZFi-niab-0fnzvA1OFhJ0GKLtOO_Em7acSAksEeJzHx_NetI3glPR_DG3VxUHE9Bkfm0g-3S1GNrojKMAaN-p0XR7S-SYubpHnWbr2oafkJKQj7TntZ034_NIna4u4vTjrAacgrpISHwir0CPQ19R7qpiDrNe_soA7WTb7TMYQovS4zUdD_Ornb3wlH167OblbSeKhsB9mS9IR-0sdXzx0uTSyQ7yxp-wamXtnY-kqiQ3hfutE0yvX9KcXZlbTayfWvbmzl_67PrrkKsxQDq3ph3Ii-lAmjT348/https%3A%2F%2Fgithub.com%2Frmjarvis - do you agree with my assessment here?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1QDpEmaKwn5rsb52GNk94HZQndRPT-rQ85-ZgNb4w30xFNUR-g1hTl2fv5l1QRW6QRYuQS-wlqwptE76xqaBf1dT1ixR1rDFp4eQXX9SRDF5KHVatKUuTyG0rFdVFLvNzFUk4o6znCx9IMtuuYSPphkMyRNNFUhxficBe6s9WmAX_EwR1gCcsJkO_R6g_RIPZDbVFmeGY-ib8L2vUdGgxuiEEHlXs-JeTQpa7NsQCoz0t_lsT8QXISlDWQnXDSN2beiuzeLvB5XPWRpPB0QNpwIRHxPH4pl4ZLGeh4hoLJR7xwvMhtlWDxmuBlCNTSh_8RNf5lqIrB2rBt1PTnyl02B6oqKF4ja7Qt_d9uigvVFk/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341422918, or mute the threadhttps://secure-web.cisco.com/16jHZWxa-yXGAsWlZPQBcLRTt3lH2_BzC1qyiCD4osslzzkGkHlqLqHd7zVcaJ-vENCF2VJWqbKu-LP6NaRsDt4ptUbNhadfyk5SPvpxqbVeuoihtgdYwgJVVAXsIdLyDdonxoRTIrM83cATX3X-13go7fdEW219T8RfrFwN9u5wqhXKjOrStv50B4ktop27dODEp6Qpj1pMh6hkCgM0aim1KFHJc5C0_jjllgfoaoeL1q31oq26LbptC1XaB9ddKBPKe0FiZYuxhaAsbkyLk11A7cQLbAB6VQCpQpSHg8oYm_KR0CQYspFOtIsUYsBQZBsPbJjj49ypqMuLqn2lmAt8znV-n0iQMHWXgxbxhL2c/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8hgf49GD2DKUBAPCqWGf0bmcRpnJks5sycWigaJpZM4QL1tu.
———————————
John R. Peterson
Assoc. Professor of Physics and Astronomy
Department of Physics and Astronomy
Purdue University
525 Northwestern Ave.
West Lafayette, IN 47906
(765) 494-5193

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.

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 run for now doesn't seem helpful to me.

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:

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.
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.
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.
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
On Nov 2, 2017, at 2:30 PM, Mike Jarvis <notifications<EMAIL_ADDRESS>wrote:
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.
@jmeyers314https://secure-web.cisco.com/1xSchRKsLmKfFZJbmEPqPpHEkBJ3ujizRc3Figsq3ejmfbKiVz4J3LVkacB2w9d-m3geEg_-roKVXQJ-4biAfwb6-e2egoB82AKkOCkSx8akTwVtdWNeU8nZfmHOzUk_jxs-KziuEiadwzu_Mim2zuKeGcfTkirB_fzGKMO_nGqltgA2hjKY4hQ1zd0vCsfB8XR3xS3MluPVyzHSw6JtLwve2hN3IwbHbAEIIEY0xZ72gCRrRII064HtulGDur58YLSo8wY9sQttLvlamUk3NoUgZT5bp2Ud5AmMV5C5DtPmX9eAYYDkIQ1i50H9YomiMSPaN6FhBHamtRqHqj4YADxYOkMd9fFoU5O0Vz5zSEQE/https%3A%2F%2Fgithub.com%2Fjmeyers314 , @rmjarvishttps://secure-web.cisco.com/1DS7i9o-9wGAXB1lMkhnR_TsWbQZ77YRK2Tr6VwEbxlhTUCtCzz0TKhItNuYRDYuZ-ItgOImHPte2VVLhwnZpNe6z0JicgNOL5Bpz7fXupjh-vXnTBjp-E4k6_9S6D7XOMUFUMdipo6P8AEkVnpZVjMIS1aFhWao0jiJJPgvv5iaq_n0pz66_TkH-3dZPtKwyB6lSZdjJcFeYk3VkFWz7vXw7ekgL9Jh8iNG5DeN6TfYIkHz9ibVK3RjmDVFeQsjNN4xKFudQgcE5Qq1pEC1jJL1_VEen7jMxusOrO7KpQVnpIX8CluFMjhva0hP-UW8azwR-Uth69NrgmUTb45N5sQ762ygylnRMQP727E88p78/https%3A%2F%2Fgithub.com%2Frmjarvis - 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 run for now doesn't seem helpful to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1RdXkNPfHcrlXYYigrI3_fdWH_6VQpaEypit5uUtOjWK5srNcozPHVerfninQnFBGKaxZfCk8xlya9CARRzF1KCAeHQnk5JIZPv5MUVPcFI0HbIE5Nw1_jh79v3p0wUo5YB6aS5D_fogxXw7omjNuKmBKpxXIQ6oUQEGSPhqP2mGJPaGQPF0vrRYWqB5Akm-Ll2Gt5Xl6MkpakW3yUbin5MDT9JDxDSTAZFqOCpm3oVoCYSSDDLkgx7crrDowQaDWa05afmJ9SorbA9yD5eCpEHER7yKK1l62vkHQM-fSxqk0l7QO6g9A4Baw7BEzTssM55Zd3XA3Ct2dRQMyKJkytR1bXQP81Kh9Pw1FrhLSRaE/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341516943, or mute the threadhttps://secure-web.cisco.com/1zvX63BHGI6mKXcGbxfjE9Q5Wst4GJ4KJwcCP4RJ33_UhB6NIRzu6UbkoWUO6C6HRAFKV2iQEG_ag5IDFzyuaL1FsqVsDxCrOWMXYxke4FRoXy1EAy_ly9bcN3l9DE0UuBywUsPS7AJr_gK5Ehj_zQOTDR5-ZfvVF0idVjpkzRBClSJJu2kRSdPHvLJbv7GgnFTknTJnsMpzrEeNCiqIRdCWGFO_mz1eFtQPP-w9PyIxKbwYmr3udizuvjKikXf2IYLwgA66ZEBSekAne45RtQxD_to0SFwa7YvO4b7QpjYHQkTAafninO_ZdwaydWzjlNhrgxOqkCC8BS4bmvBxUp8o31hlCRDpRZp2dCbGaet0/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8vknlYcG37cocj0ghiEYJxePjoWVks5sygpAgaJpZM4QL1tu.
———————————
John R. Peterson
Assoc. Professor of Physics and Astronomy
Department of Physics and Astronomy
Purdue University
525 Northwestern Ave.
West Lafayette, IN 47906
(765) 494-5193

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.

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.

oh also, in DC1 PhoSim was run with all of this ON.   so does anyone know if there were any problems with that?
On Nov 2, 2017, at 3:16 PM, Ian Sullivan <notifications<EMAIL_ADDRESS>wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1iT0qoeKgbhmYENOrOKDkrGkYj-rR315GyYzrr8e-I9qvvh0CTZypuxreTdjAaE3PhigTiCfoq9vduszZqfRnt4cRFA_vFBzqKkiz9DPQ0KYEuJUoZNaETBibwXBbNPde5InSJts63o5atwcXULLUkbQyUud3f73sBACwwN3ueVLQhR1VfmFM-ryDYdUzjB6DY0tAhcpiwrGSWlQVWf8urkR0LhPaoVk3Jk9IfTVKV1jIMQBkykpo-ns_tExAaSOJ40nLpBBAiljLlvWOgDixz0JdD8bVMNwI47bqe8e5aXGfbjaK_W9lvlNwooxJXU9HjXQOXzX1cRFs8xNYprxIS7a-xbIznNn2oE_ZhAv4CqM/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341529452, or mute the threadhttps://secure-web.cisco.com/1AJona8m06XYWpJ9BieL8X0zq9cMb46H189CUvP32ADSFoYDZkNzPMZU2g2JhZ2ZnwT0e6dQ3NjCuIV9tQKzgXkFQ06plF4LFxtvrXqPDDtL_0qXOQ_b3bzGscDDS6g_WcwG7m8HXqMyIXJ3ep7gMA7g1FfySXaM1vNIebLWUmXiCCQJAEDAlt1ogDR8iTtbo-7cYIcC4H_iti1m6ExXxlReYXuusvUHZEG0UETM1sYE2s_FLTJrc5qZDrJ9q3CnFXPPT9oQvXXvlj0-jAhXbg5SrkL4drsOYDp998evf2xQH5vDVvHcgJEPuf05_rJGXVSXPxC2brwlXiBp1UeFM-IvkeIZwLnEl2iFwiLiZXOA/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8oLFnBahxtR90rUkNG3vDdLNIgOyks5syhUIgaJpZM4QL1tu.

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.

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.

@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).

Chris-
i don’t know any of these issues are.  what are the sky level, rotation, and proper motion problems?
john
On Nov 2, 2017, at 9:06 PM, Chris Walter <notifications<EMAIL_ADDRESS>wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1qt3xSNhMjarU39OrCyCVQdTg0hPXdpGruoXfY1TYbg_1Y_dMZTDy7OwVEM8q4tolmZa5htrk4sQYLOOvPrMx58z49Hm9DodiarcQiZz24yBTqQyCONya6rxsjL8d1B_4Lv_uWwgOEeorZwXr7dNqEQyK3RthM-BT0EV2CJEdBd2qH37OAceRxHRxw1qdcjnPm4y7rL_Xw7DWNRrjisM9Rl0juQYrBYFqqrlbnn4DSoeFUuKjDGv0nTJVS2-1odEkoPIWOP_Omx1W6GgIOc62T-fNT7TRRb-M5mfFAss8u3bvmpMw0t5ZmMQ4jxdJQIT1yOA_UVSiCJz3Vix3lucWht-zvThmVY-Yd5ZOj-M-v4s/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341601406, or mute the threadhttps://secure-web.cisco.com/1vw1SbTE39K2bnmPHs8pdrlXtDxAT0r4KJlzPv9g-p_asdSu3KuxnWGDCvOyvJIDGDLUeIH-hlhN0rZXfcNbj73zoHrKt0fIpmRyMfSU7O30AkXUfsLvlp9i0VRlLg-TDIN2D1FgFeHlvE2_U8R4vW2mwUgJEEfsoiKD2ZiVJqSl4ilm9FDni1hd7gPPQKejAIpfb9v8dG1EkPT7KRBtfSqydgYyiusruKRC7KsjPplB68bH_IybuaQZWpFsJ--F8CaD957ZFnsgeCTfZ9cCiEtpJvWjABYDgx_rg5NbYvz1W4OvZHGau8Tf812uVYjjhQBXdlSh4sCo0pMNniLYGkU2-GqA0GsNL12YjwNRXzLM/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8tP4XSi_9upktZfXyGjucxybzjFoks5symb5gaJpZM4QL1tu.

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

what does the sky background have to do with this though?
On Nov 3, 2017, at 3:27 PM, Chris Walter <notifications<EMAIL_ADDRESS>wrote:
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-onhttps://secure-web.cisco.com/1lB0pkGE6_DJFx5G1KJc04WaIvQzJ8_1eMFC-rHGr6Sr7RFKG0A9iMxlgFHEmVHpygshrLKuzXZrRt7mPek0jmsDyGRVbOm3oKXWNwUDC2MWs88qVhx9uBcNxy2MzMjr67FmOkzDZdBZBGGB8k2SJPRFKvV1Xo8aNZac8IRKFNd4fGvly-4o0Fp3GP0QSYsk3Uw0tz0Ugh4YLz_lG4TfPxHO7KOHIZwxFaldUR29LK74-wtlvIZNs6uIUud8XRJTYPayE334vxGIgMaJXagpLTMLdY2e17len9XSLpTCVMmnstrHSc9sjCx7XtCnLjI2uUVvuoz0YMyYyOhAGzkgCPGPPwY301V-nUCXG5rI-y58/https%3A%2F%2Fbitbucket.org%2Fphosim%2Fphosim_release%2Fissues%2F32%2Ffunctional-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:
LSSTDESC/SSim_DC1#43https://secure-web.cisco.com/1p6z2fLko8EJsancBONg_tsuwc47RhGIgkBHx-WRnsGYiYOTBOiiztyA3r5s547N50cMz95fVj8y9tx9BmrEYeUgvSF-JRoIgFmm-ygKiz4MilYbCGRficJJOazGtumn0-FzkowM3eTft5d5cy9nBxQ4-R7cUixFhTx4LPHB6ZId9FcmUxrx1P2jCNNMw4468pl1N8vy-NuHUsga7V3K3iOKRONN-FiweaCYyPVU2glAYZ1KLDBF-VMw51dygrDC5rc3e1DUhBAQGPI8ahHcpLIj-JGqt85pdCW9BauufanvHSEDxGySrcXijQKlYjsOhKuyvaDN0p6nm-fcGHhoLIRRPIjsMjaiBFea2EPxwOZI/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FSSim_DC1%2Fissues%2F43 and LSSTDESC/SSim_DC1#36https://secure-web.cisco.com/1N-kHoAg8BFixMB2oPboB7DGcyRQEhOgxcDktCgislzj7-VAXZnxuA1ygtJJveOTeqJ5r_rOZz3vpuzlUINantr1q7GJA8cwnYMBJR2dTBRjU03sL6xKQD3tMqBrxPi_RIhbBTorhyPxitlRSlBNyF74H2CsgLtLn35jNuezgxVL9xDSZnhD1YBlMWeMLDArs8IVuA89ZrPEHofz2R8DcogzU7frI8QSuBfT9oxs4ylR7dphZ6yjomOGULEAJvQ8TOm8o6400FA177M6uJsKupxvORfRKuCWMa8QKoPh6W8F4XhDheLZ5p69rzfa1RCFpso8jlSgZ74BTMdD2EZa12myaF0PzZaBkQ4y0J9SbrmM/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FSSim_DC1%2Fissues%2F36
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/16iUKzqNLC3qq5MvgKpn7pyUJAoQcdW5hF-ozDfWOfRyArMl5MEnOS2_Lw6QUTcT4QtYwjJrfB8PkkeQj9u3vX1v3d2GzyLhKZ-jT9_8-S_L5Z-TUAzXstinaOcGVKOqQ1OzeyifIpdVwpzantyPB5ZMalZdhEjja5wpbKy80CG9WH2vTP7llY5wyj8EQg7A_JKDdQy1pT2xOoaP-VZY9rbW4Km4mQmpaAvs60Mu8h3DdjbRRZ4R9-73Tn32qk4tETv2JWodu-RsUJ-jyQakHZgOnW0U0m7u7ePNj7MdE8ZE3m9wxymliVoCbysXSL5D32nyOa4nYAmhKIvoGxVDrOkYze6MUmS1QlfRcKSBHXZk/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341803571, or mute the threadhttps://secure-web.cisco.com/1PUIM-3Yi0OKTOe2DKGzVjGyHbmuliAzlM1m3qd7TTNWvB4a1Cc8ZNSDol-tMLXMKiuvpgshLmpDI4sQVy80bUmN1f9cSaVLv7dIFdRFYXi0TOH7asbaJs6mHfgOOBLGGZpo9ri5Xq1TbOgSd5CfMFtHCFfmxpZXQQPrCFMdNyv93ikNEEbnB4cnVYBfoaENs3LSKzVXBhnE2j-4b7XS9xnoKWriG9KoNnHSyEpGLL6x3bvtbexKqSMJvmM18HsQecoWaMXnUwCAp6cQxpvy_WE2oDkqQmzFIRskS19EEq22PCgvqQaxrAlqs-JR4JhIqSX3ooYfwDAo8FfAasr5QhWofuMhzRrP5xZcyXDunTxI/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8ubYn4MPrVIG09TlbTHVVtiD_JH6ks5sy2k5gaJpZM4QL1tu.

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.

On Nov 3, 2017, at 3:46 PM, Chris Walter <notifications<EMAIL_ADDRESS>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.

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)

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.

@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.

On Nov 3, 2017, at 4:44 PM, Rachel Mandelbaum <notifications<EMAIL_ADDRESS>wrote:
@johnrpetersonhttps://secure-web.cisco.com/1VOeh3YzkvKNtXqoA1cBQ8ozZy7kSEGnFSL_LqJAvkEgcgEPIQBHvfhabLwX3a3NPDLO5Mt1bIY87k0W1hRfRq3lqUkWWUzpFso_o6VI8x5hia2dXDzoCxKQNIOqlxFEb_beNgDeK9poC-LuGsiIrLE094J7TenFzj9x9-uMW-XF8Ys5SAyA9H01tHgXZ_KWRVrTA56VvJRzSY7Vz29wPXyNR4SyINrJTdyvAQ1hFnH0gqzgo7XBHdnLfh8NLWA4wRbs16ftMGab2HvYn5T3Xo6_EY02VoFgrXkGz4fXB2C2P5OH8ej0YwDojQrVmhHMGjINwMpPfJ0D6rElUV0JuoQ6l0M7-48NNgrz2Gxd2xG8/https%3A%2F%2Fgithub.com%2Fjohnrpeterson - 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.
john
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1bdB3CRY7-Fe9sSl0UZHswonZuuaPgoiR3h5U0uTEoNoLsVSjCMHtLLu08x4If8yyD0s-9o88oUtnaY9WpKgSTjjBfWLoL5G6AIuziRresof80o_yseEvq_anaZ_qEG4k2LlL29L3NrzeIPtRSGFYG4jsOyhawGbzRVnfjZ2ybTrxKbmXagBLRMDA0mleQKmN2pZtaXEbJauqoWaMwr7gM-xrkU_qJlIC3nZsPrYZFBdC2UpAKIMMiHMamq4ogtiyJzw6qZMnc-j6uznM72O8VU3Lq4Ff-p8ZD7ijSbxVqjk5t008Da0YFwhDDLyAjw7RVqJZw_RsiiSEjlnmH2dI3nmxQAHPVa66ftatGEMJmv4/https%3A%2F%2Fgithub.com%2FLSSTDESC%2FDC2_Repo%2Fissues%2F28%23issuecomment-341822116, or mute the threadhttps://secure-web.cisco.com/1Wx8638jcCbPoZOkB6Ihg8Rb6uSXXgOsuF9G7uYiQLRbFkaojJDbn3Y9TYRKIPDkezxkIXZ7RSiEQfQsM5XgkwUr2jw6LVI2JA34_qAZH9gauTG-w7ikDHN2UjJMpNGQjBO3WVZubcoULxITs7KL36KsKFzn-fdlViN4iivV5ZD3V2pAKcLC8_Rc28U2Iz1HH2tvqidKyHBHr7Dgzsf3bIxSF-GFfsh6kqytq_Hxsqewwi8BRVvroUW5EwVyZGWHswyENu9y10XxNbeA0ZdUZ1R2hUnfUIyD1Wr_xtiZO8CVO9rVXb0Oa6dLlaXrQ7It3EcRHiZI0d65EfwHi-A-VIr437BSYY82B3ztBeC_v5Rc/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJbT8nX5lrdqq94Ky-4bGGf_V3T5PeD5ks5sy3sogaJpZM4QL1tu.

@rmandelb that sounds good to me.

Closing #28.


⚡ Cache user bets tab with react query!!

From the insight that NextJS does client-side navigation when clicking Links, it means we can cache data in-memory.
This PR caches all the user bet data, including portfolio history, user bets, and the contracts corresponding to your bets using react query.
Further, we call these hooks on home and the market page to "precache" the data so that it will load instantly when navigating your user page bets tab.
To make this work, I backfilled the uniqueBettorIds in every contract so that we can query all the contracts you have bet on in one go.

cc: @mqp


Sticky scroll folded headings should keep their margin buttons beside the line-numbers

I would like the new sticky scroll feature to keep the "run test" button next to the line of code that acts as the header.
To clarify what I'm specifically calling for, here's a short screen recording.
https://github.com/microsoft/vscode/assets/10055135/d82d49ff-93c5-4f36-98c9-7598336bd1d8
I filed a ticket against jest-community/vscode-jest#1139 thinking this was their issue, but they're pointing me here.
let me know if there's anything I can do to help bring this to life.

duplicates https://github.com/microsoft/vscode/issues/187834


Actor sheets with exploration activities do not load

Attempting to open a sheet with an exploration activity has the following error:
undry.js:753 TypeError: An error occurred while rendering CharacterSheetPF2e 116. Cannot read properties of undefined (reading 'includes')
    at #prepareActions (pf2e.mjs:18:169752)
    at CharacterSheetPF2e.getData (pf2e.mjs:18:146762)
    at async CharacterSheetPF2e._render (foundry.js:5785:18)
    at async CharacterSheetPF2e._render (foundry.js:6503:5)
    at async maintainTagifyFocusInRender (pf2e.mjs:6:246485)
    at async CharacterSheetPF2e._render (pf2e.mjs:16:107691)
    at async CharacterSheetPF2e._render (pf2e.mjs:18:101481)
onError @ foundry.js:753
(anonymous) @ foundry.js:5744
Promise.catch (async)
render @ foundry.js:5742
render @ foundry.js:7082
_onClickLeft2 @ foundry.js:56033
callback @ foundry.js:31547
#handleClickLeft2 @ foundry.js:31751
#handleMouseDown @ foundry.js:31718
notifyListeners @ earcut.js:128
notifyTarget @ earcut.js:128
propagate @ earcut.js:128
dispatchEvent @ earcut.js:128
mapPointerDown @ earcut.js:128
mapEvent @ earcut.js:128
onPointerDown @ earcut.js:128

Attempting to add an exploration activity to a sheet has the following error, which then prevents the sheet from being reopened:
peError: An error occurred while rendering CharacterSheetPF2e 118. Cannot read properties of undefined (reading 'includes')
    at #prepareActions (pf2e.mjs:18:169752)
    at CharacterSheetPF2e.getData (pf2e.mjs:18:146762)
    at async CharacterSheetPF2e._render (foundry.js:5785:18)
    at async CharacterSheetPF2e._render (foundry.js:6503:5)
    at async maintainTagifyFocusInRender (pf2e.mjs:6:246485)
    at async CharacterSheetPF2e._render (pf2e.mjs:16:107691)
    at async CharacterSheetPF2e._render (pf2e.mjs:18:101481)

All modules off. Removing exploration activities from the actor's json and reimporting the actor resolves the issue but no new exploration activities can be added.

This seems like a missing template.json (due to a possibly bad install). Let me know if it persists after a reinstallation.

This seems like a old template.json (due to a possibly bad install). Let me know if it persists after a reinstallation of the pf2e system.

Reinstalling solved the problem for me.

Reinstalling the PF2e system resolved the problem. Closing the issue. Thanks!


Indicate when DM reply is not allowed in interleaved views.

The PR implements a functioning where we disable the compose reply button for DMs in case the user is not allowed to send a DM. Previously, we do this for DM view only but this PR implements it for all the view including DM feed view, Combined feed view, Mentions view, Reactions view, Starred messages view and Search view,

 Video description for all the views

NOTE:
Desdemona is the only one who can authorize or initiate a DM. This is required for the differentiation.
Before column contains same video in all the tables, as all the view share the same behavior.

DM Feed

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/50e4eba8-155a-428b-b7e6-0e8e9cfad076

Combined Feed

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/d574fd25-83f7-4053-b42e-6729255bdb75

Mentions

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/21c2953c-1f5b-4423-be2e-03ed8b834d44

Reactions

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/86dd9bf5-6386-4d24-a5d4-385207533232

Starred Messages

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/5919f2b3-8e49-4841-9912-09d146a2bf3c

Search View

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/f2a17ef0-85cb-422e-affb-d4c1c64c9f97

Fixes: #32597 .

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Hey @alya, could you please take a look at this one?

Hey @alya @amanagr , could you please take a look at this one?

Thanks! @amanagr tagging you for a review.

@amanagr , ready for next review.

@whilstsomebody maybe you should revisit this code later but close this PR now since I don't think contributor is ready to make an effective contribution right now in this code area.


Set Temperature is not shown correct

Hi, first thanks a lot for your work, we really love this :)
Please see the screenshot for error description:

Please let me know which information could be helpful for analyses :)

This problem will get fixed in the new version. I will close the issue as it will be a big refactoring. See https://github.com/ciotlosm/lovelace-thermostat-dark-card


fix: handle the case if we are on the root of a bare repo

This PR fix the plugin when used in a bare repo

Thanks! Merging after a minor refactoring.


undo / redo feature

Thanks all for this fantastic platform. One very obvious feature I am missing and which isn't even posted so far is "undo" (CTRL + Z). Deleted a layer you want back? Undo. Deleted a data set you want back? Undo. Changed a bunch of visuals to test different styles out? Undo, undo, undo. Of course, once you have undo, you can also think about a redo function. Any thoughts?

Available options:

https://redux.js.org/recipes/implementing-undo-history
https://www.npmjs.com/package/redux-time-travel


SDK should internally use ReadOnlyMemory or CosmosStream

Currently several places in the code are optimized for MemoryStreams. The SDK should internally be converted to ReadOnlyMemory or CosmosStream where the underlying buffer is always accessible. The SDK already buffers everything and relying on the soft contract and ensuring that the memory stream allows access to the buffer has caused several performance issues.

Good to keep in mind the serializer contract from the Azure.Core team: sdk/core/Azure.Core/src/Serialization/ObjectSerializer.cs
So CosmosStream would need to inherit from Stream/MemoryStream. Using ReadOnlyMemory might imply a MemoryStream creation.


Query: projecting naked correlated collection when tracking should return collection object of it's parent entity

when we issue this query:
customers.Select(c => c.Orders)

currently we generate a new instance of Orders collection type. Instead we could/should grab the collection instance from the parent entity and use it instead. This way we can better handle all exotic cases, where customer collection is exposed as interface, doesnt have parameterless ctor etc.
In fact, we could potentially leverage include pipeline for this case. Include gets parent entity and collection of its children, associates them together and returns the parent entity. For this case the only difference is that we have to return collection instead.

Triage: Added a reference from the 3.0 queries issue.


Professional Support

Hire me if you need professional support.

Contact me by email to discuss this in more detail.


Grammarly Extension

[ ] Extension name: Grammarly (unofficial)
[ ] Extension GitHub or homepage: https://github.com/znck/grammarly

Thanks for opening an extension request!
We are currently in the process of switching extension marketplaces and transitioning over to Open VSX.
Once https://github.com/eclipse/openvsx/issues/249 is implemented, we can fully make this transition. Therefore, we are no longer accepting new requests for extension requests.
We suggest installing the VSIX file and then installing into code-server as a temporary workaround. See docs for more info.


d1: Update limits.md

Table wrap breaks mobile entirely.

https://github.com/cloudflare/workerd/pull/695


⚠ Jenkins Plugins Artifactory has degraded performance

In fc78a5f, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1243 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 2309b21 after 24 minutes.


[api] Support encode/decode String tensor

Fixes: #3033
Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report
Attention: Patch coverage is 90.00000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 72.24%. Comparing base (b6b8729) to head (7f786dd).
Report is 1 commits behind head on master.

Files
Patch %
Lines

...src/main/java/ai/djl/pytorch/engine/PtNDArray.java
60.00%
1 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #3034      +/-   ##
============================================
- Coverage     72.29%   72.24%   -0.06%
- Complexity     7293     7295       +2
============================================
  Files           722      722
  Lines         32512    32533      +21
  Branches       3396     3401       +5
============================================
- Hits          23506    23504       -2
- Misses         7386     7409      +23
  Partials       1620     1620

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


feat: config for report output destination and other suggestions

🆒 Your use case
So I was fiddling around with generating link reports. These might come in handy for our CMS editors to check for broken links, since my prerender config contains failOnError: false (i dont want it to fail for every 404)
When running a build locally, the link-checker-report.html (or .md) file is generated in the ./.output folder. But if i want to access it from my Nuxt App directly, it would make more sense to have it in ./.output/public/link-checker-report/index.html
Also, when deploying to Netlify, I'm getting Nuxt Link Checker HTML report written to .netlify/functions-internal/link-checker-report.html. Which is weird, since all other files are outputted in a dist folder conform the nitro preset for netlify. This might be an upstream bug though, since this seems to be okay
Lastly, for the reports to be actually useful, the UI would need an upgrade. At this point (with 500+ prerendered routes) it' just an endless list
🆕 The solution you'd like
First, I would suggest adding a new config prop called outputDir, which accepts a function with a single argument, the current nitro config. This would give control over the output behavior of reports.
linkChecker: {
    failOnError: process.env.FAIL_BUILD_ON_ERROR === 'true',
    report: {
      html: true,
      markdown: false,
      outputDir: (nitro) => resolve(nitro.options.output.dir, 'public', 'link-checker-report', 'index') // where index is the file name
    }
  }

Secondly, I'd like to add a third output type json, which would write the allReports into a json file. This would allow us to build a custom UI in our nuxt app for the report data
linkChecker: {
    failOnError: process.env.FAIL_BUILD_ON_ERROR === 'true',
    report: {
      html: false,
      markdown: false,
      json: true,
      outputDir: (nitro) => resolve(nitro.options.output.dir, 'public', 'link-checker-report', 'index') // where index is the file name
    }
  }

🔍 Alternatives you've considered
No response
ℹ Additional info
No response

Hey, I've released v3.1.0 which may solve this for you.
While the report should be easier to navigate with less data, I'm open to improving the UI but I don't have capacity at the moment. If you want to make a new issue with any ideas for it, that would be great.
By the way, this feature was originally built to have the reports displayed as part of your CI. For example, you can use the comment GitHub action to add the link report to any production PRs.
    - name: Sync links
      uses: GrantBirki/comment@v2
      with:
        file: .output/link-checker-report.md

Will close for now but let me know if you have any feedback.

3.1.0 is looking! This was exactly my suggestion 😀 will give it a go tomorrow.
As for the UI, i'll let you know if I have built something for it. The project I'm currently working on is using Nuxt UI, so that wouldake it easier to refactor for usage in this nuxt module.

Hi Harlan,
Built a quick UI component based on this example.
for a demo, see https://dev.traineesinonderwijs.nl/link-report/
It's built with Nuxt UI, into a single component <RouteList :data="data" /> where the data prop is the generated json report, so it should be fairly simple to integrate into your module.
If you'd like I could make a PR
And more more thing: why filter for reportsWithContent in
const reportsWithContent = allReports.filter(({ reports }) => reports.some(r => r.error?.length || r.warning?.length))

I actually also want reports without errors and warnings, so i have a complete list of all (prerendered) routes!
PS. Is the type of warning identical to error? Could not find a type declaration in the src

This looks great :+1: There is complexity involved around this though, we'd need a separate nuxt app just to render the list to HTML.

I actually also want reports without errors and warnings, so i have a complete list of all (prerendered) routes!

I'd imagine most people don't as they can check their sitemap if they need a URL list. I will consider adding this back if there is some useful data for each route (i.e the internal / external link counts).

PS. Is the type of warning identical to error? Could not find a type declaration in the src

Yes


Tooltip trigger item

Hello,
Great library, one bug though on the line charts. When SymbolSize is zero or showSymbol false on series tooltip is not working.
Thanks,
dscis

@100pah will follow up and find if this is a feature or bug.

Trend line is ultimately line chart and where I prefer to keep SymbolSize is zero or showSymbol false and want to show trend line expression as tooltip on line.

Any progress?


fix(background): increase request timeout for the OP SDK

Changes proposed in this pull request

Since quoting was removed in https://github.com/interledger/web-monetization-extension/pull/371, I constantly see timed out requests. The reason: under the hood, Rafiki still performs a quote, but we do not make the HTTP call. Since the quoting is still performed, some of the requests are timing out if it takes them more than 5 seconds to complete.

Extension builds preview

Name
Link

Latest commit
47d675b6627fa14cbe17489ee4e136d6c91c8ce7

Latest job logs
Run #9886425712

DownloadDownload


test(Event_Logs): Add tests for encrypted event logs

From #6411 we also got 2 different types of encrypted logs, namely the encrypted note logs that we were used to, but also event logs.
The even log is currently using the exact same ciphertext setup as the notes, and might need to be altered slightly to be easier to reason about since the storage_slot and note_type_id might not really be useful in this context but event_type_id might be (similar to an event selector in Ethereum).
Tests should be added to ensure that we can decrypt these nicely.

Just FYI added a test in #6536 alongside those for unencrypted and note encrypted logs in e2e_block_building under 'calls a method with nested encrypted logs' - I didn't add any enc/dec testing as know it's being worked on and may change. It does test the logs are correctly populated, siloed, and ordered throughout the kernels.
(Also added tests to private_execution.test, but these are more for kernel testing and don't include enc/dec checks)


The project doesn't work. How I can work out?

I am very interestd in your project. It's a terrific work. But I cannot run it perfectly. Could you give me some advice or some instructions, I have managed to do this even a half afternoon, but have no idea so far.
And anyone here encounter this problems?

When I tried to click the button on the webpage, It shows the following error:


[FEA] Add support in Bootstrap tool for multithreaded settings

The following settings could be set by the bootstrap tool for Dataproc and EMR based on the number of CPU cores in each worker node:

spark.rapids.shuffle.multiThreaded.reader.threads
spark.rapids.shuffle.multiThreaded.writer.threads
spark.rapids.sql.multiThreadedRead.numThreads

Additionally, we can default the RAPIDS Spark shuffle manager to enabled:

spark.shuffle.manager

Possibly, but we should be able to bootstrap based on cluster shape (e.g. # of CPU cores in worker nodes).  So we first can do in bootstrap and then later on see if we need to add autotuner support as well.

Filed issue to track similar changes in Profiling tool for autotuner: https://github.com/NVIDIA/spark-rapids-tools/issues/262.


chore: bdd-gh-1585313299 to 0.0.1

chore: Promote bdd-gh-1585313299 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Remove suffix from version fetcher

not needed, fixed by https://github.com/netbirdio/dashboard/commit/a65b892441a8a40901bb109e0c414b166cb62e9f


newest dockerfile did not include nccl

Looks like a spam. Closing this issue. If you are stuck, please open a separate issue with all information filled as per the template. Thanks!


Install a local clusterctl executable and use it in make targets

What this PR does / why we need it:
The dev docs rely on the clusterctl executable, as do some make targets. The clusterctl version should correspond to the cluster-api go module dependency version.
I expect this change to make it easier to follow the developer documentation.
If we like this approach for clusterctl, we can also consider it for kind, and even kubectl.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
How Has This Been Tested?:
Here's output of running a make target that depends on clusterctl:
> make --debug test-clusterctl-create
GNU Make 4.3
Built for x86_64-redhat-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles....
Updating goal targets....
 File 'test-clusterctl-create' does not exist.
   File '/home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl' does not exist.
  Must remake target '/home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl'.
curl -sSfL -o /home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.3.5/clusterctl-linux-amd64
chmod u+x /home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl
  Successfully remade target file '/home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl'.
Must remake target 'test-clusterctl-create'.
/home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl version
clusterctl version: &version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.5", GitCommit:"58770484dee6c99c10e32c06652e9f9643f78e9e", GitTreeState:"clean", BuildDate:"2023-03-02T15:57:13Z", GoVersion:"go1.19.6", Compiler:"gc", Platform:"linux/amd64"}
Using configuration File="/home/dlipovetsky/.cluster-api/clusterctl.yaml"
/home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl config repositories | grep nutanix
Using configuration File="/home/dlipovetsky/.cluster-api/clusterctl.yaml"
nutanix        InfrastructureProvider   file:///$HOME/.cluster-api/overrides/infrastructure-nutanix/v0.0.0/                         infrastructure-components.yaml
Using configuration File="/home/dlipovetsky/.cluster-api/clusterctl.yaml"
/home/dlipovetsky/nutanix/cluster-api-provider-nutanix/hack/tools/bin/clusterctl generate cluster mycluster -i nutanix:v1.3.99 --list-variables -v 10
Using configuration File="/home/dlipovetsky/.cluster-api/clusterctl.yaml"
Using Override="cluster-template.yaml" Provider="infrastructure-nutanix" Version="v1.3.99"

Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
Release note:

NONE

/ok-to-test

/lgtm

I had to rebase on main. I did that, and force-pushed. There were no rebase conflicts.

/lgtm
/approve

I had to rebase again, but this time I used GitHub's "built-in" rebase, and existing approvals were not revoked.

Well, adding a fixup commit dismissed all the reviews, except one. So I decided to squash the fixup commit now, rather than wait for later.

/lgtm
/approve


Send-MailMessage changes attachment file name on Linux

Steps to reproduce
Send-MailMessage -Priority High `
-From $NotificationFrom `
-To $NotificationTo `
-SmtpServer $SMTPServer `
-Subject "Attachment renamed in linux" `
-Body 'Test' `
-Attachments @('something.zip')

Expected behavior

Receive an attachment, named 'something.zip'

Actual behavior

Received an attachment named folder1folder2folder3something.zip
where /folder1/folder2/folder3 is the current folder

Issue present on Linux only.

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.1.0-preview.1
PSEdition                      Core
GitCommitId                    v6.1.0-preview.1
OS                             Linux 4.4.0-119-generic #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Fix in corefx was merged, so we should get this when we pick up future corefx after 2.1 Preview2

This should be fixed in latest nightly build w/ dotnetcore2.1-rc1


python3Packages.pytest-order: 1.2.0 -> 1.2.1

Description of changes
https://github.com/pytest-dev/pytest-order/releases/tag/v1.2.1
Also add myself as a maintainer and enable strictDeps.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3788


EPIC RSR-51 / RSR-64 : Associate a list of Connected Access Point (ConnectedAP) to a SubNetwork

As a COMPAS service user, this US purpose is to associate Connected Access Points (ConnectedAP) of an IED with a SubNetwork.
As service user, from the list of selected name and iedName of the Connected Access Points ( i.e all couples (ConnectedAP.apName, ConnectedAP.iedName)) that are in the ICD file of the IED, I want to associate my selection of Connected Access Points with a given SubNetwork already defined in SCD file.
Prerequisites : an SCD file is already existing and contains at least one /SCL/IED.name with associated /DataTypeTemplates and one /SCL/Communication/SubNetwork.name which can be empty or not.
The inputs of this service are:
A previous existing SCD file (Mandatory) defined by Header.id, Header.version and Header.revision
An ICD file from where the selected ConnectedAP.name will be imported
The IED.name for which the /SCL/Communication/SubNetwork/ConnectedAP will be imported.
A list of connected Access Points with target Subnetwork.name (Subnetwork.name, ConnectedAP.apName, ConnectedAP.iedName=IED.name)
This US is covering the third part of the following functional service as described in the 61850-6:
S22 Create and configure SubNetworks and IED communication addresses
The following steps have to be considered to associate a Connected Access Point, i.e a couple (ConnectedAP.apName, ConnectedAP.iedName), by insertion in the given SubNetwork.name of a SCD file:
For each selected Connected Access Points (Subnetwork.name, ConnectedAP.apName, ConnectedAP.iedName), check that (ConnectedAP.apName, ConnectedAP.iedName) of the ICD are not already present in the SubNetwork.name of the SCD file:
If a couple (ConnectedAP.apName, ConnectedAP.iedName) is already present, display an error and process the next ConnectedAP.apName
else copy from /SCL/Communication/SubNetwork/ConnectedAP XML block (include subchildren elements see bellow) from ICD file WHERE ConnectedAP.apName = ConnectedAP.name defined in the input TO SCD file /SCL/Communication/SubNetwork WHERE Subnetwork.name of SCD file = value of Subnetwork.name defined as input AND /SCL/Communication/SubNetwork/ConnectedAP.iedName = IED.name defined as input; only the
/SCL/Communication/SubNetwork/ConnectedAP/Address
And /SCL/Communication/SubNetwork/ConnectedAP/PhysConn if exists
SCL/Communication/SubNetwork/ConnectedAP/GSE and SCL/Communication/SubNetwork/ConnectedAP/SMV XML blocks must be excluded if exists
The uniqueness of the (ConnectedAP.apName, ConnectedAP.iedName) within its SubNetwork.name is defined by XSD verification
If yes commit the change into SCD file.
If not do no commit change into SCD file, reject ICD file and output an error message "The connectedAP.apName = valeur of the connectedAP.apName, ConnectedAP.iedName = value of the ConnectedAP.iedName"
The output of the service
An updated SCD file with added ConnectedAP copied from ICD file OR an error message if the connectedAP.apName, ConnectedAP.iedName is already existing in the Subnetwork.name = value of the Subnetwork.name

Looks good to me!


winget command-line tool is not bundled in modern versions of Windows 10 contrary to what documentation says

https://github.com/MicrosoftDocs/windows-dev-docs/blob/docs/hub/package-manager/winget/index.md#install-winget says

Windows Package Manager winget command-line tool is bundled with Windows 11 and modern versions of Windows 10 by default as the App Installer.

I have updated to latest version of Windows 10: version 22H2 (OS Build 19045.2364).
But, typing winget in PowerShell says the term is not recognized.

In my experience it's also not bundled with Windows 11.


Transmission RPC URL credentials not decoded before transfer to Authorization header

The credentials that may be present in the Transmission RPC URL (config or command-line flag) are not decoded before they are base64 encoded and put into the Authorization header. This results in a 401 response from Transmission when the username and/or password contains characters that require URL encoding to be applied: https://github.com/cross-seed/cross-seed/blob/c538e38ca3329274f1061a593352bda10b619e2d/src/clients/Transmission.ts#L59
This problem does not seem to be present in the other clients, these all perform a call to decodeURIComponent before passing the information on into the relevant API requests.
(small side-request; log the response code when an error is returned? https://github.com/cross-seed/cross-seed/blob/c538e38ca3329274f1061a593352bda10b619e2d/src/clients/Transmission.ts#L101)

Just as a note, this behavior is also present in the qbittorrentUrl and I'd assume rTorrent's implementation too.

It is. But:

This problem does not seem to be present in the other clients, these all perform a call to decodeURIComponent before passing the information on into the relevant API requests.

For some reason it's just not being done for Transmission.

I've had multiple people with special characters in their qbit password tell me they cant connect, and changinf to an alphanumeric password fixed it...
This was within the last few weeks. I'll double check this later, as it wasn't my personal instance or setup... but I assume this is the case.

these all perform a call to decodeURIComponent before passing the information on into the relevant API requests. For some reason it's just not being done for Transmission.

This sounds like it was just an oversight - we should be able to fix easily


Add avatar field and remove button

Requires https://github.com/snapshot-labs/snapshot.js/pull/226

 Add avatar field on settings


how to query data from multiple table?

for example, now I have two tables. user and preference.
user
id, username,preference_id

prefenerce
id, data

the tables relationship is 1O1, that means one user only have one preference.then, I want to query data from two tables.
for example:
SELECT
	p.id,
	p.preference_id,
	p.created_at,
	o.data
FROM
	USER p
	INNER JOIN preference o ON p.preference_id = o.id

so, what should I do with entgo?
thank you very much.

Hey @houko and thanks for opening this issue.
I'd say that the way to do it in Ent is with eager-loading, and you can Select specific fields that you want to load.
client.User.Query().
	Select(user.FieldPreferenceID, user.FieldCreatedAt).
	WithPreference(func(q *ent.PreferenceQuery) {
		q.Select(preference.FieldData)
	}).
	All(ctx)

However, if you still want to use JOIN and scan the result to a custom struct, you can use query modifiers: https://entgo.io/docs/feature-flags#custom-sql-modifiers.
Closing, but please feel free to reopen or join our Discord community if you still need help with this 😎

https://discord.com/channels/885059418646003782/885059419107360779/1020165742114644048
I send a message to discord too.
maybe my shema have some mistake.


Add External Patient ID to schema

We have a use case where systems that are submitting to us may need to track more than ID for a patient, for example a school may want to include the student ID when submitting records to SimpleReport, or a department of corrections may want to include a prisoner's ID. To facilitate communicating that to STLTs, we need to add a new field to the COVID-19 schema that will be called external_patient_id. If it is has a value, we will fill in a repeat on the PID-3 value. The external_patient_id will ALWAYS go after the primary patient_id field.
In addition, we will add a feature flag to allow for states to receive external patient IDs. If the flag is false, we will NOT put any repeat into the PID-3 field even if external_patient_id has a value. This means, for example, that if a resident of VT ends up in a prison in TX and TX sends us the prisoner's ID, we would not send that second ID to the state of VT unless they have specifically and explicitly asked us to turn this feature on.
Acceptance Criteria

The field is added to the schema
If the field has a value, we add it to PID-3 as a second repeat.
If the field doesn't have a value, we do not affect PID-3 in any way
The feature flag for second additional IDs is added to the translation config and the logic for inserting the repeat will be wrapped in the check of the feature flag

NOTE: because of the way we process elements in reports, external_patient_id will come first before patient_id, which means you cannot simply just add the external_patient_id to PID-3. You can add it, but you will need to make sure that when you are inserting the patient_id that you prepend it to the existing value in PID-3. This is similar to the logic we use when we put the email after the phone number in PID-13.

This was mentioned as a possible need during the kickoff call.  BI2 Technologies is working to create their 1st test file.  We'll wait to see if they request this addition.

@brick-green Any qualms with closing this? As per Adrian's comment no one is asking for it and it looks related to SR if anything.

@brandonnava I think we can close till it's asked for. I like the concept for the ticket.


Discriminate json from raw http request

:thinking: What?
Change the original httpRequest to not require a decoder.
:man_shrugging: Why?
There's no way to request raw text.
:pushpin: Jira Issue
Not tracked
:no_good: Blocked by
Not blocked
:clipboard: Pending

[x] Feed the trolls.

:fire: Extra
This will break every elm project, but don't worry: it's a single-line change.

still need to do a version bump tho


Google DFP ads appear and quickly disappear from sticky sidebar

I use a sticky sidebar on my website - https://geek.hr/znanost and i have DFP ads in it.
The problem is that the right top sidebar ad will load and then disappear quickly.
This happens randomly in all browsers, but almost always in Edge browser.
Does anyone know what the problem is and how to fix it?
Thanks

This is the same issue as #7. You need to make sure you have the inner containers with class="theiaStickySidebar" right inside your sidebar. More info: https://github.com/WeCodePixels/theia-sticky-sidebar#usage


Deprecated Method Warnings

I recently moved over from the jc21 container to this one and so far so good. Everything seems to be working, but I do see this warning in my logs. Just flagging in the case it's actually something I did wrong hah.
[12/30/2021] [9:51:26 AM] [Express  ] › ⚠  warning   invalid signature,
`QueryBuilder#allowEager` method is deprecated. You should use `allowGraph` instead. `allowEager` method will be removed in 3.0,
`QueryBuilder#eager` method is deprecated. You should use the `withGraphFetched` method instead. `eager` method will be removed in 3.0,
QueryBuilder#omit is deprecated. This method will be removed in version 3.0,
Model#$omit is deprected and will be removed in 3.0.

This is not a problem.  You should also have the same warning with the jc21 image.

This is not a problem.  You should also have the same warning with the jc21 image.

Thanks for the confirmation!


Bump fetch to 0.9.0

For some reason, npm installed 0.7.0 (I assume "^0.7.0" should install 0.9.0 too?), which failed my code because i used response.ok... It works now with 0.9.0, I bump here so I don't have to update all my package.json files in the future :)

^ drifts 0.7.x and 1.x.x basically, the first non-zero version stays fixed.

release as v1.2.1


Implement plotting overrides in plotting methods themselves, instead of "wrappers"

This PR replaces #45 in order to clean up its history.
This addresses #43. It moves plotting-function enhancements from dedicated "wrapper" functions to the methods themselves, breaks apart some really unwieldy wrappers into their component parts, and (just like matplotlib) combines the keyword arg tables associated with each plotting wrapper using matplotlib.docstring.dedent_interpd.

This will make it much easier for new users to learn ProPlot -- people have a hard time wrapping their heads around wrapper functions ;)
This will also make the tracebacks much cleaner. It can be pretty disorienting when an error is raised and there are 3x more frames than necessary.

When using proplot locally, the proplot and matplotlibdocstrings will be concatenated with nice headers for each section using _concatenate_docstrings in axes.py. When sphinx is importing proplot for generating documentation, they will not be concatenated -- only the proplot docstring will be shown with an intersphinx link to the matplotlib one. This is done by adding docstring.hardcopy: True to the local .proplotrc. Then _concatenate_docstrings skips concatenation if rcParams['docstring.hardcopy'] is True.

Closed by #197


chore: change name to egg-rpc-for-apache-dubbo

Checklist

[x] npm test passes
[x] tests and/or benchmarks are included
[x] documentation is changed or added
[x] commit message follows commit guidelines

Affected core subsystem(s)

Description of change

为啥要改名字

为啥要改名字

@fengmk2 dubbo 要从 apache 毕业了，说是不改有法律问题。。。

<EMAIL_ADDRESS>


Make: Update package classifiers

:tada: This PR is included in version 1.1.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Support exp notation in CLI parameters

Support "solver[parameter=1e-5]" in CLI. (follow-up of #362).

Codecov Report

Merging #383 (410adcd) into main (91df91c) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #383      +/-   ##
==========================================
+ Coverage   56.09%   56.11%   +0.01%
==========================================
  Files          42       42
  Lines        2519     2520       +1
  Branches      476      476
==========================================
+ Hits         1413     1414       +1
  Misses       1006     1006
  Partials      100      100


Shadow token

Description of the PR

Validation for the A+ Token dialog
Dropdown with the user's name and a log in/out button
Closes #272

Testing

unit
integration
e2e
manual

- [ ] new unit tests created
- [x] all unit tests pass

- [ ] new integration tests created
- [x] all integration tests pass

- [ ] new e2e tests created
- [x] all e2e tests pass

- [ ] manual testing went well

Have you updated the TESTING.md or other relevant documentation on your branch?

[ ] Yes.
[ ] Not yet. I will do it next.
[x] Not relevant.

Additionally: why delete centering of buttons in dialog boxes?

Dialog action buttons should apparently be right-aligned:
https://upsource.jetbrains.com/idea-ce/file/idea-ce-7b9b8cc138bbd90aec26433f82cd2c6838694003/platform/platform-api/src/com/intellij/openapi/ui/DialogWrapper.java?nav=49847:50272:focused&line=2287&preview=false

"fix"


Handle gas fees for oracles in contracts

Delivers https://www.pivotaltracker.com/story/show/159686884
Please refer to commit messages for details.
TODO:

[ ] Ensure CI passes.
[ ] Documentation (i.e. refreshed version of this RFC PR).

Apparently unrelated test failure in CI test job in mid-PR commit:
%%% aesc_fsm_SUITE ==> all_tests.transactions.change_config_get_history: OK

=ERROR REPORT==== 26-Sep-2018::00:48:40 ===
Error in process <0.29051.0> on node epoch_ct@localhost with exit value:
{timeout,[{aesc_fsm_SUITE,receive_from_fsm,6,
                          [{file,"/home/builder/epoch/_build/test/lib/aechannel/test/aesc_fsm_SUITE.erl"},
                           {line,1037}]},
          {aesc_fsm_SUITE,receive_from_fsm,5,
                          [{file,"/home/builder/epoch/_build/test/lib/aechannel/test/aesc_fsm_SUITE.erl"},
                           {line,1025}]},
          {aesc_fsm_SUITE,create_channel_from_spec,5,
                          [{file,"/home/builder/epoch/_build/test/lib/aechannel/test/aesc_fsm_SUITE.erl"},
                           {line,901}]},
          {aesc_fsm_SUITE,create_multi_channel_,2,
                          [{file,"/home/builder/epoch/_build/test/lib/aechannel/test/aesc_fsm_SUITE.erl"},
                           {line,802}]}]}
%%% aesc_fsm_SUITE ==> all_tests.transactions.multiple_channels: FAILED
%%% aesc_fsm_SUITE ==> {'EXIT',timeout}


feat!: enforce use of strict (===) equality

ESLint can enforce this for us with the built-in "eqeqeq" rule, which you might not know about if you'd search for "strict", "equality" or "equal" in the rules list.
Idea is to avoid coercion due to ==/!= which can be a source of bugs, except in the case of null, where x == null is a convenient and idiomatic shorthand for x === null || x === undefined (you can still do an explicit x === null check if that's what you want).

Autofix diff is (14 files changed, 24 insertions(+), 21 deletions(-)):
https://gist.github.com/wincent/9b1925268aa56312106908b892c09138
Not-autofixable stuff is like this:
		return pauseNodes.filter(({id}) =>
			nodeKeys.find(node => node.id == id)
		);

All of these require human review to be sure they're safe, and even then I don't think we can be sure. I think we just have to ship it, run the tests, and watch for regressions.


Global index extension added

Sphinx's singlehtml builder apparently does not yet support a full index option.
Added custom extension "globalindex" in order to provide a full index for singlehtml builds
Minor rewording of "start menu" section

Nice!

There's still some issues with it that I'm looking into (lower level shortcuts seem to still be broken), but hopefully this will be workable.


Internal Server Error

Hello @remy do you know why https://output.jsbin.com/qoqukof is giving Internal Server Error?
Had been working for years.
The code is mirrored at
https://gist.github.com/probonopd/45636fc168d3dbf71db2463bfa07319c
Reference:
https://github.com/AppImage/docs.appimage.org/issues/61

@Stale

This is not resolved yet.

Encountered this today

Is this like a common thing or between june 26 and now it wasn't an issue?

Different error. Tracking on a different issue.

Tracking on a different issue.

Thanks.
Where?

http://output.jsbin.com/qoqukof is still broken. Been almost a year now.


add useReflex js function to "support" the composable pattern

Type of PR
"Feature"
Description
This PR adds theuseReflex() js function to "support" the composable pattern.
Why should this be added
This can be useful if you include a handful of mixins in your connect() function (e.g. some mixins from stimulus-use) and want them to all look similar. StimulusReflex.register(this) would stick out in that matter.
Example
import { Controller } from 'stimulus'
import { useReflex } from 'stimulus_reflex'
import { useResize, useIdle } from 'stimulus-use'

export default class extends Controller {
  connect() {
    useReflex(this)
    useResize(this)
    useIdle(this)
    // ...
  }

  // ...
}

Reference:

https://github.com/stimulus-use/stimulus-use
https://www.betterstimulus.com/architecture/mixins.html

Checklist

[x] My code follows the style guidelines of this project
[x] Checks (StandardRB & Prettier-Standard) are passing
[x] This is not a documentation update

Noice!


Question about stream analysis

Hi!
I want to check the mode information of stream encoded by vvenc, but when I check it with software called streameye, the code stream cannot be opened. Stream can normally analyze the code stream of vtm12.0. So I have the following two questions:

Which version of VTM corresponds to vvenc 1.4, that is, which version of VTM's stream is the same with vvenc1.4?
Is there any software like streameye that can analyze the stream generated by vvenc？

Thanks in advance,
Jin.

Hi,
its interesting, because this year at NAB I was at the Elecard stand, and we had a look at our vvenc-1.4 bitstreams in their demo software. It worked alright.
Your question misses the point, that both software are compliant VVC encoders. VTM since version 11.0 (10.0 was supposed to be the final version, but had a major bug). VVenC since version 0.1 is supposed to be VVC compliant. There is still the potential that VVenC has a bug. So if the bitstream cannot be opened, you could try decoding it with VTM decoder (or VVdeC, but if it doesnt decode with VVdeC the next step would be to try VTM either way). In this case please file a bug report, specifying the exact used encoder version, parameters, some info about the input sequence and possibly the bitstream.
So in simple terms, any vvenc version is just as VVC compliant as any VTM version including and after 11.0.
Hope this helps, Adam

Hi,
I have confirmed that both vvdec and VTM can normally decode the stream generated by vvenc, so the problem should come from the streameye software itself.
Thank you for your patience.
Jin.


S3 scan docs

Description
Adds s3 scan documentations and metrics
Issues Resolved
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Switching this to editorial review since we have an extra day before DP 2.4


Update classname to add border for article

Adds a border to the bottom of the header for articles

:+1:


 I also have philosophical issues with the management of Travis CI and would prefer to use a different platform if possible.

@kevinburke Which alternative do you prefer? I could work on a CircleCI workflow.

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!


Add opening & closing parens in gutter (contextual)

Feature Request
Have been using sublime for a while and wish if you can add the opening and closing brackets visuals on the gutter as sublime do:
------ CASE ONE
{|    { some code and CURSER here
|    [ some code no curser here
|    ]
}|   }
------ CASE TWO
|    { some code no curser here
[|    [ some code and CURSER here
]|   ]
|   }
it helps a lot in knowing where you are in code!

To keep the number of issues in our inbox at a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: we look at the number of votes the issue has received and the number of duplicate issues filed. Thank you for your time and understanding.
If you disagree and feel that this issue is crucial: we're happy to listen and to reconsider.


Fix react select cached options issue

Summary
When changing the ReactSelectSetting component to use AsyncSelect in this PR, a bug was introduced that made the initial options cached, and only shows updated options upon typing a query.
The component now accepts an explicit "limitOptions" boolean prop that is used when the instance of the component may need client-side paging, and that the caching of the "no query" (user has typed nothing into select) values is acceptable. This is true for the selects that have the same values upon first render, like the projects select.
This is only occurring on master. No release versions have this issue @DHaussermann
Ticket Link
https://mattermost.atlassian.net/browse/MM-18568
Repro Steps
To produce the bug:

Open "Create Issue" modal
Select a project
Notice the default issue type is chosen for you
Notice clicking the Issue Type select component does not show any options without typing (this is the bug)
Typing the prefix of an issue type shows the correct results

Another test case is to test with multiple projects and make sure the issue types update per project choice. That is also fixed in this PR.
Testing that the project select performance is still improved for 100+ projects is also a good test case. It should the exact same behavior as when the performance increase was introduced.

@cpoile We discussed earlier that this performance improvement is not applied to the issue search select. If we did apply it there, it actually wouldn't have any effect because when we hit the Jira api to search, we limit the results to 50 items.


Doesn't compile

Broken with error:
#import <Filestack/FSStoreOptions.h>
file not found.
I don't see this file anywhere in the repo. Is this service and repo dead?

I'm seeing the same thing. How is anyone compiling this?


resolution feedback files

Demonstration of these two files shown here: https://smb.slac.stanford.edu/~dermen/capstone/reso.html


feat: .NET Support

Adds support for generating a .NET (C#) project.
I choose namespace rather than package since it seemed more appropriate when generating source code.
I went with dotnet since it matches the jsii naming, but csharp may make more sense for configuration options / cli parameters. I don't believe there are any plans to generate F# code in jsii, but if there were, I'd lean towards using csharp naming.

@campionfellin can you take a quick look?

LGTM!


RT-2.12: Fix static to isis redistribution test

There were some of test issues:

The test was doing an update of the table connections policy instead of replace. This was causing the policies to get appened to the import-policy, which causes things to fail on implementations that support only one policy at a point of attachment. Since the intent of the test isn't to validate multiple policies at the point of redistribution, change isisImportPolicyConfig to use BatchReplace

The prefixes in the prefix-set were missing the prefix portion, so was getting rejected by implementations that check the format of the prefix. Fix it by adding the prefix portion to rplPrefixMatch

Fix some typos in the test descriptions

Additionally add an arista eos specific deviation routing_policy_tag_set_embedded since it does not natively support tag-sets that can be referenced.

Pull Request Functional Test Report for #3004 / 843334476d5458ea8ecbf155ba88852dcf1c556a
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

RT-2.12: Static route to IS-IS redistribution

Cisco 8000E

RT-2.12: Static route to IS-IS redistribution

Cisco XRd

RT-2.12: Static route to IS-IS redistribution

Juniper ncPTX

RT-2.12: Static route to IS-IS redistribution

Nokia SR Linux

RT-2.12: Static route to IS-IS redistribution

Openconfig Lemming

RT-2.12: Static route to IS-IS redistribution

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

RT-2.12: Static route to IS-IS redistribution

Cisco 8808

RT-2.12: Static route to IS-IS redistribution

Juniper PTX10008

RT-2.12: Static route to IS-IS redistribution

Nokia 7250 IXR-10e

RT-2.12: Static route to IS-IS redistribution

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.859%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3550

💛  - Coveralls