Fitacf3 warning messages with reprocessed cve, cvw data #650
Description
BUG
A print statement happens on many files of the reprocessed cve, cvw data. For example, running make_fit -fitacf3 20201231.0601.00.cvw.rawacf will result in a lot of printed messages such as: range: 0, inverse_alpha: -nan, pwr slope: -nan, pwr: -nan, inverse pwr: -nan.
Priority
- Minor - typo, incorrect naming, fails in a specific uncommon situation
- Major - misrepresentation of data, failure in a common situation
- Urgent - failure in usage, large misrepresentation of data
RST version
Does the bug occur in an official RST release?
- Yes. RST version: 5.1_
- No. Branch containing the bug (e.g. develop): ______
Example of the bug
See in description above.
Attempts
What have you tried already to fix it?
During Data Analysis Working Group we found the print statement is coming from a check in fitacf3's fitting library (codebase/superdarn/src.lib/tk/fitacf_v3.0/src/fitting.c). This is happening because some of the last records in the files where the radar crashed are populated with -nan values in the pwr0, acfd, and xcfd arrays.
What have you tried to work around it?
Data Access
File was downloaded from the BAS mirror
Potential Solution(s)
Discussed during the Data Analysis Working Group meeting to just comment out the print statement since there is nothing else done during the -nan value check.
Extra Notes
Please provide any other details about this bug
I did some more digging on this as far as what we should be concerned about with RST. The resulting fitacf3 file does output some strange records based on the -nan input. All of the arrays are populated with 100 values. The pwr0 array is populated with values of -50. As expected, the slist array contains each range gate. The qflg array is populated with ones and the gflg array is populated with zeros. I can't remember if quality flag of one is good or bad, and our documentation doesn't answer this question. The rest of the arrays (p_l and onward) are populated with -nan values.
For fitacf2 processing, a record is made for this bad input data, but the output stops writing after the pwr0 array. Is this acceptable that we're making what could be a partial record? A simple binary like fitstat seems to be able to read the data without crashing.
I did test both of these files on VT's website to generate RTI plots. This plotting uses pydarn and did not seem to have any obvious problems plotting these fit-level files. Is it possible this could break other plotting software?
The other question to think through is does this kind of fit-level data go against any kind of loose standard or assumptions about the range of values in the fit-level data?