lmaurits/beastling

A linguistics-focussed command line tool for generating BEAST XML files.

#BEASTling

A linguistics-focussed command line tool for generating BEAST XML files. Only BEAST 2.x is supported.

BEASTling is written in Python. Python versions 2.7 and 3.5+ are supported. It is available from the Python Package Index, aka "the Cheeseshop". This means you can install it easily using easy_install or pip. Otherwise, you can clone this repo and use the setup.py file included to install.

BEASTling has a few dependencies. If you use easy_install or pip, they should be taken care of automatically for you. If you are installing manually, you will also have to manually install the dependencies before BEASTling will work. The dependencies are:

• appdirs
• clldutils
• newick
• six

BEASTling will run without BEAST installed, but it won't be very useful. Therefore, you should install the latest version of BEAST 2. Old BEAST 1.x versions are not supported. Note that recent BEAST 2.x releases depend upon Java 8. They will not work with Java 7. So, you should install the latest version of Java for your platform first.

BEAST 2 is a modular program, with a small, simple core and additional packages which can be installed to add functionality. Managing packages is easy and can be done with a GUI. You should install the following packages, as BEASTling makes use of them for much of its functionality:

• BEAST_CLASSIC
• BEASTLabs
• morph-models

In summary:

1. Install/upgrade Python. You need 2.7 or 3.5+
2. Install BEASTling (plus dependencies if not using pip etc.).
3. Install/upgrade Java. You need Java 8.
4. Install/upgrade BEAST. You need BEAST 2.
5. Install required BEAST packages.
6. Profit.

Bug reports, feature requests and pull requests are all welcome.

beastling's Issues

Models are hard-coded in configuration.py

There is a finite list of models listed in configuration.py, so anyone (like me) wishing to add another model to the list has to not just write a new module for the model, but also add two lines to configuration.py.

Making use of python's basic introspection and interpretation capabilities (such as dir and some kind of safer __import__ or eval), this need could be removed, and it would even be possible to specify any Model class, which could be defined in a separate package (or in pwd), to provide the model logic through the configuration file.

Interpolation in configuration files

I think we are currently parsing configuration files explicitly without interpolation. Is there a good reason for that, or can I just switch interpolation on? I assume it's a good feature eg. for setting up a type of analysis and filling in some family-specific blanks using another config file that just sets a few lineage-dependent variables.

Beastling creates tags with both `idref` and `spec`

Beastling calls ElementTree.SubElement setting both the idref and the spec attribute, for example in beastxml.py:162

                    ET.SubElement(taxonset, "taxon", {"idref":lang, "spec":"Taxon"})

This leads to a long trace of superfluous warnings in the beast2 stderr.

Provide wrapper script to make BEAST usable in pipeline

To integrate BEAST into a UNIX-style pipeline, a wrapper script is needed which

• reads BEAST XML from stdin and writes it to a temporary file
• calls BEAST, pointing it to the temporary file
• reads BEAST output and writes it stdout
• optionally removes the temporary file

ScaleOperators have default value of scaleFactor=1.0, which basically disables them.

ScaleOperators multiple a parameter by a random value drawn from the uniform distribution on (1/scaleFactor, scaleFactor). E.g. if scaleFactor = 0.5 (the default value produced by BEAUti), the random scaling value is between 0.5 and 2.0.

BEASTling sets scaleFactor=1.0, so the scaling values is between...1 and 1. And thus parameters operated on only by these operators move excruciatingly slowly (interestingly, they do in fact move, which I guess must be due to numerical issues).

UpDown operator which scales tree height is still present in config even if sample_branch_lengths=True

UpDownOperator cannot operate on trees.

Generating a beast xml file using beastling, I get

Error 130 parsing the xml input file

nullThis BEASTInterface (UpDown) has no input with name tree. Choose one of these inputs: scaleFactor,up,down,optimise,elementWise,upper,lower,weight

Error detected about here:
  <beast>
      <run id='mcmc' spec='MCMC'>
          <operator id='UpDown' spec='UpDownOperator'>

caused by the following lines of code:

    <operator id="UpDown" scaleFactor="1.0" spec="UpDownOperator" weight="30.0">
      <tree idref="Tree.t:beastlingTree" />
      <parameter idref="birthRate.t:beastlingTree" />
    </operator>

These are generated by beastxml.py:201ff.

        # Up/down
        updown = ET.SubElement(self.run, "operator", {"id":"UpDown","spec":"UpDownOperator","scaleFactor":"1.0", "weight":"30.0"})
        ET.SubElement(updown, "tree", {"idref":"Tree.t:beastlingTree"})
        ET.SubElement(updown, "parameter", {"idref":"birthRate.t:beastlingTree"})
        if self.config.calibrations:
            for model in self.config.models:
                ET.SubElement(updown, "parameter", {"idref":"clockRate.c:%s" % model.name})

Checking the beast2 git, UpDownOperator never dealt with trees, what operator did you mean?

Insufficient error reporting for inconsistent language sets

When faced with two input data files with non-equal language sets, beastling dies during the process with an error message that might not be easily comprehensible for the uninitiated user.

Traceback (most recent call last):
  File "/home/gereon/python/pkg_beastling/bin/beastling", line 34, in <module>
    main()
  File "/home/gereon/python/pkg_beastling/bin/beastling", line 24, in main
    xml = beastling.beastxml.BeastXml(config)
  File "/home/gereon/python/beastling/beastxml.py", line 32, in __init__
    self.build_xml()
  File "/home/gereon/python/beastling/beastxml.py", line 115, in build_xml
    model.add_likelihood(self.likelihood)
  File "/home/gereon/python/beastling/models/basemodel.py", line 194, in add_likelihood
    self.add_data(distribution, trait, traitname)
  File "/home/gereon/python/beastling/models/covarion.py", line 44, in add_data
    traitrange = sorted(list(set(self.data[lang][trait] for lang in self.config.languages)))
  File "/home/gereon/python/beastling/models/covarion.py", line 44, in <genexpr>
    traitrange = sorted(list(set(self.data[lang][trait] for lang in self.config.languages)))
KeyError: u'Afrikaans'

Instead, I think the default behaviour should be to early on test the overlap of the language sets, and – depending on a choice made in [language], I guess – incompatibility should lead to either an error being raised, or the union or intersection of available values being taken.

Unescape `'` in newick node labels when reading Glottolog trees

The ' in sub-group names in Glottolog Newick files is escaped as \'. This has to be taken into account when parsing the names.

Multiple config files with inheritance

Python's ConfigParser (and I presume clldutil's INI which we are using it's place) supports reading multiple config files, with subsequent files able to overwrite the values set by earlier ones. I've realised it would actually be fantastically powerful if beastling supported this for advanced cases. One could have a "master.conf" which defines languages, calibrations, models etc. and then say three clock files "strict.conf", "relaxed.conf", "random.conf". By running:

$ beastling master.conf strict.conf strict.xml
$ beastling master.conf relaxed.conf relaxed.xml
$ beastling master.conf random.conf random.xml

You could get three different versions of the analysis with different clocks. The advantage is that you can make changes to the languages, calibrations, models etc. in one place instead of three. Of course you could also fix the clock and have multiple different files for different substitution models, or whatever you want. You basically get all the power of multiple inheritance in OOP. I can certainly envision people having standard configuration components that they combine like Mixins.

This could also make our testing setup easier. Right now we have 33 different config files in tests/configs and 6 in tests/bad_configs/ in order to try various different combinations of settings (and we still don't have full coverage!). There is a lot of duplication across them and this will only get worse as things progress. If we could break the different chunks out separately and have the test script assemble different combinations this could cut down our growth rate of config files.

The only sticking point is that the command line syntax proposed above, i.e.:

$ beastling config_1.conf, config_2.conf, ...., config_n.conf, output.xml

does not seem to work smoothly with argparse (if the config file argument was given nargs="+", I believe it would also consume the output file argument). I'm not sure how best to proceed. I can see how to hack argparse to make this work, but it would result in the automatically generated usage message being less useful than it is now.

Thoughts?

Analyses with multiple models get multiple clocks which are not handled well

At the moment, if one specifies an analysis with two or more [model] sections, each model gets its own strict clock.

If branch lengths are being sampled and no calibration is provided, both clocks are fixed at 1.0. If Gamma rate variation is turned on, both models get their own Gamma distribution shape parameter, which can be fit independently, so if there is more rate variation in one data set than the other, everything works out in that department. However, the mean mutation rate is still assumed to be equal for both datasets, which may not be true.

If branch lengths are not being sampled and/or a calibration is provided, then both clocks are free to vary independently. This means that one data may have a higher mean mutation rate than the other if the data demands it, which is better than the above situation. But there is no restriction that the mean of all clocks be 1.0, which seems like it would be a natural thing to do - it's basically just a hierarchical version of within-dataset rate variation.

Embed files of families, features, etc. along with data

When data embedding is enabled, in addition to embedding the data files specified by data=, we should check whether anything else which could be a file (families, features, etc.) is a file, and if so, embed it too, otherwise the extracted config file will not work.

Adding multiple models to a config causes errors due to duplicated clock parameters in the statespace

When multiple [model] sections with different names are present in a config file, the clockRate parameter and associated things (priors, operators, etc.) are placed into the XML file twice, causing BEAST to error out.

The ideal solution to this has the user being able to easily choose between a single clock shared across all models, or independent clocks for each model.

IDs are not unique across models

Defining two different covarion models in my configuration file, I get

Error 104 parsing the xml input file

IDs should be unique. Duplicate id 'covarion_alpha.s' found

Error detected about here:
  <beast>
      <state id='state'>
          <parameter id='covarion_alpha.s' name='stateNode'>

IDs should always also contain the model name, I guess.

Fix situation with pruned trees and Random Local Clocks

When using PrunedTrees/PrunedAlignments for datasets with lots of missing data, non-strict clock models need special treatment to ensure that everything still works correctly. Joseph has written a PrunedRelaxedClock class, and BEASTling uses this when appropriate. However, no PrunedRandomLocalClock class exists yet. We should (i) first change BEASTling to switch off PrunedTrees for analyses with RLCs (and inform the user), and (ii) sometime in the nearish future write the PrunedRandomLocalClock class and get it in BEASTLabs.

python 2 + 3 support

It would be nice if BEASTling could be run with both python 2.7 and python >= 3.4.

Better logging

BEASTling should automatically log more details than it currently does, and logging policy should be driven by best practices for MCMC phylogenetics. For example, for every clade with a calibration prior, we should also log the age of that clade, so that when the analysis is run sampling from the prior, the interaction between the tree prior and the calibrations can be inspected.

We should log tree heights in all analyses where branch lengths are sampled.

If possible, random local clock analyses should log rate change locations, and if not possible we should write the Java code to make it possible.

Covarion model input handling

The documentation states:

Note that in order to use the Covarion model, you should not provide your data in binary format (i.e. do not use a .csv file full of 1s and 0s). Instead, provide your data in multistate format, i.e., in the case of cognate data one column per meaning slot, with values corresponding to cognate class membership. BEASTling will automatically translate this into the appropriate number of binary features. This approach means that you can have a single data file which can be used to generate binary and multistate analyses, and also lets BEASTling share mutation rates across binary features corresponding to a single meaning slot.

On the other hand, this does not allow me to use a covarion model where a meaning class can be represented by multiple cognate classes. It would therefore be nice to have the option to use either convention.

Configurations for BSVS models with rate variation do not run

Example error:

Error 170 parsing the xml input file

Could not find object associated with idref clockRate.c

Error detected about here:
  <beast>
      <run id='mcmc' spec='MCMC'>
          <operator id='BSSVSoperator.c:lexicon:a1' spec='BitFlipBSSVSOperator'>
              <input>

Enable continuous integration via travis-ci

We should use travis-ci to run the test suite upon each push to the repos. This will probably require mocking the beast calls. We could still have an option to run these tests locally, but removing the dependency on BEAST2 for tests may be a good idea anyway.

Write tutorial

...include example data.

Beast maximum chain length is 2^32

Beast stores chain length in an int, so its maximum value is 2^32 (maybe -1 or /2, for signs and zeros)
We should not permit bigger chain lengths to be written to xml, at least not without a warning.

XML creation somewhat broken on python 3.4

Just came across the following inconsistent behaviour of ElementTree.tostring in python 3.4:

>>> ET.tostring(ET.Element('a'), encoding='UTF-8')
b'<a />'

compared to python 2.7:

>>> ET.tostring(ET.Element('a'), encoding='UTF-8')
"<?xml version='1.0' encoding='UTF-8'?>\n<a />"

To workaround this issue, we may want to use ElementTree.ElementTree.write to serialize BeastXml more consistently.

Taxon sets of starting trees are not vetted for compatibility with data

The starting_tree= option in a [model] section allows the user to specify a starting tree. If the taxon set of that tree does not perfectly match the taxon set of the data (after applying family filters, throwing out languages with no data, etc.), then BEAST will not run the resulting analysis.

Ideally, BEASTling should extract the taxon set from a provided starting_tree and compare it against the data. If the data contains languages which are not in the tree, this pretty much has to be a fatal error.

If the starting tree contains languages which are not in the data set, but all languages in the dataset are present, ideally BEASTling should prune the starting tree to match. This facilitates, e.g, using published reference trees for large families with datasets which may not contain 100% of the languages in that family. This requires either writing a Newick parser, or becoming dependent upon an existing one (ete2?).

MCMC is the only config section with capital letters in it

MCMC is the only config section with capital letters in it. I forgot this and typed [mcmc] and wondered why my chain lengths were so small. This is inconsistent.

1. Make sure that the section [mcmc] works, maybe alternatively.
2. Warn the user when there were unused sections.
3. Bonus: Generally use pop or something when getting config properties, and check if they got all consumed, and warn about those that were not. I am not sure there is a reasonable way to do this, in particular given that new models might add new parameters, and we would not want to rely on model writers adding a del config.property in the right place. This would help with typos in other sections, as well.

Advanced clock handling

In addition to the current strict clock models, BEASTling should support uncorrelated relaxed clocks (in Exponential and Lognormal forms) and random local clocks. It should also be possible to specify different clocks of different types for different datasets. This is obviously going to involve overhauling the configuration format somewhat.

The most straightforward thing seems to be to add [clock ] sections, similar to how we currently have [model ] sections. Options within these sections can specify the kind of clock (strict, relaxed, random) and associated parameters. Models can specify which of the instantiated clocks to use with a "clock=" option, which refers to clocks by name.

Right now, the specification of clocks is entirely implicit, and each [model] section gets its own strict clock. For the sake of backward compatibility, we should leave this as is. However, as soon as a single [clock] section is introduced, we basically have free reign for defining new behaviour. One thing that I think would be nice is that if only a single [clock] section is specified, then that clock gets associated with all [model] sections, unless those sections have their own "clock=" option within them overriding this. This results in the minimum number of config lines for what I assume will be the most common situation (one clock shared across all models).

@xrotwang @Anaphory @SimonGreenhill Does this sound sensible to people?

Support for simulating data

(This is a long term "would be nice" kind of Issue)

BEAST has support for simulating datasets (via beast.app.seqgen.SequenceSimulator), however to my knowledge at the moment it is only possible to store the output in a Nexus file. My (quick and dirty) project harvest is a Python program which builds a BEAST XML file (actually, using old proto-BEASTling code), invokes BEAST with the nexus output saved in a temp file, parses the temp file and emits the data as an honest, God-fearing CSV file before deleting the tempfile.

A more correct approach would be to (1) expand SequenceSimulator to support CSV output directly and (2) integrate this into BEASTling, e.g. by allowing any config file to have "mode=simulate" or some such added to [admin]. We could make sure that the output CSV is in CLDF format.

Remove Bontok hack

There's a hack in configuration.py supposed to redo a wrong assignment of an ISO code in Glottolog. Bontok is assigned to the macrolanguage ISO code bnc, but BEASTling seems to insist on assigning it to the contained language Central Bontok lbk. This shouldn't be necessary, because Central Bontok is included in Glottolog 2.7 as well.

Generate reports

It would be nice if BEASTling, in addition to the basename.xml file containing a BEAST configuration, could optionally generate a human-readable basename.txt (or maybe even basename.pdf if the user had an optional dependency on some kind of PDF library) report on the analysis.

In particular, the final set of languages in an analysis is often very much implicit - it may be those languages in the intersection of multiple large data files, filtered by Glottolog family (and possibly soon Glottolog macro-area). The user may not actually know exactly which set of languages they are asking for an analysis of. A nice, neat summary listing details like the number of languages and the number of Glottolog families they come from, could be handy.

Set up docs on ReadTheDocs.

Easy to do and means that users don't need to run Sphinx.

https://read-the-docs.readthedocs.org/en/latest/getting_started.html

BEASTling uses non-standard Beast classes

BEASTling assumes classes like AlignmentFromTrait, PrunedTree or SVSGeneralSubstitutionModel are available, but does not tell me in the documentation that I should ensure certain packages need to be installed.

Automatically disable tree logging if the tree is known and fixed

If the user provides a known starting tree with starting_tree=, and sets sample_topology=False, and sets sample_branch_lengths=False, then a tree log file is just a waste of disk space, so we shouldn't produce one.

Read data from stdin, write xml to stdout

If beastling would read data from stdin and write the BEAST XML to stdout, configuration could be shared more elegantly, because no reference to a data file would be needed in the config. This would allow pipelines of the form

#!/bin/bash
for macroarea in africa papunesia
do
    csvstack -t Grambank/datasets/$macroarea/*.tsv | beastling grambank.conf > $macroarea.xml
done

BEASTling looks for data files relative to pwd, not to config file. Is that intended?

When I called beastling in a situation where the current working directory was different from the directory the configuration file was located, beastling complained about missing the data csv files. They do reside in the same directory as the config, and were specified only by filename (i.e. relative path).

Should doc/config.rst explicilty state that the data files are searched relative to pwd and not relative to the config file, or should they be relative to the config file no matter what cwd is? With the ability to read other values from files, I assume the former, because it permits reusing configuration files.

Option to include data files in XML?

Currently, BEASTling includes a copy of the configuration file in a comment block at the top of the produced XML. Perhaps we should add an option to also include a copy of the used CSV data files in the XML as well (probably off by default). If this is done, the XML file becomes completely self-contained. You could copy the included config and data files and paste them into separate new files and then make arbitrary changes to either. This is desirable for repeatability, peer-review, etc.

Error running BEAST 2.3.1 with xml created from tests/configs/basic.con

I created a BEAST XML file running

beastling tests/configs/basic.conf 

but BEAST 2.3.1 chokes on it, reporting:

Cannot create class: LewisMK. Class could not be found. Did you mean beast.core.Logger?

Error detected about here:
  <beast>
      <run id='mcmc' spec='MCMC'>
          <distribution id='posterior' spec='util.CompoundDistribution'>
              <distribution id='likelihood' spec='util.CompoundDistribution'>
                  <distribution id='traitedtreeLikelihood.model:f0' spec='TreeLikelihood'>
                      <siteModel id='geoSiteModel.model:f0' spec='SiteModel'>
                          <substModel id='mk.s:model:f0' spec='LewisMK'>

`language_column` is not removed as expected

I thought I had already adapted the code to remove the language_column from the data even when it is not called iso, but the issue is still there.

Support Glottolog releases

BEASTling should have support for Glottolog releases, i.e. it should be possible to specify a particular Glottolog release in the configuration from which to use the classification. The classification of the latest Glottolog release (or of all previous releases) available for a BEASTling release should be distributed with the BEASTling package, and specifying a more recent release should result in downloading the new classification, possibly to a BEASTling user cache dir.

Clock rate operator is not produced in analyses with fixed tree but no calibration

If no calibration points are provided, BEASTling locks the main clock rate to 1.0, on the logic that the tree can be scaled to make this work, and the branch lengths will then be in units of expected mutations per feature, which is nice.

This logic fails if a reference starting tree is provided with, say, branch lengths in units of thousands of years, and sample_branch_lengths is set to False. A user won't provide calibration points in this case (since the tree is known good and already has branches in years), so BEASTling will stick with a clock rate of 1.0, which may not be appropriate for the data.

Adding geography support

Now that non-strict clocks are looking largely complete, the next major functionality hurdle is to add support for geography to BEASTling.

The plan is for this to be largely powered by yet more integration with Glottolog, which will be able to provide a latitude/longitude point and a macro-area for a great many languages. Of course it should be possible for users to provide their own file of latitude/longitude points, but if no such file is provided then the default is to use Glottolog data.

I envisage two aspects to the geography support.

The first, which is fairly straightforward, is the ability to use geography for filtering the languages in an analysis. At the moment, we have the ability to specify a list of families by name or glottocode, and also the ability to just specify a list of languages. It would be great it filtering could also be achieved by supplying a list of macro-areas. I am open to further filtering support, e.g. filtering by Tsammalex ecoregion, or, even allowing the user to define their own latitude/longitude-based polygon shape to select languages from (assuming there is adequate and lightweight enough Python library support to make this possible), but filtering by macro-area should be quick and easy and so makes sense as a good first target.

The second is to actually add a phylogeographic component to the inference on whatever languages make it through the filter. It does not seem like this will be too hard to do once we have access to a list of latitude/longitude features.

As per the clock situation, I guess most of the planning/discussion which needs to happen is surrounding configuration.

It seems sensible to me that language filtering by macro-area should happen in the [languages] section, i.e. in the same place as all other filtering takes place. A simple macro-areas = option should get the job done.

As for adding phylogeography, a new [geography] section seems appropriate. I had imagined this containing a type= option to choose between spherical or planar diffusion (with BEASTling making the decision for the user based on the size of the region languages are spread over), however I've now been told that the planar model is never faster than the spherical model and there is essentially no reason to ever use it. So for now the only option that needs to be supported is a clock= option so that the geographic part of the likelihood can be associated with a clock, exactly as per the current handling of models. I imagine further options will certainly appear as support expands, though.

An open question is, if the user wants to specify their own file of location data, where should this be done? The information would be used for both language filtering (done in [languages]) and for phylogeography (done in [geography]), so there's some freedom in where it would go. I suppose [languages] makes the most sense - actually, it's the only thing that makes sense, as we want to support geographic filtering for analyses which don't actually have a phylogeographic component to the analysis (and hence have no [geography] section).

Does anybody know if there is a widely-used and supported standard file format for exchanging latitude and longitude data? Or, let me guess, there are seven such standards?

Calibration specification is too inflexible

I realised this while writing a test case for the calibration system. Currently calibrations can only be specified using Glottolog IDs. It would be nice if one could just provide a comma-separated list of taxa, e.g.:

[calibrations]
Indo-European = 5000 - 8000
foo, bar, baz = 4800 - 5200

Input file not found: coplains about lack of model section instead

When beastling cannot find the input config file, it does not say so. Instead, it complains that the given file does not contain a model section. If we can, we should distinguish those error messages.

beastling --extract is undocumented in --help

I just realised that there is no help text for beastling --extract (and some other, more obvious options) in beastling --help

Allow glottocodes in calibration specs

Specification of clades for calibration points should default to glottocodes, but clade names should also be recognized.

Test for lack of features

BEASTling will fail if the user specifies a "languages=" or "families=" setting which is so restrictive that there are no languages left. However, it will happily generate an output with a "features=" setting so restrictive that there is no data. Since we have support for explicitly sampling from the prior, cases such as these should fail loudly.

Add support for non-ISO language identifiers

At the moment, languages whose identifiers are not ISO codes are silently ignored by BEASTling. This is undesirable because lots of legitimate linguistic analyses involve languages without ISO codes (dialects, creoles, etc.), and because good data exists in the CLDF format which encourages the use of URLs as identifiers. So, we should accept non-ISO identifiers.

However, ISO codes facilitate all kinds of goodness, like the easy family selection and the monophyly features of BEASTling. So it's important to still recognise when data is using ISO codes and treat it appropriately.

Inconsistent naming of `monophyly` settings

To configure monophyly constraints, a setting monophyly or monophyletic can be specified (monophyletic is documented). But the additional settings monophyly_grip, etc. are not accepted in the monophyletic_* variant.

Add correlated=True/False option to RandomLocalClock

`monophyly_grip` setting does not work

Setting monophyly_grip to loose results in the following exception:

   xml = beastling.beastxml.BeastXml(config)
  File "/home/robert/venvs/beastling/BEASTling/beastling/beastxml.py", line 32, in __init__
    self.build_xml()
  File "/home/robert/venvs/beastling/BEASTling/beastling/beastxml.py", line 110, in build_xml
    self.add_prior()
  File "/home/robert/venvs/beastling/BEASTling/beastling/beastxml.py", line 140, in add_prior
    attribs["newick"] = self.make_monophyly_newick(glotto_iso_langs)
  File "/home/robert/venvs/beastling/BEASTling/beastling/beastxml.py", line 294, in make_monophyly_newick
    struct = self.make_loose_monophyly_structure(langs)
  File "/home/robert/venvs/beastling/BEASTling/beastling/beastxml.py", line 282, in make_loose_monophyly_structure
    return [[l for l in langs if point in self.config.classifications[l.lower()] ] for point in points]
TypeError: 'bool' object is not iterable

Support for data files in cldf format

It would be nice, if BEASTling could handle cldf data out-of-the-box, i.e. a matrix

iso    f1    f2    ...
abc    1     0    ...
cde    0     1    ...

would be encoded as

abc    f1    1
abc    f2    0
cde    f1    0
cde    f2    1