Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added support for the -mlnj-only parameter - for which some refactoring
was necessary (see #2 through #8 and particularly #5 below), and also drafted some additional "progress-reporting" (see #9 through #11): 1. If -mlnj-only is found on the command-line, Params::compute_ml_tree_only will be set to true (in parseArg(), in utils/tools.cpp). 2. initializeParams doesn't call computeInitialTree if compute_ml_tree_only is set to true. 3. You can't set the root of a tree (if you don't yet have one), a bit later in the same function (and also in IQTree::initSettings). 4. Added PhyloTree::ensureNumberOfThreadsIsSet (and updated repetitive code that was doing what it does, in several other places). This forced some updates in other files, such as main/phylotesting.cpp. 5. Added PhyloTree::ensureModelParametersAreSet (as the same steps need to be carried out somewhat later if there isn't an initial tree before ML distances are calculated). It returns a tree string. 6. In runTreeConstruction, when compute_ml_tree_only is set, negative branches are resolved, and #4 and #5 are called only AFTER the tree has been constructed. 7. In IQTree::initCandidateTreeSet the tree mightn't be a parsimony tree (I think if you've combined -nt AUTO and --mlnj-only) as such, but there will be *a* tree. The list of cases wasn't exhaustive any more. 8. Added a distanceFileWritten member variable and a getDistanceFileWritten Member function to PhyloTree. 9. (This and the following changes are progress reporting changes). Added member functions for progress reporting to PhyloTree: (a) initProgress (pushes where you are on a stack, and starts reporting progress, if there's now one level of progress reporting on the stack) (b) trackProgress (bumps up progress if progress stack depth is: 1) (c) hideProgress (called before you write log messages to cut) (d) showProgress (called again after) (e) doneProgress (pops, and stops reporting progress, if the last level of progress reporting was just popped) The supporting member variables are progressStackDepth and progress. 9. IQTree::optimizeNNI uses the functions added in change #9 to report Progress (problem here is that MAXSTEPS is a rather "high" guess (For n sequences it is ~2n, when the best guess for how many iterations There will be, with parallel NNIs, is on the order of ~p where p is the worst-case "tip-to-tip" path length of the tree - probably a lot less. 10.PhyloTree::testNumThreads also uses the functions added in change#9 to Report how many threads it has tried (though, for now, it badly over-reports how long it thinks it will take) (because it thinks it will do max_procs iterations and each will take as long as the last, but, Really, it'll do max_procs/2, or so, and they go faster and faster as there are more threads in use in later steps - one more each step). 11.PhyloTree::optimizeAllBranches reports progress (via the functions added in change#9). Normally it reports progress during parameter optimisation (because I haven't written "higher-level" progress reporting for that yet). There are some potential issues though: 1. The special-case code for dealing with "+I+G" rates doesn't yet have a counterpart when compute_ml_tree_only is set (in runTreeConstruction). 2. Likewise, the code for when (params.lmap_num_quartets >= 0) (No counterpart when compute_ml_tree_only is set, yet) (this too is in runTreeConstruction). (I haven't figured out how to test the "counterpart" versions of those yet, which is why I haven't written them) 3. If you pass -nt AUTO I'm not sure how many threads the NJ (or whatever) step will use (I think it's all of them), and the ML distance calculations also "use all the threads" (because the thread count's not set when that code runs either). Both parallelise... well... but I'm not so sure it's a good idea that it hogs all the CPU cores like that.
- Loading branch information