[SUGGESTION] Install AAS WorldWide Telescope JupyterLab components

[pkgw]

Is your feature request related to a problem? Please describe. I want to explore whether the AAS WorldWide Telescope (WWT) software package can deliver a compelling solution for exploratory visualization of Rubin imagery on the RSP.

Describe the solution you'd like In order to test out the WWT visualization framework for this use case, a few software components need to be added to the RSP JupyterLab stack (see below).

Describe alternatives you've considered Most of the WWT components can installed at the user level if needed, but there are a couple of server extensions required in order to pass data from the kernel backend(s) to the browser frontend. I don't believe that those are user-installable with the RSP setup, although I'm not 100% sure about that.

Additional context The key server extensions are:

• pywwt
• wwt_kernel_data_relay

The ideal setup would also include the WWT JupyterLab extension, installable either as:

• @wwtelescope/jupyterlab "source" form
• wwt_jupyterlab_extension "prebuilt" form

There are also kernel-side Python packages to complete the framework (most importantly pywwt) but those can be user-installed if needed.

[pkgw]

Hi — is there any extra information that I can provide that would help move this ticket forward? Thanks!

[MelissaGraham]

Hi Peter, I'm sorry this issue has gone unanswered for so long. I'm inquiring with the Rubin Science Platform team about the feasibility of this, and they think WWT might be useable with the RSP later this year, but it is not guaranteed.

I'd be curious to hear if you did try to install the software you need, and if so how it went?

[frossie]

Apologies for the delay. The short answer is that we are not prepared to support the WWT on the Rubin Science Platform at this time. We have removed it from our notebook aspect interface. The long answer is that there are a lot of challenges in supporting a compute environment for thousands of users, and testing that everything works (and stays working) is an effort-consuming process. We therefore look for "common denominator" packages that are requested by a sizeable fraction of the community as well as our own internal science users, so that we can be certain that they are extensively used and that they have active users as internal champions. At this (pre-operations) stage of the project we have not been able to find any compelling interest in using WWT in the RSP nor any current WWT users among our product owners. Moreover, graphical user interfaces are a worst-case scenario, as they are not tractable to our current automated testing and have an even higher bar for being made available than numeric packages. In the long run, during Rubin Operations we will develop a process for adding capabilities to the RSP in consultation with our User Committee. I anticipate that at that time, we might be able to add capabilities without internal project advocates under circumstances where third-party support can be provided by another institution. That will be a good time to revisit the WWT issue. Sorry to be the bearer of bad news.

[pkgw]

OK, thanks for explaining the rationale. There's definitely a chicken-and-egg problem here since people can't become users without having a chance to use the software where it works best, so I'd like to find a way to give people a chance to at least try it out even if support is limited. But I'm getting married in a few days, then going on my honeymoon, so I won't be able to spend any time on this in the near future. I'll be back online in time for AAS240 in Pasadena and will be interested to discuss further with whoever's there.

[MelissaGraham]

Congratulations and best wishes @pkgw!

Rubin Observatory will have a booth in the AAS 240 Exhibit Hall, and I'll be there a lot of the time. Looking forward to chatting.