NUV line-spread functions about veeper HOT 5 CLOSED

Incremental progress: I've retooled how the LSFs are managed and am now storing one per unique chunk of wavelength to be fitted (the ones you see when you turn on 'Lines used in fit'). This modification is in preparation to incorporate the NUV LSFs, which will be relatively straightforward now, but it should also speed the code up somewhat. Previously, I would check the wavelength of each chunk to assign an LSF during each convolution (and thus each evaluation of the profile).

Regarding the NUV, I suggest that we have a variable in the cfg.py file that determines a wavelength cutoff between FUV and NUV. Then, above this wavelength, we will use the NUV LSFs. Can you advise what an initial value for this cutoff might be?

The code will then be readily extensible to other types of LSFs (Gaussian, etc.) by turning the cutoff wavelengths into ranges and having a companion list of corresponding pointers to the right LSF.

from veeper.

Joe-

I don't remember if I replied to this:

above this wavelength, we will use the NUV LSFs. Can you advise what
an initial value for this cutoff might be?

I think I was not able to reply when I read the message the first time.
Here is the answer:

COS FUV vs. COS NUV cutoff: 1800 A

This one is easy, and it will always be the same. The more difficult
decision is the COS NUV vs. STIS NUV cutoff. We will definitely need to
do this on a case-by-case basis, but for now I recommend this default
value:

COS NUV vs. STIS NUV: 2404.5 A

Are the NUV LSFs now built into the code?  This is turning out to be 

quite important, so it would be good to have this capability asap.

Thanks,
Todd

On 2016-07-28 23:00, jnburchett wrote:

Incremental progress: I've retooled how the LSFs are managed and am
now storing one per unique chunk of wavelength to be fitted (the ones
you see when you turn on 'Lines used in fit'). This modification is in
preparation to incorporate the NUV LSFs, which will be relatively
straightforward now, but it should also speed the code up somewhat.
Previously, I would check the wavelength of each chunk to assign an
LSF during each convolution (and thus each evaluation of the profile).

Regarding the NUV, I suggest that we have a variable in the cfg.py
file that determines a wavelength cutoff between FUV and NUV. Then,
above this wavelength, we will use the NUV LSFs. Can you advise what
an initial value for this cutoff might be?

The code will then be readily extensible to other types of LSFs
(Gaussian, etc.) by turning the cutoff wavelengths into ranges and
having a companion list of corresponding pointers to the right LSF.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#2 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ATkhRt2rmV-0yetOYSeaKd-py2PrTmRpks5qaWy5gaJpZM4JO5zS

from veeper.

Great! The initial response did not come through, but I got it this time. It's great that we can set a definite (but changeable) cutoff between NUV and FUV. As far as STIS vs. COS, we can handle that by having a setting for the instrument in the cfg.py file. This can easily be changed on a case-by-case basis.

The NUV is just about ready to go...should have that in place in the next 48 hours.

from veeper.

Excellent!

On 2016-08-01 16:13, jnburchett wrote:

Great! The initial response did not come through, but I got it this
time. It's great that we can set a definite (but changeable) cutoff
between NUV and FUV. As far as STIS vs. COS, we can handle that by
having a setting for the instrument in the cfg.py file. This can
easily be changed on a case-by-case basis.

The NUV is just about ready to go...should have that in place in the
next 48 hours.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#2 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ATkhRp9U4x0T6l4TXTxsa63pW_2_0OL4ks5qblNugaJpZM4JO5zS

from veeper.

We are close to implementation on this....currently matching up the binning and profile width in the kernel to the data.

from veeper.