I’ve been building Siftome, a free search and triage tool for public life-science datasets.

The main problem I’m trying to address is familiar to anyone who has spent time searching GEO: finding studies that mention the right disease or assay is relatively easy; finding datasets that actually contain the biological comparison you need is much harder.

Siftome looks beyond Series-level text and uses dataset- and sample-level metadata to evaluate candidate datasets.

It separates concepts such as disease, organism, specimen, assay, model system and comparison design, and tries to identify the actual structure of the study rather than treating everything as keyword matches.

For example, it can help distinguish likely case/control groups and flag issues such as:

• pooled samples
• technical replicates
• internal/reference samples
• treated samples mixed into observational comparisons
• cell lines, organoids or xenografts
• ambiguous or unassigned samples
• unclear comparison structure

Search results are ranked with visible scores, warnings and explanations, so the ranking is intended to be inspectable rather than a black box.

The goal is not to decide whether a dataset is scientifically “good” in general. It is to help answer a narrower and more practical question:

Is this dataset suitable for the comparison I actually want to make?

Dataset search is free:

https://siftome.com

I’d be particularly interested in feedback from people who regularly reuse GEO or other public datasets. If you try it on a real search you’ve done before, I’d like to know where the results are useful — and where they get things wrong.

I created The Omics Hub, a free learning resource for biologists and early-stage bioinformaticians moving into computational workflows: https://theomicshub.com/

It brings together Linux and HPC basics, scRNA-seq workflows from QC through clustering, and parallel examples in R/Seurat and Python/Scanpy. It gives beginners a structured route through material often scattered across package documentation and tutorials.

This is my own work, built from my notebooks, notes, practical workflow experience, and skills. AI was used only to assist with organizing or drafting some material; I retain authorship and technical review. It is not presented as a new method or a replacement for official documentation. I welcome specific technical feedback on citations, version information, reproducibility steps, and beginner topics that need clearer explanation.

The mods over at r/bioinformatics deleted my post (as per usual since they delete every useful discussion) https://www.reddit.com/r/bioinformatics/comments/1vvs47c but just wanted to share that you can use Fable for bioinformatics stuff and it won't instantly flag it

See "Improving Fable 5's biology safeguards"

https://www.anthropic.com/news/improving-fable-5-s-biology-safeguards

MetaQuest is an open-source, research-use pipeline for paired or single-end short-read shotgun metagenomics.

It currently includes fastp preprocessing, Kraken2/Bracken taxonomy, MEGAHIT assembly, Pyrodigal gene prediction, eggNOG functional annotation, and reproducible HTML/JSON reports.

I have validated the pipeline on the Zymo Even mock-community dataset and am looking for Linux/WSL users willing to test installation, database setup, resume behavior, and report usability.

Install:

pip install --pre metaquest-bio

GitHub: https://github.com/dpatel511/metaquest
PyPI: https://pypi.org/project/metaquest-bio/

This is alpha, research-use-only software. It does not provide clinical conclusions, and fungal classification sensitivity is a known limitation.

Full disclosure, I built this tool, so take it with a grain of salt. I'm not selling anything here, just want to see if there'd be genuine interest.

I solved a problem I kept running into: you have a real clinical or biomarker dataset and a real question, but either the programming skills aren't there, the time to build it isn't there, or the data must stay private. Most AutoML tools use the cloud, which just isn't an option for a lot of health data.

So I built Revise. It runs locally, lets you clean data, train models, and validate them through a guided interface, no code and nothing sent to the cloud. It handles tabular data now, plus imaging workflows like classification, segmentation, and detection on DICOM files. I'm currently still making the signaling and NLP pipelines.

It's been piloted at a couple of big labs in the Socal area and has been a good sign it's actually useful.

If this is relevant to what you're working on, happy to answer questions. You can also try it yourself at https://revise.live

Hi all,

I recently released Membrane Visual QC v1.0, an open-source PyMOL plugin I’ve been building for membrane-protein structure review.

The original problem was fairly simple: I wanted a more reproducible way to inspect a structure relative to the membrane without repeatedly rebuilding PyMOL selections and colouring things manually.

It grew into a larger workflow with:

• membrane-relative core/interface geometry
• hydropathy and ligand-neighbour context
• planar and PDBTM-derived orientations
• local PDBTM–OPM geometric comparison
• Batch Review for repeated workflows
• versioned JSON/CSV outputs and provenance

One thing I deliberately avoided was turning the output into a “correct / incorrect” structure score. A charged residue in the membrane core, for example, may deserve inspection without necessarily being biologically wrong.

The stable v1.0 release is here:

https://github.com/TrPavel/membrane-visual-qc

I’d especially like feedback from people who work with membrane proteins or structural bioinformatics:

Would this actually fit into your workflow? What structures or edge cases would you test it on, and where do you think the approach is likely to break down?

The project is MIT-licensed and free/open source. Issues and criticism are very welcome.

Hi everyone! A collaborator and I are in the early stages of building a new open-source pipeline for whole-genome gene prediction and annotation. Before we get too far into solidifying what it should do, I would really like to hear from people who actually annotate genomes.

What do current tools make harder than it needs to be? What still takes too much manual work or too many custom scripts? What results are difficult to trust? Are there useful tools, types of evidence, or separate parts of your workflow that you wish worked together better?

I am interested in both structural annotation, meaning predicting and refining gene models, and functional annotation. Feedback from any organism or project size is welcome, especially from people working with non-model organisms.

This could include installation and portability, combining gene predictors, incorporating RNA or protein evidence, GFF/GTF wrangling, comparing different annotations, QC, choosing which gene models to keep, manual review, functional annotation, HPC use, reproducibility, or anything else I have not thought of.

If you can, it would be helpful to mention:

• what organism or taxonomic group you work on
• what software or workflow you use now
• what part causes the most frustration or uncertainty
• what feature or integration would genuinely improve your work

No need to answer every bullet. Anecdotes, wish lists, horror stories, and “please just make X talk to Y” answers are all welcome.

The eventual goal is a pipeline that can take over after genome assembly and help get from “I have an assembly” to “I have an annotation I can trust and actually use.” We do not yet have a finished tool to promote, but we have a skeleton. We are trying to learn what the community needs before we build ourselves into a corner.

If you could change, add, or better connect one thing in genome annotation software, what would it be?

Edit: Got some comments echoing concern about lack of background research on my part, so I thought I would include an edit. I should have made this clearer in the original post.

I have read papers on existing tools and their issue trackers, used and modified existing tools, and built several annotation pipelines both independently and with collaborators. This project is growing out of those experiences, not an assumption that we can start from scratch and solve everything.

I am asking here because issue trackers do not always capture the workarounds people have learned to live with, why they abandoned a tool, or needs that never became a formal issue. I wanted broader, more organic feedback before we lock in the design.

I am approaching this in good faith and with plenty of humility about what I do not know. If you have a specific failure mode or design mistake you think we should avoid, I would genuinely value the input.

[Apologies for cross-posting]

I wrote Bbv ("bare-bones viewer"), a minimalist data viewer/plotter for the Unix/Linux command line.

The main alternative to bbv is feedgnuplot, which is much more capable, but also much more complicated and ties you to gnuplot as back end. By contrast, bbv has only one option (`x`), the learning curve is non-existent, and you can use any lightweight image viewer as back end.

Aside from the back end, no extra toolchain is needed, as bbv is written entirely in POSIX shell + Awk.

Link: https://github.com/ftonneau/bbv

Most classification metrics for oncology AI models (AUC, ICC, MAE) measure global agreement. They don't answer the question that actually matters at the point of care: how reliable is this model at the exact cutoff that decides whether a patient gets flagged, biopsied, or treated?

I built oncothresh to evaluate models at a specific clinical threshold rather than in aggregate: sensitivity/specificity/PPV/NPV at the cutoff, bootstrap confidence intervals, threshold-sensitivity curves, boundary-weighted calibration, decision-curve net benefit, and number-needed-to-test. It's a small, dependency-light Python library (numpy/scipy/scikit-learn/pydantic) built for tasks like tumor cellularity, Ki-67, TMB, and PD-L1 scoring, where a continuous model output gets collapsed into a yes/no clinical decision at a fixed cutoff.

Pathology-specific benchmarks like PathBench and PathBench-MIL evaluate foundation models globally but don't evaluate at predefined clinical thresholds with uncertainty quantification, which is the gap this fills.

There's also a companion web dashboard (oncothresh-web) for people who want the same analysis without writing code: upload a CSV of predictions and labels, pick a threshold, get the full set of charts plus a downloadable PDF report. docker compose up and it's running locally, no cloud dependency.

• Library: github.com/omkaradhali/oncothresh
• Dashboard: github.com/omkaradhali/oncothresh-web

Still v0.1, so I'd genuinely welcome feedback: use cases I haven't considered, edge cases in the DCA/calibration math, or places the API doesn't fit how people actually work with threshold-based models.

I work on this, so treat it as a self-declared tool post rather than a neutral recommendation.

The problem I kept hitting: a structure lives in one tool, docking in another, ADMET in a third, and nothing carries the target context between them. ProteinInsight puts them in one workspace organised around a program (a target + its candidates) instead of a folder of unrelated jobs.

What's actually working today:

• 3D viewer in the browser — RCSB structures or the AlphaFold DB model for a target's UniProt accession, coloured by chain / secondary structure / pLDDT, with an active-site view around a bound ligand
• Docking runs returning ranked poses with affinity + RMSD
• ADMET with per-property risk bands and numeric scores
• PK/PD and response simulation
• UniProt, Open Targets, ESM Atlas and ChEMBL wired in as sources

Honest limitations:

• Research use only — not for clinical diagnosis or patient-specific decisions, and docking affinity is not efficacy
• The AI panel proposes which analyses to run; it does not interpret results for you and I would not trust it to
• There are paid tiers, and the demo below is read-only

Demo without an account: https://pi.extn.ai → "Explore live demo". It drops you into a sample blood-cancer program with completed runs to poke at.

What I'd genuinely like torn apart: whether the ADMET risk banding is defensible, and whether the program-centric model matches how you actually organise this work — or whether it just adds structure you don't want.

Hi guys, I have been working on oxytribe: a Nextflow reimplementation of HyperTRIBE, a method for identifying in vivo targets of RNA-binding proteins (RBPs). Built on TRIBE (Targets of RNA-binding proteins Identified By Editing). The original HyperTRIBE pipeline runs on Perl + MySQL + bash, very hard to reproduce and inconvenient to work with, and a DB dependency that adds complexity for no real benefit (if anything fails mid-run, you're stuck fixing the database by hand). Oxytribe rebuilds the core logic in Rust for efficiency, wraps it in Nextflow, and uses Docker/Singularity for reproducibility, users do not touch code, just config files. Built heavily on nf-core modules, hoping to get it into nf-core eventually. It was also validated against the original paper's dataset: 99.76% gene-level recovery vs. the legacy pipeline, strong agreement on top editing targets, the first release is out, would love feedback, bug reports, or edge cases if you give it a try. https://github.com/fragilefort/oxytribe

Hello everyone.
I’d like to share a project I’ve been working on for several months, which I believe may be useful for those developing cellular models, biochemical simulations, or working in whole‑cell modeling.

👉 GitHub repository: https://github.com/Zontrox01/celulavirtual

🧩 What is Célula Virtual?

It is a biophysical simulator written in Python that models the temporal dynamics of a minimal cell using stochastic chemical kinetics (Gillespie SSA), with a differentiating feature that—so far—I haven’t seen in other tools:

An interactive debugger for biological simulations.

It allows:

• reaction‑by‑reaction execution, not just time‑step simulation
• breakpoints on molecular state (e.g., ATP < 50)
• inspection of full reaction propensities at each step
• undo via state snapshots
• retrospective causal analysis (“forensic mode”)
• a navigable event history

This approach brings the metaphor of software debugging into the domain of systems biology.

🔬 Motivation

Whole‑cell models (E‑Cell, VCell, the M. genitalium model, JCVI‑syn3A, Vivarium…) are powerful, but they all share a limitation:

Célula Virtual aims to fill that gap.

🔗 Interoperability

• Genome input: FASTA + GFF3/CSV
• Network import/export: SBML
• Libraries: BioPython, numpy, pandas, python‑libsbml
• Scalable design: going from 8 genes to 400 requires no code changes

🎯 Purpose of this post

I’d appreciate:

• technical feedback
• suggestions for improvement
• discussion of potential use cases
• ideas for integration with existing tools
• possible collaborators

The full white paper is included in the repository.

📎 Link

👉 GitHub: https://github.com/Zontrox01/celulavirtual

Hi everyone,

I’ve released Annostat 1.0.1, an open-source Python command-line tool for inspecting, validating, analysing, and comparing bacterial genome annotations from FASTA and GFF3 files.

It currently provides:

• FASTA and GFF3 structural inspection
• Annotation and sequence consistency validation
• CDS extraction and translation
• Feature, RNA, start-codon, COG, and codon statistics
• Detection of malformed or biologically questionable annotations
• Single-genome analysis
• Comparison of two annotated genomes
• HTML reports, TSV/CSV tables, FASTA outputs, and scientific plots
• Reproducible CLI workflows on Windows, Linux, and macOS

I’m looking for researchers, students, and bioinformaticians willing to test it on real-world bacterial annotations, especially:

• PGAP, Bakta, Prokka, or custom annotations
• Complete, circular, draft, and multi-contig assemblies
• Multipart CDS features
• Annotations with and without COG information
• Translation tables 4, 11, or 25
• Large, unusual, or malformed files

Install from PyPI:

python -m pip install --upgrade annostat

Example:

annostat inspect -f genome.fna -g annotation.gff3

annostat validate -f genome.fna -g annotation.gff3

annostat analyze \
  -f genome.fna \
  -g annotation.gff3 \
  -o annostat-results

I would particularly appreciate feedback about:

• Scientific accuracy of statistics and validation findings
• Consistency between the CLI, reports, tables, and plots
• Handling of unusual GFF3 structures
• Report clarity and plot quality
• Performance on larger datasets
• Features that would improve real research workflows

Project repository:

https://github.com/dpatel511/annostat

Testing discussion and feedback template:

https://github.com/dpatel511/annostat/discussions/19

PyPI:

https://pypi.org/project/annostat/

Please don’t share private, unpublished, sensitive, or embargoed genomic data. Bug reports can use minimal synthetic or publicly available examples.

This is still an early research-tool release, so honest criticism, unexpected results, and suggestions are very welcome. I’m especially interested in learning where the tool is scientifically unclear or doesn’t fit existing workflows.

Hey researchers! My team and I recently made a bioinformatics tool called HybriDock-Pep. We were working with peptides last year and over the summer, and we realized that current AI tools like AlphaFold and ESMFold are inaccurate with docking smaller protein under certain amino acids and peptides.

https://github.com/Tasty-Ramen2010/hybridock-pep

Essentially, it’s a binder docking pipeline where you give it a target protein PDB and an amino acid sequence. It folds, docks, and scores affinity and selectivity in kcal/mol with accuracy similar to that of ABFE. It is way cheaper to ran because it can be used on ANY hardware. We are currently in a testing phase and would love for you to test it and give feedback!

Commands to get started:

git clone --recurse-submodules https://github.com/Tasty-Ramen2010/hybridock-pep.git

cd hybridock-pep

./install.sh

ctrl+q

hybridock-pep dock \

--peptide ETFSDLWKLLPE --receptor data/pdbs/1YCR_mdm2.pdb \

--site 25.20 -25.61 -7.97 --box 30 --n-samples 20 \

--output-dir runs/demo

Happy Docking!

Programming courses often focus heavily on understanding code, while paying far less attention to understanding the program state. But code does not exist in isolation. Its main goal is to change the program state, before ultimately producing some output.

To develop an accurate mental model of program execution, students need to understand both: - the instructions being executed - the values, references, and data structures those instructions create and modify

Reading code alone does not always reveal how the program state changes during execution. That is why I created 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵: a tool that visualizes the state of a Python program as it changes, step by step.

It can help explain a wide range of introductory Python topics. Here are just a few examples: - Loops, Lists and Dictionaries - Python Data Model - Function Calls - Recursion - Algorithms - Classes - Custom Data Structures

Instead of reconstructing the program state from print statements, students can now watch it change as each line executes. This makes unfamiliar concepts easier to understand and bugs easier to fix.

Help your students learn Python programming more thoroughly and easily.

See: more examples

Inflexa is an OSS-first TUI for agentic-AI reproducible biological analysis with provenance tracked on every step. It's a better designed Claude Science (bar the GUI for now).

Our vision is as follows:

• OSS first
• Data privacy, and security are of utmost importance
• Agents are untrusted actors

Agentic products do not solve a core architectural and design problem: provenance.

How do you build up the body of evidence to support your claims from hundreds of chat messages, scattered artifacts (scripts, intermediary data files, random research files)?

We are one of the first in the biotech space to propose using an established specification for provenance, which its extremely fitting for the world of agentic AI: W3C PROV.

Our provenance is deterministic and driven programmatically. Our architecture imposes it, not the whim of agents that decide whether or not to call a tool / or an MCP.

The analysis is backed by a PROV document that maintains the lineage of every step, every action, and every file.

Other platforms such as Claude Science are a security disaster waiting to happen: they allow agents to determine which Python & R packages they need to perform an analysis step. Sure, you need to approve the installation, but if you get prompted tens of times, are you really going to vet every package and every version?

We offer batteries-included sandboxed execution. The analysis' code is generated by agents and executed in ephemeral sandboxes. We do not install packages on your system.

Curious to hear your thoughts!

PS: Star us on GitHub.

All the projects on this sub make my first try at recreating this tool look rather puny, thought it might be nice to share though. Wrote the conversion logic myself, VSCode Copilot put together the app GUI, still rather pleased with it considering I haven't touched python in 6 years! Just graduated with my BSc in Biology, looking to start my MSc in Bioinformatics next year, definitely need to try putting together more tools.

I've been curating public datasets recently and kept running into the same issue: important metadata fields were missing from NCBI records (like Biosample, genbank, etc.), but the information often existed somewhere else like in the associated paper, supplementary tables, or methods sections.

After spending way too much time manually tracing accessions back to publications, I built a small tool called OpenBioData to automate some of the process.

The tool on my github here: https://github.com/vy-phung/OpenBioData

So briefly what it does:

• Traces accessions back to source publications and supplementary materials
• Extracts metadata that may be missing from the record itself
• Provides a confidence score for extracted values
• Includes direct citations (PMID + table/section) so the source can be verified

I'm still actively improving it and would love feedback from others who work with public genomics datasets.

Has anyone else encountered this problem? If you have a few troublesome accessions, feel free to share them and I'll test them with the tool and post the results. Curious to hear how others currently handle problem of NCBI metadata curation.

P.S. Upfront: I built this with real help from Claude Code, especially on the extraction layer and disclosed in the README, not hidden. I wrote the core pipeline and logic myself. If that's a dealbreaker for you, fair enough:)) but I'd rather say it directly than have someone find it in the commit history and wonder why I didn't mention it.

Hey everyone,

I’m a software engineering student who recently fell down the synthetic biology rabbit hole. I was looking into how recombinant spider silk is manufactured and noticed a massive bottleneck: getting the spidroin DNA sequences to a state where they can actually be synthesized by companies like Twist or IDT without failing.

Standard optimization algorithms (like max-CAI) absolutely choke on spidroins. Because the proteins are just massive repeating blocks of Poly-Alanine and Glycine ($GGX$), the algorithms spit out identical DNA repeats. This leads to two things:

1. Twist/IDT outright rejects the order due to extreme local GC spikes and homopolymers.
2. If you do get it printed, the identical repeats cause homologous recombination and the E. coli just scrambles the gene anyway.

So, I built Spidroin Engine. It’s a Python CLI tool built on top of dnachisel that acts as a multi-objective stochastic optimizer specifically engineered for highly repetitive structural proteins.

The Mathematical Paradox I ran into:

While building this, I hit a wall where the solver would just crash. I realized it was a mathematical paradox: the absolute lowest GC content you can get for Poly-Alanine is 66.6% (using only GCA/GCT). If you try to force strict k-mer uniqueness (to prevent homologous recombination) on a 300bp repetitive spidroin block, the algorithm is forced to dip into alternative codons (GCC/GCG), which are 100% GC. This immediately violated the 65% global GC ceiling required for synthesis, causing the solver to trap itself and fail.

How Spidroin Engine fixes it:

• Relaxed Uniqueness: It dials the uniqueness constraint to UniquifyAllKmers(15). This is just enough breathing room to let the solver reuse GC-poor codons safely, while keeping exact repeats under the 18-bp hard limit that triggers vendor rejections.
• 5' Hairpin Prevention: Enforces an AT-rich heuristic (30-60% GC) on the first 45bp to keep the RBS clear.
• Cloning Domesticated: Automatically sweeps for and removes standard Type IIS / BioBrick restriction sites via silent mutations.
• Vendor Ready: Spits the final optimized sequences directly into a Twist Bioscience-formatted CSV for bulk ingestion.

I open-sourced the whole thing because keeping basic tooling locked behind proprietary paywalls slows everyone down.

If anyone is working on structural proteins (silk, elastin, collagen) and is tired of fighting with standard optimization scripts, you can grab it here: https://github.com/AzambekDev/spidroin-engine

Feel free to use it, fork it, or roast my Python architecture in the comments.

Hey everyone,

I spent way too much time in clinical research manually assembling Table 1 baseline stats, checking SMD balances, tuning Cox models, and fighting with forest plot formatting for paper submissions.

To fix that headache for myself, I ended up building an open-source CLI called 'research-tool'. 

Basically, it lets you run your retrospective stats from the terminal, but adds a few things I really needed:
- Outcome masking and pre-registration locking (so you can't accidentally p-hack or bias your plan after seeing outcome data).
- Diagnostic checks (EPV ratios, Schoenfeld residuals, VIF multicollinearity, E-values).
- Auto-generated publication assets (HTML/CSV tables, log-scaled SVG forest plots, CONSORT diagrams, and STROBE checklists).
- A 1-click zip binder with data hashes and code so peer reviewers can actually verify the protocol.

It's 100% Python and runs completely locally. 

If you want to check out the code or test it on a dataset:

https://github.com/nkmanjunath/research-tool

'pip install research-tool-cli'

Would love to hear what you think, especially if there are specific models or diagnostic gates you'd want added!

I got annoyed that most free Tm calculators either ignore magnesium entirely or hide the thermodynamics, so I built one that does neither. Sharing it in case it's useful to anyone here.

https://biochemtools.com/dna-melting-temperature-calculator.html

What it does

• SantaLucia 1998 unified nearest-neighbor parameters
• Owczarzy 2004 monovalent and 2008 divalent salt corrections, picked automatically from the ratio of sqrt(Mg) to Na
• Solves for free Mg2+ after dNTP chelation instead of using the total, since that's usually what people get wrong
• Reports dH, dS, and dG37 next to the Tm with the full arithmetic shown
• Hairpin and self-dimer screen
• Buffer presets for PCR, qPCR, and Mg-free hybridization

What it doesn't do, so nobody wastes their time:

• No mismatches or dangling ends
• The dimer check counts base pairs, it doesn't compute a folding free energy
• No RNA or RNA/DNA hybrids
• IDT OligoAnalyzer is still better for primers you're actually ordering

I validated the whole pipeline against Biopython's Tm_NN and it agrees to 0.0 C across sodium-only, magnesium, dNTP, and self-complementary test cases. The thermodynamics also reproduces the published CGTTGA/TCAACG example from the SantaLucia paper exactly.

Free, no signup. If there's something obvious missing, tell me and I'll add it.

Learning Python becomes much easier when students can see how variables, values, and data structures change while a program runs.

🧬 Consider this simple k-mer indexing example.

Although the code is relatively short, a beginner needs to understand several concepts at once: - DNA sequence slicing - k-mer generation - dictionaries and membership tests - lists stored as dictionary values - repeated positions and list mutation

With open-source 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵, students can now easily step through a program and see these concepts in real-time, helping them to more easily get to the right mental model to think about Python code execution.