View on GitHub

IntaRNA

Efficient target prediction incorporating accessibility of interaction sites

JSON parameter files

IntaRNA --parameterFile=parameter.json accepts the same CLI option names and values as a legacy key = value file. Detection uses the first non-whitespace character, after an optional UTF-8 BOM, independent of the filename suffix. Legacy files remain supported. Explicit scalar CLI options override file values; composing options such as out accumulate as before. A file’s personality selects defaults before parsing; an explicit CLI personality takes precedence.

{
  "schema": "IntaRNA-parameters-v1",
  "_comment": ["Reproduce: IntaRNA --parameterFile=parameter.json"],
  "parameters": {
    "query": {"text": ">query\nGGGAGGAGGG\n"},
    "target": {"text": ">target\nCCCUCCUCCC\n"},
    "temperature": 25,
    "outMode": "C",
    "out": ["interactions.csv", "qPu:query-pu.txt"]
  }
}

parameters contains strings, JSON numbers and booleans. Repeated/composing options accept nonempty arrays. Flags without values accept true or false. Unknown options, duplicate keys, null values, unsupported nested values and recursive parameterFile are errors. Existing native type, range and cross-option validation still applies. JSON uses normal JSON escapes; #, whitespace and newlines in string values are not interpreted as legacy configuration syntax.

The optional _comment field holds provenance and reproduction instructions as ordinary JSON data, so files work with standard JSON parsers. Optional gui metadata describes browser-only output selections and is ignored by the CLI. Other document fields and unsupported schema versions are rejected.

Embedded inputs

For query, target, qAccFile, tAccFile, qShape, tShape and energyVRNA, use {"text": "file contents"} to embed UTF-8 text. FASTA may contain multiple records. Accessibility uses RNAplfold text; SHAPE and energy parameters retain their native formats. Ordinary strings retain their original meaning (sequence, preset or filesystem path). Relative paths remain relative to the working directory, as with legacy configuration files. Binary .agz caches can still be referenced by path; they are not a text encoding.

For accessibility of multiple selected records, {"texts": ["record 1 data", "record 2 data"]} materializes files with the existing -sN suffixes, indexed by original FASTA record number. Use text when selecting a single record. No user-specified paths are used for embedded files. A private temporary directory keeps generated files alive for the entire prediction and removes them on normal exit or exception unwinding. WASM uses its private in-memory filesystem. Like other temporary resources, abrupt process termination can leave native files.

Dependency choice

We evaluated Boost.JSON and nlohmann/json. Both provide typed JSON and can avoid a separately linked JSON library. Boost.JSON would raise our current Boost 1.50 minimum to a release containing JSON, or require another vendored Boost component and its dependency integration. Boost.PropertyTree is already available but loses JSON scalar/array type distinctions needed here.

We chose the unmodified, MIT-licensed nlohmann/json 3.12.0 single header (953,436 bytes), compiled in one CLI translation unit. It adds no system package, linker flag, public library API or WASM build dependency. The tradeoff is a vendored header to maintain and extra compile/binary size; the parser is outside prediction loops. Checksums and update instructions live in src/bin/nlohmann/README.md. The source distribution and staged GUI include the license.

Observed WASM footprint

With Emscripten 4.0.23, ViennaRNA 2.7.2 and Boost 1.87.0 using scripts/wasm/build.sh, the cached pre-JSON engine at d44d7a6 is 3,217,224 bytes (781,737 bytes with Python gzip.compress(..., mtime=0)). The JSON-enabled engine is 3,362,458 bytes (823,241 gzip): an increase of 145,234 bytes raw and 41,504 compressed. These are local artifact-size observations with matching dependency versions, not runtime benchmarks or guarantees for other toolchains. Reproduce by building both revisions, comparing site/wasm/intarna.wasm, and checking site/build-info.json for compiler/library provenance.