Avogadro started 20 years ago with a manifesto. There were plenty of tools for viewing chemistry in 3D, but few for building and editing molecules, and almost none of those were free and open source. We wanted a tool that was easy to use, cross-platform and available to users worldwide; that worked for new students and expert researchers alike; that produced publication-quality graphics; and that stayed efficient on budget hardware. We also wanted high-quality, tested code.
At the time, many people questioned whether chemists should build on and contribute to a shared open-source ecosystem. Today much of computational chemistry works that way. Avogadro now reaches users through desktop apps in dozens of languages, and soon through the web, Jupyter notebooks, and automation tools too.
What Avogadro is for
Building and editing structures, as well as viewing and analyzing them.
Easy for new students, powerful for experts.
Free, open and part of the open-science ecosystem. Avogadro is permissively licensed, so it is both an application and a set of libraries others build on, and it connects to the wider ecosystem of open chemistry and materials tools.
Available everywhere: on Windows, macOS and Linux through our website, the Microsoft Store, Flatpak, Homebrew and most Linux distributions; soon in the browser through avogadro-web (WebAssembly); in automation and AI tools through avogadro-mcp; and in dozens of languages. That also means small downloads, offline use, and running well on budget hardware.
Publication-quality graphics. Including connections to tools like Blender and modern rendering programs.
Reliable: high-quality, tested code that should never crash.
Private by default. Research data stays confidential. Nothing leaves your computer unless you choose to share it.
Open formats, readable forever. Formats are documented and open, Avogadro reads and writes many others, nothing locks you in, and old files always open.
Stable for users and developers. Scripts, plugins and commands stay backward compatible as far as possible, and changes are announced well in advance.
Scientifically sound and properly credited. Results and methods are validated against reference data wherever possible, and Avogadro tells you what to cite for the methods and tools you used, including those that come from plugins.
A platform to use and to build on. In teaching and research, students and researchers use Avogadro and also extend it through plugins, course projects and research prototypes.
A sustainable community. More maintainers and contributors, mentoring for newcomers, and perhaps an advisory board, so the project does not depend on any one person.
These are proposed rules for deciding what goes in, and where.
Works offline on a laptop or tablet. Workstations, clusters, cloud compute and network services add to that but are never required.
Quality before features. New file readers are tested, changes that affect scientific results come with reference data, and bugs or crashes take priority over new features.
Nothing leaves your computer silently. Every network request is visible to the user and under their control.
Plugins over core; schemas over code. New capabilities arrive as plugins where possible. Protocols and file formats will outlive any one program, so they get the most design care.
Legible outputs. If Avogadro did something, a person can read what it did in the command log, the job script, the input file or the profile it used.
Honest results. Results show their uncertainty and provenance where those matter, so a single number never claims more precision than it has.
Accessible by default. Color is never the only cue, and everything can be reached from the keyboard. Scientific conventions stay the default, with accessible alternatives available.
More and more, Avogadro’s job is to connect the open-science tools that already exist or are emerging. The best builder, analysis method or ML potential usually lives in its own project. Avogadro should make each one easy to use from a molecular editor, and make it easy for that project’s developers to maintain and extend the connection themselves.
Area
Examples
Plugin type
Build tools
PackMol, TurtleMol, ASE and pymatgen builders, framework and supramolecular builders
Menu commands
ML potentials
Models for interactive optimization and MD (supported since 2.0)
Energy models
Simulation engines
OpenMM, LAMMPS, xTB, quantum chemistry codes
Input generators, and backends to run them
Analysis
Trajectory analysis, output parsing, spectra
Menu commands, file formats
Compute
Local, WebMO, clusters, cloud
Backends (proposed)
Several things would help the ecosystem grow:
A quick start. Plugin templates already generate a working plugin; a short tutorial for each plugin type would help.
Stable contracts. Versioned schemas for CJSON, commands and settings, so a plugin written for one release keeps working in the next.
Discovery and trust. Browsing and installing plugins from inside Avogadro, with security scanning and compatibility testing against each release.
Maintainers outside core. Tool developers maintaining their own plugins, with “maintained” and “tested with” labels so users know what they can rely on.
Free automation. Every plugin command becoming a scriptable command with no extra work from its author.
Binary plugins are an open question. IMHO, we should only distribute them if they can be security audited, for example by running them in a sandbox. Suggestions are particularly welcome.
The aim is faster building with fewer mistakes, and features that are easier to find.
Command palette: one searchable box, as in VS Code, for every action and plugin command. For the effort involved, it is probably the biggest gain in discoverability.
More ML potentials. Since 2.0, plugins have provided interactive auto-optimization and molecular dynamics with ML potentials. More models will arrive the same way, ideally maintained by the groups that develop them.
Chemistry linting. Avogadro would flag unusual bond lengths, clashes, odd formal charges and unexpected stereochemistry the way a spell checker underlines words, each with a quick fix.
Autocomplete: faint “ghost” atoms for likely substitutions or ring closures that Tab accepts.
Symmetry-aware editing: edit one site and its symmetry equivalents follow, using point groups for molecules and Wyckoff positions and space groups for crystals.
Snapping and guides for ideal angles and positions, as in a vector drawing program.
Ring fusion to build ring systems, much like chemical drawing programs
Avogadro should make it practical to build, edit, visualize and simulate realistic heterogeneous systems: proteins on nanoparticle surfaces, complex multilayer materials, porous MOF and COF crystals with defects. Much of this will come from linking to dedicated tools.
Ideas from CAD. A collaborator pointed out how much of this CAD tools have already worked out:
Rich selection by chemistry (element, SMARTS pattern, residue, coordination number), by geometry (inside a shape, a slab between two planes, within a distance of a surface), by topology (a connected fragment, a ring, framework linkers versus nodes) and by exposure (surface or solvent-accessible atoms, a crystal facet), plus grow, shrink and “select similar”.
Named selection sets, saved in the file, that commands, scripts and fills can reuse.
Context-aware fills, such as “add this alkanethiol ligand to the cap of this cylindrical nanoparticle, bound through sulfur, pointing along the surface normal, at this density”, “fill these pores with CO₂” or “solvate only this region”. The selection says where and the fragment says what; options set the density, anchor atom and orientation.
A feature tree. CAD’s editable history of operations is the same idea as the non-destructive pipeline described below: change the ligand density and everything downstream rebuilds.
System
What’s needed
Tools to connect
Proteins on nanoparticles
Nanoparticle shapes cut from bulk crystals (spheres, rods, faceted particles), ligand shells, protein placement
Layer stacking, lattice matching with a strain report, interfaces
ASE and pymatgen (existing plugins)
MOFs and COFs
Building from a topology and building units, missing-linker and missing-node defects, pore filling
Reticular framework builders
Packed and solvated systems
Filling volumes at a target density, oriented placement
PackMol, TurtleMol
TurtleMol, a Python packing tool that already ships an Avogadro plugin, is working on oriented placement (for example, thiol monolayers) and defect surfaces, so it fits context-aware fills well. Once a heterogeneous system is built, the hardest step is usually getting simulation parameters for it. ML potentials help, and so would automated force-field atom typing in the OpenMM and LAMMPS input generators (or other similar programs)
The goal is smooth interaction and playback for systems from small molecules up to a million atoms, with publication-quality output when you need it.
Rendering performance. 2.2 will remove the per-frame rebuild for trajectories and moving atoms. Later releases add GPU instancing, culling and level of detail, streamed trajectories, and a updated graphics backends (Metal, Vulkan or Direct3D through Qt’s RHI layer), as laid out in the rendering roadmap.
Background work. Surfaces, file loading and analysis run in the background and appear progressively, so the window never freezes.
Rendering tiers: a fast interactive mode, with ambient occlusion or path tracing on demand for figures.
Figure presets for journal styles, colorblind-safe palettes, and consistent atom sizes across a set of figures.
Ensemble views, where conformer sets, docking poses and ML-model samples appear together as overlays, ghosts or a scrubbable strip.
Materials. 2.2 will bring a native CIF reader with partial occupancy and disorder, flexible crystal packing, Miller planes and slabs, coordination polyhedra, volumetric data in skewed cells, and thermal ellipsoids. Beyond 2.2, the main proposal is a non-destructive pipeline of operations in the style of OVITO, for example supercell 2×2×2 → cleave (111) slab → add a vacancy → relax, where each step stays live, reorderable and toggleable over the original structure. Defect and interface builders would fit in as pipeline steps.
Video editors such as iMovie and Final Cut solved problems much like ours: many versions of one thing, changes over time, and a finished product assembled from many pieces.
Video-editing idea
Avogadro version
Multi-track timeline
Separate tracks for geometry frames, display-style changes, camera keyframes and annotations, so a reaction-mechanism movie can be built inside Avogadro
Skimming
Hover over a strip of conformer or trajectory thumbnails and the 3D view scrubs live; J/K/L keys shuttle through frames
Auditions (alternate clips in one slot)
Alternate tautomers, protonation states or conformers in one slot; cycle through them in place, and downstream analysis follows the active one
Non-destructive effects
The materials pipeline above, and the same idea for molecules: adding hydrogens, optimizing and solvating as reversible steps
Library with smart collections
Saved queries over your structures and results, such as “all conformers within 3 kcal/mol”
Themes and templates
Figure presets, and animation templates for mechanisms
If every action in Avogadro is a named command with recorded parameters, then reproducibility, scripting and AI assistance all come from the same mechanism. The command registry and RPC work in 2.2 are the first step.
Record to script: work through a task interactively, then export the session as a replayable script.
Generalizable recordings. “Replace H7 with a methyl” only works on one molecule, while “replace the hydrogen para to the nitro group” works on a series. Recording selections as chemical patterns (SMARTS) instead of atom numbers would turn a recording into a reusable macro. This is an open research problem, and a good one.
Headless runs that replay scripts without a window, to batch-process structures or regenerate every figure in a paper when the data change.
Notebooks, with Avogadro’s 3D view inside Jupyter via the WebAssembly build, synced both ways with notebook variables.
Provenance. Each structure records what produced it (method, software version, parameters), so Avogadro can draft a computational-methods paragraph for you, with citations for every method, force field, ML potential and plugin involved.
AI assistants via MCP. Avogadro’s commands become tools an AI assistant can call. Each assistant action lands in the undo history with a label, so you can review and revert it step by step, as with tracked changes. Commands declare their effects (changing the molecule, writing files, using the network, starting programs), and you decide which kinds need your approval.
Structural diff, showing which atoms and bonds were added, removed or moved between two versions. That helps when reviewing assistant edits or keeping structures in git.
People liked clicking Submit in an input generator and having a job run. The standalone MoleQueue app is frozen unless a new maintainer wants to take it on, so the proposal is a new backend plugin type that keeps one-click Submit and works across a laptop, a teaching workstation and a cluster.
Backend
What it reaches
local (built in)
Your own computer, with a small queue so a teaching lab’s jobs don’t all start at once
webmo
A WebMO server, via its REST API
slurm-ssh
An HPC cluster over SSH, including cloud clusters running Slurm
cloud-batch
Managed batch services such as AWS Batch or Google Cloud Batch
Later
Globus Compute, HTCondor for the Open Science Grid, AiiDA
molequeue bridge
Existing MoleQueue installs keep working
The protocol extends MoleQueue’s JSON-RPC, so existing input generators keep working. Profiles hold the setup for a cluster and can be shared: a computing center, a research group or an instructor saves a profile with its secrets stripped, and others load it. A shared GitHub repo would collect public profiles. A detailed protocol draft is available for review.
Recipes come next. These are multi-step workflows such as generate conformers → screen with xTB → optimize with DFT → compute NMR shieldings → Boltzmann-weighted spectrum, with explicit solvent as an optional step. Each step runs on whichever backend you choose, and the energy window at each stage can be set from the cheaper method’s known error instead of a fixed cutoff.
Avogadro is used in many classrooms, and these ideas would make it a better teaching tool that everyone can use.
Tutorials that check the result. A step says what should be true (“the molecule has a C=O and the carbonyl carbon is selected”), and the tutorial checks the student’s structure, so it works whichever path the student takes and survives changes to the interface. Coach marks point at the right part of the window.
Recorded lessons. An instructor works an example, and the recording becomes a small, editable, translatable tutorial. Students can pause at any point and “take the wheel”, then hand control back.
Predict, then reveal. Students sketch a dipole direction, guess an orbital’s nodes or apply VSEPR, then compute and compare.
Live sliders. Drag the butane dihedral while the energy curve traces out, or change a HĂĽckel parameter and watch orbital energies and shapes update together.
Interactive figures on the web, with the WebAssembly build embedded in course pages, Jupyter Book or MyST, so readers can rotate, measure and explore a textbook figure.
Teaching-lab compute: the local backend with per-user core caps, and course allocations with locked-down recipes so a class can run real DFT safely.
Accessibility after 2.2. 2.2 delivers the first phase of the accessibility plan. Later work includes colorblind-friendly element schemes, high-contrast modes, generated text descriptions of the current view for screen readers, keyboard navigation of the molecular graph, and alternatives to dragging. These need design discussion and input from disabled users first.
Which of these ideas would change your daily work most, and which would you never use?
Goals: what is missing from the goals?
Community: would you help maintain an area, mentor new contributors, or serve on an advisory board?
Plugins: which open-science tools should Avogadro connect to next? If you develop one, would you maintain its plugin?
Complex systems: what do you build by hand today (nanoparticles, interfaces, frameworks, membranes) that should take one command?
Teaching: what do you need in labs and lectures that isn’t here?
Compute: which clusters, schedulers or services do you use, and would you contribute a profile for your site or group?
Materials: after the crystal tools in 2.2, what is the biggest remaining gap compared with VESTA, OVITO or Mercury?
Recipes: which multi-step workflows do you repeat most (conformers → DFT → NMR, pKa sets, band structures)?
AI assistants: what should an assistant be allowed to do in Avogadro without asking first? Launch the program in the background? Open files? Edit existing files?
Accessibility: if you use a screen reader, magnification or only a keyboard, we especially want to hear from you. How to get involved: reply in the forum thread for this draft or comment on the parts you care about. Many items above split into small, well-bounded pieces, and we will file good-first-issue tasks as each area starts. Larger areas (backends, recipes, recording, tutorials) need people to lead them.
“Record to script” and “Headless runs” is what I really liked about VMD. I would do some operations in the GUI to figure out the desired workflow, and with the history window open, you can see how every GUI operation wraps a Tcl command. I’d copy or export that to a file, simplify and generalize it, then do Tasks for Automation - #8 by erb74 . So not only could I build a reusable workflow, I could understand how it might be extended and learn the VMD Tcl API.
Yes, it’s good for a few reasons, including reproducibility (export a log of all actions), tracking possible citations, and even testing - makes it much easier to find bugs deep in the GUI.
Offscreen rendering is now mostly working. Hopefully we’ll get pretty much every action will be scriptable in 2.2.
I think what you described is now possible in v2.1.