Skip to content

Update logo for RAVEN 3 - #708

Merged
edkerk merged 1 commit into
develop3from
update-logo-v3
Aug 28, 2026
Merged

Update logo for RAVEN 3#708
edkerk merged 1 commit into
develop3from
update-logo-v3

Conversation

@edkerk

@edkerk edkerk commented Aug 28, 2026

Copy link
Copy Markdown
Member

Summary

  • Drop the version number and "THE" from the wordmark so the logo no longer needs updating each release
  • Switch the wordmark font to Century Gothic Bold, keeping the existing raven silhouette
  • Rename RAVEN2.png to RAVEN.png and update the references in README.md, _config.yml, and installation/findRAVENroot.m (which also uses the file as a functional root marker)

Test plan

  • Verified RAVEN.png renders correctly and matches the original's proportions
  • Regenerate doc/installation/findRAVENroot.html (auto-generated via m2html) on next docs build to pick up the filename change

Drop the version number and "THE" from the wordmark so the logo no
longer needs updating each release; switch to Century Gothic Bold.
Rename RAVEN2.png to RAVEN.png and update references accordingly.
@edkerk
edkerk merged commit 32a8348 into develop3 Aug 28, 2026
4 checks passed
@github-actions

Copy link
Copy Markdown

Function test results

303 tests   277 ✅  1m 5s ⏱️
 25 suites   26 💤
  1 files      0 ❌

Results for commit 717565e.

@edkerk
edkerk deleted the update-logo-v3 branch August 28, 2026 08:37
edkerk added a commit that referenced this pull request Aug 28, 2026
The hard error broke CI: checkInstallation's own setpref, moments
later re-read by checkFunctionUniqueness's separate findRAVENroot
call, disagreed with RAVEN.png's presence in a way that only reproduced
on the CI runner, cascading into ~40 failing test classes. Reverted to
silently falling through to resolving the root from the executing file,
matching every prior passing run --- still validated (an invalid stored
preference is not trusted), just not fatal.

Also: RAVEN2.png was renamed to RAVEN.png upstream (#708, picked up by
merging origin/develop3); the preference-validation branch had missed
that rename since it has no equivalent on the upstream side to merge
against.
edkerk added a commit that referenced this pull request Aug 28, 2026
)

* Fix stale RAVEN root preference and skip unneeded HMM download

findRAVENroot now validates a stored MATLAB preference against
RAVEN2.png before trusting it, instead of blindly returning a path
that may belong to a different RAVEN checkout on the same machine.

getKEGGModelForOrganism only downloads the ~100+ MB HMM library when a
FASTA file is actually supplied; the annotation-only path never uses
libraryFile, so the download was pure waste on that path.

* getModelFromKEGG: build the global model from raven-data artefacts

keggModel.mat was never shipped in the repository and had no working
way to be regenerated, so any reconstruction for an already-annotated
KEGG species failed outright (issue #704).

getModelFromKEGG now downloads and assembles the same data from the
raven-data kegg118 release instead: the gene-free reference model plus
the ko_reaction/organism_gene_ko/rxn_flags relational tables published
by the raven-toolbox Python package. Every organism's genes are joined
onto the reference reactions through their shared KO ids using two
sparse incidence matrices (gene-KO, KO-reaction) multiplied together,
since organism_gene_ko can carry millions of rows and a per-row loop
isn't viable. The assembled result is cached to keggModel.mat exactly
as before, so this only costs the (slow, ~150+ MB) build once.

getPhylDist/keggPhylDist.mat is unaffected: that file is already
committed to the repository and was never part of this issue.

* findRAVENroot: error on a stale root preference instead of falling back

A stored preference pointing at a directory without RAVEN2.png now
throws immediately, naming the bad path and how to fix or clear it,
rather than silently falling back to resolving the root from the
currently executing copy of RAVEN.

* kegg: generalize the raven-data fetch helper, centralize the KEGG version

fetchKEGGArtefact only ever downloaded the kegg118 core bundle. Replaced
it with fetchRavenDataAsset, which takes the release tag and asset name
as arguments instead of hardcoding kegg118 --- so it can also serve the
HMM library download in getKEGGModelForOrganism (previously its own
inline websave/try-catch), and any future raven-data asset that isn't
KEGG at all.

The "kegg118" string itself now lives in exactly one place,
reconstruction/kegg/KEGG_VERSION.md, read via the new keggDataVersion.
Everywhere else that named it directly (buildGlobalKEGGModel's artefact
names, getKEGGModelForOrganism's HMM library names/URL) now reads it
from there, so a future KEGG release only needs that one file bumped.

* Move fetchRavenDataAsset to installation/

It isn't KEGG-specific --- it downloads any raven-data release asset by
tag and file name --- so it belongs alongside downloadRavenBinaries,
which fetches from the same repository, rather than under
reconstruction/kegg/. No behaviour change.

* downloadRavenBinaries: use the shared fetchRavenDataAsset helper

Replaces its own inline websave/try-catch (and the now-redundant base
URL variable) with the same download-with-cache helper KEGG artefacts
and the HMM library already use, since it downloads from the same
raven-data repository. No behaviour change beyond the shared helper's
messaging.

* findRAVENroot: revert to silent fallback, fix RAVEN.png rename

The hard error broke CI: checkInstallation's own setpref, moments
later re-read by checkFunctionUniqueness's separate findRAVENroot
call, disagreed with RAVEN.png's presence in a way that only reproduced
on the CI runner, cascading into ~40 failing test classes. Reverted to
silently falling through to resolving the root from the executing file,
matching every prior passing run --- still validated (an invalid stored
preference is not trusted), just not fatal.

Also: RAVEN2.png was renamed to RAVEN.png upstream (#708, picked up by
merging origin/develop3); the preference-validation branch had missed
that rename since it has no equivalent on the upstream side to merge
against.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant