Eventually WWZ would be nice. This has a lower priority than features such as arbitrary least squares fit etc.
Raising the priority of this in response to a post by Aaron:
This is now under active development. In http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=806:
First, untested, translation of WWZ algorithm from the AAVSO Fortran code.
Added code to collect WWZ stats in wwt() method (all and maximal WWZ stats); renamed WWZ data point class.
Added T Umi based unit tests, inspired by the example in Grant Foster's book. Fixed bugs after initial unit testing comparing against wwz11.f Fortran code.
Small changes to expected data sets based upon bugs found in the Fortran code in http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=810
Cleaned up a lot of dead code and made analysis array sizes variable, dependent upon the dataset size for application of WWZ.
First exposure of WWZ in VStar GUI. So far we have plots of period vs time and semi-amplitude vs time; results checked by comparison to T Umi graphs in WWZ sections of Grant Foster's book. WWZ parameter dialog, contour plot for WWZ statistic and data tables are next, along with ability to create phase plots and models from the main dialog. Added T Umi test data in range 2,420,000..2,455,000.
I just took a quick look at this - very interesting. I'll comment on the particulars when I've had a chance to familiarize myself with it.
But one short note regarding performance. On a 2.5GHz Intel Core 2 Duo VStar uses between 52-54% of CPU. In other words it is using all of one core, and the other is mostly idle. In the long term - is there any way to multithread the analysis to better make use of multi core or SMP? From what I understand, Apple no longer sells desktops or laptops with single cores. This will become increasingly important as the size of datasets grows.
This is definitely something I have thought about and I agree that it will become more important for scaling as dataset size grows.
I don't have an answer right now, but it's on my radar. The same could be said for DC DFT I imagine.
I will commit more WWZ code later.
A few notes about multicore...
Java threads now correspond to native threads (and have for a long time). So, the way to making better use of multi-core is to split the work of the algorithm across multiple threads, or in the case of 1 available processor: 1 thread. The rest is up to the OS scheduler.
The question is how amenable to becoming parallel is a particular algorithm? In WWZ's wwt() method, there is potential to iterate over the times under test with a step of two, so that if there are 2 available processors, 2 threads could be allocated, computing two iterations of the algorithm, or the main inner loop perhaps, at once. So long as the cost of synchronisation and use of the results of each iteration is not prohibitive, then it may result in a speedup. This was just after a quick look, but it seems feasible. The "work matrices" are small and constant sized. Similarly, DC DFT may be amenable to speed up.
Of course, functionality first, speed later. ;) There may also be other inherent inefficiencies in the algorithm implementation that could benefit from a Big O analysis first, even before we consider multicore.
Here are some useful links for future consideration. I like the fact that we can create JVM thread pools based upon the number of currently available processors.
A related question is whether it would be worth trying to make use of a GPU. There are are Java libs for this, e.g. http://gpgpu.org/2009/02/27/java-bindings-for-cuda, but this one's a little more "out there".
Yes, functionality first, I agree. I don't consider this a "bug" or a priority, but it makes sense to think about this early in the design to make it easier to work in later..
The writing is on the wall, as they say. Even my tiny little netbook has a dual core Atom processor that is ~ 55% utilized.
I'll take a look at those links.
Added ability to create multi-periodic models from best-fit sinusoid values in WWZ algorithm output. Need to sanity check the way I'm handling more than one period per model and residual creation.
Now always using all stats for model creation in WWZ dialog.
Added 3D WWZ plot and made it possible to enable New Phase Plot button from selection on 2D plots.
Period analysis selection listener and message generation changes in WWZ.
Added first cut of a contour plot for WWZ. Fixed a bug in the allocation of a frequency value list in WWZ algorithm.
Added WWZ period range plugin.
Fixed a bug reported by Brian Kloppenborg in WWZ in which for some values of number-of-time-divisions, the number of tau values was being cut well short of the end of the JD range under test. Also cleaned up some WWZ code.
Create Model on some tabs should be removed for now!
Log in to post a comment.