Verify need for v3yangle, vparity in L3 pipeline

[schlafly]

The exposure level pipeline doesn't presently use the v3yangle or vparity keywords, though it may need to in the future when setting the telescope pointing. The mosaicing pipeline does use these keywords, however, and it's not obvious to me that it needs to; the WCS object contains all the information that should be needed. We should investigate whether these keywords are actually required.

[stscijgbot-rstdms]

This issue is tracked on JIRA as RCAL-834.

[stscijgbot-rstdms]

Comment by Jonathan Eisenhamer on JIRA:

The sole place where the wcsinfo is used is in stcal.alignment.util._generate_tranform

This routine creates an astropy.Model of scale/rotation for the output wcs.

A couple of approaches can be taken:

Modification of stcal: _generate_tranform could be modified to calculate such values from the existing refmodel wcs. This could cause issues with jwst compatibility.

romancal-specific: The transform can be pre-calculated in romancal's make_output_wcs. Passing the transform in through the wcs_from_footprints call, would avoid the need for _generate_tranform to use the wcsinfo block. The advantage here is that this is a romancal-specific change only, making use of existing api.

Unless otherwise dictate, Jonathan Eisenhamer will take the romancal-specific path.

[schlafly]

Could you check whether JWST actually uses this? I think our goal is for eventually Webb++ to start using stcal.alignment, but currently I think Roman is the only user. i.e., I think that if we think the _generate_transform API isn't right, we have flexibility to change it.

[nden]

These are used to determine the roll angle roll_ref , computed in set_telescope_pointing.

[schlafly]

Sorry, I haven't tracked the full path, but looking at this briefly, _generate_transform is ~recomputing the WCS object we already have, and accepts a transform argument that we could imagine supplying it to avoid that path?

[stscijgbot-rstdms]

Comment by Jonathan Eisenhamer on JIRA:

After discussions with Eddie Schlafly , this issue is being closed without further work modulo the following:

• The default output WCS uses the roll, parity, and v3yangle from the first input WCS. This isn't great but absent direction (which will provided for the skycells) isn't horrible.
• To make this insensitive to the wcsinfo, the WCS can be used directly to compute the angles, scales, and parities. But since this is only computing the choice of WCS there is no real bug here.
• A better job computing the output shape can be implemented in the future if needed.