Make filter value input to TemperatureResponseFundamental consistent with Sunpy

[jslavin]

Currently the value returned by an XRTMap object created via
import sunpy.map
xrtmap = sunpy.map.Map(filepath)
gives the filter combination as an attribute of xrtmap:
xrtmap.measurement = 'Be thin-Open'
However the format is not compatible with that accepted by XRTpy.response.temperature_response.TemperatureResponseFundamental
e.g. 'Be-thin' or 'Be_thin'
For the sake of interoperability these should be made compatible (not saying which should change).

[wtbarnes]

This may also be related to #88. Notably, the xrtpy approach only uses a single filter wheel to denote a particular configuration whereas the XRT map source in sunpy returns both filter wheel positions.

[jslavin]

Hi Joy, I created a new branch to work on this: improve-filter-value-input-handling Jon

…

On Tue, Jul 18, 2023 at 4:12 PM Joy ***@***.***> wrote: Assigned #117 <#117> to @jslavin <https://github.com/jslavin>. — Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE5OY7GYUQEYCRYSAGLC43XQ3U3NANCNFSM6AAAAAAUHUYP3E> . You are receiving this because you were assigned.Message ID: ***@***.***>

[jslavin]

One tricky part about this is the question of what we'll accept as inputs. I would think we should accept ones in the Sunpy style, e.g. Open-Ti poly (with a space), and in the fits header style, e.g. Ti_poly or Open/Ti_poly. Any others? What if someone gives 'Ti poly' for example, or 'Open/Ti poly'? The parsing could get complicated.

[jslavin]

It appears that currently it is okay to supply "open" as the filter name to Channel. Why would that be? It seems that that should not be allowed since, as far as I know, that's not an allowed observation mode.