burn-in iterations

[stephens999]

from Chad Klumb:

One other scat question relates to the burn-in iterations being written to the same file as the main iterations, which is what's currently done. For down-stream operations (plotting, running voronoi) you need to know how many of the iterations in the output file are burn-ins and how many are main iterations, since there's no indication in the file of where one ends and the other begins. At present the GUI does not appropriately handle variability in the number of burn-ins and main iterations (it assumes burn-ins are always the first 100 iterations, and main iterations are either everything else or the next 100 iterations depending on whether it's plotting or running voronoi). I'm trying to fix this issue while keeping the GUI as simple as possible, and there seem to be two basic approaches:

(1) stop writing burn-in iterations (or at least stop writing them to the same file as the main iterations) and allow the GUI to automatically determine the number of main iterations in the output files

(2) keep writing burn-ins as they are written now but add extra fields where the user needs to specify how many burn-ins and main iterations there are in each (group of) output file(s)

I think that (1) would be easier for the user, but would require us to change scat (remove line 3415, if I'm not mistaken) and would require somewhat more significant modifications to the GUI code (but I think I can do it in a timely manner). Option (2) would be a little confusing (due in part to how the GUI compiles data for plotting and voronoi runs) but is a possibility if you would prefer to keep burn-ins in the output files.

[stephens999]

In some sense there is actually no real difference between burn-in iterations and real iterations. So if
we do 100 burn-in and 100 real iterations, really we just do 200 iterations. That's why results are output like that. Results output by scat that are averaged over iterations discard the burn-in iterations, but this is just a convenience, and nothing to say that 100 is optimal. So it makes more sense for the GUI user to specify how many iterations they want to discard as burn-in. For example, suppose you ran SCAT with 100 burn-in and 100 main. But then on looking at the results you realize you maybe should have chosen 150 burnin and only want to use the last 50 iterations for your downstream analyses.

So I suggest basicaly the GUI just read in all the iterations and let the user decide how many to treat as burnin (which may or may not be the same as the number specified when running the software)