Pith. sign in

REVIEW 3 major objections 6 minor 5 cited by

Africanus IV. The Stimela2 framework: scalable and reproducible workflows, from local to cloud compute

T0 review · 3 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Pith's one-line read Stimela2 is a workflow framework that lets radio astronomy reduction recipes be written once as YAML and run unchanged on a laptop, a Slurm cluster, or a Kubernetes cloud, with containerized, versioned software for reproducibility.

desk verdict A clear, honest design overview of a real framework; the reproducibility claim is oversold relative to what is demonstrated, but the paper deserves refereeing. read the letter →

arxiv 2412.10080 v2 pith:GTBQWMPY submitted 2024-12-13 astro-ph.IM

classification astro-ph.IM
keywords workflowmanagementradioastronomydatareductionreproducibilitycontainerizationKubernetesSlurmYAMLrecipescloudcomputing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that a data-reduction workflow framework can occupy the middle ground between hand-written scripts and formal dataflow systems: radio astronomy reductions are described as linear, human-readable YAML recipes, while the framework silently maps them onto containers, Slurm, or Kubernetes so the same recipe runs locally or in the cloud. The authors state that Stimela2 has largely achieved this aim, combining ease of development, scalability, and practical reproducibility, and they point to cloud deployments on AWS in earlier papers of the same series as evidence. If the claim is right, astronomers can publish not only results but executable, reproducible recipes that others can rerun without installing arcane software stacks.

What carries the argument

The central object is the nested YAML namespace: recipes, cab definitions, schemas, and configuration all merge into one ordered dictionary, so workflow logic and local environment specifics can be composed from separate files. The load-bearing mechanism is the schema-plus-substitution system, where parameters can be typed, validated, aliased, and combined via formulas like "=recipe.ms" and string substitutions like "{recipe.image_name}", keeping parameter bookkeeping tractable in long reductions. On top of this, the backend layer executes the same abstract steps natively, in an Apptainer container, through the Slurm scheduler, or as Kubernetes pods with per-cab CPU and memory requests, which is what allows a workflow to scale from a laptop to a cloud cluster without changing the recipe.

What would settle it

Run a representative end-to-end MeerKAT reduction, expressed once as a Stimela2 recipe, on a local cluster and on an AWS EKS cluster with autoscaling, recording elapsed time, instance-hours, storage and egress costs, and the numerical agreement of the final images; if autoscaler cold starts or instance spin-up delays make the cloud run slower or more expensive than a fixed on-premises allocation, the central claim of practical and economical cloud deployment is not supported.

Watch

Extended reading notes

Core claim

Stimela2's central claim is that a concise linear recipe language, backed by formal typed schemas, can be turned into distributed execution without requiring users to become workflow specialists. A recipe is a YAML sequence of steps; each step invokes a cab, an atomic task whose cargo can be a binary executable, a Python function, a CASA task, or inline Python code, and whose inputs and outputs are described by a schema. Because cabs carry schemas, Stimela2 can prevalidate parameters, chain them through formulas and string substitutions, scatter loop iterations across machines, and detect failures by parsing console output. Because the same step can be selected to run natively, under Apptainer, through a Slurm wrapper, or inside a Kubernetes pod, the logical recipe stays unchanged while the execution environment changes, and cloud autoscaling can in principle match cheap small instances to thin steps and large expensive instances to thick ones.

Load-bearing premise

The cloud-scalability claim depends on the assumption that Kubernetes autoscaling, bringing virtual machines up and down on demand, can economically handle workflows whose steps alternate between thin, serial tasks and thick, parallel, memory-hungry tasks; the paper gives no cost or performance measurements for this.

Editorial extensions

If this is right

  • The same recipe file can run unchanged under the native, Apptainer, Slurm, or Kubernetes backends, so workflow logic does not need to be rewritten when moving from a laptop to a cluster to the cloud.
  • Containerized cab collections such as cult-cargo make workflows effectively zero-install: a host needs only Stimela2 and a container engine, while versioned images are downloaded on demand.
  • Scatter-gather loop constructs let parallelizable steps fan out over cluster nodes while serial steps remain serial, which is the paper's proposed answer to the "thick-thin" resource profile of radio astronomy reductions.
  • Published science can be accompanied by its actual reduction recipes, as in the RATT PARROT example, so other groups can rerun the exact processing rather than approximate it by hand.
  • Because Kubernetes pods carry predefined CPU and memory requests, autoscaling can in principle allocate small cheap instances to light steps and spin up large instances only for heavy steps, making cloud execution economically plausible.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: if the recipe language is as portable as claimed, the same cab-and-schema design should transfer to any containerized data-processing domain, since nothing in the core framework is radio-specific.
  • The paper leaves cost and performance unmeasured; a natural next experiment is a head-to-head dollar-per-image comparison of the same recipe on an in-house cluster, fixed cloud nodes, and autoscaling Kubernetes.
  • The proposed "certifiable workflow" idea, hashing container images, configuration, and input data into a workflow signature, could generalize into a reproducibility standard for containerized pipelines generally, provided that image registries remain accessible and immutable.
  • An open recipe competition, as sketched in the paper, would make algorithm comparisons more quantitative than side-by-side images, because swapping an imaging step inside a published recipe gives a direct, reproducible basis for comparison.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. This paper describes Stimela2, a workflow framework for radio-astronomy data reduction that represents pipelines as linear YAML recipes composed of typed "cab" definitions. The paper presents the architecture: schema-based parameter validation, a substitution/evaluation language, composability via _include/_use constructs, cab flavours for native executables, Python functions, CASA tasks, and inline Python code, and execution backends for native, Apptainer, Slurm, and Kubernetes environments. It also covers logging, profiling, and resource-management features, and illustrates the design with a MeerKAT simulation recipe and a mixed local/Kubernetes deployment example in Appendix B. The paper is an overview and design document; quantitative benchmarks are not reported here but are attributed to companion papers in the same Africanus series.

Significance. If the design performs as described, Stimela2 addresses a real community need: modular, human-readable, portable recipes that can run on a laptop, an HPC cluster, or a cloud deployment, with containerized dependencies curated through cult-cargo. The framework is open source, the companion package provides versioned container images, and the paper includes substantial runnable examples. The claimed value is therefore credible as a software-engineering contribution, and the previously published RATT PARROT recipes give some external evidence that the system is usable in real science analysis. However, the paper's own text shows that the reproducibility pillar is not yet demonstrated, and the cloud cost/scalability claims rest on companion papers rather than on measurements reported here. The contribution is best characterized as a well-specified design with partial validation, not a fully evaluated framework as the abstract and conclusions sometimes imply.

major comments (3)
  1. [Abstract; §8; §10.2] The abstract promises "fully reproducible workflows" and §8 states that the Apptainer backend "allows for true zero-install, fully reproducible workflows", but §10.2 explicitly concedes that reproducibility "still needs to be proven in practice", that "total replicability may always remain hostage to the robustness of algorithm implementations", and that a formal "certifiable workflow" mechanism is future work. In addition, §4.4 and Appendix B deliberately permit per-cab and per-step switching to native backends, which §8 itself notes "certainly does not promote reproducibility". This is an internal inconsistency in one of the three pillars of the central claim in §10. The manuscript should either report a concrete reproducibility experiment (for example, a containerized recipe executed on two different hosts or architectures, compared bitwise or with a stated numerical tolerance) or qualify the abstract and conclusions so that they claim reproducible software environments rather than fully reproducible results. As written, the abstract overstates what the paper demonstrates.
  2. [§10.1; §9.2] The central cloud-computing claim is that Kubernetes autoscaling with predefined pod CPU/RAM requests can resolve the "thick-thin" resource-profile problem by bringing virtual machines up and down on demand, allocating small cheap instances to thin steps and large instances to thick steps. The paper gives no measurements of autoscaling overhead, cold-start latency, scheduling delay, or cost versus static allocation to support this. §9.2 states that the Kubernetes backend currently collects only basic metrics (CPU usage, RAM usage, pod count, elapsed time) and explicitly leaves "dollars per run" as future work. The anecdotal totals in §10.1 ($25,000 for the whole paper series, under $1,000 for a workshop) do not quantify the marginal cost of autoscaling and cannot substitute for a controlled comparison. If scalable cloud deployment is a central contribution, the paper should include such measurements or clearly mark the autoscaling discussion as expected behavior rather than demonstrated capability; the current wording is stronger than the evidence presented in this manuscript.
  3. [§1; §10] The paper frames Stimela2's aim as occupying the middle ground between casual scripting and dataflow frameworks such as CWL and DALiuGE, and §10 concludes that Stimela2 "has largely achieved" this aim. However, the paper provides no evidence about the ease-of-use side of that trade-off: no usability study, no recipe-authoring time comparison, no assessment of recipe readability against CWL or DALiuGE, and no systematic demonstration that the scatter-gather constructs scale beyond the examples in companion papers. This does not invalidate the architecture, but it means the "largely achieved" conclusion is an assertion rather than a finding. Since companion papers (Kenyon et al. 2024; Bester et al. 2024; Smirnov et al. 2024) contain empirical demonstrations, the authors could include a short synthesis of those results and explicitly delineate which claims are established there and which remain design goals. In the absence of that, the conclusion overstates the evidence available in this manuscript.
minor comments (6)
  1. [§1] The word "incoperating" should be "incorporating".
  2. [§4.1] In the sentence "A cab definition is simply a section of YAML, Fig. 2 being an example", the reference should be to Listing 2 rather than Fig. 2.
  3. [§4.3] The word "informaton" should be "information".
  4. [§8] The backend heading "Kkubernetes" should be "Kubernetes".
  5. [§10.2] The heading "Wither reproducibility?" appears to be a typo for "Whither reproducibility?", unless the decay sense of "wither" is intentionally intended.
  6. [Appendix B] In the `compare_models` step, `epsilon` is set to `=recipe.steps.sara.tol`, but the `sara` step shown in the same augmentation file does not define a `tol` parameter; if `tol` is provided by the base recipe of Bester et al. (2024), this should be stated explicitly in the text.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Stimela2 is a software-design paper with no derived predictions; self-citations point to separate benchmark papers and the admitted reproducibility gap is an evidentiary weakness, not a circular reduction.

full rationale

Stimela2 is a software-architecture paper: its central claims concern the design of YAML recipes, cab definitions, schemas, substitutions, and backend execution. These claims are supported by code listings and design discussion within the paper itself, not by a derivation chain that re-imports its own conclusions. No fitted parameters, prediction loops, equations whose outputs equal their inputs by construction, or imported uniqueness theorems are present. The cloud and scalability statements in Section 10 refer to companion Africanus papers (Kenyon et al. 2024; Bester et al. 2024) and the RATT PARROT paper (Smirnov et al. 2024); these are same-team self-citations, but they reference separate benchmark runs on publicly available MeerKAT data, so they constitute external evidence rather than a circular premise. The paper itself flags a genuine evidentiary gap in Section 10.2 ('Wither reproducibility?'): 'this still needs to be proven in practice' and 'total replicability may always remain hostage to the robustness of algorithm implementations.' This weakens the abstract's wording about 'fully reproducible workflows', but the weakness is an unsupported or overstrong claim, not circularity: containerization is not defined in terms of the reproducibility outcome, and no claim in the paper reduces by construction to its own inputs. Accordingly, no circular steps are identified and the circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

Stimela2 introduces no new physical entities or fitted parameters. The central design claims rest on domain assumptions about containerization guaranteeing reproducibility, Kubernetes autoscaling being cost-effective, and YAML readability improving accessibility.

assumptions (3)
  • domain assumption Containerization with versioned images is sufficient to make workflows reproducible
    Used throughout Sections 8 and 10.2; the paper itself notes this is an aspiration, not yet proven, and numerical algorithms may differ across architectures.
  • domain assumption Kubernetes autoscaling can efficiently handle the heterogeneous resource demands of radio astronomy workflows
    Section 10.1 claims pods with predefined resources plus autoscaler resolve the 'thick-thin' problem; no measured evidence is presented.
  • domain assumption YAML-based linear recipes are more approachable than Python APIs for the target user community
    Section 1 argues the first-generation Python API devolved into hard-to-read scripts; this is a qualitative design judgment not tested here.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Africanus IV. The Stimela2 framework: scalable and reproducible workflows, from local to cloud compute." pith.science (2026). https://pith.science/paper/GTBQWMPY

@misc{pith2026241210080,
  author       = {Pith},
  title        = {Pith review of: Africanus IV. The Stimela2 framework: scalable and reproducible workflows, from local to cloud compute},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GTBQWMPY}},
  note         = {Machine review of arXiv:2412.10080}
}
read the original abstract

Stimela2 is a new-generation framework for developing data reduction workflows. It is designed for radio astronomy data but can be adapted for other data processing applications. Stimela2 aims at the middle ground between ease of development, human readability, and enabling robust, scalable and reproducible workflows. It represents workflows by linear, concise and intuitive YAML-format "recipes". Atomic data reduction tasks (binary executables, Python functions and code, and CASA tasks) are described by YAML-format "cab definitions" detailing each task's "schema" (inputs and outputs). Stimela2 provides a rich syntax for chaining tasks together, and encourages a high degree of modularity: recipes may be nested into other recipes, and configuration is cleanly separated from recipe logic. Tasks can be executed natively or in isolated environments using containerization technologies such as Apptainer. The container images are open-source and maintained through a companion package called cult-cargo. This enables the development of system-agnostic and fully reproducible workflows. Stimela2 facilitates the deployment of scalable, distributed workflows by interfacing with the Slurm scheduler and the Kubernetes API. The latter allows workflows to be readily deployed in the cloud. Previous papers in this series used Stimela2 as the underlying technology to run workflows on the AWS cloud. This paper presents an overview of Stimela2's design, architecture and use in the radio astronomy context.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 5 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. The Peculiar Mini-Halo in the Shapley Supercluster Member Abell 3558

    astro-ph.GA 2025-07 conditional novelty 6.0 of 10

    The diffuse radio emission in A3558 is a peculiar mini-halo with a new northern extension, a steep spectrum of 1.18, and a sublinear radio-X-ray correlation that steepens with frequency, consistent with sloshing-induc...

  2. Mining the time axis with TRON. I. Millisecond pulsars in Omega Centauri, Terzan 5 and 47 Tucanae detected through MeerKAT interferometric imaging

    astro-ph.IM 2025-01 conditional novelty 6.0 of 10

    TRON detects five known or candidate millisecond pulsars in archival MeerKAT images, validating image-plane mining of the time axis for medium-timescale radio transients.

  3. Africanus I. Scalable, distributed and efficient radio data processing with Dask-MS and Codex Africanus

    astro-ph.IM 2024-12 conditional novelty 6.0 of 10

    Dask-MS and Codex Africanus let radio astronomers run interferometry data reduction on Dask clusters, with demonstrated strong and weak scaling for a DFT model predict on AWS.

  4. Africanus III. pfb-imaging -- a flexible radio interferometric imaging suite

    astro-ph.IM 2024-12 conditional novelty 6.0 of 10

    A flexible imaging library, pfb-imaging, implements a sparsity-based SARA algorithm with interpretable parameters and demonstrates it on terabyte-scale MeerKAT data.

  5. Africanus II. QuartiCal: calibrating radio interferometer data at scale using Numba and Dask

    astro-ph.IM 2024-12 conditional novelty 5.0 of 10

    QuartiCal, a new Python-based radio interferometry calibration package, supports arbitrary chains of gain terms and uses Dask to scale from a laptop to distributed cloud clusters, outperforming CubiCal in memory and speed.

Reference graph

Works this paper leans on

28 extracted references · 8 canonical work pages · cited by 5 Pith papers

  1. [1]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in ":" * " " * FUNCTION f...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION fin.entry write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION new.sentence output.state after.block = 'skip output.state before.all = 'skip after.sentence 'output.state := if if FUNCTION not #0 #1 if FUNCTION and 'skip pop #0 if FUNCTION or pop #1...

  3. [3]

    2015, , 579, A101

    Aladro, R., Martín, S., Riquelme, D., et al. 2015, , 579, A101

  4. [4]

    write newline

    " write newline "" before.all 'output.state := FUNCTION fin.entry write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION new.sentence output.state after.block = 'skip output.state before.all = 'skip after.sentence 'output.state := if if FUNCTION not #0 #1 if FUNCTION and 'skip pop #0 if FUNCTION or pop #1...

  5. [5]

    , year 2023

    author Berriman , G.B. , year 2023 . title How Can Astronomers Make The Best Use of Cloud Platforms? , in: booktitle American Astronomical Society Meeting Abstracts , p. pages 312.04

  6. [6]

    , author Kenyon, J.S

    author Bester, H.L. , author Kenyon, J.S. , author Repetti, A. , author Perkins, S.J. , author Smirnov, O.M. , author Blecher, T. , author Mhiri, Y. , author Roth, J. , author Heywood, I. , author Wiaux, Y. , author Hugo, B.V. , year 2024 . title Africanus III. pfb-imaging -- a flexible radio interferometric imaging suite . journal Astronomy and Computing...

  7. [7]

    , author Jacobs, D

    author Byrne, R. , author Jacobs, D. , year 2021 . title Development of a high throughput cloud-based data pipeline for 21 cm cosmology . journal Astronomy and Computing volume 34 , pages 100447 . :https://doi.org/10.1016/j.ascom.2021.100447

  8. [8]

    , year 2015

    author van Diepen, G. , year 2015 . title Casacore table data system and its use in the measurementset . journal Astronomy and Computing volume 2 . :10.1016/j.ascom.2015.06.002

Show all 28 references
  1. [9]

    , author Momjian , E

    author Dodson , R. , author Momjian , E. , author Pisano , D.J. , author Luber , N. , author Blue Bird , J. , author Rozgonyi , K. , author Smith , E.T. , author van Gorkom , J.H. , author Lucero , D. , author Hess , K.M. , author Yun , M. , author Rhee , J. , author van der H...

  2. [10]

    , author Vinsen , K

    author Dodson , R. , author Vinsen , K. , author Wu , C. , author Popping , A. , author Meyer , M. , author Wicenec , A. , author Quinn , P. , author van Gorkom , J. , author Momjian , E. , year 2016 . title Imaging SKA-scale data in three different computing environments . jo...

  3. [11]

    , year 2020

    author Heywood , I. , year 2020 . title oxkat: Semi-automated imaging of MeerKAT observations . howpublished Astrophysics Source Code Library, record ascl:2009.003

  4. [12]

    , author Andati , L.A.L

    author J \'o zsa , G.I.G. , author Andati , L.A.L. , author de Blok , W.J.G. , author Hugo , B.V. , author Kleiner , D. , author Kamphuis , P. , author Moln \'a r , D.C. , author Makhathini , S. , author Maccagni , F.M. , author Perkins , S.J. , author Ramaila , A. , author Ra...

  5. [13]

    , author Perkins, S.J

    author Kenyon, J.S. , author Perkins, S.J. , author Bester, H.L. , author Smirnov, O.M. , author Russeeawon, C. , author Hugo, B.V. , year 2024 . title Africanus II. QuartiCal: calibrating radio interferometer data at scale using Numba and Dask . journal Astronomy and Computin...

  6. [14]

    , author Smirnov , O.M

    author Kenyon , J.S. , author Smirnov , O.M. , author Grobler , T.L. , author Perkins , S.J. , year 2018 . title CUBICAL - fast radio interferometric calibration suite exploiting complex optimization . journal MNRAS volume 478 , pages 2399--2415 . :10.1093/mnras/sty1221, http:...

  7. [15]

    , year 2018

    author Makhathini, S. , year 2018 . title Advanced radio interferometric simulation and data reduction techniques . Ph.D. thesis. Rhodes University; Faculty of Science, Physics and Electronics

  8. [16]

    , author Wei , S

    author Mei , Y. , author Wei , S. , author Wang , F. , author Wu , C. , author Tobar , R. , author Shaikh , M. , author Deng , H. , author Dai , W. , author Liang , B. , author Wicenec , A. , year 2022 . title An empirical evaluation on the applicability of the DALiuGE executi...

  9. [17]

    , year 2021

    author Molenaar, G.J. , year 2021 . title Design patterns and software techniques for large-scale, open and reproducible data reduction . Ph.D. thesis. Rhodes University; Faculty of Science, Physics and Electronics

  10. [18]

    , author McKinley , B

    author Offringa , A.R. , author McKinley , B. , author Hurley-Walker , N. , author Briggs , F.H. , author Wayth , R.B. , author Kaplan , D.L. , author Bell , M.E. , author Feng , L. , author Neben , A.R. , author Hughes , J.D. , author Rhee , J. , author Murphy , T. , author B...

  11. [19]

    , author Guy , L

    author O'Mullane , W. , author Guy , L. , author Dubois-Felsmann , G. , author Economou , F. , author AlSayyad , Y. , author Graham , M. , author Slater , C. , year 2023 . title Vera C. Rubin Observatory: Open Science to the core , in: booktitle American Astronomical Society M...

  12. [20]

    , author Kenyon, J.S

    author Perkins, S.J. , author Kenyon, J.S. , author Andati, L.A.L. , author Bester, H.L. , author Smirnov, O.M. , author Hugo, B.V. , year 2024 . title Africanus I. Scalable, distributed and efficient radio data processing with Dask-MS and Codex Africanus . journal Astronomy a...

  13. [21]

    , author Wicenec, A

    author Pritchard, N.J. , author Wicenec, A. , year 2024 . title Formal definition and implementation of reproducibility tenets for computational workflows . http://arxiv.org/abs/2406.01146 arXiv:2406.01146

  14. [22]

    , author Sánchez-Expósito, S

    author Sabater, J. , author Sánchez-Expósito, S. , author Best, P. , author Garrido, J. , author Verdes-Montenegro, L. , author Lezzi, D. , year 2017 . title Calibration of lofar data on the cloud . journal Astronomy and Computing volume 19 , pages 75--89 . :https://doi.org/10...

  15. [23]

    , author Heywood , I

    author Samboco , V.G. , author Heywood , I. , author Smirnov , O. , year 2024 . title SolarKAT: Solar imaging pipeline for MeerKAT . howpublished Astrophysics Source Code Library, record ascl:2401.013

  16. [24]

    , author Stappers , B.W

    author Smirnov , O.M. , author Stappers , B.W. , author Tasse , C. , author Bester , H.L. , author Bignall , H. , author Walker , M.A. , author Caleb , M. , author Rajwade , K.M. , author Buchner , S. , author Woudt , P. , author Ivchenko , M. , author Roth , L. , author Noord...

  17. [25]

    , author Hugo , B

    author Tasse , C. , author Hugo , B. , author Mirmont , M. , author Smirnov , O. , author Atemkeng , M. , author Bester , L. , author Hardcastle , M.J. , author Lakhoo , R. , author Perkins , S. , author Shimwell , T. , year 2018 . title Faceting for direction-dependent spectr...

  18. [26]

    , author Benn, D

    author Toomey, L. , author Benn, D. , author Chapman, J. , author Dai, S. , author Dempsey, J. , author Hobbs, G. , author Russell, C. , author Wang, C. , author Wang, J. , author Zic, J. , year 2017 . title Processing public pulsar astronomy data in the Amazon Cloud . type Te...

  19. [27]

    , author Tobar, R

    author Wang, R. , author Tobar, R. , author Dolensky, M. , author An, T. , author Wicenec, A. , author Wu, C. , author Dulwich, F. , author Podhorszki, N. , author Anantharaj, V. , author Suchyta, E. , author Lao, B. , author Klasky, S. , year 2020 . title Processing full-scal...

  20. [28]

    , author Tobar , R

    author Wu , C. , author Tobar , R. , author Vinsen , K. , author Wicenec , A. , author Pallot , D. , author Lao , B. , author Wang , R. , author An , T. , author Boulton , M. , author Cooper , I. , author Dodson , R. , author Dolensky , M. , author Mei , Y. , author Wang , F. ...

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.