Isis3: QNET Writes Out Bad Control Net, Gives Error, Refuses to Save Properly, Work Lost!

[ascbot]

---

Author Name: Stuart Robbins (Stuart Robbins)

Original Assignee: Jesse Mapel

---

Since I updated to the latest version of ISIS, I will occasionally get an error in QNET that says, "Error saving control network. I/O ERROR Failed writing control network to file [{path}]. I/O ERROR Can't write control net file." Where {path} is the path and name of the net.

The network is perfectly fine. It had literally just saved it a minute ago. However, this error will signify that it has written out a partial network that can't be opened, and I can't save nor save-as somewhere else under a different name to write out the network properly. Meaning all work is lost on that network with that name, unless there's a backup. I've ben trying to remember to copy my network file just before I save, but with the latest just now and forgetting to do so, I'm logging this bug.

It is literally random -- it doesn't seem to happen when doing anything specific other than saving. I'm on a Mac, it happens under OSX 10.11.4 and 10.13.5.

[ascbot]

---

Original Redmine Comment
Author Name: Stuart Sides (@scsides)
Original Date: 2018-07-03T16:31:54Z

---

We are looking into this and will get back to you.

[ascbot]

---

Original Redmine Comment
Author Name: Jesse Mapel (Jesse Mapel)
Original Date: 2018-07-03T16:35:54Z

---

Stuart,

Unfortunately it looks like only the top level error message is being shown. So, can you send us both a clean control network and the corrupted control network file? How are you saving your control networks in qnet? Are you using the save network button in the point editor or are you using the toolbar/file menu save buttons?

Also, is this the 3.5.2 release that went out at the beginning of this year, or one of the alpha releases we've put out for specific missions?

-Jesse Mapel

[ascbot]

---

Original Redmine Comment
Author Name: Stuart Robbins (Stuart Robbins)
Original Date: 2018-07-03T17:20:30Z

---

Software version 3.5.2.0, public. I've been saving by pressing the little disk icon in disk icon in the top-left corner of the QNET Tool window (faster than clicking to a menu).

I delete stuff when this happens, so I will have to put the issue on hold until it happens again, then I'll send the stuff. I realized yesterday that it might be a memory issue -- it's possible that this has happened when I have maybe two dozen CTX images open in the main QNET window. But that could be an assumption that has altered my memory to conform to it.

[ascbot]

---

Original Redmine Comment
Author Name: Stuart Robbins (Stuart Robbins)
Original Date: 2018-07-04T17:29:27Z

---

Unfortunately, didn't have long to wait. Did my manual edits to correct some automated stuff, saved, it was fine. Did 20 minutes of tying to ground, copied the net pre-that, saved, and got the same error. Fortunately, only 20 minutes lost.

This forum won't let me upload the network. Says I can't upload a .net, can't upload .txt (I tried changing the extension), can't upload .zip (tried compressing). Suggestions on getting it to you?

Not a RAM issue so far's I can tell because I didn't have any images open in the main window this time other than the ground source. No error was output to the terminal window, either.

Tiny side-note, just realized the file name should be "fullControl" not "fullManual."

[ascbot]

---

Original Redmine Comment
Author Name: Jesse Mapel (Jesse Mapel)
Original Date: 2018-07-06T16:03:53Z

---

Stuart,

you should be able to upload a pdf file, or you can e-mail it to me at [email protected]
Once I get the network I can start looking at where it failed in the writing process and work backwards from there.

-Jesse Mapel

[ascbot]

---

Original Redmine Comment
Author Name: Stuart Robbins (Stuart Robbins)
Original Date: 2018-07-06T21:03:22Z

---

Just to track on here, I e-mailed Jesse the control net files. Likely why the status was just changed to In Progress. :)

[lwellerastro]

This is happening to my networks as well and there is no recovering from it - work lost 100%.

I have experienced this under isis3.6.1 and isis3.6.0 and there does not appear to be any pattern. I have tried to reproduce it, but I just can't make it happen. It sort of just happens. However, once I have a network open for editing, it seems like the problem happens after I have saved to a new network and continue to save new edits to it. Once a new network is saved, I use the shortcut ctrl-s to save after first saving the measure, then point (using the shortcuts for both, m and p respectively). The problem does not happen after every measure edit, or every time I have a network open. But it is happening a lot.

I am having to use qnet a lot for Europa Voyager images and having this problem will greatly impact that project as there is a lot of manual work complete. I may consider doing this work under a version of isis that pre-dates changes to the ControlNetVersioner to avoid losing work, but I'm not exactly sure what version of isis that shows up in.

I have a "good" and "bad" network under /work/users/lweller/Isis3Tests/Qnet/CantWriteControlNet/
bad_c1631247_Fix.net unreadable network
JigOut_c1631247.net I opened and proceeded to fix this network
c1631247.cal.deltack.cub image in network
c1631247.cub.lis image list for network
Europa_Voyager_GalileoSSI_global_mosaic_500m.cub ground source for my fixed points

Please let me know if I should start a new thread instead of hijacking this one.

FYI, this is a tiny network - 1 image with 4 manual points to the ground source listed above. This is not likely a memory issue.

Name dropping so someone notices the update (not sure I need to, so sorry if no), @jessemapel

[lwellerastro]

I don't know how to add an image of the error message here, so see error_jigsaw.png under the same directory mentioned in the last comment.

I can't recall if this happened when I tried to save to a new network, or after I had saved to a new one and made edits and was saving again.

[jessemapel]

@lwellerastro I'll add this to the list of things to look at when I'm back from LPSC.

[lwellerastro]

Thanks @jessemapel . I let Scott and Mike know what I've encountered so that the priorities for the upcoming sprint can be rearranged.

[jessemapel]

@lwellerastro What kind of edits were you making to the control network?

[jessemapel]

I took a look at the nets provided by @lwellerastro and here's the contents:

• The Good Net Standard 4 point network with each network having a single measure
• The Bad Net The PVL header is empty, but the protobuf header is present and looks okay

You can see more at this gist

[jessemapel]

Here's the execution path:

1. QnetFileTool::save
2. ControlNet::Write
3. ControlNetVersioner::write
4. Exception

Inside of ControlNetVersioner::write it successfully writes out the protobuf header in ControlNetVersioner::writeHeader, but then it fails around ControlNetVersioner::writeFirstPoint because it doesn't write any points out to the file.

[jessemapel]

@lwellerastro Is there a good time I can stop by and talk to you about what you were doing when this happened? I'm curious if this is related to adding new points because it seems like both you and Stuart were adding ground when this happened.

[lwellerastro]

@jessemapel I was not adding new points - I was editing a network I had already created and saving to a new one. The one scenario I recall:

• qnet to create new network consisting of 4 constrained points to a ground source; this was successful
• bundle the network
• qnet the output jigsaw network to fix a high residual point
  
  
  
  • edited point and adjusted a measure
  
  
  • save measure, save point
  
  
  • save to a new network - won't let me save to a new network
  
  

I think at that point I might have tried to save to the open network as well and that didn't work either. Closed app and tried again.

I don't recall the other scenarios, but I was not creating new points, just editing an existing network.

[jessemapel]

One possible reason for this to pop up now is that converting points to protobuf objects used to never thrown an exception. We added a handful of exceptions for things like unknown enumeration values or missing critical components. It could be that something was happening to create an odd control point state and then on file write, that value just defaulted. Now, instead of defaulting, critical values being off causes exceptions.

[jessemapel]

Here's the new exceptions from writing control points:

• ControlPoint ID is empty
• ControlPoint type is not Free, Constrained, or Fixed
• ControlPoint SurfaceSourceType is not None, User, AverageOfMeasures, Reference, Basemap, or BundleSolution
• ControlPoint RadiusSourceType it not None, User, AverageOfMeasures, BundleSolution, Ellipsoid, or DEM

[jlaura]

@jessemapel So I got to look at the linked gist. What happens if you pvl.load(s) the network? I assume pvl doesn't error, because you are making it to the if/else on the version. Is the head protobuf header empty or just not recording the version properly?

[jessemapel]

@jlaura The first part of the file where the PVL header would be is completely empty. The only data in the bad file is a valid protobuf header.

[jlaura]

:+1: That makes sense why the version is completely missed. I should probably open an issue on plio as well to get some better error handling into that method. Very glad to see plio getting some use for diagnostics like this. I think that package was born for this type of thing.

[jessemapel]

@all We weren't able to reliably reproduce this error, so we can't be 100% sure it's fixed. If this issue persists please re-open.