Errors in Phoenix interactive dashboard

[cosmicbabs]

Hi Gully! I hope you are well! I remember Gollum from the past CoolStars, and I wanted to try it!

I had some issues with Bokeh and the localhost when trying to use the interactive dashboard but solved them by adding this:

import os os.environ["BOKEH_ALLOW_WS_ORIGIN"] = 'localhost:8891'

Also, there were some issues with the wavelength range for the grid; it doesn't like to use precisely the min and max from the observed spectrum, but that was fixed easily by increasing the wl range.

There is one thing I haven't been able to figure out: the dashboard shows up, and I can change the vsini, the RV, and the scale factor, but it breaks when trying to change the effective temperature, log g, or metallicity. I'm not sure if it is a problem with bokeh or what, but the dashboard cannot change the spectrum to another one in the grid.

Any help would be quite welcome!

Best, Babs

[Sujay-Shankar]

Hi there! Thanks for contacting us! We're sorry to hear that you've run into some issues, and we'd be happy to help fix them.

With bokeh, by default gollum's dashboard only works when run on localhost:8888. I'm not sure as to the exact reason why, but your workaround was correct in exporting the bokeh environment variable to allow the new port. We'll definitely look into this and see what's causing the behavior to default to localhost:8888.

The wavelength range for the grid is definitely a friction point as well, we like to enforce that the wavelength range be strictly a superset of the data spectrum's wavelength range so that edge effects don't creep in when doing rotational broadening or so that cutoffs don't become visible when applying RV shifting. Grid behavior to take the burden off the user to check their wavelength limits is being actively worked on right now, so hopefully the updated API resolves these issues, but until then, it is on the user to make sure that condition is met when initializing a grid.

With the grid point errors that seem to be showing up, would you mind showing the call to the PHOENIXGrid constructor? My first hunch is that the slider callbacks aren't correctly accounting for the ragged nature of the grid in certain areas, but just to be sure we should take a look at the constructor call.

[cosmicbabs]

Hi Sujay! thanks for your help. You were right, I was using the wrong name for metallicity in the PHOENIXGrid constructor

The PHOENIX Grid I'm requesting has the following characteristics: Teff: 3000-3600 K [M/H]: -0.5 - +0.5 log g: 4.5 -5.5

I was requesting the grid with this call grid = PHOENIXGrid(teff_range=(3000, 3600), logg_range=(4.5, 5.5), metallicity_range=(-0.5, 0.5), wl_lo=wl_lo, wl_hi=wl_hi)

instead of grid = PHOENIXGrid(teff_range=(3000, 3600), logg_range=(4.5, 5.5), Z_range=(-0.5, 0.5), wl_lo=wl_lo, wl_hi=wl_hi)

But given the wrong parameters name didn't give any issues or warning, I guess because it assumes that the data is in the library, however I didn't downloaded the Z<-2.0 grids because I wasn't working with M subdwarfs ...

Maybe adding a warning either related to the name of the parameter (parameter metallicity_range doesn't exist) or about the grid (models with Z = -2.0, Z=-3.0 etc cannot be found in the library) could be useful for some other users like me :)

Using the correct parameter name, the number of spectra processed decreases from 189 to 63, as it should.

Thanks again for your help :)

[Sujay-Shankar]

That's great to hear!

It's definitely very interesting that giving metallicity_range as a keyword argument doesn't throw an error, normally Python would detect an invalid argument. I'd guess that it's getting passed through to the Spectrum1D class in **kwargs but since the Spectrum1D initializer doesn't get called, it just fizzles out quietly, while PHOENIXGrid itself looks for Z_range and just treats it as if you didn't provide metallicity limits.

The lack of errors you note is caused by the way that PHOENIXGrid loads in spectra. It is designed to suppress errors pertaining to missing spectra, and you definitely make a good point that it should be logged somewhere how many spectra are missing, although this would be tricky somewhat as the grid isn't quite a full grid due to raggedness, so it becomes an issue of how to even know what the correct number of grid points should be for any given range when PHOENIXGrid cannot necessarily differentiate between a grid point missing due to PHOENIX simply not having it, or due to the user not having it.

I believe the alternative API I'm working on will solve these problems as it intends to present model grids to the user as monolithic downloads, which would avoid any "missing spectra", as the monolith just has all PHOENIX spectra by definition. It also would rely less on class inheritance, which should cause these keyword arguments to throw errors properly.