Graphical interface

rbfenet plan has some sixty knobs. Choosing among them from the command line means running it, opening the report, changing a flag, running it again, and holding the previous answer in your head. rbfenet gui closes that loop: move a knob, see the network and its metrics, pin the run, move another knob, compare.

rbfenet gui --ligands ligands.sdf

Loaded 16 ligand(s).
rbfenet gui listening on http://127.0.0.1:8765/  (ctrl-c to stop)

It is part of the package, not an extra: the server is standard library only, and there is nothing to install beyond what planning already needs.

--ligands takes what it takes everywhere else – SDF, mol2, .smi, directories, or several of them at once – and so does the box in the page, which additionally expands a pattern like data/*.mol2 for you, since there is no shell behind it to do that.

The form is the command line

Every control on the page is generated from the CLI’s own argument parser, and the filled form is turned back into flags that rbfenet plan parses. The GUI holds no list of knobs of its own.

That is worth stating plainly because of what it buys. A flag added to the CLI appears in the form with no change to the GUI. Every refusal you see – an edge budget too small to span the ligands, a --compat level contradicting a knob it pins, a soft-core threshold out of range – is the CLI’s own message, not a second opinion about it. And the page can always show you the exact command that produced what you are looking at:

rbfenet plan --ligands ligands.sdf --planner redundant-mst --n-redundancy 3 --cbfe bridge

Copy that into a job script and you get the network on the screen. Exploring interactively and running reproducibly are the same activity, rather than two that have to be kept in agreement by hand.

What it shows you that the command line cannot

Knobs the chosen planner will ignore are greyed out. star, explicit and complete accept some fourteen network flags and then never read them; only --design and --cbfe are refused out loud, by the planner’s own support checks. The form marks the rest rather than letting you tune something that cannot take effect. --pair-evaluation adaptive gets the same treatment: it is honoured only by the mst planner and falls back to eager evaluation under any other.

Knobs that cannot change the network are labelled. --design-total-ns and the lambda bounds are read by the Amber exporter when it writes runconfigs. They are worth setting and they will not move an edge, so the page says so instead of leaving you to wonder why the diagram did not change.

Peak mapping memory is estimated as you type. FindMCS allocates monotonically and frees nothing until it returns, at roughly 40 MB per second of --mcs-timeout per job, so the defaults of 60 s and 8 jobs are some 20 GB before a single candidate is retained. The page works that out from the two knobs and warns before you start the run rather than after the machine has begun swapping.

Why a second run is faster

Mapping is where a plan spends its time, and it is the one stage that does not depend on which planner runs afterwards. Over the shipped Tyk2 set – sixteen ligands, a hundred and twenty pairs – a full plan takes about 2.1 s, and takes about 2.1 s for every variant in the published matrix whatever the selection knobs; the same run with --cbfe all, which skips mapping entirely, takes 0.5 s.

So the GUI remembers atom correspondences. Moving a selection knob re-runs the repair and the scorer, which are cheap, while the MCS searches come back from a cache. Failed mappings are remembered too: a pair no search can relate is exactly the one that costs a full --mcs-timeout to fail, and its answer cannot change when a planner knob moves.

--cache-dir keeps that across sessions, which makes the second launch fast rather than only the second run:

rbfenet gui --ligands ligands.sdf --cache-dir ~/.cache/rbfenet

The cache is keyed on the molecules’ atom blocks, the mapper, and the mapping options, so editing a ligand file or changing --mcs-timeout correctly misses. Nothing in it can go stale into a result: everything cached is recomputable, and a damaged cache file is discarded with a warning rather than raising.

Running it on a cluster

The server binds the loopback interface. To use it against ligands on a remote machine, forward the port rather than binding a public one:

ssh -L 8765:127.0.0.1:8765 user@cluster
# then, on the cluster:
rbfenet gui --ligands /scratch/ligands.sdf --no-browser --cache-dir ~/.cache/rbfenet

--host will bind elsewhere and warns when you ask it to. The server plans networks from any ligand path it is given, runs with your privileges, and has no authentication; it is a local tool, and it is not written to face a network.

Options

--ligands PATH...     Ligands to load at startup. Optional; a file can be chosen in the page.
--name-property PROP  Molecule property to read ligand names from (default: _Name).
--host HOST           Interface to bind (default: 127.0.0.1).
--port PORT           Port to bind (default: 8765). 0 picks a free one.
--no-browser          Do not open a browser window.
--cache-dir DIR       Persist mapped atom correspondences between sessions.

What it does not do

It plans and it compares. It does not export: a run offers its network.json and its full HTML report for download, and everything downstream – Amber setup, surgery and replanning – stays with the CLI and the Python API. Nor does it expose knobs the CLI has not got, such as the FindMCS settings on MappingOptions or the fields of CostModel. A knob the GUI had and the command line could not express would break the one property the whole design rests on.