thomasorb / orcs

ORCS is an analysis engine for SITELLE spectral cubes.
GNU General Public License v3.0
9 stars 6 forks source link

bad flux ratio when constraining amplitude ratio at high redshift with sinc model #21

Closed thomasorb closed 6 years ago

thomasorb commented 6 years ago

From the example in the documentation (http://celeste.phy.ulaval.ca/orcs-doc/script_example_constaining_line_ratios.html) I try to constrain the flux by constraining the amplitude ratio of two lines . It works at low redshift (the measured constrained flux ratio is indeed 3 for example) but does not work at high redshift (it gives a flux ratio of 3.4, at least with a simple sinc model). Why ?

thomasorb commented 6 years ago

Constraints on input parameters format has been raised in the next branch of orb/fit.py (https://github.com/thomasorb/orb/commit/63c2c1005c69f5a45749e79c0c9c970f55e1ade7) : e.g. it is not possible anymore to enter a single value for multiple lines, unnecessary parameters raise exceptions etc. Since then it appears that the flux ratio is behaving as it should even at high redshit. Note that fwhm parameter MUST be the same for both constrained lines.

sinc and gaussian

This script:

from orcs.process import SpectralCube
import gvar
cube = SpectralCube('/home/thomas/M31_SN3.merged.cm1.1.0.hdf5')

oiii_ratio = cube.get_amp_ratio_from_flux_ratio('[OIII]5007', '[OIII]4959',  3.)

spec, axis, fit = cube.fit_lines_in_spectrum(
    # any position would do with such an example, 
    # flux ratio must works even if only noise is fitted
    1000, 1000, 3,
    ['[OIII]5007', '[OIII]4959', 'Hbeta'],
    fmodel='sinc', # same results with 'gaussian'
    pos_def=['1', '1', '1'],
    pos_cov=[80000],
    fwhm_def=['1', '1', '2'],
    # init fwhm is nearly doubled as it is around 3.14 cm-1 
    # at the resolution of the cube, it becomes 6.74 and 7.68 in the resulting fit which is far from the 
    # theroretical FWHM, but is still works like a charm
    fwhm_cov=[3, 4], 
    amp_def=['1', '1', '2'],
    amp_guess=[oiii_ratio, 1, 1])
print fit['velocity']
fluxes = fit['flux']
print fluxes[0] / fluxes[1]

returns

# positions were just covarying and not fixed, here to show that the velocity is very high
[ 79969.26314124  79969.26314124  79969.26314124] 
3.0 # flux ratio is exactly the desired ratio

sincgauss

There is a small bias though with sincgauss because the flux also depends on the broadening which is not taken into account in the formula used in SpectralCube.get_amp_ratio_from_flux_ratio() to compute the constraint on the amplitude that must be entered to get the desired constraint on the flux ratio.

from orcs.process import SpectralCube
import gvar
cube = SpectralCube('/home/thomas/M31_SN3.merged.cm1.1.0.hdf5')

oiii_ratio = cube.get_amp_ratio_from_flux_ratio('[OIII]5007', '[OIII]4959',  3.)

spec, axis, fit = cube.fit_lines_in_spectrum(
    # any position would do with such an example, 
    # flux ratio must works even if only noise is fitted
    1000, 1000, 3,
    ['[OIII]5007', '[OIII]4959', 'Hbeta'],
    fmodel='sincgauss',
    sigma_def=['fixed', 'fixed', 'fixed'],
    sigma_guess=[20, 20, 30],
    pos_def=['1', '1', '1'],
    pos_cov=[80000],
    fwhm_def=['1', '1', '2'],
    fwhm_cov=[3, 4],
    amp_def=['1', '1', '2'],
    amp_guess=[oiii_ratio, 1, 1])
print fit['velocity']
fluxes = fit['flux']
print fluxes[0] / fluxes[1]

returns

# positions were just covarying and not fixed, here to show that the velocity is very high
[ 79940.48502221  79940.48502221  79940.48502221]
2.99755265187 # flux ratio is not exactly 3

Since the bias is very small I consider this issue as closed until someone needs a better precision on the flux constraint with the sincgauss model