Skip to content

Matrix dimensional conflicts for SBC/PR130L targets' multi-orient extraction #68

@pstammler

Description

@pstammler

Hello,
I tried to use SLITLESSUTILS to estimate fluxes for a specified source observed through the ACS's Solar Blind Channel, using PR130L prism imaging and F140LP direct imaging. In order to make comparisons, I have made the analysis through different spectra extractions, including multi-orient extraction.
However, for this case particularly, with simulated or observed data, I ended up with internal conflicts between the damping target and the equation matrix dimensions. So, with the downloaded SLITLESSUTILS Github repository, I have made changes in the Matrix code so their dimensionality can be matched for every type of spectroscopy. Here they are:

First, in the _parse_table function, I indicated the sensitivity to be defined according to the good pixels array(gpx), so it can be associated with the flatfield, the pixel-area map and the uncertainties:
Original code: sens = detdata.config[ordname].sensitivity(wav) * self.fluxscale
Modified code: sens = detdata.config[ordname].sensitivity(wav)[g] * self.fluxscale

Then, the main change concerns the damping target. In the build_matrix function, we have:

self.npix = len(self.iuniq)
self.npar = len(self.juniq)
dim = np.array([self.npix, self.npar], int)

As the matrix's shape is equivalent to dim, a dimension issue is encountered, because for SBC PR130L data, len(self.juniq) != self.nunknowns . So I changed the damping target definition as it follows:
Original code: target=np.zeros(self.nunknowns, dtype=float)
Modified code: target=np.zeros(len(self.juniq), dtype=float)
It seems to be the only way to have reliable results with this spectrum extraction. However, when I am looking on its documentation (https://slitlessutils.readthedocs.io/en/latest/multi.html), I am still skeptical about these changes' validity. So what is your viewpoint on this?
My question is probably naive, but is this method finally appropriate for SBC prism spectroscopy? If not, why?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions