Apply JIGSAW SPICE Corrections After JIGSAW Has Already Run

[astrostu]

Description
There are several instances where I've run JIGSAW, gotten a solution, and then decided I want to apply that solution to the input cubes. In other words, I start with update=no, inspect the solution, find that I like it (e.g., low residuals), and then want to run JIGSAW with update=yes.

However, I'm working on some large nets, and running JIGSAW all over again might be a significant time-sink (many hours, or even days). I also might have moved computers to a slower one, or one with more disk space and simply want to apply the solution JIGSAW has already calculated and is in the output files (_image_stats.csv? or just the onet.net file) to my images.

In rarer cases, when working on images of order 10,000, there have been Unix/Linux-level stack issues that kill the update=yes calculation after it has applied it to, say, 2^12-1 cubes. In such cases, I have changed the ulimits and gone back, re-SPICEINIT'd the images that were updated, re-run JIGSAW, and it works, but that effectively wastes a lot of time and it would have been more efficient if, as an additional feature, I could have run just the SPICE updating from the already-calculated JIGSAW solution on a sub-set of my images.

With that preamble, what I'm asking for is: (1) The ability to run JIGSAW's SPICE-update capability after JIGSAW has been run, without running the solver all over again. And, (2) The ability to do this on a sub-set of the images that are in the network.

Example
(1) I can envision a simple run-time option for the first request: recalculate=no

If recalculate=no, one would still need to have all the cnet and onet and file_prefix options from their original run, set update=yes, and the recalculate=no would tell it to use those previous outputs to apply the SPICE updates. The default option (not specified at run-time) would just be recalculate=yes

(2) Similarly, there could be a simple run-time option for the second request: apply_updates_filelist=myFileList.lis

By default, this would simply be equal to fromlist's argument, but one would have the option to specify this to only update the SPICE data for some cubes. That said, I'm re-looking at the JIGSAW documentation and perhaps this second request is already handled by "heldlist," which is the inverse of what I'm requesting (i.e., I would specify all cubes in fromlist, and then those I DON'T want updated I put in heldlist?)?

[jessemapel]

Adding this to the jigsaw application directly would be challenging as there's not enough information in just the final control network to recover the final image parameters without redoing at least one iteration of the solution.

A different option could be to take the images.csv output from jigsaw and directly apply that to the images. You can likely already do this with the csv2table application, although I would exercise caution as you could potentially completely destroy your cube's ephemeris data. Adding a new application that takes the jigsaw CSV output and dumping that to a cube would be fairly straight forward.

@astrostu If you are interested in the csv2table stuff I can provide some assistance on that right now. This would also only be a temporary solution as it would bypass the ISIS ephemeris Table API and thus miss any future changes to it. Just make sure you back up any cubes before you modify them!

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[jessemapel]

This is still a very valuable enhancement for jigsaw.

[astrostu]

Yes! Sorry, I would be interested in this feature, still, but the immediacy has changed significantly for me. If this doesn't make it into a future release before I need it, I'll message you directly, @jessemapel , to discuss how we might hack it together.

[jessemapel]

This is still a very valuable enhancement but will likely require significant work and need its own project.

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[jessemapel]

This is being considered for work in FY23.

[astrostu]

@jessemapel Great!

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[Kelvinrr]

re-opening since it is still relevant