Many people have problems trying to install Avida in their computers. If you work on GNU/Linux (or Mac) you will not have any problems cloning Avida from the GitHub developers repository or from our GitLab repository (if you want to get our latest extensions). In contrast, people using Windows most likely will have to install Avida as a Docker image.

This a step-by-step guide to install the Ubuntu Docker image that we have previously built in our lab. We first describe the process of building and uploading the image into Docker Hub. Therefore,  you can skip the first two sections and go directly to the section "Downloading the image from Docker Hub" to learn how to install the image in your computer.

Building an Ubuntu image containing Avida:

We create the following file, named "Dockerfile", using a text editor:

FROM ubuntu:20.04 as avida-build
ARG DEBIAN_FRONTEND=noninteractive
WORKDIR /gitlab.com/fortunalab/
RUN apt-get update && apt-get install -y \
gcc-9 \
g++-9 \
cmake=3.16.3-1ubuntu1 \
make=4.2.1-1.2 \
git=1:2.25.1-1ubuntu3.5 \
curl \
&& update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 100 \
&& update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-9 100 \\ && git clone https://gitlab.com/fortunalab/avida.git
WORKDIR /gitlab.com/fortunalab/avida
RUN git submodule foreach git fetch
RUN git submodule update
RUN git submodule init
RUN ./build_avida

FROM ubuntu:20.04
WORKDIR /avida/
COPY --from=avida-build /gitlab.com/fortunalab/avida/cbuild/work/ .

Next, we  build the image by calling the docker file stored in our gitlab repository:

docker build https://gitlab.com/fortunalab/avida/-/raw/master/doker@images/avida/ubuntu/Dockerfile -t fortunalab/avida:2.15.ubuntu

The above code for the compilation reads the content of the "Dockerfile" and executes the following two steps:

First, a temporal image named "avida-build" is created. This temporal image is used to install the required tools, clone the Avida repository from GitLab and compile the Avida software platform.

Second, a smaller image named "fortunalab/avida:2.15.ubuntu" is created from a clean Ubuntu 20.04 image by adding only the compiled software.

Uploading the image into Docker Hub:

Docker Hub is the world's largest repository of container images with an array of content sources including container community developers, open source projects and independent software vendors (ISV) building and distributing their code in containers. Users get access to free public repositories for storing and sharing images or can choose subscription plan for private repos.

We have uploaded the docker image containing Avida into Docker Hub. First, we logged in Docker Hub:

docker login

Then, we pushed the image to our public repository in Docker Hub:

docker push fortunalab/avida:2.15.ubuntu

The image is available at Docker Hub

Downloading the image from Docker Hub:

Install Docker:

Before downloading the image, you should have Docker installed in your computer. Docker provides documentation for different operating systems to help you in this process.

Once Docker is installed, the daemon should be initialized and the process enabled to start on boot. We check that Docker is running by executing (you need root privileges to do it):

sudo systemctl status docker

In order to execute Docker without root privileges, you need to add your username to the docker group (by default, the docker command can only be run by the root user or by a user in the docker group):

sudo usermod -aG docker username

Now, we apply the new group membership by typing the following:

su - username

You need to log out and log back to that the group membership is re-evaluated:

Then, we check that your username is now added to the docker group by typing:

id -nG

Finally, we can view system-wide information about Docker by typing:

docker info

You might need to change the permissions in order to connect to Docker (e.g., Got permission denied while trying to connect to the Docker daemon socket ...):

sudo chmod 777 /var/run/docker.sock

Download the Docker image:

Now, we login in Docker Hub from the command line as username:

docker login

download the image by typing:

docker pull fortunalab/avida:2.15.ubuntu

and check that the image has been downloaded to our computer:

docker images

Running Avida from the Docker image stored in our computer:

docker run -it avida:2.15.ubuntu /bin/bash

Go to the Avida folder:

cd avida

Check the version of Avida:

./avida -version

We should see the following output:

Now, you are ready to run your experiments using Avida.

We have created a Pipeline for the R package avidaR which is launched every time we upload some changes to our GitLab remote repository (i.e., when a push command is executed from our local repository or a commit is sent from the GiLab graphical user interface). This Pipeline is defined here.

Pipeline.

The pipeline is organized in three independent stages:

• test: avidaR is installed from GitLab, tests are run on it, and the coverage test tool is executed. No artifacts are stored.
• build: the package is built without vignettes and manual, and the R CMD check is run. The package tar-ball is stored as an artifact for later downloads.
• check: CMD check --as-cran is executed. No artifacts are stored.

Monitoring.

We can take a look at avidaR repository --> main menu -> CI/CD -> Pipelines to monitor the Pipeline status.

If any o these stages is unsuccessfully executed, we can review it to get information about bugs or notes.

Otherwise we can continue developing and updating our source code as usual. This is useful to avoid checking our code manually every time we do an update, leaving to the end the task of checking it before submitting to CRAN.

The pipeline can be improved by publishing/sending the logs and reports to the maintainers for checking.

Note: By default, only 400 minutes of CPU execution are available for the pipelines in GitLab. When this time is reached, GitLab will suggest ... to buy more time.

Artifacts.

The tar-ball file of the package stored at the public folder during the building stage can be downloaded to install, check, or submit it to the CRAN repository.

Badges.

What are badges?

"Badges are a unified way to present condensed pieces of information about your projects. They consist of a small image and a URL that the image points to. Examples for badges can be the pipeline status, test coverage, latest release, or ways to contact the project maintainers ...".

Read here more about badges.

Pipeline status and code coverage percentage badges are populated with data extracted from the pipeline output logs created during execution.

Note: CRAN and Downloads badges are populate from the CRAN API. At the time of writing this document, avidaR package is still in development process and has not yet been sent to the CRAN repository.

Code.

In order to show the badges it in the README.md file, we have added the following code at the top of the document:

<!-- badges: start -->

[![pipeline status](https://gitlab.com/fortunalab/avidaR/badges/main/pipeline.svg)](https://gitlab.com/fortunalab/avidaR/-/commits/main) [![coverage report](https://gitlab.com/fortunalab/avidaR/badges/main/coverage.svg)](https://gitlab.com/fortunalab/avidaR/-/commits/main) [![Version on
CRAN](https://www.r-pkg.org/badges/version/avidaR?color=brightgreen)](https://cran.r-project.org/package=avidaR) [![Total downloads on
CRAN](https://cranlogs.r-pkg.org/badges/grand-total/avidaR?color=brightgreen)](https://cran.r-project.org/package=avidaR) 

<!-- badges: end -->

Settings

In the repository menu -> CI/CD -> Editor, add the keyword coverage and set its value:

Then, click on the Commit Changes button.

Finally, we browse/refresh the README.md file to check out that the coverage percentage is updated.

Note: Value coverage percentage is captured from the output generated by R -e 'covr::package_coverage()' command at test stage.

An ontology written in the OWL language is a bunch of definitions and their semantic relationships that a machine can read. Unfortunately, the content of an owl file cannot be easily visualized by humans. pyLODE is a python tool based on LODE that makes owl ontologies human-readable.

pyLODE converts an owl file into a html page where the IRIs, descriptions, domain and ranges of the classes, object properties, and datatype properties can be easily read and visualized.

We have customized the original templates provided by pyLODE to convert a scheme of our owl ontology OntoAvida in a html file (see screenshot above). You can find our customized templates at our gitlab repository.

The html description of the owl ontology can also include figures depicting the main relationships between the terms defined in the ontology (as below),

besides the IRI and description of the classes, as well as the domain and range the class is involved in (as shown here for the class digital organism).

Transforming the data into information and knowledge that can be understood by machines requires a semantic approach. Unfortunately, most scientists are unware of the Semantic Web effort. The Resource Description Framework (RDF) is a standard model for data interchange on the Web. The building block of the RDF model is the triple (subject - predicate - object) and this implies an atomic decomposition of your data in individual statements.

An RDF graph is a set of tiples or statements where both the subject and the predicate are resources (uniquely identified by URIs) and the object can be either another resource or a literal. There are two key characteristics of RDF stores (aka triple stores): the first and by far the most relevant is that they represent, store and query data as a graph. The second is that they are semantic,which means that they can store not only data but also explicit descriptions of the meaning of that data (i.e., ontologies).

Making the semantics of your data explicit in an ontology will enable data and/or knowledge exchange and interoperability which will be useful in some situations. In other scenarios, you may want to use your ontology to run generic inferencing on your data to derive new facts from existing ones. Another similar use of explicit semantics would be to run domain-specific consistency checks on the data.

In previous posts we have described a semantic model for scientific publishing (nanopublications) and a property graph database (Neo4j). This time we will introduce our work for extending the rdf4r library and accelerate the process of building, storing, and uploading thousands of RDF triples directly from the R programming language. This has been a great advance in developing and setting up our semantic graph databases in remote graphDB repositories.

rdf4r (extended) library for R.

We have extended the functionality of the rdf4r library, originally developed by Viktor Senderov for working with Resource Description Framework (RDF) data in the R programming environment, to improve performance when uploading lots of RDF triples into a graphDB triplestore hosted in a remote server. Please, see the original readme file for getting more details of the rdf4r library.

New functions added:

• add_triples_extended():
• serialize_to_file():
• add_trig_file_to_graphdb():
• ntriples():

add_triples_extended():

The function add_triples() included in the rdf4r original package takes huge amount of time adding triples to its internal dynamic vector. Time consumption increases exponentialy when thousands of triples are added, and resizing the dimension of the dynamic vectors does not help. Our new function add_triples_extended() creates instead a list of dynamic vectors by adding them to the list every time the function is called on the same RDF object. It also skips some data processing that are not required when data are well-curated in the source dataframe (i.e., before adding triples to the RDF object). Therefore, using our new function add_triples_extended() accelerates the proccess of adding thousands of triples.

The function takes a dataframe as input data and iterates throught its rows to build the triples. Then, it adds the triples to the RDF object using only a single instruction. In addition, a progress bar is shown by default during the process of adding triples, although it can be hidden by setting param progres_bar = FALSE.

The predicate of the triples is defined once for all triples that will be added to the RDF object, using an identifier before calling the add_triples_extended() function. To build the subject and the object of the triples from each row of the dataframe, different rules will be applied to the add_triples_extended() function depending on the values of the following parameters:

• WHEN subject_column_label = "" AND subject_column_name != "", THEN subject = identifier(id = subject_column_name, prefix = subject_rdf_prefix)
• WHEN subject_column_label != "" AND subject_column_name != "", THEN subject = identifier(id = paste0(subject_column_label, subject_column_name), prefix = subject_rdf_prefix)
• WHEN subject_column_label != "" AND subject_column_name = "", THEN subject = literal(text_value = subject_column_label)
• WHEN subject_blank = TRUE THEN subject = identifier(id = paste0(subject_column_label, subject_column_name), prefix = NA, blank = TRUE)

The objects of the triples are build in the same way but replacing subject by object in the above rules.

example:

# define a RDF object:
rdf_infects <- ResourceDescriptionFramework$new()
    
# define the prefixes:
prefixes <- c(
   rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
   rdfs = "http://www.w3.org/2000/01/rdf-schema#",
   owl = "http://www.w3.org/2002/07/owl#",
   phageon = "http://owl.fortunalab.org/phageon#",
   obo = "http://purl.obolibrary.org/obo/"
)

# phageon prefix:
phageon <- prefixes[4]

# read data from a file and store them as a dataframe:
phage_host <- read_csv("phage_host_db.csv", col_types = cols(phage_taxid = col_character(), host_taxid = col_character()))
  
# define the predicate:
infects <- identifier(id = "PHAGEON_0000001", prefix = phageon)
  
# define the subject and object while building and adding the triples from the data frame:
rdf_infects$add_triples_extended(
   data = phage_host,
   subject_column_label = "NCBITaxon_", subject_column_name = "phage_taxid", subject_rdf_prefix = phageon,
   predicate = infects,
   object_column_label = "NCBITaxon_", object_column_name = "host_taxid", object_rdf_prefix = phageon
)

serialize_to_file():

The function serialize() from the original rdf4r package takes a huge amount of time serializing thousands of triples. Our new function serialize_to_file() iterates through the list of dynamic vectors built previously to extract the triples and store them into a trig output file, skiping some data processing that are not required. Therefore, using our new function serialize_to_file() accelerates the proccess of saving the triples into trig files. In addition, a progress bar is shown by default during the process, although it can be hidden by setting param progres_bar = FALSE.

example:

# set the context (for named graphs):
rdf_infects$set_context(identifier(id = "phageon", prefix = phageon))

# serialize RDF object to file:
rdf_infects$serialize_to_file("rdf_infects.trig")

add_trig_file_to_graphdb():

Our new function add_trig_file_to_graphdb() retrieves the triples stored in a trig file and inserts each triple into an element of a list. Then, this list is imported to graphdb using the rdfr4::add_factory() function from the original package.

example:

# set the graphdb access options to the repository:
graphdb = rdf4r::basic_triplestore_access(
   server_url = "http://your_graphdb_url/",
   user = "your_username",
   password = "your_password",
   repository = "graphdb_repository_name"
)
# import the trig file:
rdf4r::add_trig_file_to_graphdb(graphdb_access_options = graphdb, prefixes = prefixes, trig_file = "rdf_infects.trig")

ntriples():

Our new function ntriples() returns the number of triples added to the RDF object using the add_triples_extended() function.

example:

# build the sparql query to retrieve the triples:
query = "
   PREFIX phageon: <http://owl.fortunalab.org/phageon#>
   SELECT ?s ?p ?o
   WHERE {
      GRAPH phageon:phageon {
         ?s phathe:PHAGEON_0000001 ?o .
         ?s ?p ?o
      }
   }
"

# submit the query to the graphdb repository:
n_inserted_triples <- rdf4r::submit_sparql(query = query, access_options = graphdb)

# check and show results:
cat(paste0("Number of triples inserted: ", rdf_infects$ntriples(), "\n"))
cat(paste0("Number of triples retrieved from the triplestore: ", nrow(n_inserted_triples)), "\n")
n_inserted_triples %>% head

New data types added:

Some missing XSD data types have been added:

• xsd_double
• xsd_boolean

Installation.

devtools::install_git("https://gitlab.com/fortunalab/rdf4r.git")

Source code.

The extended rdf4r library was developed by Raúl Ortega.

We have failed to store and organize much of the rapidly accumulating scientific information in rigorous, principled ways, so that finding what we want and understanding what is already known become exhausting, frustating, stressful and increasingly costly experiences. For information to be usable, it must be stored and organized in ways that allow us to access it, to analyze it, to annotate it and to relate it to other information. Only then can we begin to understand what it means. Only with the adquisition of meaning we adquire knowledge.

Nanopublications are a Linked Data format for scholarly data publishing that has received considerable uptake in the last few years. We briefly explain here an approach to use and link nanopublications as a unifying framework to represent knowledge in a semantic way.

A nanopublication is a single publishable and citable entity that combines an assertion, the provenance of the assertion, and the provenance of the nanopublication. This information can be about anything, for example a relation between a gene and a disease. Nanopublications are fully expressed in a formal and machine-interpretable way, making scientific communication more effective and user-friendly. Furthermore, because nanopublications can be attributed and cited, they provide incentives for researchers to make their data available in standard formats that drive data accessibility and interoperability.

We illustrate here the uniqueness of the nanopublication-based scheme by representing three instances of the class Nanopublication, two instances of the classes Provenance and PublicationInfo , and one instance of the classes Assertion, Subject, Predicate and Object.

Nanopublications are identified by their URIs, that it, by pointing the address where the file is stored. Many nanopublications can share the same Assertion (e.g., the one identified by the following statement: "Escherichia coli is resistant to ampicillin"). However, they can only share a second class: either the Provenance of the assertion, e.g., the one identified by the PubMed ID 16562043 (i.e., a research paper published  in 1965 in Journal of Bacteriology) or the PublicationInfo, e.g., the one identified by the ORCID 0000-0002-8374-1941 (i.e., the author of the nanopublication).

This means that more than one author (uniquely identified by his/her ORCID) can report the same assertion from the same provenance (e.g., a research paper), and the same author can report the same assertion from different provenances (e.g., distinct research papers). In fact, this is something good and desirable to happen.

Let's focus now on the instance of the Assertion class to understand how a collection of nanopublications, as the one shown in the above illustration, becomes a knowledge graph.

The instance of the class Assertion identified by the statement: "Escherichia coli is resistant to ampicillin" is a RDF graph (i.e., a triple consisting on a Subject, Predicate and Object).

The instance of the class Assertion takes its identifier (i.e., statement) by combining the three identifiers (id) of the instances of the classes it is linked to. If two instances of the class Assertion have the same identifiers for their Subject, Predicate and Object instances, the assertions will be linked by a synonymous relationship, regardless of the statement identifiers of the assertions (i.e., the same researcher might extract the same claim from the same publication but write it down in a slightly different natural language).

In RDF, the Subject of this triple is the URI of the taxon "Escherichia coli" (defined in the NCBI Taxon ontology ) the Predicate is the URI of the term "resistant to" (defined in the Ontology of Microbial Phenotypes), and the Object is the URI of the antibiotic "ampicillin" (defined in the NCI Thesaurus).

The instance of the class PublicationInfo identified by orcid: 0000-0003-3974-6515 is, in fact, another RDF graph (i.e., a triple consisting on a Subject, Predicate and Object).

The Subject of this triple is the URI of the nanopublication, the Predicate is the ORCID, and the Object is the literal containg the value of the ORCID.

All resources in a triple (here, only the Subject and the Predicate) are represented in RDF by their URIs (they were meant to be read by machines). That's why the Predicate contains URI: http://purl.obolibrary.org/obo/APOLLO_SV_00000496 instead of ORCID. The Semantic Web encourages the use of URIs as names of things to use a common vocabulary, pointing at places where the meaning of the terms are clearly defined. The term ORCID, is defined in the Apollo Structured Vocabulary (Apollo-SV) ontology.

When the Object of a triple is not a resource (which means it cannot be the Subject of any triple), the datatype of the literal is indicated. We use here the XML Scheme Definition (http://www.w3.org/2001/XMLSchema) to indicate that the ORCID value is a string.

In natural language, this PublicationInfo triple reads: "This nanopublication was created by Carlos J. Melián".

Likewise, the instance of the class Provenance identified by pmid:336612 is, in fact, another RDF graph (i.e., a triple consisting on a Subject, Predicate and Object).

The Subject of this triple is the statement of the assertion, the Predicate is the URI of the PubMed ID term (i.e., pmid is defined in the EDAM Ontology), and the Object is the literal containg the value of the pmid (in this case, a research paper published in 1977 in Journal of Bacteriology).

In natural language, this Provenance triple reads: "The statement Escherichia coli is resistant to ampicillin was extracted from a publication having PubMed ID = 336612".

In summary, we should make published scientific literature more machine-readable, and hence more dynamic and informative. Nanopublications are a way of annotate semantically the scientific literature to understand the meaning of the published information and enable the linking to related documents.

Should peer review stop being anonymous? Inspired by Arthur Schopenhauer’s "On authorship and style", I now sign my reviews. Below are some excerpts on anonymity in literary journals from this memorable essay.

Above all, that shield of literary knavery, anonymity, would therefore have to be discarded. It was introduced into literary journals on the plea of protecting the honest reviewer, the monitor of the public, from the pique and animosity of the author and his promoters. But for one such case there will be a hundred where it merely serves to absolve from all responsibility the man who cannot back up what he says, or even to hide the shame of the person who, for a financial consideration from the publisher, is mercenary and mean enough to recommend to the public an inferior book. It often serves also to conceal the obscurity, insignificance, and incompetence of the critic. It is incredible to see the audacity of the fellows and the sharp practices at which they do not shrink when they know they are safe under the cover of anonymity. Just as there are universal medicines, so is the following a universal anti-critique against all anonymous reviewers, it matters not whether they have praised the bad or censured the good. Your name, you scoundrel! For to mask and disguise yourself and to attack those who go about undisguised is not the act of an honourable man, but of knaves and rascals. Therefore your name, you scoundrel!  probatum est.

It should at least be conditioned by a prohibition of every kind of anonymity and pseudonymity, so that everyone might be held responsible, at least with his honour if he still has any, for what he publicly proclaims through the far-reaching trumpet of the press, and also that, if he is without honour, his words might be neutralized by his name. It is obviously dishonourable to attack anonymously those who have not so written. An anonymous reviewer is a fellow who will not stand by what he tells to, or conceals from, the world concerning other people and their work and who, therefore, withholds his name. And is anything like this tolerated? No lie is so shameless that an anonymous reviewer will not venture to use it; indeed he is not responsible. All anonymous reviewing aims at falsehood and imposture. Therefore just as the police do not allow us to walk about the streets in masks, so should they not tolerate anonymous writing. Anonymous literary journals are the very place where ignorance with impunity sits in judgement on scholarship, and stupidity on intelligence, and where the public is deceived and through the praise of inferior work is cheated of its time and money, again with impunity. For is not anonymity the stronghold of all literary, and especially publicist, rascality? It must, therefore, be pulled down to the very ground, in other words, so that every article in a journal shall always be accompanied by the name of the author and the editor shall accept the heavy responsibility for the correctness of the signature. Since even the most insignificant man is known in the place where he lives, two-thirds of the lies in journals would thus disappear and the audacity of many a venomous tongue would be kept within bounds.

But as long as that prohibition does not exist, all honest authors should unite in  proscribing anonymity by publicly branding it with the mark of their utmost contempt, daily and hourly expressed. They should make it known in every possibleway that anonymous reviewing is contemptible and dishonourable. Whoever writes and carries on a controversy anonymously, is eo ipso presumed to be trying to deceive the public or to injure the reputation of others without risk to himself. And so whenever we speak of an anonymous reviewer, even when we do this quite incidentally and do not otherwise find fault with him, we should use only such expressions as: ‘the cowardly, anonymous rogue at such and such a place’, or ‘in that periodical the masked, anonymous scoundrel’, and so on. This is really the right and proper tone in which to speak of such fellows in order to put them out of conceit with their business. For obviously everyone can claim some personal consideration only in so far as he enables us to see who he is, so that we know with whom we are dealing, but not the man who slinks around disguised in a mask, and who is then pert and saucy. On the contrary, such a man is ipso facto proscribed and outlawed. [...] We should, therefore, at once call every anonymous reviewer a knave and a cur, especially in anti-critiques, and not talk of the honoured and respected reviewer, as do some of the pack of defiled authors through cowardice. ‘A cur who withholds his name!’ must be the cry of all honourable authors. And now if anyone distinguishes himself by removing the mist-cap from such a fellow who has run the gauntlet, and by seizing his ear and dragging him forward, then the night-owls will be delighted to see such sport. When a slander comes to our ears, the first outburst of indignation is usually the question ‘Who said that?’ But anonymity returns no answer.

Arthur Schopenhauer. Parerga and Paralipomena (volume 2). Oxford University Press. 1974 (translated from the German Parerga und Paralipomena (1851) by E. F. J. Payne). (https://archive.org/details/23341891SchopenhauerParergaAndParalipomenaV2/page/n517/mode/2up).

As I said in a previous post, we work in the cloud. Our data and the software required to analyze them are stored in our Meerkat System76 server. We do not need powerful desktop computers, just single connection points in the cloud. Our server will do the hard work.

You might heard of the Raspberry Pi, a credit card sized single board computer. The latest Raspberry Pi 4 is based on a new processor called the BCM2711, a system-on-a-chip that integrates a 64-bit 1.5 GHz Quad-Core (ARM v8) CPU and up to 8 GB of  SDRAM. Local storage is provided via a ScanDisk memory card slot on board.

The power consumption of a single Raspberry Pi 4 is slightly less than 5W at full speed: all cores at 100%. It runs the Raspbian operating system, an optimized version of the Debian GNU/Linux distribution (you can download a pre-loaded image from the Raspberry Pi Foundation).

This is the list of what you need to build a connection point to your server:

• Raspberry Pi 4 Model B
• Raspberry Pi Keyboard & Hub
• Raspberry Pi Mouse
• Raspberry Pi 15.3W USB-C Power Supply
• Raspberry Pi 4 Case
• Raspberry Pi NOOBS - Preinstalled Micro SD Card (64 GB)
• Heat Sink Raspberry Pi 4
• Micro HDMI to Standard HDMI (A/M) Cable (2 units)
• Dell Ultrasharp U2719DX 27-Inch WQHD 2560x1440 (2 units)

We'll start by placing the four pieces of aluminium heatsinks (CPU, memory, chipset USB, and chipset Ethernet).

It will look like this:

Next, we will insert the Raspberry Pi 4 into the case:

After connecting the keyboard, mouse, Ethernet, and the power supply, we will connect the Raspberry Pi 4 to the two Dell monitors:

We will rotate the monitors and install Raspbian from the NOOBS micro SD card.

And this is how our desktop computer looks like:

In our lab we do not need powerful computers for our team, just what you see here: a silent, energy-efficient, and dual display workspace.

The lack of a clearly defined vocabulary makes biologists feel reluctant to embrace the field of digital evolution. The Ontology for Avida (OntoAvida) project is developing an integrated vocabulary for the description of the most widely used computational approach for performing experimental evolution on digital organisms (i.e., self-replicating computer programs that evolve within a user-defined computational environment).

In this post, I show briefly how this project has started.

The Ontology Development Kit (ODK), from the OBO Foundry, provides a way of creating an ontology project ready for pushing to GitHub. Just to illustrate the goal of the OBO Foundry, in this site you will find a table of ontologies, available in several formats, with details for each, and documentation on OBO Principles. Please, take a look at some of them and you realize the huge effort of ontology developers to add semantics to the biomedical and biological scientific fields.

We will use Docker to install the Ontology Development Kit from the GitHub repository.

We first create a new folder for storing our ontology:

mkdir ontology@avida

Then, we pull the software to the newly created folder:

cd ontology@avida
docker pull obolibrary/odkfull

Next, we download the wrapper script that will configure the source tree directory for the ontology:

wget seed-via-docker.sh

We need to make this script executable by changing the permissions and by allowing it to access the Docker sock:

chmod 755 seed-via-docker.sh
chmod 777 /var/run/docker.sock

We customize the project.yaml file that was downloaded along the ODK to the ontology@avida folder (i.e., edit the file using, for example, the nano editor), by adding the following:

id: ontoavida
title: OntoAvida
github_org: fortunalab
repo: ontoavida

Then, we run the wrapper script (make sure you have Docker running):

./seed-via-docker.sh -C project.yaml

After changing the permissions to access the source tree directory:

sudo chown -R yourusername:yourusername target
cd target/ona

we have all we need to start developing the ontology under the OBO Foundry guidelines.

To make the ontology available to the scientific community, we create a repository in GitLab (OntoAvida, as we specified it in the project.yaml file):

We push the project to GitLab:

git remote add origin git@gitlab.com:fortunalab/ontoavida.git
git push -u origin master

Now, everybody can access the ontology tree directory and the ontology OWL file ontoavida.owl.

Please use this GitLab repository's Issue tracker to request new terms/classes or report errors or specific concerns related to the ontology.

The Ontology Web Language (OWL) was not designed to be read by humans but by machines (i.e., we are adding semantics to data). That's why the ontoavida.owl file is not reader-friendly. There are software applications specifically developed to visualize and edit owl files. The most widely-used open-source ontology editor is called Protégé, developed by the Stanford Center for Biomedical Informatics Research at the Stanford University School of Medicine.

You can freely download Protégé and then open the ontology file ontoavida.owl to visualize the Classes, Object Properties, and Datatype Properties currently added to the Ontology for Avida.

I hope you enjoy it.

DataCite is an international not-for-profit organization which aims to improve data citation.

Although DataCite members can assign digital object identifiers (DOIs) to data sets, you do not need to be a DataCite member to get a reference from a DOI appropriately formatted to the journal you are planning to submit your manuscript.

Scroll down to Get started with DataCite:

Click on Generate your references automatically ... and you will be redirected to the main search page:

Paste your DOI, select the formatting style, and click on Format:

For example, for the formatting style of the journal Ecology, the reference corresponding to that DOI will read as:

Then, you can copy and paste the bibliographic reference in the reference list of your manuscript.

Quite easy, isn't it?

Sometimes you change the location of a shared file in your server for technical reasons. When this happens, the link to the shared file you provided to others (e.g., by email or embedded in a document) does not work anymore and shows a 404 error. PURLs (persistent uniform resource locators) are an approach to fixing the problem of unstable URLs (uniform resource locators).

A PURL is a persistent URL, it provides a permanent address to access a resource on the web. When a user retrieves a PURL they will be redirected to the current location of the resource. When an author needs to move a page or file they can update the PURL to point to the new location.

This post covers how to create and use a PURL that you can share with your colleagues.

The PURL system is a service of the Internet Archive.

To create and update a PURL, you need to have a user account with the Internet Archive.

You will be prompted to enter your email and create a password.

Once you sign up, they will send you a link you will need to click on to validate the registration process.

Now you can login with your email and password.

You will be returned to the PURL Administration page.

URLs are grouped into domains that can be searched from the home page.

Let's create a domain that will host your URLs.

Now it's time to create the PURLs that will point to your URLs.

The PURL resolution service associates the PURL with the actual URL and returns that URL to the client as a standard HTTP redirect.

Since the Internet Archive has taken full control of PURLs, we will not use the service shown above, instead, we will go to its website and login our account:

We see our recently created domain /fortunalab. We click on it:

It's empty right now. We click on Edit (top-left corner):

Now, we click on change the files (next to the butterfly):

Finally, we select Add a file to upload it.

We see now one comma-separated values file (on the right) pointing to the following address: https://archive.org/download/purl_fortunalab/avida_genbank.csv and a torrent download available at the following address: https://archive.org/download/purl_fortunalab/purl_fortunalab_archive.torrent\

You can share that link with your colleagues.

That's it!

Docker Hub is the world's largest repository of container images with an array of content sources including container community developers, open source projects and independent software vendors (ISV) building and distributing their code in containers. Users get access to free public repositories for storing and sharing images or can choose subscription plan for private repos.

We start by creating an account:

Then, we login in Docker Hub:

We search for the required image (in our case, the phamdb image created by James Lamine):

Click on the image name to see more details:

Now, we are going to download the image. We first login in our account from the command line:

docker login

Second, we download the phamdb image created by James Lamine:

docker pull jglamine/phamdb

We will solve the warning we have received: "Image docker.io/jglamine/phamdb:latest uses outdated schema1 manifest format. Please upgrade to a schema2 image for better future compatibility".

From the above link, we can read: "One way to upgrade an image from image manifest version 2, schema 1 to schema 2 is to docker pull the image and then docker push the image with a current version of Docker. Doing so will automatically convert the image to use the latest image manifest specification".

We start by getting the ID of the image we just downloaded:

docker ps -a

Then, we tag the jglamine/phamdb image:

docker tag d4f0e6e9d45b fortunalab/phamdb:schema2

After tagging the image, we push it to our repository:

Before pushing, you might need to logout, then log in from the command line to your docker hub account.

docker push fortunalab/phamdb:schema2

The image is now stored in our DockeHub account:

We pull the image from our remote public repository to our local server:

docker pull fortunalab/phamdb:schema2

We see that we do not receive that warning anymore.

That's it.

Docker is a software platform for deploying applications in resource-isolated processes. Docker runs processes in isolated containers. Containers isolate applications at the process level and use the host's kernel instead of virtualizing an entire operating system. The host does not care about what is running inside the container and the container does not care about which host it is running on. In short, they are similar to virtual machines, only more resource-friendly.

In this post we'll install Docker and pull a Docker image.

Install Docker.

We install Docker from the official Docker repository to ensure we get the latest version.

First, we'll add a new package source:

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add

Second, we add the GPG key from Docker:

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

Third, we update the package database with the Docker packages from the newly added repo:

sudo apt update

Make sure we are about to install from the Docker repo instead of the default Debian repo:

apt-cache policy docker-ce

Finally, we install Docker

sudo apt install docker-ce

Docker should now be installed, the daemon started, and the process enabled to start on boot. We check that it's running:

sudo systemctl status docker

The output should be similar to the following, showing that the service is active and running:

Once we have Docker installed, we can use the docker command line utility (i.e., the Docker client).

We add the user username to the docker group (by default, the docker command can only be run by the root user or by a user in the docker group):

sudo usermod -aG docker username

Now, we apply the new group membership by typing the following:

su - username

We check that our user username is now added to the docker group by typing:

id -nG

We can view system-wide information about Docker by typing:

docker info

We might want to change the root directory /var/lib/docker (i.e., the location of the Docker files) to another directory because we ran out of disk space in /var. To do this, we create the file /etc/docker/daemon.json and populate it with:

{
    "data-root": "/new/docker/root"
}

Then, we restart the daemon:

systemctl daemon-reload
systemctl restart docker

We now check that the the root directory has been updated by typing:

docker info

Install a Docker image: Ontology Development Kit (ODK) as an example:

The Ontology Development Kit (ODK) provides a Docker image that helps you in the process of creating OBO ontologies.

We download the image by typing:

docker pull obolibrary/odkfull

We check that the image has been downloaded to our server:

docker images

We check that a container ID (e3044811f2f0, in this case) is running the image obolibrary/odkfull by listing the containers that are running in our server:

docker ps

or we might want to list all the containers (i.e., the started and the stopped ones):

docker ps -a

We can remove a container (e.g. e3044811f2f0) we do not need anymore by typing:

docker rm e3044811f2f0

That's it!

Zenodo is a general-purpose open-access repository developed under the European OpenAIRE program and operated by CERN . It allows researchers to deposit data sets, research software, reports, and any other research related digital material. For each submission, a persistent digital object identifier (DOI) is minted, which makes the stored items easily citeable.

We will illustrate this process by creating a release of a repository stored in our GitHub account, uploading a copy into Zenodo, and using the DOI provided by Zenodo in our manuscript before submitting it to a scientific journal.

This is the repository we are going to upload to Zenodo:

Let's start. Go to the Zenodo website:

Now, Log in to your account or Sign up if you do to not have registered in Zenodo yet.

Once you log in, go to GitHub:

Note that you need to authorize Zenodo to connect to your GitHub account in the GitHub section. Zenodo will redirect you to GitHub to ask for permissions to use webhooks on your repositories.

Then, enable the repository (from OFF to ON):

Click on the recently enabled repository.

Next, we are ready to create a release for that repository (click on Create release and we will be redirected to the GitHubrepository). If we didn't do it before, the following screen will show up:

Click on Create a new release:

After adding a version name, title, and a short description of the release, click onPublish release:

Zenodo will automatically download a .zip ball of the new release and register a DOI.

Click on it to see more details of the release just created.

The directory structure will show up as it is stored in your GitHub repository.

That's it. You can now add the following sentence when submitting the manuscript to the journal:

The data reported in this paper and the code to perform the analyses have been archived on Zenodo: https://zenodo.org/badge/latestdoi/192325725.

In the previous post we briefly introduced the Avida software platform for the study of evolution. Here, we will learn to work with parasites within this computational tool. Parasitic digital organisms are almost identical to the hosts, and as such they self-replicate by copying their genome instruction by instruction into a new memory space. But they operate inside hosts, stealing CPU cycles from them to execute their own genome’s instructions and, hence, reduce their host fitness.

Digital coevolution between hosts and parasites resembles, at some level, the coevolutionary dynamics among bacteria and phages (ie.,. viruses that infect bacteria). On the one hand, bacteria must have receptors on their surface in order to import resources from their environment. On the other hand, phages must attach to those receptors in order to infect bacteria. Therefore, a trade-off exists between having receptorsf or obtaining nutrients and being susceptible to phages.

Coevolutionary dynamics results from bacteria evolving phage resistance by changing their surface receptors, and from phages countering bacteria resistance by altering their tail fibres to attach to the novel receptor.

Analogously, digital hosts must compute logic operations to consume resources and thus replicate, but those traits leave them susceptible to infection by digital parasites.

Installation.

We need first to install git  (see how to do it from JuptyterLab).

Then, from the devosoft/avida development account on github

we get the repository after setting-up git  from the command line:

mkdir git_avida # create folder
cd git_avida # go to folder
git init # initialize git repository (it creates a subfolder named .git)
git clone https://github.com/devosoft/avida # get repository

and, finally, we follow the instructions:

cd avida
git submodule init
git submodule update

We then compile and install Avida:

./build_avida

Of course, we can do it from JuptyterLab as well:

Configuration.

After a successful installation, we will have the following directory structure:

We go to cbuild and then to work

The work folder contains the configuration files *.cfg and the executable file avida.

The  avida.cfg file is the main configuration file for designing an experiment.

It's a text file containing many options along with a description of what each one does and what its parameters are.

In order for Avida to work with parasites, we need to change the instruction set that is going to be used in the experiment. That is, the genetic language for digital organisms (analogous to the four nucleotides for biological organisms). By default, the genome of a digital organism is made of instructions taken from the set of 26 instructions specified in the file instset-heads.cfg (you can also see the instset-heads-sex.cfg file in the folder, which is used in experiments in which recombination between organisms is allowed). Parasites and their hosts work under a different instruction set, instset-transsmt.cfg. This 33-instruction set contains the instruction Inject that, when executed, is used for the parasite to infect its host. Do not forget to change this! It's the only option we're going to modify by editing the avida.cfg file directly. We will set the configuration options when running Avida from the command line.

There are many ways for a digital organism to mutate,

many demographic parameters to be set,

and many options for them to interact with the environment.

The PARASITE GROUP options are the ones required for setting up parasites.

You can get more information on how parasites work in Avida from his developer, Luis Zaman.

If the instset-transsmt.cfg file provided by default looks like the one below,

please, replace it by this one (the instruction Inject should be there, as well as Divide-Erasethat is used to produce offspring under this instruction set):

You can see the meaning of the 33 instructions contained in the instset-transsmt.cfg from our repository.

The environment.cfg file contains the options that will allow digital organisms to get extra CPU cycles (and hence self-replicate faster) when computing Boolean functions.

We will replace the content of the default environment.cfg file as follows:

We specify a single resource that will limit population size (first line). Parasites and hosts will take a unit of resource (if available) the first time they compute a Boolean function (any of the 9 functions defined here: NOT, NAND, AND, ORN, OR, ANDN, NOR, XOR, and EQU) by manipulating—with the instructions they may harbor in their genomes—32-binay numbers that the take from the environment. If they do not perform any Boolean function, or if there are not resources available in the environment, the digital organisms will fail when producing offspring.

We do not reward digital organisms with extra CPU cycles for computing Boolean functions. Then, there are no fitness differences between organisms encoding different phenotypes (i.e., computing different Boolean functions): the only selective pressure will come from the antagonistic interactions between hosts and parasites.

The envents.cfg file contains many options to specify the kind of data we want to get from the experiment and when we want them. Below, you can see an example that illustrates many more options that the one we will use here.

The content of our envents.cfg file will be the following:

A host population will grow and evolve, from a single ancestor, in the absence of parasites until a single parasite ancestor is introduced at time 5000 (after approximately 100 host generations, for this particular host ancestor). The experiment will last until time 500000 (approximately, 10000 host generations).

You can choose any of these 30 hosts and 15 parasites as ancestors to perform your our coevolutionary experiments:

The genome of one of these hosts looks like (100 instructions):

Same for parasites:

Execution.

We run Avida from the command line, or from a bash notebook in JupyterLab, as:

./avida -set DATA_DIR data_coevo -set WORLD_X 100 -set WORLD_Y 100 -set COPY_MUT_PROB 0 -set DIVIDE_INS_PROB 0 -set DIVIDE_DEL_PROB 0 -set OFFSPRING_SIZE_RANGE 1 -set MIN_COPIED_LINES 0 -set MIN_EXE_LINES 0 -set REQUIRE_EXACT_COPY 1 -set STERILIZE_UNSTABLE 1 -set HARDWARE_TYPE 2 -set BASE_MERIT_METHOD 2 -set DEATH_METHOD 1 -set AGE_LIMIT 3000 -set MAX_CPU_THREADS 2 -set PARASITE_VIRULENCE 0.9 -set PARASITE_NO_COPY_MUT 1 -set INJECT_METHOD 1 -set REQUIRE_SINGLE_REACTION 1 -set DIVIDE_MUT_PROB 0.025 -set INJECT_MUT_PROB 0.01

We have modified many options of the configuration file  avida.cfg by adding set - option when calling Avida.

You will see the following output after running the above command in JupyterLab

or in a terminal:

The total number of hosts Orgs: and parasites Para: will change over time as a consequence of the ecological and coevolutionary dyamics.

One the experiment is over, we will ge the following directory structure:

We briefly explain what those files tell us. We start with the file grid_task_hosts.500000.dat

Each number represent the phenotype (i.e., a unique combination of the Boolean functions that a digital organism performed) of the  host organism that was living at that time (i.e., 500000, that is, the end of the experiment) in that memory cell within the 100x100 grid (defined by the WORLD_X and WORLD_Y options).

The number -1 indicates that that particular memory cell was empty at that time (i.e., there was no organism living there).

The phenotype of the organism living in a particular memory cell can be obtained by converting the number into the vector of the Boolean functions as (e.g., 4):

Same for the file grid_task_parasite.500000.dat Here, the parasite lives in the same memory cell where its host is living. It cannot be located in an empty memory cell: -1 in the grid_task_hosts.500000.dat

The file host_genome_list.500000.dat contains the genomes of each host organism whose phenotype was described above.

Note that the genomes of all host organisms contain the instruction G  (i.e., the one required to produce an offspring Divide-Erase).

Same for the parasite_genome_list.500000.dat file. Parasite genomes are shorter than host genomes (for this particular experiment).

Here, all parasite's genomes contain the instruction F (the one required to infect a host Inject).

The host_tasks.dat file contains the number of host organisms performing each Boolean function. Note that this is not the number of hosts whose genomes encode a distinct phenotype (i.e., a host organism can perform more than one Boolean function).

Same for the parasite_tasks.dat file. Remember that parasites were introduced at time 5000, that's why we do not see any parasite in the screenshot yet.

Finally the time.dat file contains the mapping between updates (i.e., the unit of time in Avida) and the corresponding number of generations. The time required for an organism to produce an offspring (called in Avida gestation time) depends on the genome, which is continually evolving).

The information provided in those files is enough for generating figures like this one (and movies; see the next post):

You can take a look at our paper on the role of exaptations in shaping antagonistic host-parasite networks to learn more about setting and running coevolutionary experiments in silico.

Digital evolution is a form of evolutionary computation in which self-replicating computer programs—digital organisms—evolve within a user-defined computational environment. Avida is the most widely used software platform for research in digital evolution. It satisfies the three essential requirements for evolution to occur: replication, heritable variation, and differential fitness. The latter arises through competition for the limited resources of memory space and central processing unit (CPU) time.

A digital organism in Avida consists of a sequence of instructions—its genome or genotype—and a virtual CPU, which executes these instructions. Some of these instructions are involved in copying an organism’s genome, which is the only way the organism can pass on its genetic material to future generations. To reproduce, a digital organism must copy its genome instruction by instruction into a new region of memory through a process that may lead to errors (i.e., mutations). A mutation occurs when an instruction is copied incorrectly, and is instead replaced in the offspring genome by an instruction chosen at random (with a uniform distribution) from a set of possible instructions.

Some instructions are required for replication (i.e., viability), whereas others are required to complete computational operations (such as addition, multiplications, and bit-shifts), and are executed on binary numbers taken from the environment through input-output instructions. When the output of processing these numbers equals the result of a specific Boolean logic operation, the digital organism is said to have a functional trait represented by that logic operation.

An organism can be rewarded for having a functional trait with virtual CPU-cycles, which speeds up its execution of instructions. These rewards create an additional selective pressure (besides streamlining replication) which favours those organisms with mutations that have produced sequences of instructions in their genomes that encode functional traits. Organisms that are more successful—those that replicate faster—are more likely to spread through a population.

The genome of a digital organism.

The genome of a digital organism is a circular sequence of instructions taken from a 26-instruction alphabet. It comprises instructions for copying (e.g., v, w, x) as well as for completing computational operations (such as additions, subtractions, and bit-shifts), which are executed on binary numbers taken from the environment. The default environment provides the organism with new, random input strings every time an input-output instruction (y) is executed.

The genome of a digital organism can harbor one or several input-output instructions (y) that can be executed either only once or many times during the time it takes to generate an offspring. This means that the organism can take input numbers from the environment more than once before replicating and can compute the result of more than one logic operation (see below). Only one instruction from the instruction set is itself a logic operator (u).

This is the nand (not-and) instruction, which must be executed in coordination with input-output instructions (y) to perform the NAND logic operation. The nand instruction reads in the contents of the BX and CX registers and performs a bitwise NAND operation on them (i.e., it returns 0 if and only if both inputs at the corresponding bit positions are 1, otherwise it returns 1).

The result of this operation is placed in the BX register. The input-output instruction (y) takes the contents of the BX register and outputs it, checking it  for any logic operations that may have been performed. It will then place a new input into BX. All other logic operations must be performed using one or more nand instructions in combination with input-output (y) instructions.

The phenotype of a digital organism.

Phenotypes are defined by the combination of the following 9 Boolean logic operations that organisms can perform on 32-bit one- and two-input numbers: NOT, which returns 1 at a bit position if the input is 0 at that bit position, and 0 if the input is 1; NAND, which returns 0 if and only if both inputs at the corresponding bit positions are 1 (otherwise it returns 1); AND, which returns 1 if and only if both inputs are 1 (otherwise it returns 0); OR_N (or-not), which returns 1 if for each input bit pair one input bit is 1 or the other is 0 (otherwise it returns 0); OR, which returns 1 if either the first input, the second input, or both are 1 (otherwise it returns 0); AND_N (and-not), which only returns 1 if for each bit pair one input is 1 and the other input is 0 (otherwise it returns 0); NOR (not-or), which returns 1 only if both inputs are 0 (otherwise it returns 0); XOR (exclusive OR), which returns 1 if one but not both of the inputs are 1 (otherwise it returns 0); EQU (equals), which returns 1 if both bits are identical, and 0 if they are different.

You can explore a database of 512,000 organism's genomes and the phenotypes they encode in a single environment here.

Charles Ofria and Claus O. Wilke explain here the general principles on which Avida is built, as well as its main components and their interactions.