Dear Jaume,

1). HyPhy doesn't like '.' in sequence names for technical (programming) reasons. One way to circumvent this is to simply multiply all the dates by an appropriate power of 10 to get rid of the decimals (e.g. 90.23 -> 9023) and remember to do the backconversion on the output. Another option is that I could modify dated...bf to take dates from branch lengths (and not tip names) included in the tree - this will allow decimals directly. Let me know if you'd like this done.

2). The '0' rate estimate is probably a bug in the output. I'll look into it and get back to you ASAP.

Cheers,
Sergei

Dear Jaume,

Quote:


I fixed the 0 substitution rate bug (Multimedia File Viewing and Clickable Links are available for Registered Members only!!  You need to Login).

Which codon models did you have in mind? You can always add your own models to those in the 'Standard' list which pops up. That's probably easiest. If you tell me which model you want to try, I can write a little step-by-step tutorial for how to add such a model to the list.

Cheers,
Sergei

Dear Jaume,

Quote:


You can add a CovarianceMatrix (see documentation about the options) to obtain 95% profile likelihood confidence interval on any of the model parameters. Let me know if you need assistance setting this up.

Quote:


I am not sure you can do this type of comparison with codon models - they don't really support the notion of 4-fold or 2-fold synonymous sites; rather all synonymous substitutions etc. Have you tried doing the analysis with synonymous rates only for a 'local' (separate dS and dN for each branch) codon model? This is probably more general than only looking at subset of synonymous substitutions. Of course you could always extract the type of sites you want from your data (e.g. 4-fold 3rd codon positions) and fit nucleotide models to this subset, but I'd recommend doing synRate clock first with a proper codon model.

Cheers,
Sergei

Dear Jaume,

Quote:


Sadly, the current implementation of the method does not allow local rates properly (it could, I just didn't implement it). Effectively, if you have multiple parameters per branch, it is difficult to decouple their contribution to the branch lengths without knowing something else. Imagine for example, that you allow transition (t) and transversion (v) rates. Then your branch length will be a linear combination of the two: B = a_1*t + a_2*v, where a_1 and a_2 are functions of base frequencies. If you then want to constrain the branch length B to be something measured in units of time (as TipDate does), you can't easily solve for rates, because you get a whole line of solutions: t = (B-a_2*v)/a_1.

Of course, the error message you got was not very informative - sorry about that.

HTH,
Sergei