Dear Users,

BEAST 1.7.3 is released.

Thank you for your support,
Walter

It seems the generate BEAST file button in BEAUTi 1.7.3 is broken somehow.
Just set up a new analysis from scratch, and it seems that if I define any
taxa to be monophyletic the Generate button does nothing.

Tried with 1.7.0 and works fine. I'm on a 2006 MacBook Pro running snow
leopard.

Dear Jacob,

I am sorry but I cannot replicate this problem. I loaded a file, created some taxon sets and set them to be monophyletic. The XML generated fine so the 'generate BEAST file' button isn't generally broken. Please provide a more details of what you did, what your system is etc.? If you can replicate the issue with a test data set or post details of exactly what you need to do to get the error. Ideally posting it to our issue database saves time:

http://code.google.com/p/beast-mcmc/issues/list

Andrew

On 20 Aug 2012, at 20:30, Jacob Berv <jacob.b...@gmail.com> wrote:

___________________________________________________________________
 Andrew Rambaut                
 Institute of Evolutionary Biology       University of Edinburgh
 Ashworth Laboratories                         Edinburgh EH9 3JT
 EMAIL - a.ramb...@ed.ac.uk                TEL - +44 131 6508624        

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

I think I've narrowed it down a bit - In order to determine what step was
causing the problem I tried clicking the generate button after every step.
I was trying to set up an phylogeographic analysis using the continuous
diffusion model.

1. Imported my data (4 genes), 1 start tree - OK
2. unlinked clocks, models, linked trees - OK
3. Defined ingroup to be monophyletic - OK
4. defined lat, long traits for continuous phylogeographic analysis,
created partition - OK
5. set models, clocks, tree prior using logistic growth - OK
6. set priors - OK
7. set prior for treemodel.rootheight - FAIL
8. remove trait partition - OK

I can replicate this problem if I use the RacRABV dataset (and choose an
arbitrary ingroup) so unless I'm missing something this does seem to be a
bug with how the traits are managed/defined.

What do you think is going on?

I should add that I have the same problem for discrete traits as well.

Thanks Jacob,

What is the prior you set on rootheight?

Andrew

On 20 Aug 2012, at 22:08, Jacob Berv <jacob.b...@gmail.com> wrote:

___________________________________________________________________
 Andrew Rambaut                
 Institute of Evolutionary Biology       University of Edinburgh
 Ashworth Laboratories                         Edinburgh EH9 3JT
 EMAIL - a.ramb...@ed.ac.uk                TEL - +44 131 6508624        

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

It seems to fail on arbitrary rootheight priors, but I've been using 4.52,
0.851

Hi all,

I am attempting to sample ancestral states for a sequence of
morphological characters (binary) evolving under a lewisMk
model, with some unknown states.

I can run the analysis just fine until I add the ancestral
state reconstruction code.

The key bits of XML here are:

[...defining the character evolution model...]

<lewisMk id="lewis_un_2_Model">
   <frequencies>
    <FrequencyModel idref="morph_2_Model"/>
   </frequencies>
  </lewisMk>

[...define the likelihood of that data on the tree...]

  <ancestralTreeLikelihood id="morph.un2.treeLikelihood"
useAmbiguities="true" stateTagName="morph.un2.states">
   <patterns idref="morph_un2.patterns"/>
   <treeModel idref="treeModel"/>
   <siteModel idref="morph_un2.siteModel"/>
   <discretizedBranchRates idref="branchRates"/>
   <lewisMk idref="lewis_un_2_Model"/>
  </ancestralTreeLikelihood>

[...log the ancestral states...]

<!-- START Ancestral state reconstruction  -->
<trait name="morph.un2.states" tag="morph.un2.state">
<ancestralTreeLikelihood idref="morph.un2.treeLikelihood"/>
</trait>
<!-- END Ancestral state reconstruction  -->

Problems that arise:

1. When I run this on BEAST 1.7.3 WITHOUT Beagle, I get:

======================
[...]

TreeLikelihood(treeModel) using Java general likelihood core
   Using ambiguities in tree likelihood.
   With 223 unique site patterns.
Branch rate model used: discretizedBranchRates
Ancestral reconstruction using ambiguities is currently not
support without BEAGLE

[crash]
======================

2. But when I run WITH Beagle turned on, I get:

=============================
[...]

Using discretized relaxed clock model.
   over sampling = 1
   parametric model = logNormalDistributionModel
    rate categories = 70

Creating state frequenciesParsing error - poorly formed
BEAST file,
v13a_BDserial_onlyGreatApes_noDNA_add_tip_sampling4.xml:

The '<lewisMk>' element with id, 'lewis_un_2_Model', is
incorrectly constructed.

The following was expected:
Exactly one ELEMENT of name frequencies REQUIRED containing
     Exactly one ELEMENT of type FrequencyModel REQUIRED
  model 'null': Initial frequencies = {0.5, 0.5}
Creating state frequencies model 'null': Initial frequencies
= {0.33333, 0.33333, 0.33333}
Creating state frequencies model 'null': Initial frequencies
= {0.25, 0.25, 0.25, 0.25}
Creating state frequencies model 'null': Initial frequencies
= {0.2, 0.2, 0.2, 0.2, 0.2}

BEAST has terminated with an error. Please select QUIT from
the menu.
=============================

The second error occurs despite the fact that the lewisMk
model is specified just as required (see above) and the
identical XML works fine in non-state-reconstruction analyses.

It looks like the problem is also noted on CIPRES:

http://www.phylo.org/index.php/help/error_messages/#beastbeagle

3. Just for kicks I also tried running ancestral state
reconstruction with beagle off, AND changing to
"useAmbiguities=false".  This gave a hard crash:

=============================
Branch rate model used: discretizedBranchRates
Creating swap operator for parameter branchRates.categories
(weight=10.0)
Likelihood computation is using an auto sizing thread pool.
Creating the MCMC chain:
   chainLength=100000000
   autoOptimize=true
   autoOptimize delayed for 1000000 steps
# BEAST v1.7.3, rr5146
# Generated Mon Aug 20 19:25:37 PDT 2012 [seed=1345515937166]
state   Posterior       Prior           Likelihood      Root Height
Rate
0       -3316.5324      -313.3966       -3003.1358      32.95
1.00000         -
Exception in thread "Thread-2" java.lang.RuntimeException:
Reconstruction not implemented for multiple categories yet.

at
dr.evomodel.treelikelihood.AncestralStateTreeLikelihood.traverseSample(Unkn own
Source)
at
dr.evomodel.treelikelihood.AncestralStateTreeLikelihood.traverseSample(Unkn own
Source)
at
dr.evomodel.treelikelihood.AncestralStateTreeLikelihood.redrawAncestralStat es(Unknown
Source)
at
dr.evomodel.treelikelihood.AncestralStateTreeLikelihood.getStatesForNode(Un known
Source)
at
dr.evomodel.treelikelihood.AncestralStateTreeLikelihood$1.getTraitString(Un known
Source)
at
dr.evomodelxml.tree.TreeLoggerParser$2.getTraitString(Unknown Source)
at dr.evolution.tree.Tree$Utils.writeTreeTraits(Unknown Source)
at dr.evolution.tree.Tree$Utils.newick(Unknown Source)
at dr.evolution.tree.Tree$Utils.newick(Unknown Source)
at dr.evolution.tree.Tree$Utils.newick(Unknown Source)
at dr.evolution.tree.Tree$Utils.newick(Unknown Source)
at dr.evolution.tree.Tree$Utils.newick(Unknown Source)
at dr.evomodel.tree.TreeLogger.log(Unknown Source)
at dr.inference.mcmc.MCMC$1.currentState(Unknown Source)
at
dr.inference.markovchain.MarkovChain.fireCurrentModel(Unknown Source)
at dr.inference.markovchain.MarkovChain.runChain(Unknown Source)
at dr.inference.mcmc.MCMC.chain(Unknown Source)
at dr.inference.mcmc.MCMC.run(Unknown Source)
at java.lang.Thread.run(Thread.java:680)
=============================

...which may be due to having ambiguities in the data but
saying "useAmbiguities=false" anway.

The above problems may just be "stuff that hasn't been
implemented yet", but I figured I should summarize my
findings to help the google-ability of this issue for
others, and/or to find out/hope that the wonderful BEAST
developers have something in the works to cover this.

(Or maybe I missed something obvious.)

Cheers!
Nick

The workaround seems to be to produce an XML file without setting the
rootheight prior, an XML file with the rootheight prior but without the
phylogeography setup, and then to copy the priors block from the latter
over the former.

Thanks Jacob,

I will investigate what the issue is.

Andrew

On 21 Aug 2012, at 20:03, Jacob Berv <jacob.b...@gmail.com> wrote:

___________________________________________________________________
 Andrew Rambaut                
 Institute of Evolutionary Biology       University of Edinburgh
 Ashworth Laboratories                         Edinburgh EH9 3JT
 EMAIL - a.ramb...@ed.ac.uk                TEL - +44 131 6508624        

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

<jitter window="0.0005 0.0005" duplicatesOnly="true">
<parameter idref="leaf.location"/>
</jitter>

Any idea what could be causing this?

Hi Andrew - have you made any headway on this issue in the last 10 days?

What issue?

Andrew

On 31 Aug 2012, at 00:45, Jacob Berv <jacob.b...@gmail.com> wrote:

___________________________________________________________________
  Andrew Rambaut                
  Institute of Evolutionary Biology       University of Edinburgh
  Ashworth Laboratories                         Edinburgh EH9 3JT
  EMAIL - a.ramb...@ed.ac.uk                TEL - +44 131 6508624      

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Well at first it was the issue with the generate beast xml button that I
described earlier in the thread. I haven't found a way around this bug
beyond producing two xml files and combining them. A few days later, after
successfully getting the combined files to actually run, I had an issue
with strange artifacts occurring the run. For example, the treeRoot would
get stuck on a single value and not update between generations. Setting
beagle scaling equal to always seems to have solved this issue. Now, I'm
gotten my files to run and go to completion, but I'm having serious
convergence problems with the phylogeographic analysis and some other
strange issues.

I have tried discrete analysis (areas of endemism) and continuous analysis
(sampling coordinates) (brownian, cauchy RRW and gamma RRW, all produced in
1.7.3). The dataset I've been working with normally is well converged by
100M generations, sampled every 10k. With the addition of the discrete
analysis, it seems I need to bump it to 200M generations (sampled every
10k) to get convergence and ESS's above 200 for all parameters. For the
continuous analysis (brownian), the ESS for the prior and likelihood (and
others) are mostly under 30, even after 200M generations. I checked it at
100M and 200M generations and the ESSs were mostly unchanged. For the
cauchy and gamma RRW analysis, I get high ESS values and convergence by
200M generations, but only the cauchy RRW makes any sense when I visualize
it in spread. The gamma RRW suggests several ancestral locations that are
totally impossible (and far outside of the range of the original
coordinates), and dispersal routes that zig zag around the map. In sum, for
the continuous analysis, I have only been able to get the cauchy RRW model
to work so far. When I do a bayes factor test in Tracer on the brownian,
cauchy, and gamma log files, it suggests the gamma model is best, but as I
mentioned, the visualization of ancestral locations is not plausible. Any
suggestions would be greatly appreciated. I would be happy to send you my
XML files directly if you think that would help.

Finally, another bug I've encountered in 1.7.3 is whenever I do a run, I
get a bunch of "Unhandled attribute (typo?) stateTagName in treeLikelihood"
messages, though I've been ignoring them and it doesn't seem to make a
difference in the analysis...