Debugging input errors

[houchin]

Is there a recommended ADL 3 configuration for debug/logging that would make it easy to determine if ADL did not complete due to an error in the inputs. For example, we ran ADL 3 with an input directory that contained a VIIRS SDR Delta C file that was too small. Obviously, ADL didn't complete normally. However, other than ADL completing and there being no SDR products in the output directory, we were unable to determine authoritiatively what the problem was. Only by examining all of the inputs and tracking back to the original files was I able to identify the short file.

[bhenders]

The default ADL run-time configuration files that ADL delivered, should have the debugLevel set to DBG_LOW and the debug destination as D_FILE. The dbgPath was also set to $ADL_HOME/log. Each time you run a process you will get a log file in that directory for the process. Here is an example log file name from running the ProEdrViirsNccImagery.exe -> ProEdrViirsNccImagery.exe_auisdev1m_1028108.log. The fastest way to generally find failures is to search for PRO_FAIL in the log file. However, keep in mind that some failures like optional inputs may assert PRO_FAIL's but they are handled by the framework software. Generally the fastest way for me to determine success or not is to grep for an "EDR_GRAN" or "SDR_GRAN" message in the log file. These messages are logged whenever output products have been produced successfully.

In the ADL Users manual Part 2 see section 5.8.7 Algorithm Execution Failures for reference also.

ADL is instrumented pretty heavily with debug messages that for most failures looking at the logging information should make it apparent on what the problem might be. Though, I'll admit I've had numerous years of experience looking at such failure log files...

Bryan Henderson
Raytheon Company