During preparation for CLEANest development, I am noticing differences between VStar's DC DFT and the TS frequency scan to which it corresponds. Differences are seen anywhere from the 2nd to 4th decimal places in period, in the order of seconds to minutes. This may not matter so much for LPVs or Cepheids, but would more so for CVs.
The unit tests for DC DFT have so far relied upon the direct comparison of the results of the AAVSO TS standard scan (option 1 under Fourier analysis) of del Cep data with VStar's standard scan results:
http://vstar.svn.sourceforge.net/viewvc/vstar/trunk/test/org/aavso/tools/vstar/util/period/dcdft/
It's important to note that when first added to VStar, its DC DFT was the same as TS standard scan. Subsequently (since version 2.4 in August 2010), a frequency parameters dialog (low, high, resolution) was added such that standard scan was replaced by this from a user interface perspective. This has only ever been manually tested and has no corresponding unit test.
First, I am adding back the option of performing a TS-style standard scan (in addition to frequency scan), since this does perform as per TS, both via unit testing and manual testing.
Second, at least one unit test based upon TS output needs to be created for (e.g. using del Cep or the TS supplied tcas.dat).
This underscores, again, the need for more incisive, systematic testing.
Added DC DFT standard scan top hits UT in
http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=739
and
added unit tests for standard scan and frequency range modes for DC DFT. The first behave as per AAVSO's TS program, while the second have similar results but do not agree with TS exactly. in http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=740
In http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=741:
Changed frequency range T Cas unit test input values (low/high frequency, resolution) to match the actual values being computed internally by default for T Cas data by the Fortran TS Fortran code as opposed to the displayed default values which TS only shows to a few decimal places of precision. Also changed the period analysis parameters dialog to show full available precision so as to avoid this same default parameter problem in VStar.
I found this by first translating the Fortran TS code to C with f2c and debugging it with gdb (which I couldn't get to work so well with gfortran generated code) and comparing key variables with VStar's.
So, it turns out that there was no problem with the DC DFT implementation in VStar (i.e. Java translation of the Fortran TS code).
Now we have regression tests in place that will reveal any future similar problems with this code, e.g. if I optimise the algorithm.
In http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=742:
Added another DC DFT frequency range unit test.