Category: RNA

  • Building the RNA Simulation Engine


    INSERT: RNA-Bee Simulation / Folding Hero Pattern


    Building the RNA Simulation Engine

    The simulation engine is the scientific core of RNA-Bee. Its job is to take RNA sequences, apply mutations, predict structures, evaluate the results and use those evaluations to drive repeated rounds of selection.

    Rather than embedding one scientific library directly into every part of the application, RNA-Bee is designed around small domain models and replaceable adapters. This keeps the evolutionary logic independent from the external prediction tools it uses.


    INSERT: Sequence → Folding → Fitness → Selection Diagram


    The basic simulation loop

    At its simplest, an evolutionary RNA simulation can be described as a repeated loop.

    Initial population
            |
            v
    Mutation
            |
            v
    RNA folding
            |
            v
    Feature calculation
            |
            v
    Fitness evaluation
            |
            v
    Selection
            |
            v
    Next generation
            |
            +---- repeat

    Each stage has a deliberately separate responsibility. Mutation changes sequences. Folding predicts structures. Feature calculation extracts measurable properties. Fitness converts those properties into an objective score. Selection determines which candidates contribute to the next generation.

    Keeping these stages separate makes it possible to change one part of the experiment without rewriting the rest of the engine.


    Representing an RNA sequence

    The most basic domain object in RNA-Bee is an RNA sequence.

    GGAUACCGUAAUGCU...

    The sequence itself is simple, but a simulation gradually associates additional information with it.

    • Unique sequence identifier
    • Nucleotide sequence
    • Parent sequence or lineage
    • Generation number
    • Mutation history
    • Predicted structure
    • Calculated energy or other properties
    • Fitness score

    This distinction matters because the raw nucleotide string is only one part of an experiment. Reproducibility also requires knowing how a sequence was produced, which model evaluated it and under which parameters.


    Mutation creates variation

    Evolution requires variation. In RNA-Bee, mutation operators are responsible for creating new sequences from existing ones.

    • Substitution — replace one nucleotide with another.
    • Insertion — add one or more nucleotides.
    • Deletion — remove nucleotides from the sequence.
    • Multiple mutations — apply several changes within one generation.

    The mutation strategy itself should be configurable. Different experiments may use different mutation probabilities, sequence-length constraints or permitted mutation types.

    A mutation operator should therefore produce a new sequence and a description of what changed, rather than directly making decisions about whether the new sequence is “better”. That decision belongs to the fitness and selection layers.


    INSERT: Mutation Example Image / Pattern


    Predicting RNA folding

    After mutation, the engine needs to estimate how the new sequence folds. RNA-Bee delegates that calculation to established scientific software rather than implementing folding algorithms from scratch.

    The first integration target is ViennaRNA, which provides mature tools for RNA secondary-structure prediction and thermodynamic calculations.

    Sequence
    GGAUACCGUAAUGCU
    
            |
            v
    
    Prediction engine
    
            |
            v
    
    Structure
    (((....))).....
    
    Energy
    -4.20 kcal/mol

    Dot-bracket notation provides a compact representation of RNA secondary structure. Matching parentheses represent paired nucleotides, while dots represent unpaired positions.

    RNA-Bee should store both the predicted structure and relevant numerical results instead of storing only a rendered image. That keeps the scientific data reusable for later comparison and analysis.


    Why use adapters for ViennaRNA and RNAstructure?

    The simulation engine should not contain ViennaRNA-specific commands throughout its business logic. Instead, RNA-Bee introduces a small prediction interface between the simulation model and the external scientific software.

    Simulation Engine
            |
            v
    RNA Folding Interface
            |
            +---- ViennaRNA Adapter
            |
            +---- RNAstructure Adapter
            |
            +---- Future Predictor

    The engine can then request a prediction using a common application-level operation, while each adapter handles the details of the external library.

    • Input validation
    • Calling the scientific library
    • Normalizing returned structures and energies
    • Recording tool and version information
    • Handling calculation errors

    This makes comparison possible later without coupling the simulation itself to one external API.


    From folding result to measurable features

    A predicted structure alone does not tell the evolutionary engine whether one candidate should be preferred over another. The next step is therefore to derive measurable features.

    • Minimum free energy
    • Number of paired bases
    • Sequence length
    • GC content
    • Similarity to a target structure
    • Structural motifs
    • Distance from another sequence or structure

    These calculated values form the bridge between scientific prediction and evolutionary selection.


    Fitness defines what “better” means

    An evolutionary algorithm cannot optimize RNA in the abstract. It needs an explicit objective.

    The fitness function converts one or more calculated properties into a value that can be compared between candidates.

    features(sequence, structure)
            |
            v
    fitness function
            |
            v
    score

    For one experiment, a high score might mean that a predicted structure closely resembles a target structure. Another experiment might favour low free energy, a specific GC range or a combination of several properties.

    This is one of the most important design choices in RNA-Bee: fitness must be configurable and separate from folding. The scientific engine predicts what a sequence does; the experiment defines what the simulation considers desirable.


    INSERT: Fitness Function / Target Structure Illustration


    Selection creates the next generation

    Once every candidate has a fitness score, the selection strategy determines which sequences survive or reproduce.

    • Elitist selection — keep the highest-scoring candidates.
    • Weighted selection — better candidates receive a higher probability of contributing to the next generation.
    • Tournament selection — repeatedly choose small groups and select the strongest candidate from each group.
    • Diversity-aware selection — avoid allowing one nearly identical lineage to dominate the population too quickly.

    The selection algorithm strongly influences how the population explores the search space. Too much selection pressure can make the population converge prematurely; too little pressure can make improvement very slow.

    RNA-Bee therefore treats selection as another replaceable strategy rather than a hard-coded rule.


    Populations, generations and lineage

    A useful simulation needs more than the current best sequence. RNA-Bee should preserve enough information to reconstruct how a population developed.

    Experiment
       |
       +-- Generation 0
       |      +-- Sequence A
       |      +-- Sequence B
       |      +-- Sequence C
       |
       +-- Generation 1
       |      +-- Sequence D ← mutation of A
       |      +-- Sequence E ← mutation of B
       |
       +-- Generation 2
              +-- ...

    Tracking lineage makes it possible to answer questions that a single final result cannot answer.

    • Which mutation created an improvement?
    • How quickly did the population converge?
    • Did several independent lineages discover similar structures?
    • Which generations lost or gained structural diversity?

    Reproducibility is part of the experiment

    An evolutionary simulation includes randomness, so simply storing the final sequence is not enough.

    A reproducible RNA-Bee experiment should record the parameters that influenced the run.

    • Initial sequence or population
    • Random seed
    • Mutation probabilities
    • Population size
    • Number of generations
    • Fitness function and parameters
    • Selection strategy
    • Scientific predictor and version

    With these values stored alongside the results, an experiment can be repeated, compared or modified instead of existing only as an opaque simulation run.


    A small engine with clear interfaces

    The core engine can remain conceptually small even when the experiments become complex.

    Sequence
    MutationStrategy
    FoldingPredictor
    FeatureCalculator
    FitnessFunction
    SelectionStrategy
    ExperimentRunner

    Each component owns one responsibility. The experiment runner combines them, but it should not contain the implementation details of every algorithm.

    The simulation engine should understand the experiment, not the command-line syntax of the scientific tools underneath it.


    What comes first?

    RNA-Bee does not need the complete evolutionary system on day one. The simulation engine can grow in small, testable stages.

    1. Accept and validate an RNA sequence.
    2. Fold one sequence with ViennaRNA.
    3. Store the structure and calculated energy.
    4. Create deterministic sequence mutations.
    5. Compare a parent and mutated sequence.
    6. Introduce a simple fitness function.
    7. Create a small population.
    8. Add selection and multiple generations.
    9. Add alternative predictors and more sophisticated fitness models.

    This incremental approach keeps the scientific assumptions visible and makes every stage independently testable.


    INSERT: First Folding Experiment Screenshot / Result


    Where the simulation engine goes next

    The first milestone is intentionally modest: send a real RNA sequence through the scientific adapter, obtain a folding result and persist enough information to reproduce that calculation.

    From there, mutation and selection can be layered on top until RNA-Bee moves from individual folding predictions to complete evolutionary experiments.

    The next article steps back out of the scientific core and looks at the web platform that exposes these experiments to users.


    INSERT: Link / Button to “Building the RNA-Bee Web Platform”


    The RNA-Bee series

    1. Introducing RNA-Bee — the project, RNA folding, evolution and its goals
    2. RNA-Bee Architecture — system architecture and technical decisions
    3. Building the RNA Simulation Engine — ViennaRNA, RNAstructure, mutation, folding, fitness and evolution
    4. Building the RNA-Bee Web Platform — Docker, Django REST, Celery, Redis and WordPress integration

    Project links

    Open RNA-Bee

    View source on GitHub

  • Building the RNA-Bee Web Platform


    INSERT: RNA-Bee Web Platform Hero Pattern


    Building the RNA-Bee Web Platform

    RNA-Bee is not only a simulation engine. It is a complete web platform designed to make computational RNA experiments accessible through a browser while keeping the scientific backend independent from the public website.

    The platform combines WordPress, Django REST Framework, PostgreSQL, MariaDB, Redis, Celery and Docker Compose behind a single public HTTPS endpoint.


    INSERT: Full Web Platform Diagram


    The web platform has two faces

    RNA-Bee exposes one public website, but internally two applications cooperate.

    WordPress

    WordPress handles the visible website: pages, navigation, project presentation and the block-based interface that users interact with.

    Django REST

    Django handles the scientific application layer: API endpoints, experiment models, validation, persistence and orchestration of computational work.

    This separation allows each side to remain focused. WordPress does not become a scientific backend, and Django does not need to solve content management, page building and editorial workflows.


    One domain, different routes

    Users reach RNA-Bee through one HTTPS domain. Apache acts as the public reverse proxy and decides which application receives each request.

    https://rna-bee.nathabee.de/
            |
            v
    Apache
            |
            +---- /       → WordPress
            |
            +---- /api/   → Django REST API

    This produces a simple browser experience while preserving a clean backend boundary.

    The WordPress interface can call the API using normal HTTP requests without exposing internal services such as PostgreSQL or Redis to the internet.


    INSERT: Apache Reverse Proxy / Request Routing Image


    Why WordPress for the frontend?

    RNA-Bee uses WordPress as a frontend because the public site needs more than a single application screen. It also needs normal website capabilities such as project pages, explanations, navigation, reusable design patterns and eventually dedicated blocks for scientific interaction.

    • Block-based page construction
    • Reusable Gutenberg patterns
    • Custom RNA-Bee blocks
    • Theme-based visual identity
    • Accessible editorial content without changing backend code

    The important architectural decision is that WordPress remains the interface layer. Scientific state and simulation logic stay behind the API.


    Why Django REST for the application backend?

    The scientific side of RNA-Bee belongs naturally in Python because the broader computational biology ecosystem is strongly represented there.

    Django provides the application framework around that scientific code, while Django REST Framework exposes the operations through a structured HTTP API.

    • Validate RNA sequences and experiment parameters
    • Create and retrieve experiments
    • Persist simulation metadata
    • Start asynchronous jobs
    • Expose progress and results to the frontend
    • Provide a stable boundary around the scientific engine
    WordPress block
          |
          | HTTP / JSON
          v
    Django REST API
          |
          +---- experiment data
          |
          +---- simulation jobs
          |
          +---- result retrieval

    Keeping long-running work out of HTTP requests

    Scientific computation does not fit well into a normal request-response cycle. A simple folding prediction may be fast, but evolutionary experiments can require repeated calculations across many sequences and generations.

    Instead of making the browser wait for the complete computation, RNA-Bee delegates longer jobs to Celery workers.

    Browser
       |
       v
    POST /api/experiments/
       |
       v
    Django validates request
       |
       v
    Experiment saved
       |
       v
    Task sent to Redis
       |
       v
    Celery worker executes simulation
       |
       v
    Results persisted
       |
       v
    Frontend requests status/result

    This gives the platform a much cleaner execution model. A web request can finish quickly while the experiment continues independently in the background.


    INSERT: Async Experiment Lifecycle Diagram


    Redis as the message broker

    Redis provides the communication layer between Django and the Celery workers.

    Django does not need to know which worker will execute a task. It submits the job, Redis makes it available to the queue, and an available Celery worker takes responsibility for the computation.

    Django
       |
       v
    Redis queue
       |
       v
    Celery worker

    This loose coupling also makes it possible to add more workers later without changing the public API.


    PostgreSQL for scientific application data

    The Django application uses PostgreSQL for structured simulation and application data.

    • Experiments
    • RNA sequences
    • Predicted structures
    • Generations
    • Fitness values
    • Mutation history
    • Simulation status
    • Reproducibility metadata

    This data belongs to the scientific application, not to the content-management system.


    MariaDB stays with WordPress

    WordPress keeps its own MariaDB database for normal CMS responsibilities such as pages, menus, users, settings and editorial content.

    Using two databases may appear redundant, but it preserves an important boundary:

    Website content belongs to WordPress. Scientific experiment data belongs to the RNA application.

    Neither application needs direct database access to the other. Integration happens through application interfaces instead of shared tables.


    Docker Compose ties the platform together

    All application services are described through Docker Compose. This keeps the runtime environment explicit and reproducible.

    • wordpress — public WordPress application
    • wordpress-db — MariaDB for WordPress
    • django — Django REST application
    • celery-worker — asynchronous simulation execution
    • postgres — Django and simulation database
    • redis — task broker

    The containers can be rebuilt independently while persistent state remains in dedicated volumes.


    INSERT: Docker Compose Services Diagram


    Private Docker networks

    Not every service needs to communicate with every other service. RNA-Bee uses network boundaries so that services are connected only where necessary.

    Frontend network
       |
       +-- WordPress
       +-- Django
    
    Backend network
       |
       +-- Django
       +-- Celery
       +-- PostgreSQL
       +-- Redis
    
    WordPress DB network
       |
       +-- WordPress
       +-- MariaDB

    This makes dependencies clearer and reduces accidental exposure between unrelated services.


    Only the web layer is exposed

    PostgreSQL, MariaDB, Redis and Celery do not need public internet access.

    The host exposes only the web applications locally, and Apache publishes those applications through HTTPS.

    Internet
       |
       v
    Apache :443
       |
       +---- WordPress container
       |
       +---- Django container
    
    PostgreSQL   private
    MariaDB      private
    Redis        private
    Celery       private

    This keeps infrastructure services behind the application boundary instead of turning every Docker port into a public service.


    Persistent data and disposable containers

    One of the useful properties of the Docker model is the distinction between applications and data.

    Containers can be recreated. Important data must survive independently.

    • MariaDB data
    • PostgreSQL data
    • WordPress files and uploads
    • Redis state where persistence is useful
    • Generated simulation results

    These are stored separately from the short-lived container filesystem, so rebuilding an application image does not imply losing the project state.


    A development and deployment workflow built around Git

    The reproducible platform also changes how RNA-Bee is developed.

    Local development
          |
          v
    Git commit
          |
          v
    GitHub repository
          |
          v
    VPS git pull
          |
          v
    Docker Compose rebuild / restart

    Application code, Docker configuration, the WordPress child theme and project-specific plugins can be versioned together, while runtime data remains outside Git.

    This creates a useful boundary between what defines the application and what the running application produces.


    WordPress as a programmable interface

    The long-term WordPress role goes beyond presenting static project pages.

    RNA-Bee can expose scientific functionality through dedicated Gutenberg blocks. A block can collect experiment parameters, call the Django API and render the returned state or results inside the website.

    RNA-Bee Gutenberg Block
            |
            +-- RNA sequence
            +-- experiment settings
            +-- start action
            |
            v
    Django API
            |
            v
    Experiment
            |
            v
    Result
            |
            v
    Visualization block

    This approach keeps the user experience native to WordPress while ensuring that the scientific implementation remains in Python.


    INSERT: Future RNA-Bee Gutenberg Simulation Block Screenshot


    Why this platform fits an experimental project

    RNA-Bee is expected to change as new experiments and interfaces are added. The platform therefore needs to support iteration without forcing every change into one monolithic application.

    • WordPress can evolve independently as the interface changes.
    • Django can evolve independently as experiment models become richer.
    • Celery workers can scale independently as computation becomes more expensive.
    • Scientific adapters can change without redesigning the public website.
    • Docker keeps the runtime reproducible while the project grows.

    The browser sees one RNA-Bee application; internally, each layer remains responsible for a different part of the problem.


    The platform is the foundation, not the experiment

    The web platform is now capable of hosting the project, serving the frontend and API, persisting application state and executing asynchronous jobs. But infrastructure alone does not make RNA-Bee scientifically interesting.

    The next milestones move back toward the experiments themselves: the first real folding workflow, mutation and selection models, RNA structure visualization and reproducible evolutionary runs.


    The RNA-Bee series

    1. Introducing RNA-Bee — the project, RNA folding, evolution and its goals
    2. RNA-Bee Architecture — system architecture and technical decisions
    3. Building the RNA Simulation Engine — ViennaRNA, RNAstructure, mutation, folding, fitness and evolution
    4. Building the RNA-Bee Web Platform — Docker, Django REST, Celery, Redis and WordPress integration

    Future build notes

    As RNA-Bee moves from platform setup into actual experiments, individual milestones can be documented separately.

    • RNA-Bee: First folding experiment
    • RNA-Bee: Mutation and selection model
    • RNA-Bee: Building the WordPress simulation block
    • RNA-Bee: Visualizing RNA structures
    • RNA-Bee: Reproducible experiments

    Project links

    Open RNA-Bee

    View source on GitHub

  • RNA-Bee Architecture


    INSERT: RNA-Bee Hero / Architecture Pattern


    RNA-Bee Architecture — separating the web platform from scientific computation

    RNA-Bee is built as a containerized multi-service application. The architecture deliberately separates the public website, API, persistence, asynchronous workloads and scientific computation instead of placing everything inside a single application.

    The goal is not maximum complexity. It is clear responsibility: each component should do one job well and remain replaceable as the project evolves.



    The architecture at a glance

    The application is divided into two main layers: a public web layer and a computational backend.

    • WordPress handles the public website and block-based user interface.
    • Django REST Framework provides the application API and coordinates simulation logic.
    • PostgreSQL stores application and scientific experiment data.
    • Redis acts as the message broker for asynchronous jobs.
    • Celery workers execute computational tasks outside normal web requests.
    • ViennaRNA and other scientific tools provide the actual RNA algorithms.
    • MariaDB stores the WordPress application data.
    • Apache provides the public HTTPS entry point and routes requests to the correct service.

    One public endpoint, two applications

    From the browser, RNA-Bee looks like a single website. Internally, however, normal website requests and API requests are handled by different applications.

    https://rna-bee.nathabee.de/
            |
            +---- /       → WordPress
            |
            +---- /api/   → Django REST API

    Apache sits in front of the Docker services and acts as the reverse proxy. This keeps the individual containers private while exposing only the routes that visitors actually need.

    The routing decision is simple but important: WordPress remains responsible for pages, navigation and interaction, while scientific requests are directed to the Python backend.


    INSERT: Reverse Proxy / Request Flow Diagram


    Why WordPress and Django?

    Using WordPress and Django together may initially look unusual, but the two systems solve very different problems.

    WordPress

    • Pages and navigation
    • Gutenberg blocks
    • Content and documentation
    • Interactive project interface
    • Theme and visual presentation

    Django

    • Scientific application logic
    • REST API
    • Experiment models
    • Simulation orchestration
    • Integration with Python scientific libraries

    The separation keeps WordPress out of scientific computation and avoids forcing the Django backend to become a content-management system.


    Asynchronous computation with Celery and Redis

    Some RNA calculations may finish quickly, while others can involve many sequences, generations or repeated folding operations. Those workloads should not keep a browser request open until the entire simulation finishes.

    RNA-Bee therefore separates web requests from computational jobs.

    User starts experiment
            |
            v
    Django API
            |
            v
    Create job
            |
            v
    Redis queue
            |
            v
    Celery worker
            |
            v
    RNA computation
            |
            v
    Store result

    Django can accept an experiment, validate it and create a job. A Celery worker then performs the actual computation independently. The frontend can query the API for progress and results without tying the lifetime of the experiment to a single HTTP request.


    INSERT: Celery Job Flow Diagram


    Two databases for two responsibilities

    RNA-Bee deliberately does not force WordPress and the scientific backend into the same database.

    MariaDB

    MariaDB belongs to WordPress and stores normal CMS data such as pages, configuration, users and site content.

    PostgreSQL

    PostgreSQL belongs to Django and is intended for simulation runs, experiment definitions, sequences, generations, computed properties and other application-specific data.

    This boundary prevents scientific domain models from becoming dependent on WordPress tables and makes the Python application easier to test, migrate and evolve independently.


    Keeping the scientific engines replaceable

    The computational layer should not be tightly coupled to one RNA library. RNA-Bee is designed so that the simulation engine can ask for operations such as folding or scoring through a defined application interface.

    Simulation Engine
            |
            v
    RNA prediction interface
            |
            +---- ViennaRNA adapter
            |
            +---- RNAstructure adapter
            |
            +---- future engines

    This adapter-based approach allows the project to begin with ViennaRNA while leaving room for comparison, validation or additional scientific engines later.

    The simulation model should therefore understand concepts such as sequence, structure, energy and fitness, but it should not need to know the command-line details or API conventions of a particular external library.


    Docker as the application boundary

    RNA-Bee uses Docker Compose to describe the complete runtime environment. Each major responsibility runs in its own service while persistent data is stored outside the disposable container filesystem.

    • WordPress
    • WordPress MariaDB
    • Django API
    • Celery worker
    • PostgreSQL
    • Redis

    This makes the application reproducible: the same project definition can be used for development, testing and deployment without manually rebuilding the entire server environment.


    INSERT: Docker Services / Networks Diagram


    Public services and private services

    Not every container should be reachable from the internet.

    Only the public web interfaces need host-level access. Databases, Redis and background workers remain internal to the Docker environment and communicate over private networks.

    • Public through Apache: WordPress
    • Public through Apache: Django API
    • Private: PostgreSQL
    • Private: MariaDB
    • Private: Redis
    • Private: Celery workers

    This reduces the exposed attack surface and keeps infrastructure components behind the application boundary.


    Persistence without treating containers as servers

    Containers are replaceable. Data is not.

    RNA-Bee therefore keeps persistent state in dedicated Docker volumes rather than relying on the writable filesystem of a particular container instance.

    • WordPress database data
    • WordPress uploads and runtime files
    • PostgreSQL application data
    • Redis persistence where required
    • Simulation-generated files and results

    A service can therefore be rebuilt or upgraded without implying that its application data should disappear with it.


    Design principles behind the architecture

    • Separation of concerns — presentation, API, data and computation remain distinct.
    • Replaceability — individual scientific engines and infrastructure components should be exchangeable.
    • Reproducibility — the environment is described as code rather than reconstructed manually.
    • Asynchronous by design — expensive simulation work does not belong in browser request lifecycles.
    • Minimal exposure — databases and infrastructure services remain private.
    • Independent evolution — the WordPress interface and Python scientific backend can change at different speeds.

    The architecture is intentionally modular: the web interface asks for scientific work, but it does not perform the science itself.


    Where the architecture goes next

    The infrastructure is only the foundation. The next major architectural work happens inside the scientific domain: defining sequences and experiments, implementing folding adapters, representing mutation and fitness, and designing evolutionary runs that remain reproducible.

    That is the subject of the next article in the RNA-Bee series.


    INSERT: Link / Button to “Building the RNA Simulation Engine”


    The RNA-Bee series

    1. Introducing RNA-Bee — the project, RNA folding, evolution and its goals
    2. RNA-Bee Architecture — system architecture and technical decisions
    3. Building the RNA Simulation Engine — ViennaRNA, RNAstructure, mutation, folding, fitness and evolution
    4. Building the RNA-Bee Web Platform — Docker, Django REST, Celery, Redis and WordPress integration

    Project links

    Open RNA-Bee

    View source on GitHub

  • Introducing RNA Bee


    RNA-Bee — exploring RNA folding and evolution

    RNA-Bee is an open-source experimental platform for exploring RNA structure, mutation and computational evolution.

    The project combines established scientific RNA software with a modern web platform to create an environment where sequences can be analysed, mutated, compared and eventually evolved through reproducible simulations.


    INSERT: Project Overview Image


    What is RNA?

    RNA, or ribonucleic acid, is one of the fundamental molecules of life. It carries biological information, participates in the production of proteins and can also perform regulatory and catalytic functions.

    Unlike the familiar double-stranded structure of DNA, RNA is commonly single-stranded. Parts of the molecule can pair with each other, causing the sequence to fold into characteristic structures.

    This relationship between sequence and structure makes RNA particularly interesting computationally. A small mutation in the sequence can preserve a structure, slightly modify it or produce a completely different folding pattern.

    Sequence determines folding, folding influences behaviour, and mutation creates new possibilities.


    What RNA-Bee explores

    RNA-Bee turns these relationships into a computational playground. Instead of studying only a single sequence, the long-term goal is to create experiments in which populations of RNA sequences can change over many generations.

    • RNA structure prediction — calculate predicted secondary structures from nucleotide sequences.
    • Mutation — create variants and observe how sequence changes affect predicted folding.
    • Comparison — compare sequences, structures and calculated properties.
    • Fitness and selection — evaluate sequences according to configurable objectives.
    • Evolution — repeatedly combine mutation, evaluation and selection across generations.
    • Visualization — expose computational experiments through an interactive web interface.

    Sequence → mutation → folding → evaluation → selection → next generation.


    Why build RNA-Bee?

    RNA-Bee is both a software project and an experiment in computational biology. The aim is not to replace established scientific tools, but to build an accessible environment around them where different ideas can be implemented, combined and tested.

    The evolutionary aspect is particularly interesting: instead of manually designing every sequence, a simulation can create variation, evaluate the resulting candidates and repeatedly select sequences that better satisfy a chosen objective.

    This makes RNA-Bee a useful playground for studying how simple computational rules can produce increasingly complex populations and structures over time.


    Built on open science

    RNA-Bee does not attempt to reinvent RNA folding algorithms. Instead, the project is designed to integrate established open-source scientific software and expose it through a reproducible simulation environment.

    ViennaRNA

    The ViennaRNA ecosystem provides widely used algorithms and libraries for analysing and predicting RNA secondary structures.

    RNAstructure

    RNAstructure provides another established collection of tools for RNA structure prediction and analysis and gives RNA-Bee room to compare or extend computational approaches later.

    RNA-Bee focuses on the layer around these scientific engines: experiment definition, mutation, fitness models, evolutionary workflows, persistence, reproducibility and visualization.


    A web platform around scientific computation

    RNA-Bee is built as a containerized full-stack application. The public website and interactive interface are separated from the Python computation layer so that each part of the project has a clear responsibility.

    • WordPress provides the public-facing website and block-based user interface.
    • Django REST Framework provides the application API and Python backend.
    • PostgreSQL stores application and simulation data.
    • Redis and Celery provide the foundation for asynchronous computational jobs.
    • Docker Compose keeps the different services isolated and makes the environment reproducible.

    The complete system architecture, service boundaries and technical decisions are documented separately in the next RNA-Bee article.


    INSERT: Link / Button to “RNA-Bee Architecture” Post


    Open source by design

    RNA-Bee is developed as an open-source project. The source code and technical documentation are public so that the system can be inspected, reproduced and extended.

    The project is intended to remain modular: scientific engines can be exchanged or extended, new simulation strategies can be introduced, and the web interface can evolve independently from the computational core.

    • Study the implementation
    • Reproduce the application environment
    • Experiment with RNA simulations
    • Extend the simulation engine
    • Develop additional interfaces and visualization tools

    Current status

    RNA-Bee is under active development. The initial application infrastructure is already running, including the containerized WordPress and Django services, PostgreSQL, Redis, Celery and the public HTTPS routing.

    The next development phase moves from infrastructure toward the scientific core of the project: RNA folding integration, experiment models, mutation strategies, fitness functions, evolutionary simulations and interactive visualization.

    • Available: Docker-based application environment
    • Available: WordPress frontend
    • Available: Django REST API foundation
    • Available: PostgreSQL, Redis and Celery infrastructure
    • Next: scientific RNA folding integration
    • Next: mutation and fitness models
    • Next: evolutionary simulation engine
    • Next: interactive WordPress simulation interface

    The RNA-Bee series

    This introduction is the first part of a series documenting the project from both the scientific and software-engineering perspectives.

    1. Introducing RNA-Bee — the project, RNA folding, evolution and its goals
    2. RNA-Bee Architecture — system architecture and technical decisions
    3. Building the RNA Simulation Engine — folding, mutation, fitness and evolution
    4. Building the RNA-Bee Web Platform — Docker, Django, Celery, Redis and WordPress integration

    Follow the experiment

    RNA-Bee will evolve alongside the experiments it runs. The live application provides the project environment, while GitHub contains the source code and technical documentation.

    Open RNA-Bee

    View source on GitHub