cam2map under cam2map4stereo.py stalling for LROC-NAC stereo processing

[alfiahrizky]

This is a problem I had experienced in about the last 3 weeks. All cam2map4stereo.py runs stall on the first stereo pair cam2map. The [file_name].map.cub is created, but the cam2map will stall until more than 3 days, while previously a DTM from 1 LROC-NAC stereo pair can be processed in 2 days. This happens even when I try doing this for a pair I successfully made a DTM from before. If I run cam2map with the default setting separate from cam2map4stereo.py (only cam2map from=[file_name].cub to=[file_name].map.cub) , the cam2map is successful, but if I run with the cam2map4stereo.py setup, it stalls.

I have updated my SPICE kernels, I have also tried updating the SPICE data using web service. The pair I successfully processed before but not now is M1106216804LE-M1106238239LE. The specs of the machine I use is Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz Ubuntu 18.04.3 LTS. Thank you.

[rbeyer]

Something else must have changed, because cam2map4stereo.py hasn't. Did you start using a different version of ISIS in that time, or anything else that's different? When you say that 'cam2map4stereo.py' stalls, is there anything printed out to the terminal that might help us diagnose what's wrong? When you say "stalls," do you mean that the program is still running on your computer but never exits? Is the output map.cub being written to at all once it is created (by examining time stamps on the file)? We need more information to be able to diagnose.

Anything interesting in the tail end of the print.prt file right before this happens?

[alfiahrizky]

Hello Ross, thank you for responding.

I haven't updated my ISIS and haven't changed anything as far as I know, my ISIS3 is version 3.9.0. I saw other thread about incompatible SPK (de430.bsp), but I don't have that in my SPK folder.

Stalling, in this case, is only showing the cam2map command without any other output (cam2map from=../M1106216804LE.cub to=../M1106216804LE.map.cub pixres=MPP resolution=1.4565567773809 defaultrange=MAP minlat=22.412064466379 maxlat=24.739719423873 minlon=312.79234548216 maxlon=313.07864983111). if I stop the processing (CTRL+C), the output is ^CTraceback (most recent call last): File "./cam2map4stereo.py", line 275, in sys.exit(main()) File "./cam2map4stereo.py", line 244, in main code = subprocess.call(cam2map_cmd, shell=True) File "../conda_env/isis3/lib/python3.6/subprocess.py", line 269, in call return p.wait(timeout=timeout) File "../conda_env/isis3/lib/python3.6/subprocess.py", line 1436, in wait (pid, sts) = self._try_wait(0) File "../conda_env/isis3/lib/python3.6/subprocess.py", line 1383, in _try_wait (pid, sts) = os.waitpid(self.pid, wait_flags) KeyboardInterrupt

The tail end of the print shows camrange result: Object = getkey IsisVersion = "3.9.0 | 2019-09-13" ProgramVersion = 2013-02-04 ProgramPath =../conda_env/isis3/bin ExecutionDateTime = 2020-05-11T15:53:42 HostName = Unknown UserName = arp2 Description = "Outputs the value of a requested keyword"

Group = UserParameters FROM = ../camrangeattacb9x.txt GRPNAME = UniversalGroundRange KEYWORD = MaximumLongitude UPPER = False RECURSIVE = False End_Group

Group = Results From =../camrangeattacb9x.txt MaximumLongitude = 313.07864983111 End_Group

Group = Accounting ConnectTime = 00:00:00.0 CpuTime = 00:00:00.2 End_Group End_Object

If I compare the qview from default cam2map [file_name]map.cub and the temporary map.cub from the cam2map4stereo.py, it looks fine other than it not being full strip as the processing is still running but stalling.

Thank you.

[dpmayerUSGS]

You might consider trying again with ISIS 3.9.1. According to the release notes, that point release fixed an issue with cam2map that caused indefinite run times..

[alfiahrizky]

Thank you, David. Let me try it first and check whether the issue persists. Hopefully, that's the solution.

[rbeyer]

@alfiahrizky, did you resolve this, one way or another?

[rbeyer]

I'm going to assume you did, and will close this for now.