Skip to content

writeYAMLmodel: nest ec-rxns enzymes; printOrange: print \n as line break - #751

Merged
edkerk merged 2 commits into
develop3from
fix/yaml-enzyme-indent-printorange-newlines
Sep 11, 2026
Merged

edkerk merged 2 commits into
develop3from
fix/yaml-enzyme-indent-printorange-newlines

Conversation

@edkerk

@edkerk edkerk commented Sep 11, 2026

Copy link
Copy Markdown
Member

Two issues found while running GECKO 4's full_ecModel tutorial against RAVEN 3.0.0b1 (see SysBioChalmers/GECKO#481 and CompMetEng/geckopy#54).

writeYAMLmodel: ec-rxns enzymes are not nested under their key

Each ec-rxns entry writes its enzyme stoichiometry as an !!omap under - enzymes, but the enzyme lines were written at the same indentation as that key:

  - !!omap
    - id: r_0001_EXP_1
    - kcat: 5.77
    - enzymes: !!omap
    - P00045: 1.0        # sibling of "enzymes", not inside it
    - P32891: 1.0

readYAMLmodel ignores indentation and reads this back correctly. A YAML parser, however, sees an empty enzymes mapping. ruamel.yaml, as used by raven-toolbox and geckopy, fails with 'ScalarNode' object has no attribute 'flow_style', so no ecModel saved from GECKO 4 can be opened in geckopy. The enzyme lines are now two spaces deeper, as the coefficients under - metabolites already are.

Verification:

  • The GECKO full_ecModel tutorial's stage-2 ecModel was re-saved with the fixed writer. RAVEN reads it back with identical rxnEnzMat and kcat.
  • geckopy now loads that file (4834 ec reactions, 5418 enzyme links) and gives the same maximum growth as MATLAB (0.1158 /hour). The file from the current writer fails to load.

printOrange: \n printed literally

Since printOrange prints via fprintf('%s', …) so that a % in model text is not treated as a format directive, \n is no longer expanded either. Callers that end a message with \n print a literal backslash-n with no line break: 15 calls in RAVEN and 17 in GECKO, including GECKO 4's backward-compatibility notice:

NOTE: This is GECKO 4, which is not fully backward-compatible\nwith GECKO 3.

printOrange now turns \n into a line break; no other escape sequence or format directive is interpreted, so % still prints as-is. All callers in both repositories use only \n.

Tests

  • New tests, each failing on develop3 and passing here: tIO/writeReadYAMLNestsEcRxnEnzymes (indentation plus round trip of ec.enzymes/rxnEnzMat) and tUtils/printOrangeExpandsNewlineWhenPrinting.
  • tIO and tUtils pass locally (MATLAB 2024b); the two parallelWorkersRAVEN tests are filtered by their assumptions on this machine, as before.

Each ec-rxns entry writes its enzymes as an !!omap under "- enzymes",
but the enzyme lines were written at the same indentation as that key.
readYAMLmodel does not look at indentation and reads them back, but a
YAML parser sees an empty "enzymes" mapping followed by sibling keys:
ruamel.yaml, as used by raven-toolbox and geckopy, fails with
"'ScalarNode' object has no attribute 'flow_style'", so no ecModel
saved by GECKO 4 could be opened in Python. The lines are now indented
two spaces deeper, like the metabolite coefficients under
"- metabolites".

Tested by re-saving the GECKO full_ecModel tutorial's stage-2 ecModel:
RAVEN reads it back with identical rxnEnzMat and kcat, and geckopy now
loads it (4834 ec reactions, same maximum growth as in MATLAB).
printOrange prints its text with fprintf('%s',...) so that a "%" in
model text is not read as a format directive. That also stopped "\n"
from being expanded, and every caller that ends a message or breaks a
line with "\n" printed a literal backslash-n instead: 15 calls in RAVEN
and 17 in GECKO, including GECKO 4's backward-compatibility notice.
printOrange now turns "\n" into a line break; no other escape sequence
or format directive is interpreted.
@github-actions

Copy link
Copy Markdown

Function test results

390 tests   351 ✅  1m 28s ⏱️
 24 suites   39 💤
  1 files      0 ❌

Results for commit 3cbe5c1.

@edkerk
edkerk merged commit 29bcc55 into develop3 Sep 11, 2026
4 checks passed
@edkerk
edkerk deleted the fix/yaml-enzyme-indent-printorange-newlines branch September 11, 2026 21:15
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