Log Files - UVA-CAMA/NICUHDF5Viewer GitHub Wiki

Using NICUHDF5Viewer v4.0 or later or BAP v2.0 or later will generate a log.mat file alongside each result file. The log file will have the name of the source file but with log.mat at the end.

The Log File Contains:

  • algorithm - A list of all the algorithms that were called to run on a particular file
  • version - The version number of those algorithms
  • success - Whether that algorithm was successful
  • error - An error stacktrace (if the algorithm was unsuccessful)
  • filename - The name of the source (hdf5) file

A screenshot of a log file:

LogFile.PNG

Resetting the Log File

The log file is cleared out and regenerated with each run of a batch of algorithms on a particular file. This allows us to debug a particular run of the batch algorithm processor (or viewer) and not get lost digging through old errors that have since been repaired.

The Error Stack Trace

For this example, I purposely created some errors by breaking some functions so we could see the error stack trace. This is what is under the "error" column in the screenshot above when you click on the 1x1 MException

LogFileError.PNG

And if you open the stack, you will see:

LogFileErrorStack.PNG

The Success Messages

In the "success" variable, there are several possible messages you can get. To understand exactly where these messages are generated, please review run_all_tagging_algs.m.

The messages you can get are the following:

  • Success - the algorithm completed running for the first time within this run of the BAP or Viewer and stored some results as tags (though there may not be any actual tagged events (if no events occurred within the file)
  • Cleanly exited - the function returned without any tag information (specifically, it returned no tag column names). This is set to occur when the source variables necessary to run the function are not available.
  • QRS Success - qrs detection was run for the first time within this run of the BAP or Viewer and some qrs results have been stored. Note that the apnea algorithm can call qrs detection (if it has not already been run) and return qrs results, so this can show up as an output from the apnea algorithm.
  • QRS Cleanly exited - this occurs in two scenarios: 1. when the source qrs signal is not available to run qrs detection on 2. the apnea algorithm has the option to run qrs detection if it has not already happened, but if it hasn't run qrs detection, it will simply return a "QRS Cleanly exited" message.
  • Previously run - the algorithm (of this specific version number) has already been run and results are already stored in the results file. The algorithm was not re-run.

Apnea Algorithm Can Generate Two Rows in the Log File

Here is an example of what you may see as an output from the apnea algorithm when QRS detection had already been run before the apnea algorithm was called (note, the large number of rows in this file is because this screenshot is from a merged log file):

LogFileApnea.PNG

Here is an example of when the apnea algorithm has already been run (you don't see the duplicate lines for tags and QRS because it doesn't run the algorithm at all).

LogFileApneaPreviouslyRun.PNG

Merged Log Files

When results files are merged, the log files will also be merged. When log files are merged, they are simply vertically concatenated. The merged log file will contain the name of the first log file but with merged.mat at the end.