Turn your microscope into a sequencing machine.
Explore the docs »
View Demo
·
Report Bug
·
Request Feature
What are the aims of µLRM?
µLRM or microLRM is an open source alternative to Illumina's Local Run Manager. µLRM is a compiled software for real-time microscope and fluidics control that turns any microscope supported by micro-manager's mmCoreAndDevices into a sequencing machine for in situ sequencing.
With micro Local Run Manager you will be able to: create, monitor, and analyze microscope sequencing runs.
µLRM is not a tool for tertiary analysis, i.e. making sense of the data in a genomic context. The scope of µLRM is purely focused on the primary and secondary steps of next-generation sequencing analysis.
Output format closely follows the file folder structure of most contemporary sequencing machines.
Traditionally a "Lane" in Next Generation Sequencing context is the physical lane on a flow cell.
Lanes might be used to separate different experiments through physical separation of the sequencing reaction.
Splitting up the analysis based on lanes has traditionally been important for QC purposes in figuring out when fluidics for a given flow cell lane is failing.
However, for in situ sequencing context the lane, or rather the reaction well or fluidic wall, is not the only important level of analysis since realtime sequencing performance is also dependent on the tissue environment of the single sample being sequenced.
Rather than structuring up into more subfolders a "lane" here is considered to be an individual piece of tissue covered by a set of field of views. Note that with this definition several "lanes" can belong to a single reaction well. To further designate which tissue pieces belong to the same reaction a 📝 LaneGroups.json file provides information on the groupings of "lanes".
.
├── 📂 Data
│ ├── 📂 Intensities
│ │ ├── 📂 BaseCalls
│ │ │ └── 📂 L001
│ │ │ └── 📂 C1.1
│ │ │ └── 📝 s_1_1.bcl
│ │ └── 📂 L001
│ │ └── 📝 s_1_1.locs
│ └── 📂 RTALogs
├── 📂 InterOp
│ └── 📂 cache
├── 📂 Logs
├── 📂 Recipe
├── 📝 RunInfo.json
├── 📝 RunParameters.json
├── 📝 LaneGroups.json
├── 📝 SampleSheet.csv
└── 📂 Thumbnail_images
└── 📂 L001
└── 📝 s_1_1.html
At the lowest level base calls for a given cycle, e.g. 📂 C1.1, lane, e.g. 📂 L001, and field of view (FOV) is represented by a single .bcl file.
Locations of individual amplicons and their point set registration results across cycles are summarized for a given lane, e.g. 📂 L001, and FOV by a single .locs file.
The binary base call (BCL) sequence file format is a binary format that can easily be converted to a human readable FASTQ file. µLRM software writes the base and the confidence in the call as a quality score to base call (.bcl) files. This is done in real time, i.e. for every cycle of the sequencing run a call for every location identified on the flow cell is added. BCL files are stored in binary format and represent the raw data output of a sequencing run.
BCL files are compressed with the gzip (*.gz) or blocked GNU zip (*.bgzf) format.
Blocked gzip files are larger in size but improves random access.
Table 1. Byte specification of the BCL format
| Bytes | Description | Type |
|---|---|---|
| 0–3 | Number of N cluster | uint32 |
| 4-(N+3) N-Cluster index |
Bits 0–1 are the bases, [A, C, G, T] for [0, 1, 2, 3]. Bits 2–7 are shifted by 2 bits and contain the quality score. All bits with 0 in a byte are reserved for no call. | uint8 |
The locs file format stores position data exclusively. locs files store position data for successive clusters in 4 byte float pairs, described as follows:
Table 2. Byte specification of the LOCS format
| Bytes | Description | Type |
|---|---|---|
| 0-3 | Version number | uint8 |
| 4-7 | 2.0 | double |
| 8-11 | Number of clusters | uint32 |
| 12-15 | X coordinate of first cluster | double |
| 16-19 | Y coordinate of first cluster | double |
| 20-23 | Z coordinate of first cluster | double |
The remaining bytes of the file store the X, Y and Z coordinates of the remaining clusters.
µLRM, unlike traditional fluorescent NGS platforms, is specifically designed to handle 3D data acquired through z-stacks a tiles with confocal quality. That is not to say that 2D data cant be used as input. However the default trained neural networks differ from 3D and 2D scenario. See segmentation and base calling for more details.
Ultimately the goal of µLRM is to function as the acquisition engine (red) within the following plugin landscape:
.
├── CMakeLists.txt
├── app
│ └── main.cpp
├── include
│ ├── example.h
│ └── exampleConfig.h.in
├── src
│ └── example.cpp
└── tests
├── dummy.cpp
└── main.cpp
Additional sources go in src/, header files in include/, main programs in app/, and
tests go in tests/ (compiled to unit_tests by default).
If you add a new executable, say app/hello.cpp, you only need to add the following two lines to CMakeLists.txt:
add_executable(main app/main.cpp) # Name of exec. and location of file.
target_link_libraries(main PRIVATE ${LIBRARY_NAME}) # Link the executable to lib built from src/*.cpp (if it uses it).You can find the example source code that builds the main executable in app/main.cpp under the Build section in CMakeLists.txt.
If the executable you made does not use the library in src/, then only the first line is needed.
Build by making a build directory (i.e. build/), run cmake in that dir, and then use make to build the desired target.
Example:
> mkdir build && cd build
> cmake .. -DCMAKE_BUILD_TYPE=[Debug | Coverage | Release]
> make
> ./main
> make test # Makes and runs the tests.
> make coverage # Generate a coverage report.
> make doc # Generate html documentation.This is free and unencumbered software released into the public domain.
Daniel Fürth, SciLifeLab/Uppsala University.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent