Skip to content

RAVEN 2.11.4 - #760

Merged
edkerk merged 3 commits into
mainfrom
develop
Oct 7, 2026
Merged

edkerk merged 3 commits into
mainfrom
develop

Conversation

@edkerk

@edkerk edkerk commented Oct 7, 2026

Copy link
Copy Markdown
Member

Main improvements in this PR:

Instructions on merging this PR:

  • This PR has develop as target branch, and will be resolved with a squash-merge.
  • This PR has main as target branch, and will be resolved as descriped here.

)

* Fix gurobi solving without Parallel Computing Toolbox

* Report missing WSL when HMMER check fails on Windows

* Update documentation

* Diagnose why the HMMER check fails on Windows

* Update documentation

* Restore and update documentation

* Skip getCurrentTask when Parallel Computing Toolbox is not licensed
* fix: read RAVEN 3 model files, and tolerate a non-double rev

RAVEN 3 and raven-toolbox write YAML this version cannot read. The
metaData map is tagged (`- metaData: !!omap`), which the exact-match case
missed, so the whole block was skipped and the model came back with no
id, name, version or date. A reaction's free text moved from `rxnNotes`
to `notes`, which aborted the read outright with "Unknown entry in yaml
file". EC codes and SMILES moved inside the per-entry `annotation` block,
where they were gathered as MIRIAMs instead of filling eccodes and
metSmiles. An empty gene list is written inline, and the GECKO flag is
spelled `gecko_light`.

All of these are accepted on read now; what this version writes is
unchanged, so its own output stays valid for older RAVEN.

importModel also only found a model note inside a <body>, which RAVEN's
exportModel writes but a writer serialising a notes dictionary does not;
such a writer emits one "<p>key: value</p>" per entry, so the labelled
entry is taken when there is one and the <body> text otherwise.

mergeLinear combines rev with a sparse logical, which MATLAB refuses for
an integer class ("Sparse integer array arithmetic operations are not
supported"). A model built outside RAVEN can carry an integer rev, so it
is coerced once on entry rather than failing several steps into ftINIT.

metComps is documented as an integer column: a reader that turns the
1-based index into a position needs an integer, and MATLAB stores an
integer-valued double narrowed to an integer type in any case.

* docs: regenerate HTML for the changed functions

updateDocumentation regenerates the whole doc/ tree, but the committed
files were generated on Windows and every other one differs only in the
path separator of its index link and title (external\kegg vs
external/kegg). Only the three functions this branch changes are updated,
so the diff stays about the change rather than about the platform it was
regenerated on.

* fix: compare rev rather than coerce it, and cover ftINIT too

The earlier fix coerced reducedModel.rev to double on entry to
mergeLinear, which changed the class of rev in the model it returns --
a type the caller did not ask to have changed.

Comparing instead matches what every other use of rev in RAVEN already
does (rev == 1, rev ~= 0, find(rev)), works for a double, an integer or a
logical alike, and leaves the model untouched. On the released Human-GEM
2.1.0 .mat, whose rev is int64, both forms return the same 8751
reactions with the same S and the same rev values, but the comparison
leaves rev as int64 instead of silently making it double.

ftINIT had the same pattern and the same failure:

    any(prepData.refModel.S(metSel,:) < 0,1) & prepData.refModel.rev.'

a sparse logical combined with rev, which MATLAB refuses for an integer
array. It only runs when metabolomics data is supplied, which is why
#1143 did not reach it. Every other use of rev compares first and is
already class-agnostic.
@edkerk
edkerk merged commit 7b835c6 into main Oct 7, 2026
1 check failed
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