Bug 1306 - Output filenames in "dry run" log are wrong with multiple instruments and/or focal planes
Summary: Output filenames in "dry run" log are wrong with multiple instruments and/or ...
Alias: None
Product: DIRSIG5
Classification: Unclassified
Component: BasicPlatform (show other bugs)
Version: 5.0.10
Hardware: Intel x86 Windows 64-bit
: P3 normal
Assignee: Scott D. Brown
Depends on:
Reported: 2020-10-24 04:28 EDT by David Allen
Modified: 2020-10-26 10:43 EDT (History)
0 users

See Also:

test scene files (85.41 KB, application/x-7z-compressed)
2020-10-24 04:28 EDT, David Allen

Note You need to log in before you can comment on or make changes to this bug.
Description David Allen 2020-10-24 04:28:44 EDT
Created attachment 428 [details]
test scene files

In a scenario that has multiple focal planes on a platform, the expected naming for ""individual files for each capture in each task"", as set in the output file schedule, is not what is reflected in the dry_run.

dry_run img name:
as rendered:

'log_info' option is numbering each capture sequentially. Using a dry run, an end user might expect:
0:0:0 = capture 1, 00 focal plane = c0000
0:0:1 = capture 1, 01 focal plane = c0001
0:0:431 = capture 431, 03 focal plane = c0431

Yet, the naming for the rendered images assigns the capture ticker according to the group of focal planes (0:0:0-3 = c0000, 0:0:4-7 = c0001). This seems to lump the focal plane as a group into each uptick of the capture indexing. (108 captures * 4 focal planes = 432 captures)

Additionally, the sequence of the captures is not predictable enough to compensate for the naming issue inconsistency. For instance, a 4-focal plane platform (0,1,2,3) will run as:
Comment 1 Scott D. Brown 2020-10-26 09:58:19 EDT
If you looked closely at the dry run log, the capture portion of the filenames simply increased across all focal planes:

grep \"filename\" log.json 
        "filename": "rgb_10k_angle3-t0000-c0000.img",
        "filename": "swir_10k_angle3-t0000-c0001.img",
        "filename": "swir_10k_angle3-t0000-c0002.img",
        "filename": "rgb_10k_angle3-t0000-c0003.img",
        "filename": "rgb_10k_angle3-t0000-c0004.img",
        "filename": "swir_10k_angle3-t0000-c0005.img",
        "filename": "swir_10k_angle3-t0000-c0006.img",
        "filename": "rgb_10k_angle3-t0000-c0007.img",
        "filename": "swir_10k_angle3-t0000-c0008.img",
        "filename": "rgb_10k_angle3-t0000-c0009.img",
        "filename": "rgb_10k_angle3-t0000-c0010.img",

Or if you look at just the RGB focal plane, there are not in sequential order as they should be:

grep \"filename\" log.json | grep rgb
        "filename": "rgb_10k_angle3-t0000-c0000.img",
        "filename": "rgb_10k_angle3-t0000-c0003.img",
        "filename": "rgb_10k_angle3-t0000-c0004.img",
        "filename": "rgb_10k_angle3-t0000-c0007.img",
        "filename": "rgb_10k_angle3-t0000-c0009.img",
        "filename": "rgb_10k_angle3-t0000-c0010.img",

What we discovered was that the filenames in the dry run were wrong. There was a missing remapping from the task and capture indexes used in the core to the instrument and focal plane specific task and capture indexes inside the BasicPlatform plugin.
Comment 2 Scott D. Brown 2020-10-26 10:08:07 EDT
The remapping was added and now the dry run log filenames are correct and they should match the ones produced during the sim or when you execute a portion of the  schedule from the command line with the "--capture" type options.

This problem was discovered in the 2020.42.0 (58ee3e8) build. It will be patched in 2020.43.0
Comment 3 Scott D. Brown 2020-10-26 10:43:52 EDT
To be clear, this problem was specific to a platform setup with multiple instruments and/or focal planes.