Metadata keyword values in Roman I-Sim (some are also related to Romancal)

[stscijgbot-rstdms]

Issue RCAL-883 was created on JIRA by Andrea Bellini:

• We recommend adding a history metadata keyword whose value is the Roman I-Sim version number/info.

• Below are 2 lists of metadata keywords and values, the first containing those whose values should be fixed, the second containing keywords that should be eventually removed. Some of the keyword/values should also be fixed or removed in Romancal; we add the marker (**) to highlight them.

• At the very end, a few keywords that need to be double checked for consistency between Roman I-Sim and Romancal. Basically, we created a L1 image with Roman I-Sim and calibrated it with Romancal. The same simulation was also outputted as L2 image by Roman I-Sim. For some reason, the number of resultants does not match.

The "fix" list:

-- meta.guidestar.gw_window_xsize (): the value should should be 16 for imaging and 170 for spectroscopy, and should depend on selected optical element -- meta.guidestar.gw_window_ysize (): the value should should be 16 for imaging and 24 for spectroscopy, and should depend on selected optical element -- meta.photometry.conversion_microjanskys: Romancal outputs the correct value. It should come from the photom ref file. -- meta.photometry.conversion_megajanskys: Romancal outputs the correct value. It should come from the photom ref file. -- meta.photometry.pixelarea_steradians: Romancal outputs the correct value. -- meta.photometry.pixelarea_arcsecsq: Romancal outputs the correct value. -- meta.photometry.conversion_megajanskys_uncertainty: Romancal outputs the correct value. -- meta.photometry.conversion_microjanskys_uncertainty: Romancal outputs the correct value. -- meta.ref_file.dark: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.distortion: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.flat: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.gain: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.linearity: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.mask: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.photom: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.readnoise: Romancal outputs the correct value. it should come from CRDS -- meta.ref_file.saturation: Romancal outputs the correct value. it should come from CRDS -- meta.wcs: Romancal outputs the correct value. -- meta.wcsinfo.s_region: Romancal outputs the correct value.

The "eventually remove" list:

-- meta.exposure.gain_factor () -- meta.exposure.framer_divisor () -- meta.exposure.group_time () -- meta.pointing.pa_v3 () -- meta.target.type () -- meta.target.ra () -- meta.target.dec () -- meta.target.ra_uncertainty () -- meta.target.dec_uncertainty () -- meta.target.proper_motion_ra () -- meta.target.proper_motion_dec () -- meta.target.proper_motion_epoch () -- meta.target.proposer_ra () -- meta.target.proposer_dec ()

The "check consistency" list:

-- amp33 -- border_ref_pix_left: -- border_ref_pix_right: -- border_ref_pix_top: -- border_ref_pix_bottom:

[schlafly]

Hi @AndreaBellini , @tddesjardins ,

Can you specify which of these you consider blockers for the next release?

Some notes:

• We are not simulating guidestars, and the locations of the purported windows are somewhere crazy. I can change the window sizes, but this is all deeply artificial; honestly, I would change the size to zero before I would change it to a correct value.
• Re the photometry, we are not getting the photometric conversions from CRDS. If I fill this out, I will fill it out with the values we derive from the Goddard filter curves rather than the CRDS values, so that it's consistent with what we actually simulate. Those differ from the CRDS values by 4% (I don't know why; possibly relating to the choice of the aperture) and by a factor of the gain (the CRDS values weren't updated when we moved from e/s to DN/s).
• I could populate the various absolute photometry uncertainties but they would not be meaningful here and are not something that are used in the simulations.
• The reference files are interesting. I could populate these, both for the L1 files and the L2 files. The pipeline populates them only for the L2 files, since they don't make sense for the L1 files. Would you want them in both? I could also populate them in a separate stanza outside roman.meta (e.g., in the romanisim block).
• What's wrong with meta.wcs?
• The border pixels are not simulated. I can obviously change their shape, but they will not have meaningful values in either case, and so it is unclear to me whether a meaningful shape is of much value.

[sanjibs]

It was not obvious that meta.wcs in romancal and romanisim generated files are the same object.

[schlafly]

I feel like we have tests that show that the WCSes after tweakreg agree at the 1 mas level, which may be the chief requirement in terms of "do the WCSes match?" If you think that's not true, then I'm interested in learning more.

If in fact the WCSes agree in the sense that they are gwcs objects that represent very similar mappings between the detector and the sky, I feel like that is the only kind of agreement that is relevant? I do not want to simulate the tweakreg process and be careful to insert the same number of layers in the gwcs object reflecting the steps that go on there?

[tddesjardins]

• I am also a little confused by the issue with the WCS object. If they agree to within some acceptable tolerance, then I don't see an issue. I'm wondering if maybe, while differencing the romancal and Roman I-sim outputs, the order or some things inside the astropy model are swapped such that, while achieving the same result, appear to be different on paper. If that's the case, then I see no problem as long as, as Eddie said, they agree with each other.
• I am still concerned that the zeropoints in CRDS are not what are being used in Roman I-Sim. I do understand the differences (and yes we still need to take gain into account, though I'm fairly certain I know how to do that now), but I worry that it will be confusing for users to have two different, conflicting sources of information about the bandpasses. RTB is anticipating delivering updated throughput information later this year that incorporates the detector QEs and measured bandpasses for the whole focal plane. We could also include color-dependent information at that point if that makes it better for the simulator, but I'd much rather have a single source of this information if possible. If the issue is getting better information from CRDS, we can prioritize getting the infrastructure for that (e.g., a schema change in the photom files) in sooner rather than later and then update the information when we get it from GSFC later.
• I think populating the reference file information into a separate optional stanza is acceptable. Also including information about the simulator version etc. there would be ideal.
• For guide window sizes, I think just setting them to 16 x 16 is more correct and yeah they can be off the detectors since we're not actually simulating them or their effects. I agree with you, Eddie, that this is as you said deeply artificial. But it is true the different modes do have different fixed sizes, and we are talking about the imaging mode which is 16 x 16.
• For the reference pixel arrays, are you just putting in numpy.zeros with some hardcoded shape? I think we are just asking to double check that the 3rd axis is the number of resultants, because from the test I was shown there was a mismatch (but I'd ask both the testers and the devs to double check that). Everything else looked correct other than the number of resultants in the reference pixel arrays.

[schlafly]

Re the WCS: yes, there is no way that we constructed the gwcs objects in exactly the same way, but that level of equivalence should not be a goal here.

The simulator benefits from the full bandpass information when simulating chromatic sources. We don't usually do that and the present implementation is only partial, but it's not something that CRDS will currently allow us to do. If you want to put the whole bandpasses in CRDS I am happy to source them from there---though even in that case I would probably want a fall back for people not using CRDS mode. While I can think of other approaches there, let's not tie them to science validation.

I will go ahead and populate the reference information et al. into the special romanisim stanza.

Re the guide window size, we "sort of" allow simulating dispersed images via --pretend-spectral GRISM.
https://github.com/spacetelescope/romanisim/blob/03fa06880ffa6918c71574330ff4078a052cc394/scripts/romanisim-make-image#L102-L104 This mode is of course garbage because the only thing it does is update one or two metadata keywords to allow some downstream tests to claim that they process spectral files. Obviously if we were doing anything with the guide windows and wanted to exercise it I would want this case and the imaging case to be well handled. In the current situation where we never touch the guide window stanza and have clearly garbage information in it, I don't really want to propagate special logic setting the size of this right for the different cases. But I guess I will if required.

The reference arrays in the L1 products have the correct shape. The reference arrays in the L2 products have the wrong size because they're never touched and take default values from roman_datamodels. I'm mildly sympathetic to getting the right sizes in general---e.g., for the L1s, if I had the wrong sizes the reference pixel correction step would break. For the L2s where we're not using these products in any way and we have no requirements, while I can change the shape it's not obvious to me what I'm buying.

But the most important thing to me is really which of these are needed to pass science validation and which of these are suggestions for things that we can do when they make more sense---e.g., when the reference pixels start getting simulated, I will of course want them to have the right shape, and if we start figuring out which stars are guide stars, then of course I should put the guide windows around them and give them the right shape.

[AndreaBellini]

Hi Eddie,

But the most important thing to me is really which of these are needed to pass science validation and which of these are suggestions for things that we can do when they make more sense---e.g., when the reference pixels start getting simulated, I will of course want them to have the right shape, and if we start figuring out which stars are guide stars, then of course I should put the guide windows around them and give them the right shape.

The keywords under “eventually remove” are not immediately critical.

Cheers,

Andrea

-- Dr. Andrea Bellini Space Telescope Science Institute 3700 San Martin Drive Baltimore, MD, 21218, USA Office: +1 (410) 338-4431