Update neurofly2026.md - #15
Open
admclachlan wants to merge 135 commits into
Open
Conversation
Correct Takemura et al. citation year to 2024
…FlyBase references and collapsible painted-domain lists Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Ohyama2015roi painted domains are loaded in the KB but not yet in PDB, so the report-page links would be dead on the live site. Kept on the rois branch until the data is published. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deprecated in Hugo v0.156.0 and slated for removal; the current build warns on every one of the 31 occurrences. Behaviour is unchanged.
The angle brackets were missing, so the page printed the shortcode source verbatim instead of linking to the tools page. Wrap it in link syntax so the anchor text stays 'tools' rather than the resolved URL.
Renders the existing content/en tree — authored pages, the generated term pages and the home page's Docsy shortcodes — with no content changes and no Docsy. Build it with `hugo --config hugo.nova.toml`; config.toml is untouched, so both sites build from the same checkout and the current one is unaffected. Toolchain: verified on Hugo 0.164.0 standard edition, zero warnings, output byte-identical to the extended edition. The theme ships plain CSS concatenated by resources.Concat rather than Sass, so it needs neither the extended edition (libsass was deprecated in v0.153.0) nor a Dart Sass binary, and no npm step. Fonts and Font Awesome are self-hosted, so there are no runtime CDN requests. hugo.nova.toml sets security.allowContent to permit content/en/_index.html: Hugo >= 0.163 refuses text/html content files by default and the build fails at assembly without it. config.toml will need the same before the Docsy build can move past 0.162. Written for the generated term corpus, which dominates the page count: - no site-wide `where` — counts and listings go through GetPage on a known section, so nothing scans the corpus, least of all from a per-page partial - `len` is checked before `where`/`sort`/`union`, and sections above 400 children are linked rather than enumerated - partialCached around the asset pipeline; head.html branches instead of using `default`, which would extract a summary for every page - services.rss.limit caps the per-section feeds - taxonomy and term kinds are disabled by default, with paginated templates shipped so they can be switched back on Measured with a synthetic corpus shaped like vfbterms.py output: ~1.4 ms and ~60 kB RSS per page, linear. 40,182 pages build in 59 s at 3.6 GB peak. vfbterms.py needs no change — assets/css/compat.css re-implements the Bootstrap classes it emits, scoped to .prose. partials/script-shim.html supplies the slice of jQuery the ontology pages' OLS widget calls, which Docsy used to provide site-wide; that widget has been dead since OLS4 regardless of theme. Dockerfile.nova and .github/workflows/nova-build.yml build and check this config only. The workflow does not deploy.
Replaces the procedural point cloud with geometry from actual models:
body flybody (Vaxenburg et al. 2024, bioRxiv 2024.03.11.584515,
Apache-2.0) — the MuJoCo whole-body model, assembled by walking its
kinematic tree and composing each part's transform at the rest pose
brain VFB JRC2018Unisex adult brain template VFB_00101567
vnc VFB JRC2018UnisexVNC adult VNC template VFB_00200000
ci/build_hero.py does the bake: parse, transform, voxel-downsample and quantise
to int16 into assets/data/hero-geometry.json (158 kB, 66 kB gzipped). The
renderer keeps the network treatment — proximity graph, commissures, travelling
pulses — and applies it to the CNS, which is where the connectomic data is.
Body points are a dim silhouette behind it. Still no libraries, and the
procedural cloud stays as the fallback if the fetch fails.
Not ready to merge:
* the brain reads as a soft cloud rather than a graph — its points are
compact enough to saturate at the size it occupies on screen
* the body silhouette is legible as dust, not as a fly
* the neck connective is drawn as long straight links and looks wrong
* the CNS is drawn at 2x true relative scale (CNS_SCALE in connectome.js);
at 1x the brain is a 60px smudge. That is a figure convention and needs
to be either accepted and documented or replaced with a better idea
* NeuroMechFly / flygym (NeLy-EPFL, Nature Methods 2024) is probably the
better body source — its geometry is x-ray microtomography of a real fly.
build_hero.py is parameterised on one MuJoCo XML plus a mesh directory, so
swapping it is a small change
Kept off feature/vfb-nova-theme, which is complete and unaffected.
Scaling the two structures about a shared centroid threw the brain forward out of the head. Each is now enlarged about its own centroid and pulled slightly towards the other, which keeps the bake's placement — central brain and optic lobe in the head, thoracico-abdominal ganglion in the thorax — and shortens the cervical connective to something plausible. Still outstanding: the brain renders as a cloud rather than a graph, the body silhouette does not read as a fly, and the assembly needs recentring in frame.
Side-on, the six splayed legs dominate and the thing reads as a spider rather than a fly. Two changes: - Default view is now three-quarter/near head-on (VIEW.yaw, negative swings the head towards the camera; 0 is lateral). This foreshortens the legs and turns the brain's widest axis — medio-lateral — towards the viewer, so the optic lobes and central brain resolve as a graph instead of a smudge. - Legs and wings are classified geometrically and drawn at roughly a third the alpha of the head, thorax and abdomen. VIEW is overridable via window.__heroView for trying angles without a rebuild.
The brain was not aligned in the head, for two reasons. First, it was drawn at 2x. The reference figures make the point that in a fly the brain fills the head capsule, so an enlarged brain is necessarily larger than the head it is supposed to sit in. The exaggeration was solving the wrong problem — the brain is small relative to body LENGTH, not relative to the head — so it is gone and everything is at true scale. Second, the axis mapping was hand-picked, which put the brain's 580um medio-lateral axis onto a head axis about 535um across. fit_into() now ranks the structure's and the cavity's extents and pairs them, with one axis pinned rather than ranked: the model is bilaterally symmetric about y, so y IS medio-lateral, and the head capsule is near-square in its other two axes (905 vs 913um) — left to ranking alone, the brain's orientation would be decided by a coin toss and it could end up stood on its side. Fitting the brain to 90% of the head capsule independently reproduces a scale of 1e-4, which is exactly the micron-to-centimetre conversion. That is a useful check: the anatomy and the arithmetic agree. Head, thorax and abdomen are also drawn more strongly than the appendages now, so the capsule the brain sits in is actually visible.
JRC2018Unisex does not include the lamina — the optic lobe in that template starts at the medulla — so scaling the mesh to fill the head capsule pushed the medulla out to where the lamina and retina actually are. Size now comes from the micron-to-centimetre conversion and fit_into() is used only to orient and centre. The resulting gap between the mesh and the eye is correct for what the mesh contains rather than an alignment error, and the README says so.
window.__heroView now takes cx, cy and zoom as well as yaw/pitch/sway, so the visual can be centred and framed for review without the hero's text column and news panel in the way. Defaults are unchanged.
Two orientation errors, both mine. The VNC was 90 degrees out. fit_into() pinned the structure's WIDEST extent to the midline, which is correct for the brain (580 x 259 x 159 um, widest IS medio-lateral) but wrong for the VNC (422 x 177 x 127 um, widest is antero-posterior). The leg neuromeres were stacked across the body instead of running along it. long_axis now says per structure which model axis the longest extent belongs on, so the neuromeres bulge towards their leg pairs and the abdominal neuromere sits at the posterior end. The brain was inverted — the central complex V has to point ventrally. This is flipped explicitly rather than inferred: the medio-lateral taper test I tried does not separate the two ends reliably (0.0101 vs 0.0139 for the brain, 0.00298 vs 0.00303 for the VNC, which is a coin toss). Shape statistics are the wrong tool. The principled fix is to take the axes from VFB's own painted domains on each template — antennal lobe ventro-anterior, calyx dorso-posterior, abdominal neuromere posterior — which removes the guesswork entirely. Not done here.
The VNC was sideways and back-to-front. Root cause is the same one that put the
brain on its side earlier: fit_into() decided the two non-pinned axes by ranking
the CAVITY's extents, and the cavities are near-square in exactly those pairs —
the head is 905 vs 913 um, the thorax 0.1060 vs 0.1077 cm. Both were settled on
a hair's breadth and both settled wrongly.
Cavity ranking is gone. axis_ranks now states, per structure, which model axis
takes which of its extents by rank:
brain (1, 0, 2) longest medio-lateral -> y, next antero-posterior -> x,
shortest dorso-ventral -> z
VNC (0, 1, 2) longest head-to-abdomen -> x, next left/right -> y,
flattest towards back and wings -> z
VNC also flipped in x: the abdominal neuromere was facing the head.
Default view is now yaw pi — the lateral view from the fly's other side, which puts the head to the left and the abdomen trailing right, rather than mirroring the image. Framing moved right and up so the head and brain clear the headline and sit above the news panel. VNC offset moved forward in the thorax (x -0.008 -> +0.014) so it sits close under the neck connective instead of trailing back towards the abdomen.
Follows on from adding vfb-nova alongside Docsy: it now replaces it rather than
running in parallel.
Removed:
themes/docsy submodule, and the stale hello-friend-ng submodule entry
config.toml
layouts/ — project-level overrides that existed only to patch Docsy
(404, head, footer, scripts, favicons, page-meta-links, content).
robots.txt, sitemap.xml, button and email were ported into the
theme, so nothing is lost.
assets/scss/ — the two Docsy variable/style override files
package.json — autoprefixer/postcss-cli/postcss, needed only by Docsy
Dockerfile.nova — folded into Dockerfile
hugo.nova.toml becomes hugo.toml, so `hugo` and `hugo server` work with no
--config flag. With the Docsy overrides gone the theme no longer has to be
mounted around them, so the explicit layouts/assets/static module mounts are
replaced by `theme = "vfb-nova"`; the content/en -> content mount is the only
one still needed.
deploy.sh drops from ~20 lines to one `hugo --gc --minify`. The npm, yarn,
postcss and `hugo mod clean/graph` calls were all Docsy's requirements, as was
running hugo twice. It still does NOT pass --enableGitInfo: hugo.toml sets
enableGitInfo=false and the flag would override it, and collecting git metadata
across the generated term corpus is expensive for something nothing uses.
Dockerfile and docker-compose.yaml move from klakegg/hugo and docsy/docsy-example
to ghcr.io/gohugoio/hugo:v0.164.0. Standard edition — no extended, no Dart Sass,
no Node. netlify.toml's HUGO_VERSION goes 0.88.1 -> 0.164.0.
The Rancher `hugo` service still needs the same image change; rcourt/docsy-builder
predates the 0.128.0 minimum. Serving is unaffected: same public/ output on the
same NFS volume behind the same nginx fileserver.
Verified on Hugo 0.164.0 standard: 186 pages, zero warnings, zero errors, with
no --config flag and from a clean tree.
deploy.sh wrote straight into /src/public, which is the NFS volume nginx serves. A full run over the generated term corpus takes minutes, and a theme change rewrites every page, so an in-place build serves a mixture of old and new markup — with fingerprinted asset URLs that may not exist yet — for the whole window. Build now goes to a staging directory and is rsynced into place afterwards. rsync -a --delete-after replaces pages one at a time and defers removals to the end, so no page is ever missing mid-run. A directory swap is not an option: public/ is bind-mounted into the nginx container, which holds the old inode and would not follow a rename. Two gates before publishing: index.html and sitemap.xml must be non-empty, and a build with more than 10% fewer pages than the live site is rejected. The term corpus comes from an API that can fail partially, so a sudden shrink is much more likely to be a truncated vfbterms run than a real deletion. ALLOW_SHRINK=1 overrides. Dockerfile adds bash, rsync and findutils on top of the official Hugo image, which is Alpine-based. STAGE_DIR, RSYNC_OPTS and HUGO_CACHEDIR are overridable; the staging tree and Hugo's cache both default onto the existing /tmp cache volume.
Robbie1977/docsy-builder is a fork of docsy-example. Its only functional content is a two-line Dockerfile — klakegg/hugo:ext-alpine plus git — and everything else is Docsy's demo content. With Docsy gone the name is wrong and the content is dead weight, so it should be retired rather than rewritten. ci/builder-image.yml publishes this repo's Dockerfile as virtualflybrain/vfb-static-builder using the org-level Docker Hub secrets, and smoke-tests that hugo, rsync, bash and find are present. That keeps the builder versioned alongside the site it builds. If a custom image is unwelcome, the alternative is to run the official Hugo image unmodified with the container doing only the hugo build, and move the rsync step into the Jenkins job where rsync already exists.
0.164.0 is the newest stable release (2026-07-06) and the site builds clean on it: 186 pages, no WARN, no ERROR. Pin rather than track :latest so rebuilding the image cannot silently change the site. Correct the Dockerfile rationale. The claim that rcourt/docsy-builder:Feb2023 predated the theme's minimum was wrong: it carries Hugo 0.122.0 extended and does build this branch, byte-identical CSS and JS against 0.164.0. The real reasons to replace it are that it has no rsync, which deploy.sh needs, and that it warns about the minimum theme.toml declares. Record that the base is Alpine 3.22, that the upstream image already carries git, Node, npm and Dart Sass, and that running as root is deliberate because the published tree on the NFS volume is root-owned. The official image sets WORKDIR to /project, so compose needs an explicit working_dir for the source mounted at /src. Drop the obsolete version key. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
The official Hugo image ships ENV HUGO_CACHEDIR=/cache. deploy.sh reads
${HUGO_CACHEDIR:-/tmp/hugo_cache}, so the default never fires and the cache
lands in the container's writable layer rather than the volume mounted at
/tmp: discarded on every run, and consuming host disk in between. The
floryn90 image it replaces put the cache on /tmp, which is why this did not
bite before.
Set WORKDIR to /src for the same reason — upstream sets /project, which is
not where the Jenkins workspace is mounted. deploy.sh cds to $SRC either way,
but the image should not disagree with the service it runs in.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
Smoke-test the tag the run actually pushed. It tested :latest, which metadata-action only emits on the default branch, so a tag-triggered or manual run would have failed against an image that does not exist. Also assert HUGO_CACHEDIR, working directory and uid, since all three are set in the Dockerfile specifically to override upstream defaults and nothing else would catch a regression. Bump build-push-action to v6 and add setup-buildx-action, matching vfb-status and vfbquery, which already publish into the virtualflybrain namespace with the same org secrets. Make the header say plainly that the image does not exist until this file is moved into .github/workflows/, and correct the description of Robbie1977/docsy-builder: it is a copy of docsy-example rather than a fork, and the Dockerfile on the branch that built the live image is floryn90/hugo:ext-alpine, not klakegg. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
Feature/vfb nova theme
Hugo takes an flock on .hugo_build.lock at startup and waits for it indefinitely with no message, no error and no timeout. The observed symptom is a build that copies the static files and then stops: 66 files and 16 MB in the staging tree, a sleeping process at near-zero CPU, low RSS, and no further output. Reproduced exactly by holding the lock against an otherwise healthy build. The workspace is on NFS, where a lock left by an uncleanly killed build outlives the process that took it, so this recurs on its own. The lock also guards against a concurrent second build, which cannot happen here: the container is the only builder and Rancher runs it start_once. It protects nothing and fails invisibly. Clear any stale lock file as well, so nothing is left lying around now that Hugo no longer manages it. Verified: with the lock held, the build now completes rather than hanging. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
…data A reviewer asked our chat assistant how many neurons are in the fly brain and it could not answer. The resolution bug is being fixed separately; this addresses the harder half, which is that the question has no single answer and we had nowhere authoritative to point. Two artefacts, one source of truth: - content/en/docs/Concepts/neuron-counts.md — the article. Why the question is under-specified, what each connectome VFB holds actually counted, what dense versus sparse reconstruction means, what flood-filling and proofreading still miss, and what people quoted before connectomics existed. - static/data/fly-neuron-counts.json — the same facts machine-readable, so VFBchat and the MCP can read the figures rather than each hard-coding them. Published at /data/fly-neuron-counts.json. Every figure was checked against its primary paper; two that could not be retrieved from the original are flagged verified:false rather than quietly included. Findings worth flagging to curators: - "~100,000 neurons" has no traceable primary measurement. It appears uncited in the papers that popularised it. - The three real non-connectome measurements disagree by 2.5x, two of them using the same technique. - FlyWire's own count moved 127,978 to 139,255 between preprint and Nature. A connectome count is a property of a release, not of a fly. - Nern et al. traced the optic lobe from part of the male CNS volume, so those two datasets are the same animal and must never be summed. - VFB DatasetImages counts are NOT neuron counts: the ratio to the published figure ranges 0.92 to 2.78 across our five datasets and does not run in a consistent direction. Also note get_term_info reports count:-1 for DatasetImages, which is the unavailable sentinel and not zero. Two knowledge-base curation items are recorded in the JSON: Bates2025 still cites only the preprint DOI (the Nature version of record is now PMID 42259917) in both Publications and Meta.Description, and Berg2025's Technique reads SBFSEM where the paper describes eFIB-SEM. Nern2024 needs no citation fix — its Publications field already carries the 2025 version of record; only the dataset id and label strings still read 2024. The data file is in static/ rather than data/ so it publishes at a stable URL with no change to hugo.toml. Hugo is not available in the environment this was prepared in, so nothing here alters the build configuration. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…undamentals Add a verified reference on Drosophila neuron counts, as page and as data
static/data/fly-neuron-counts.json could never be served. /data/ on this site is routed the same way as /reports/, treating the path segment as a dataset id, so a static file there is unreachable no matter how the site is built. Verified: an existing page under a working namespace (/docs/concepts/nblast/) returns 200, while /data/fly-neuron-counts.json returns 404. That also made the article's intro line false — it told readers a machine-readable version was published at a URL that cannot exist. Removed. No functionality is lost. The operative copy of this data ships inside the VFBchat image at config/fly-neuron-counts.json and is read in process, precisely so a figure never depends on a fetch succeeding. There is now no published mirror and no drift risk between two copies: curators edit the repo file. The article page itself is unaffected and stays — /docs/concepts/ is a normal content namespace, and it is the URL VFBchat's reviewed-docs index points at. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous commit's git rm was refused because the file had an uncommitted local edit, so it was committed as modified rather than removed. Deleted here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ta-mirror Drop the data mirror: /data/ is a routed namespace, not free space
Add "Which fly is this?" and the missing technique pages
…ers-citing Add the Heinze quote to the papers-citing-vfb page
Add a /search/ page that takes a query string
Expand the papers-citing-VFB page and make the sampling explicit
Rewrite the publications page as the group's VFB-related work
Publish an OpenSearch description so browsers can search VFB
The FANC page cited Fushiki et al., "A circuit mechanism for the propagation of waves of muscle contraction in Drosophila" — a larval paper (eLife 2016) — while carrying the correct Cell volume, issue and DOI for the FANC dataset paper. Only the title and first author were wrong, so the error was invisible next to a resolvable DOI. FANC is Phelps, Hildebrand, Graham et al. (2021), Cell 184(3), 759-774.e18, doi:10.1016/j.cell.2020.12.013. Elocation corrected from .e20 to .e18 to match Crossref. content/en/docs/Data/EM/_index.md already cites Phelps et al. against the same DOI, so the site is now internally consistent.
Correct the FANC source publication citation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.