OSIRIS-REx kernels being hosted via rsync

[ericepalmer]

I am trying to download the SPICE kernels for OSIRIS-REx to be used with ISIS.
When I try to download them, it does not appear that they are being hosted.

rsync -aznv --delete --partial isisdist.astrogeology.usgs.gov::isis3data/data/

I've reviewed the entire list and there is not an osirisrex mission listed.

[jlaura]

@ericepalmer We are currently not able to share out ORex kernels with ISIS. I will get an enhancement request put in for both this issue and #4054.

I am going to close because this is a known limitation at this time and not a bug/issue that we can address.

@KrisBecker How do you suggest users get access to these kernels at this time?

[ericepalmer]

@jlaura NAIF has the kernels through February of 2020 publicly available (https://naif.jpl.nasa.gov/pub/naif/pds/pds4/orex/orex_spice/). These kernels and the mission data are officially archived (https://sbn.psi.edu/pds/resource/orex/).

NASA has released the New Frontiers call (NFDAP: https://nspires.nasaprs.com/external/solicitations/summary.do?solId={A7388A06-1927-796A-A0D5-14CFB650C58F}) that requires all data that will be used for New Frontier proposal calls (which OREX is included), must be archived 30 days in advance, which has been done. It doesn't say anything about tools; however, the lack of ISIS support for a major mission of NASA is a surprising considering that we are just one month from the proposal due date (Nov 5th 2020). It means that scientists that wanted to use ISIS couldn't count on it when they write their proposal.

[rbeyer]

The ISIS project cannot possibly keep track of all missions and all SPICE data releases, but depends on the community to suggest improvements and additions. It relies on individuals that are knowledgeable about the missions to provide advice to the project about which data are appropriate for inclusion in the SPICE kernels released with ISIS.

Of course, that never prevents an individual researcher from downloading the latest and greatest SPICE information that they need from NAIF, and using that during the spiceinit step.

[ericepalmer]

I think it is important for highly proficient and skilled computer people to remember that tools should support a wide base of researchers. File systems, distributions, directory structures and unix commands are such a part of our lives that we sometimes forget how easy it is to lose someone who isn't as tech-savy as we.

One of the best things about ISIS is that they have an excellent way to deal with SPICE kernels. When the ISIS team added WEB=TRUE for spiceinit, it was a huge improvement to the usability of the system.

Of course you can always by-hand select each kernel for your image, but that requires quite a lot of understanding about SPICE that most scientists do not have. Also, I have never found documentation for the makedb script. I can guess how it works, but I have always been hesitant to do something that might break ISIS, so I just wait for ISIS to update or specify the kernels individually.

I have trained a descent number of people on ISIS, and one of my biggest takeaways is how important kernel management is to the system. Many people don't get SPICE kernels, but can work very effectively in ISIS and do a lot of good science.

I would suggest that data ingestion (*****2isis), SPICE integration (spiceinit) and data display (qview) are the core portions of ISIS. I suggest that we do not lose sight of the huge benefit those pieces alone provide to the community.

[rbeyer]

@ericepalmer, I don't think anyone has lost sight of that. There are efforts underway to improve the SPICE handling within the ISIS system, and everyone is quite aware of how important it is. You and Bea let the ISIS project know that something was missing, and now #4060 is in the system to get addressed. That's the mechanism working as intended.

You just seemed upset that the issue hadn't be raised earlier. One could very reasonably argue that it should have been, and then that leads to thinking about what mechanism could be used to facilitate that. It just isn't practical for ISIS to mirror the complete NAIF collection, and so relies on the community to inform the project about what's important, when it is important. As a member of the OREx team, you and your team members are the best-informed about OREx-related information, and the ISIS project relies on community members like you to raise timely issues to make things better for everyone.

[ericepalmer]

The kernel issue isn't the heart of my concern, although I was surprised ISIS wasn't supporting them yet. My comments are cautionary and dragging me into something that I've noticed but not known how to address.

I have noted as ISIS has embraced more software-development tools (GitHub, Slack, Anaconda, glitter), we are losing people from being able to use ISIS. The barrier to entry and support has gotten high. Already, I know of several people using the old version of ISIS because the Anaconda tool for distribution is too much.

Git is a powerful tool, but it is intimidating for those who haven't been using it. Bea isn't on OREx and was doing the work for the PDS. When she ran into an issue, she spent a bunch of effort trying to get support but nothing seemed the correct place to ask a question. When she finally couldn't figure out what to do, I started to look at how the ISIS support/distribution/management system had changed. I was also lost. We both assumed the problem was on our side (our ISIS distribution) rather than a lack of ISIS-supported kernels and wanted to request help rather than post a bug/issue/problem. I eventually had Bea slack @jlaura because I had met him briefly once before and thought it was a place to start. I figure that if I struggle finding how to get help, how many other people are lost and just quit?

My point is that we are using many new tools to help in the software development, project management and communications. However, we have a lot of people in planetary science that are not very tech-savy or their focus isn't on mainstream software tools (how many are still working in FORTRAN?). A significant amount of care should be taken to ensure we don't lose the non-power users of ISIS.

I would be happy to chat about my observations on ISIS support and suggestions as to how to keep the barrier to entry low for ISIS. It might be useful to extend it to a bit larger group to help get balanced feedback.

[jlaura]

@ericepalmer @rbeyer Thanks for the posts!

We have a few great venues to be able to discuss a lot of the concerns that you are identifying. The ISIS Technical Committee meets monthly and is a wonderful place to continue discussing your concerns about the user base. This is a group of developers, contributors, and end-users that are all invested in making ISIS the best possible tool for our community. We are guided, in part, by a relatively recent review by a NASA directed Special Action Team.

In terms of user support, I definitely hear what you are saying about the changes that have occurred over the last few years and the fact that those can be intimidating to veteran users. I am happy to report that we have seen a vibrant and active community coalescing around both our GitHub repos and our AstroDiscuss boards. I say vibrant both because we have consistently seen new users and because the pool of respondents to posts are not just the traditional set of folks.

On the kernel issue that initiated this thread. While we (Astrogeology) are the primary maintainers on ISIS, we are not the sole maintainers. In fact, we continue to work hard to make sure that this project is as transparent and accessible as possible. See the linked SAT document if you are interested in what that looks like in practice. @rbeyer is spot on that we (the community) are dependent upon maintainers and external teams to work together to deliver kernels in as timely a manner as possible. The capabilities in ISIS that support a lot of the kernel selection that you appreciate mean that a straight pull of the data from NAIF is not always adequate. You are seeing that lag now. Issue #4060 is the process working as intended. The issue is on the community radar, awaiting motivated (and funded) contributors to ask questions, open PRs, and make the enhancement. I am being very careful to indicate the community radar because this is an open source project.

The last point is an important one and really has me wanting to address the issues you raise about Anaconda. I would suggest two short observations. First, planetary scientists are talented, technically savvy users who are great at asking questions. ISIS installation existing within a standard ecosystem (anaconda) means that the number of platforms available to ask questions and receive great guidance has gone from n=1 (USGS) to n=10+. The contributors on this project do a wonderful job responding to installation queries with very fast turn around. Second, as an open source project, I would welcome a motivated person who came along said 'you know what, I really liked it when I could use rsync and install manually. I am going to repackage the anaconda install and serve it that way.' That packager sees a community that they feel empowered to support and makes it happen. I would love to work with that person to understand if this project could make updates to its anaconda install to make their repackaging easier while still meeting this project's goals.

Good to know that I was pinged on slack! Unfortunately, I do not use slack at all. Here or on our discussion forums are the best places to find me specifically. I do know that @thareUSGS saw the slack post so he forwarded that on to the team.

Finally, I really appreciate your comment here:

My point is that we are using many new tools to help in the software development, project management and communications. However, we have a lot of people in planetary science that are not very tech-savy or their focus isn't on mainstream software tools (how many are still working in FORTRAN?). A significant amount of care should be taken to ensure we don't lose the non-power users of ISIS.

Hopefully this means we can enlist you to help with answering installation questions, supporting local users and getting them accustomed to the new installation and communication methods, and opening PRs with improvements to our documentation so that we, as a community, are all well supported.