desihub / prospect

DESI spectral visualization tools
BSD 3-Clause "New" or "Revised" License
11 stars 6 forks source link

include ability to show Nth best model fit #18

Closed moustakas closed 4 years ago

moustakas commented 4 years ago

It would be helpful for the user to be able to display the next best-fitting template / spectrum, not just the best fit.

michaelJwilson commented 4 years ago

@armengau I wanted this so tried myself.

Example output if and if not (i.e. current) a redrock.results.read_zscan return of a redrock .h5 file is provided. https://portal.nersc.gov/project/desi/users/mjwilson/MINISV/specviewer_example_nthbestfit_0.html https://portal.nersc.gov/project/desi/users/mjwilson/MINISV/specviewer_example_nthbestfit_1.html

If that's helpful, the necessary changes are here: https://github.com/michaelJwilson/prospect/tree/nthfit

Hope I didn't miss this being done recently!

Few notes: -- DeltaChi2 of nth besfit shown isn't DeltaChi2 in the file, but relative to best fit.
-- I have to duplicate the smoothing functions, so it might make sense to have some reshuffling with update_plot.js.

armengau commented 4 years ago

@michaelJwilson Thanks a lot. Indeed this is one of the two main features to add now, and I'm actually working on it, played with read_zscan() this week in a sandbox notebook.

Here is the plan that I sent to the VI lead team ~2 weeks ago: It's related to this "Nth best fit" feature, but at the same time to the request for other "generic template" overlaid to the spectra, and to extend the wavelength range of "model" curves so that one can change z. It must take into account the major constraint that html pages must remain as light as possible (in MB).

  • keep the main fit output still as it is.
    • add an additional "model" curve, to be choose from a drop down list.

These "model" curves are computed on-the-fly in the browser (javascript code.. :-( ). They do NOT include the resolution model (contrarily to the main fit output). They can be viewed over a wide wavelength range (ie changing z). The list will be a) on the one hand the 3 best redrock fits. b) on the other hand a (limited) set of predefined models, with an arbitrary normalization adapted to the data flux.

For (b), after Kyle's feedback the plan is to use the 1st of the "basis" templates used by redrock for each of the main categories (stars still tbd). An alternative is to use other predefined model curves provided by VI leads.

Any feedback is welcome on this plan ! I've just played with redrock files since few weeks... Looking at your code, it seems that the main diff is that you create full "models" for each of Nth best fit. In the "plan" described above, I intend to compute the "model" curves in js, both to limit the size of html files and to allow viewing these "models" over a wide z range.

michaelJwilson commented 4 years ago

sounds great! I figured a handful of best fits, rather than one, wouldn't be a game changer, but I certainly appreciate the problem. I didn't anticipate Marz-like generic templates.

Just throwing an idea out there, which might save you from java ;), one might precompute the models beforehand but at a lower sampling except around the few areas we care about, e.g. the (OII) emission and absorption shown. Seems we're wasting a lot of memory on (0.8A) sampling of uninteresting template noise. Smoothing might be a bit more complicated I guess, but I doubt prohibitive. Otherwise, I think it'd be a straightforward change.

Interested to see how quickly the java will render. I'll stick with mine in the meantime. Good luck!

moustakas commented 4 years ago

Just throwing an idea out there, which might save you from java ;), one might precompute the models beforehand but at a lower sampling except around the few areas we care about, e.g. the (OII) emission and absorption shown. Seems we're wasting a lot of memory on (0.8A) sampling of uninteresting template noise. Smoothing might be a bit more complicated I guess, but I doubt prohibitive. Otherwise, I think it'd be a straightforward change.

The templates are noiseless---all the features are real--and I wouldn't be in favor of pre-deciding what spectral features are useful vs not.

michaelJwilson commented 4 years ago

Sorry, I used noise loosely. I didn't mean to imply actual noise, but high res. fluctuations that I wouldn't have expected to be typically useful in this context.

Sounds fair, but I'd have guessed the number of expected features carried around in the heads of the vi leads to be fairly small. Definitely won't be my call! Thanks.

armengau commented 4 years ago

This feature is now available in the branch disp-models (not yet merged to master). @michaelJwilson Thanks for your help, in particular the DeltaChi2 trick !

Depending on the option used when calling prospect, can display

armengau commented 4 years ago

Merged to master

michaelJwilson commented 4 years ago

No worries! Glad to see it helped.

On Fri, 12 Jun 2020 at 02:13, Eric Armengaud notifications@github.com wrote:

Closed #18 https://github.com/desihub/prospect/issues/18.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/desihub/prospect/issues/18#event-3437608210, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOBFEUNIFW5JJF3OLDSOW3RWHWTHANCNFSM4JPU63ZQ .

--


Dr. Michael Wilson

Cosmology Postdoctoral Fellow

Lawrence Berkeley National Lab 1 Cyclotron Road, M/S 50A5104 Berkeley, CA 94720, USA

Tel: (+01) 510-502-3448 (+44) 7742 373026