Add JWST collecting area to stsynphot.config.conf.area

[janerigby]

Description

Background: The telescope area is stored in stsynphot.config.conf.area; this is a very helpful shortcut for users. What is stored in area by default is the HST collecting area. Problem: I have been unable to find the same for JWST in stsynphot. All I could find is the high-level documentation showing users how to manually change it to the JWST value: https://stsynphot.readthedocs.io/en/latest/index.html I believe that users want both the HST and JWST areas available, something like stsyn.config.conf.area_hst and stsyn.config.conf.area_jwst. This would make it easy to do cross-comparisons between observatories, which is doubtless of interest at proposal-time, and also in analyzing data. Indeed, I came across this issue while doing some simple comparisons of WFC3 versus NIRCam.

Additional context

[pllim]

Hello and thanks for bringing this issue to our attention!

Having telescope-specific configuration item as you proposed might not be scalable for any future telescopes that STScI might support in this package.

May I propose a compromise? What do you think about a new constants.py module to store telescope areas as a Python dictionary? You would still have to set the area configuration item to change it from HST to JWST, but at least you would be able to grab the pre-defined value from an internal look-up dictionary, which can be updated as needed in the future without affecting the configuration system.

Please let me know.

[janerigby]

Oh that we should be so cursed, that STScI is involved with too many space telescopes to be able to keep track of their surface areas! I'm making a joke to make a point -- I don't think this that approach would be unscalable at all. We're talking about tracking areas for HST, JWST, Roman, perhaps a few more. These areas do indeed need to be version-controlled for the count-rates produced by stsynphot to make physical sense. Not to mention avoiding the headache during commissioning of having several different STScI users using different values for area_jwst, and therefore getting different calibration values!

I am not sure that I understand your proposed solution, or how it's different from what I was suggesting. Could you please elaborate?

[pllim]

I think the main difference between our ideas are constants vs config. Perhaps if I open an exploratory pull request with my idea, things will be clearer.

[pllim]

@janerigby , what do you think of my proposal at #153 ? You can see the rendered documentation for that pull request at https://stsynphot--153.org.readthedocs.build/en/153/ .

p.s. I did decide not to go with a dictionary. It did end up pretty much similar to your proposal, except the values are constants and not configuration items. 😸

[pllim]

@janerigby , I still have not heard back from you regarding this matter. FYI.

[pllim]

Hello. This is my last attempt to ping you to review #153 . I have not heard back, so maybe this issue is no longer relevant? Next time I come back to this issue, if I do not hear back, I will close this issue and the accompanying pull request without merging it. FYI. Thank you.

[janerigby]

Sorry for the delay. I am now checking that. However, NASA is blocking the URL you sent. Let me see if I can get to it from a non-NASA laptop.

[janerigby]

Thank you for your patience. I have reviewed these changes and I approve. The one minor comment is that those values are not necessarily constants -- it is possibly they will slowly change on-orbit, such that we would want to modify their values here. I'm not sure whether that's important enough for you to consider renaming "constant"

FYI, we should shortly have ready a new value for the quantity of area * reflectivity of the JWST primary mirror, as estimated during commissioning; @mperrin is the contact. Does that go directly into the jwst_area quantity you've defined here?

[pllim]

it is possibly they will slowly change on-orbit

Can you please clarify on this point? Do you expect the value to keep changing throughout JWST lifetime, or will it stabilize and become a true constant after commissioning?

And if it will keep changing throughout JWST lifetime, you will need to look up the value by observation date/time?

[pllim]

new value for the quantity of area * reflectivity

If you need both area and reflectivity to convert your flux to counts, then yes, they both go in the area keyword. If the reflectivity is used for something else, then consider encoding it into your throughput file(s).

[janerigby]

Hmm, then I'm confused. Is the throughput file not used to convert flux to counts?

[pllim]

Is the throughput file not used to convert flux to counts?

It is used to calculate the flux before the conversion, if that makes sense. I am just trying to figure out if this reflectivity is purely tied with the area for counts conversion, or something else. I don't think it ever came up as its own thing in HST.

[janerigby]

I was speaking hypothetically (Nothing to see here, reporters!) One would expect that any telescope may slowly evolve its throughput over time, due to some combination of contamination or micrometeorites. I don't think we've ever had the capability to measure that w previous missions, and I don't know that we will measure a change w JWST. If we did, I bet it's something that gets adjusted 0,1, or 2 times per mission, bc the rate of change is v slow. So the more I think about it, I was overthinking it. Let's keep it as a constant unless we know it's not.

[pllim]

Ah, throughput evolving over time is a different matter from area and that happens to HST as well. That change is encoded inside the throughput files. For example, see https://stsynphot.readthedocs.io/en/latest/stsynphot/appendixb_specialkey.html#stsynphot-parameterized-mjd for how HST does it.

[pllim]

So, it is not clear to me what the proper solution that would fit your use case. I asked @mperrin but received no reply. Any advice is greatly appreciated. Thanks!

[mperrin]

I think it’s fine, and probably best, to treat this the same way for JWST as is done for HST.

[pllim]

@mperrin , so #153 is fine as-is ?

[mperrin]

Conceptually I think it's fine to treat this as a constant.

But no, that PR isn't fine yet, since the numerical value in that PR is incorrect by a significant amount. The value for the "JWST area" there appears to be the area of an unobstructed circle with diameter 6.5 meters, which is not exactly a great model for this telescope.

Please use instead 25.43082 m^2 = 254308.2 cm^2. That is the as-built area of the primary mirror, measured on hardware prelaunch, from Ball Aerospace document "2022.04.01 Area X Transmission Budget - Rev J (post launch).xlsx" by Lightsey et al.

[pllim]

@mperrin , I updated the value as you requested in #153 . Please review that pull request. Thanks!

[pllim]

I have received no reply to indicate any interest to pursue this, so I am closing this as "won't fix". Thanks!