[briza81]

1. Optional mmCIF output in the sb-ncbr tunnels schema

calcChannels and calcPoresFromChannels gain output_format — 'pqr' (default, unchanged behaviour) or 'mmcif'.
The schema is the one MOLEonline and ChannelsDB publish tunnels under (sb-ncbr/tunnels-schema v1.0). It puts the profile, the layers and the lining residues of every channel in one file with
keys joining them, where this module otherwise spreads them over a PQR and two text tables joined only by filename convention.

Seven of the schema's eight categories are written. sb_ncbr_channel_annotation is
omitted: it records ChannelsDB literature annotation, not a property of a de-novo
trace.

Notes on the mapping, since the schema fixes no vocabulary for them:

• .type follows MOLE — a channel is a Tunnel, a pore a Pore, a chamber link a Path. Links share the channels file, told apart by this column, unlike the PQR output which keeps them separate.
• Physicochemical properties use the scales MOLE's method page names — Kyte & Doolittle, Cid et al. 1992, Zimmerman et al. 1968, Jones/Taylor/Thornton 1992, and MOLE's own logP/logD/logS fragment tables. Every item carries a value except bRadius, which needs B-factors.
• Properties are averaged over standard residues only, as the schema defines them ("a sum of charged amino acid residues") and as MOLE computes them. Where a lining holds anything else, the covered fraction and the uncovered residue names go to the log and into the file as a comment above the properties — the schema has nowhere to record them
• separate has no meaning for mmCIF (the value of the format is the joins between its categories) and is ignored.
• Multi-frame writes one .cif per frame, as the PQR path already does; the schema describes one structure.

Cost: +0–6% over the trace, ~11 ms per channel, scaling with channel count rather than structure size. File size is ~2–3× the PQR, dominated by the layer_residue join. Nothing is computed on the PQR path.

Viewer: one vis_channels.py now serves both formats, with the same group names and the same colour per rank, so a channel is the same colour whichever way the run was written.

---

2. The lining is measured to the atom surface, not its centre

distA becomes a clearance between van der Waals surfaces rather than a centre-to-centre distance, and its default moves from 2.5 to 1.5 Å.

This changes which residues are reported as lining a channel. Both radii belong in the criterion: without the probe radius a fixed distA reaches a different depth depending on how wide the channel is, and without the atom radius the reach past an atom's own surface varies by element — widest at hydrogen, negative for the alkali and alkaline-earth ions, which then had to overlap the probe before being reported at all.

Residues lying inside the route rather than beside it are now reported separately. They are usually an ion or cofactor the tessellation never saw — a real result — but can also indicate that the structure passed to the report is not the one the channels were traced on.

3. VDW_RADII overhauled and every lookup hardened

The table mixed scales without recording any of them; Bondi's transition metals are effectively metallic radii, so ZN sat a full Ångström below every modern determination. Each block now names its source (Bondi family where it agrees with
Alvarez, Alvarez for the metals, alkali/alkaline earths and f-block). 42 elements added, 27 values changed, none of them protein-forming.

Lookups are case-insensitive and fall back on a named UNKNOWN entry, announcing the substitution once rather than raising KeyError. Previously a metalloprotein handed over whole failed at the report rather than the trace — the wrong end to fail at.

4. prune_narrow_edges, off by default

CAVER-style pruning of sub-probe Voronoi edges. Without it the search routes through gates narrower than the probe and the channel is discarded afterwards by the bottleneck filter, which loses corridors: a cheap pinched route wins the exit, is
dropped, and the wider route to the same mouth is never reported. MOLE filters, CAVER prunes, and the option picks. Off by default — 4 of 22 test cases gain channels, none loses any.

---

Bug fixes in the multi-frame path

stop_frame was off by one in calcChannelsMultipleFrames's multi-model branch.
The sentinel -1 was passed straight into a Python slice, where it means "one before the end" rather than "all", so the last model was silently dropped; positive values were taken exclusively where the docstring promises inclusively. The
function's own trajectory branch and the surface-cavity equivalent were correct, so one function disagreed with itself depending on how frames were supplied. All call sites now go through one _frameBounds() helper, so the branches cannot drift apart again. Out-of-range values are clamped rather than raising, since callers had written stop_frame=numCoordsets() to work around the exclusive behaviour. getSurfaceCavityResidueNamesMultipleFrames gains the stop_frame its docstring had always documented but which was never read.

trajectory= rejected every in-memory ensemble. The frame cursor _nfi exists only on a file-backed DCD, and the branch above it converts an Atomic argument into an Ensemble — precisely the type that could not survive the next line. AtomGroup, Ensemble and PDBEnsemble now work alongside DCDFile and Trajectory; a DCD's position is still saved and restored.

Empty results left an empty file. A run finding nothing now writes no file at all

[briza81]

@karolamik13 please have a look, these include all we discussed, with several minor fixes. After this is resolved, no code changes are expected, unless bugs are to be fixed :)

[karolamik13]

I tested the code on multiple examples (single PDBs, multi-model PDBs, trajectories, etc.) -- looks good. The CIF file saved from channels seems to be fine. I don't have experience with this format. I was not able to check it with some visualization programs, but I have checked the CIF file with gemmi (see below; the number of channels is correct, and the CIF passes validation).

CIF validation: PASS
Number of channels: 9
Number of profile points: 720
channel0 points = 40 length = 5.129
channel1 points = 50 length = 5.282
channel2 points = 70 length = 5.082
channel3 points = 65 length = 5.489
channel4 points = 65 length = 5.646
channel5 points = 110 length = 15.127
channel6 points = 160 length = 24.036
channel7 points = 90 length = 16.683
channel8 points = 70 length = 9.312

[karolamik13]

For those who would like to visualize channels in PyMol:

from prody import *
p = parsePDB('1tqn')
atoms = p.select("protein")
channels, surface = calcChannels(atoms, output_path='.', output_format='mmcif', separate=True)

and then except channels also "vis_channels.py" is created.

Next (after gunzip 1tqn.tar.gz or downloading uncompressed pdb file):
pymol vis_channels.py -- 1tqn.pdb channels.cif