sibonli / blue-beast Goto Github PK

Tidy it up

Better coding style. 

Implement Heidelberg convergence statistic

Set progress = 0
Calculate the statistic anyways just to see if it's converged

Z-score calculation for Geweke

Regression based progress report for Raftery? 

so that the nextCheckChainLength isn't infinity (chainlength / 0 )

If raftery needs more samples, set progress = NaN
Geweke not converged, set progress to NaN as well. 

Currently only looks at ESS? Need to look at all the stats being used within 
the run. 

 I know in tracer if value is NaN then they just display a "-" instead of ESS. I don't know of any cases where ESS would be NaN other than that. Maybe when one of the values logged is NaN? Maybe we could check for NaN values before we add them into traceInfo

One possible solution: In cases where a file is being used, load a singledocApp 
instead of InstantiableTracerApp. That SHOULD solve the problem. 

Group varNames and traceInfo into new class Traceinfo.java  traceInfo.keySet() 
is not sorted. 

Propp 1998 introduces a way to deterministically find the point to 
coalescent/mixing at a fixed time. i.e. it removes the need for burn-in and is 
unaffected by initial values of the MCMC. 

Also, this approach can potentially be parallelized/threaded, so as to speed up 
the entire MCMC process. 

This will be a great addition to blue-beast but mathematically complicated. 

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Implement Gelman's statistic and support for Metropolis coupling

I/O functions in BlueBeastMain need to be fully tested for functionality. 

Variable haveAllConverged in ConvergeStat.java and implementing classes does 
not need to be global. Better encapsulation

Fix this. Does closing the window terminate the BEAST run? 

When running two Beast runs in the same folder the file overwrites itself. Need 
to have a name which is unique

Initialize traceInfo hashtable of arraylists with initial capacity equal to 
initialcheck divided by sample frequency. 

Minor improvements to initial performance. 

if GLM doesn't converge, would it be possible to recheck again after one more 
sample? would one sample (or even 10) make a difference to the convergence of 
the GLM? 

So that it can support multiple languages and distributed frameworks. 

Raftery takes too long to get an answer (at least 3746 samples is a long time 
right? chainlength = 4 million if sampling at every 1000 steps)

Convergence was not met in several distribution parameters of the BSSVS of 
relaxed molecular clock but BLUE-BEAST still said it had converged. 

See the below link for log files, BB log, stdout (with seed to repeat the 
analysis), XML

https://dl.dropbox.com/u/49829282/Blue_Beast_failing_example.zip

Need to make it so then convergence statistic parsers actually input the proper 
convergence statistics rather than a meaningless instance. Will need to modify 
constructors in the ESSConvergeStat.java classes etc.

Java runs out of heap space on default settings when loading up bb_temp.log