Pith. sign in

REVIEW 9 major objections 4 minor 29 references

Emulating a computing grid in a local environment for feature evaluation

T0 review · 9 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A five-container Docker setup emulates a production computing grid locally, letting new features be tested before deployment.

desk verdict A useful, honest engineering report on a local JAliEn test harness that overclaims 'identical to production' but delivers a real incremental artifact. read the letter →

arxiv 2411.12559 v1 pith:MNZMAUNP submitted 2024-11-19 cs.DC

Jananga Kalawana , Malith Dilshan , Kaveesha Dinamidu , Kalana Wijethunga , Maksim Stortvedt , Indika Perera This is my paper · ORCID
classification cs.DC
keywords computinggridemulationALICEJAliEnmiddlewareDockercontainersComposefeatureevaluationCI/CDpipelinejobsubmissionworkflow
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

The paper tries to show that a production computing grid can be shrunk into a five-container local emulation that stays faithful enough to evaluate new software features safely. It demonstrates this on the ALICE grid's job-submission middleware, JAliEn: a Docker Compose setup runs the same container images used in production, mounts a modified JAliEn codebase, submits and tracks jobs, and checks results against a standard test suite. The reported measurements say the improved setup starts the emulated grid in 6 minutes and evaluates the job-submission flow in 13 minutes, versus 10 and 42 minutes for the original manual setup. The payoff, if true, is that features can be validated automatically in a CI/CD pipeline before touching production, reducing deployment failures and wasted effort.

What carries the argument

The load-bearing object is the five-container JAliEn Setup, a mini clone of the ALICE grid built with Docker Compose. Each grid role is one container: JCentral for central services, a Computing Element, a Schedd container running HTCondor as the batch queue, a Worker node, and a Storage Element using XRootD. The same production Docker images are used, and the modified JAliEn code is mounted into the containers that run it. The test suite drives this machinery by checking container health, submitting jobs, and inspecting generated logs, statuses, and output files, while a CI/CD workflow starts the stack and runs the suite automatically on every code push.

What would settle it

Take a JAliEn change that previously caused a job-flow failure in production but is not a container-environment artifact, run it through JAliEn Setup v2, and observe whether the test suite misses it. More systematically, submit a large batch of identical jobs to the emulated setup and to a production site running the same JAliEn version; any divergence in job states, file staging, or output correctness would show that local container behavior is not identical to distributed production behavior.

Watch

Extended reading notes

Core claim

The central discovery is that a faithful local grid replica can be built from production artifacts rather than from simulation: the JAliEn Setup uses the same Docker images as the production ALICE grid components, orchestrated by Docker Compose into five containers—JCentral, a computing element, an HTCondor scheduler, a worker node, and an XRootD storage element. The modified JAliEn codebase is mounted into the central, computing-element, and worker containers, and the full job-submission flow—submit to JCentral, the computing element announces resources, the scheduler starts a job agent on the worker, the JobWrapper pulls inputs from storage and uploads outputs—runs locally. On this basis the paper claims that the setup successfully emulated the ALICE grid and that evaluation occurs in an environment identical to the production setup, with a Bash test suite and a CI/CD workflow automating detection of job-flow failures.

Load-bearing premise

Running the same Docker images in a single host with five containers faithfully reproduces the behavior of the distributed production ALICE grid, so that evaluation results transfer to production.

Editorial extensions

If this is right

  • New JAliEn features can be validated automatically in a local environment before any deployment to production sites.
  • A standard test suite gives every developer the same acceptance check, replacing manual, expertise-dependent evaluation.
  • Weekly image builds mean developers can pull prebuilt production images from the registry and skip the roughly 86-to-89-minute local image build.
  • If the methodology transfers, other computing grids with analogous computing elements and batch queues can be emulated the same way for targeted feature evaluation.
  • Production failure rates should drop because unstable job-submission changes are caught in CI/CD instead of during site-by-site rollout.

Reading between the lines

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

  • Editorial inference: the fidelity argument rests on software-level equivalence, so the setup is best understood as a regression harness for the job-submission flow rather than a testbed for network partitions or node failures—the paper itself lists distributed failures as out of scope.
  • A testable extension would inject faults—kill the worker container, delay XRootD responses, or drop JCentral connections—to see whether the suite catches production-style degradation; the paper does not report such fault-injection experiments.
  • The same Compose pattern could be used to build compact local replicas for other workload management systems, with JAliEn Setup acting as a reference architecture.
  • The quantitative comparison would be stronger if it measured defect detection rates rather than only wall-clock times; one could replay known past JAliEn regressions through Setup v2 and count how many are caught.
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

9 major / 4 minor

Summary. The paper describes a containerized local emulation of the ALICE computing grid, called the JAliEn Setup, and reports on modifications made to an earlier version (v1) to produce v2. The new setup adds a Bash-based test suite covering individual components and the full job-submission flow, automated scripts, and CI/CD integration via GitHub workflows. The authors claim that the emulated environment is identical to the production setup because it uses the same Docker images, and they report timing comparisons between v1 and v2 for building images, starting the grid, and evaluating the job-submission flow. The central contribution is presented as a methodology for local grid feature evaluation that reduces failure rates in production.

Significance. If the claims were fully established, this would be a useful low-resource tool for pre-production validation of JAliEn middleware, with a concrete artifact: a five-container Compose setup, a test suite with critical/warning/minor tests, and CI/CD pipelines. The paper also gives credit to the existing JAliEn Replica and clearly identifies the limitations it addresses. However, the significance is bounded by the lack of direct evidence for fidelity to production behavior and by a quantitative evaluation that is too thin to support the efficiency claims. The work is best viewed as an experience report describing a smoke-test environment rather than a validated demonstration that local evaluation transfers to production.

major comments (9)
  1. [Section 5.1 and Section 5.4] The claim in Section 5.1 that evaluation occurs 'in an environment identical to the production setup' is not supported and is internally contradicted by Section 5.4, which concedes that the containerized local setup may not capture communication breakdowns or node failures in production. Using the same Docker images provides software-version parity, but a single-host five-container Compose deployment does not reproduce the distributed, multi-site, failure-prone behavior of the production ALICE grid. This overstatement is load-bearing because the paper's main contribution is that local feature evaluation transfers to production. The claim should be rewritten to say that the setup provides a high-fidelity software environment for functional testing of the job-submission flow, and the scope of transferability should be explicitly limited.
  2. [Section 5.3, Table 2] The quantitative evaluation reports average times with no sample size, number of runs, variance, or statistical comparison. The averages in Table 2 therefore cannot support the statement that v2 times are 'significantly less' for starting the grid and evaluating the job-submission flow. Moreover, the comparison is confounded: v1 requires manual evaluation while v2 is automated, so the measured difference partly reflects the absence of automation rather than an inherent property of the emulated grid. The authors should report the number of measurements, dispersion, and ideally per-step timing data, and should avoid significance language without a statistical test.
  3. [Section 4.4 and Section 5.1] The paper claims the test suite is 'capable of detecting failures in job submission functionality,' but no experiment demonstrates this capability. The authors do not report a seeded-fault study, a known-bug regression test, or any case where the test suite actually failed a broken JAliEn version. Since the absence of a standard test suite was a stated limitation of v1, the paper should provide evidence that the new test suite can distinguish a working from a broken modification. A small set of injected faults with observed test results would directly support the central claim that the setup enables reliable feature evaluation.
  4. [Section 4.4] The test-suite design is described only textually, with example outputs in Figures 2 and 3. There is no listing of the specific assertions, the number of tests, or the mapping from tests to the critical/warning/minor categories. This omission makes it difficult for a reader to judge what functionality is actually covered. A table of test cases with the corresponding component and expected outcome would strengthen the paper and make the evaluation reproducible.
  5. [Section 5.3] The reported hardware specification is likely inaccurate: the Intel Core i7-6550U is a dual-core mobile processor, not an 8-core processor as stated. This matters for interpreting the absolute times in Table 2, and it should be corrected or clarified.
  6. [References] Some references do not appear to support the statements they are attached to. In particular, reference [29] is cited for HTCondor but points to a cluster-based computing paper, and reference [30] is cited for XRootD but points to a service dependability paper. The authors should verify the reference list and either replace these citations or adjust the text.
  7. [General presentation] There are several typos (e.g., 'sig nificant' in the abstract) and repeated awkward phrases such as 'containerized approach for component enumeration' where 'deployment' or 'isolation' would be clearer. The paper would benefit from a final language pass.
  8. [Reproducibility] The manuscript does not include a link to the JAliEn Setup repository, the test suite, or the CI/CD workflow files. Given that the contribution is a software artifact, providing a URL or stating that the code will be made public would help readers reproduce the results and assess the test suite.
  9. [Conclusion] The conclusion states that the emulated setup 'ensures only reliable and stable updates are pushed to JAliEn in production,' which is stronger than the evidence presented. This claim should be softened to reflect that the setup provides a pre-production check but cannot guarantee reliability in the distributed production environment.
minor comments (4)
  1. [Section 3.4.2] The phrase 'ensuring a high degree of fidelity' is acceptable if understood as software fidelity, but it should be explicitly qualified in the same sentence to avoid the later overclaim in Section 5.1.
  2. [Section 4.2] Figure 1 is referenced but not described in the text; a short caption or a sentence listing the container interconnections would help readers who cannot view the figure.
  3. [Section 4.4] The test-suite output in Figures 2 and 3 is illustrative, but the figures are not discussed in detail; a sentence explaining what a failing test looks like would be useful.
  4. [Section 5.3] The phrase 'the proposed methodology cannot be directly evaluated quantitatively' is vague; the authors should state what would count as a direct quantitative evaluation of a methodology (e.g., detection rate, false-positive rate, transferability ratio).

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation; the 'identical to production' claim is an overstated fidelity assertion, not a circularity.

full rationale

This paper makes no mathematical claims and fits no parameters, so the classic circularity patterns (fitted input called prediction, self-definitional equations) do not apply. The central contribution is an engineering modification of the existing JAliEn Setup: adding a Bash test suite, automation scripts, and a CI/CD workflow, evaluated by comparing v1 versus v2 execution times (Table 2). The 'identical to production' assertion in Section 5.1 rests on the premise that the same Docker images are used (Section 3.4.2); this is an overbroad inference rather than a derivation from the target result, and Section 5.4 explicitly concedes that local containerization cannot capture distributed production failure modes, so the claim is internally inconsistent. That is a correctness or fidelity concern, not circularity. The self-citations to prior CERN container work ([25], [26]) support the general suitability of Docker for ALICE grid components, but they are not used to define the paper's new test-suite result into existence. No circular step can be quoted. Score 1 reflects the absence of circularity with a minor caveat that the paper's strongest fidelity claim is asserted rather than demonstrated.

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

The central claim rests on two domain assumptions: local containers with production images behave like the distributed production grid, and five single-instance components cover the targeted job submission flow. A third assumption concerns the representativeness of unsupervised timing measurements. These are not free parameters in a mathematical sense, but they are unvalidated premises that carry the weight of the evaluation.

assumptions (3)
  • domain assumption Production Docker images, when run in local containers, faithfully represent the behavior of production grid components.
    Section 3.4.2 states this premise as 'ensuring a high degree of fidelity', and Section 5.1 relies on it to call the local environment 'identical to the production setup'.
  • domain assumption A single instance of each of the five selected components is sufficient to evaluate the JAliEn job submission feature.
    Section 3.4.1 explicitly says this simplification is 'sufficient for evaluating JAliEn's job submission process in a local environment', but no empirical evidence justifies sufficiency.
  • ad hoc to paper Timing measurements collected from an unspecified number of runs on one laptop are representative of typical usage.
    Section 5.3 reports average times in Table 2 without stating sample sizes, run counts, or variance, which is an unsupported empirical assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Emulating a computing grid in a local environment for feature evaluation." pith.science (2026). https://pith.science/paper/MNZMAUNP

@misc{pith2026241112559,
  author       = {Pith},
  title        = {Pith review of: Emulating a computing grid in a local environment for feature evaluation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MNZMAUNP}},
  note         = {Machine review of arXiv:2411.12559}
}
read the original abstract

The necessity for complex calculations in high-energy physics and large-scale data analysis has led to the development of computing grids, such as the ALICE computing grid at CERN. These grids outperform traditional supercomputers but present challenges in directly evaluating new features, as changes can disrupt production operations and require comprehensive assessments, entailing significant time investments across all components. This paper proposes a solution to this challenge by introducing a novel approach for emulating a computing grid within a local environment. This emulation, resembling a mini clone of the original computing grid, encompasses its essential components and functionalities. Local environments provide controlled settings for emulating grid components, enabling researchers to evaluate system features without impacting production environments. This investigation contributes to the evolving field of computing grids and distributed systems, offering insights into the emulation of a computing grid in a local environment for feature evaluation.

Figures

Figures reproduced from arXiv: 2411.12559 by the authors.

Figure 1
Figure 1. Architecture diagram of the emulated setup Each of these components is housed in a dedicated container, and together, these five containers emulate the ALICE grid. The modified JAliEn codebase is mounted for the JCentral, CE, and Worker node containers. This container setup can be used to evaluate the job submission flow functionalities of JAliEn. 4.2.1. JCentral In JAliEn, "JCentral" refers to the central services … view at source ↗
Figure 2
Figure 2. Output during test execution [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
Figure 3
Figure 3. Test suite summary 4.5. CI/CD Pipeline With the JAliEn Setup and the implemented test suite, JAliEn can be evaluated, but it must be done manually, which can be time-consuming. To address this, an automated script setup was developed using Bash. This allows the JAliEn Setup to be started and the test suite to be run with a single customizable command. The selection of technology for the automated scripts depends on … view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: CI/CD pipeline structure In addition to this, there is another periodically running workflow set up as a cron job to run weekly. This workflow builds the Docker images for container components and uploads them to the CERN Docker container registry. Therefore, when the …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 18 canonical work pages

  1. [29]

    WFCS: A Cluster -Based Framework for Dependable Computing,

    B. Shirazi, S. V. T. Beek, M. Younis, and H. Qi, “WFCS: A Cluster -Based Framework for Dependable Computing,” in Lecture Notes in Computer Science, Berlin, Heidelberg: Springer Berlin Heidelberg, 2000, pp. 1095–1104

    work page 2000

  2. [30]

    A fr amework for dependability assurance in service-oriented systems,

    F. Dechouniotis, D. Kyriazis, and G. M. Poulios, “A fr amework for dependability assurance in service-oriented systems,” IEEE Transactions on Systems, Man, and Cybernetics: Systems, vol. 47, no. 5, pp. 735–746, Dec. 2016, doi: 10.1109/tsmc.2016.2635020. AUTHORS Jananga Kalawana is an enthusiastic Computer Science & Engineering undergraduate with a strong ...

    work page arXiv 2016

  3. [1]

    The Grid: Blueprint for a New Computing Infrastructure edited by Ian Foster and Carl Kesselman Morgan Kaufman, San Francisco, CA, U.S.A., 1998. 677 pp. ISBN: 1558 -604- 758.,

    C. E. A. Karnow, “The Grid: Blueprint for a New Computing Infrastructure edited by Ian Foster and Carl Kesselman Morgan Kaufman, San Francisco, CA, U.S.A., 1998. 677 pp. ISBN: 1558 -604- 758.,” Leonardo, vol. 32, no. 4, pp. 331–332, Aug. 1999, doi: 10.1162/leon.1999.32.4.331

    work page doi:10.1162/leon.1999.32.4.331 1998

  4. [3]

    The Anatomy of the Grid: Enabling Scalable Virtual Organizations,

    I. Foster, C . Kesselman, and S. Tuecke, “The Anatomy of the Grid: Enabling Scalable Virtual Organizations,” The International Journal of High Performance Computing Applications, vol. 15, no. 3, pp. 200–222, Aug. 2001, doi: 10.1177/109434200101500302

    work page doi:10.1177/109434200101500302 2001

  5. [4]

    INFN GRID DATAGRID Prototype 1,

    F. Donno, L. Gaid o, A. Ghiselli, M. Mazzucato, F. Prelz, and M. Sgaravatto, “INFN GRID DATAGRID Prototype 1,” Jan. 2002, doi: 10.15161/oar.it/1448983015.84

    work page arXiv 2002

  6. [5]

    e - Infrastructures in IT: A case study on Indian national grid computing initiative – GARUDA,

    B. B. P. Rao, S. Ramakrishnan, M. R. R. Gopalan, C. Subrata, N. Mangala, and R. Sridharan, “e - Infrastructures in IT: A case study on Indian national grid computing initiative – GARUDA,” Computer Science - Research and Development, vol. 23, no. 3 –4, pp. 283 –290, May 2009, doi: 10.1007/s00450-009-0079-3. Computer Science & Information Technology (CS & IT) 179

    work page doi:10.1007/s00450-009-0079-3 2009

  7. [6]

    WLCG Service Challenges and Tiered arc hitecture in the LHC era,

    D. Bonacorsi and T. Ferrari, “WLCG Service Challenges and Tiered arc hitecture in the LHC era,” in Springer eBooks, 2007, pp. 365–368, doi: 10.1007/978-88-470-0530-368

    work page doi:10.1007/978-88-470-0530-368 2007

  8. [7]

    Operating the Worldwide LHC Computing Grid: current and future challenges,

    J. F. Molina, A. Forti, M. Girone, and A. Sciaba, “Operating the Worldwide LHC Computing Grid: current and future challenges,” Journal of Physics Conference Series, vol. 513, no. 6, p. 062044, Jun. 2014, doi: 10.1088/1742-6596/513/6/062044

    work page doi:10.1088/1742-6596/513/6/062044 2014

Show all 29 references
  1. [8]

    Critical services in the LHC computing,

    A. Sciabà, “Critical services in the LHC computing,” Journal of Physics. Conference Series, vol. 219, no. 6, p. 062025, Apr. 2010, doi: 10.1088/1742-6596/219/6/062025

    2010 doi

  2. [9]

    High -Energy Physics on the Grid: the ATLAS and CMS Experience,

    J. Andreeva, S. Campana, F. Fanzago, and J. Herrala, “High -Energy Physics on the Grid: the ATLAS and CMS Experience,” Journal of Grid Computing, vol. 6, no. 1, pp. 3 –13, Sep. 2007, doi: 10.1007/s10723-007-9087-3

    2007 doi

  3. [10]

    Overview of ATLAS PanDA Work load Management,

    T. Maeno et al., “Overview of ATLAS PanDA Work load Management,” Journal of Physics. Conference Series, vol. 331, no. 7, p. 072024, Dec. 2011, doi: 10.1088/1742-6596/331/7/072024

    2011 doi

  4. [11]

    The CMS experiment at the CERN LHC,

    C. Collaboration et al., “The CMS experiment at the CERN LHC,” Journal of Instrumentation, vol. 3, no. 08, p. S08004, Aug. 2008, doi: 10.1088/1748-0221/3/08/s08004

    2008 doi

  5. [12]

    glideinWMS—a generic pilot-based workload management system,

    I. Sfiligoi, “glideinWMS—a generic pilot-based workload management system,” Journal of Physics Conference Series, vol. 119, no. 6, p. 062044, Jul. 2008, doi: 10.1088/1742-6596/119/6/062044

    2008 doi

  6. [13]

    The LHCb DIRAC -based production and data management operations systems,

    F. Stagni and P. Charpen tier, “The LHCb DIRAC -based production and data management operations systems,” Journal of Physics. Conference Series, vol. 368, p. 012010, Jun. 2012, doi: 10.1088/1742-6596/368/1/012010

    2012 doi

  7. [14]

    The LHCb Data Management System,

    J. P. Baud et al., “The LHCb Data Management System,” Journal of Phy sics. Conference Series, vol. 396, no. 3, p. 032023, Dec. 2012, doi: 10.1088/1742-6596/396/3/032023

    2012 doi

  8. [15]

    SimGrid: A Generic Framework for Large -Scale Distributed Experiments,

    H. Casanova, A. Legrand, and M. Quinson, “SimGrid: A Generic Framework for Large -Scale Distributed Experiments,” Jan. 2008, doi: 10.1109/uksim.2008.28

    2008 doi

  9. [16]

    Grid’5000: A Large Scale And Highly Reconfigurable Experimental Grid Testbed,

    R. Bolze et al., “Grid’5000: A Large Scale And Highly Reconfigurable Experimental Grid Testbed,” The International Journal of High Performance Computing Applications, vol. 20, no. 4, pp. 481–494, Nov. 2006, doi: 10.1177/1094342006070078

    2006 doi

  10. [17]

    Building an automated and self -configurable emulation testbed for grid applications,

    R. N. Calheiros, R. B uyya, and C. a. F. De Rose, “Building an automated and self -configurable emulation testbed for grid applications,” Software, Practice Experience/Software, Practice and Experience, vol. 40, no. 5, pp. 405–429, Mar. 2010, doi: 10.1002/spe.964

    2010 doi

  11. [18]

    The state -of-the-art in container technologies: Application, orchestration and security,

    E. Casalicchio and S. Iannucci, “The state -of-the-art in container technologies: Application, orchestration and security,” Concurrency and Computation, vol. 32, no. 17, Jan. 2020, doi: 10.1002/cpe.5668

    2020 doi

  12. [19]

    Containers for Virtua lization: An Overview,

    V. G. Da Silva, M. Kirikova, and G. Alksnis, “Containers for Virtua lization: An Overview,” Applied Computer Systems, vol. 23, no. 1, pp. 21–27, May 2018, doi: 10.2478/acss-2018-0003

    2018 doi

  13. [20]

    A survey on network simulators, emulators, and testbeds used for research and education,

    J. Gomez, E. F. Kfoury, J. Crichigno, and G. Srivastava, “A survey on network simulators, emulators, and testbeds used for research and education,” Computer Networks, vol. 237, p. 110054, Dec. 2023, doi: 10.1016/j.comnet.2023.110054

    2023

  14. [21]

    A network in a laptop,

    B. Lantz, B. Heller, and N. McKeown, “A network in a laptop,” Oct. 2010, doi: 10.1145/1868447.1868466

    2010

  15. [22]

    Containernet 2.0: A Rapid Prototyping Platform for Hybrid Service Function Chains,

    M. Peuster, J. Kampmeyer, and H. Karl, “Containernet 2.0: A Rapid Prototyping Platform for Hybrid Service Function Chains,” Jun. 2018, doi: 10.1109/netsoft.2018.8459905

    2018

  16. [23]

    NEMO: A flexible and highly scalable network EMulatOr,

    L. Veltri, L. Davoli, R. Pecori, A. Vannucci, and F. Zanichelli, “NEMO: A flexible and highly scalable network EMulatOr,” SoftwareX, vol. 10, p. 100248, Jul. 2019, doi: 10.1016/j.softx.2019.100248

    2019

  17. [24]

    openLEON: An end-to-end emulation platform from the edge data center to the mobile user,

    C. Fiandrino, A. B. Pizarro, P. J. Mateo, C. A. Ramiro, N. Ludant, and J. Widmer, “openLEON: An end-to-end emulation platform from the edge data center to the mobile user,” Computer Communications, 2019

    2019

  18. [25]

    Grid services in a box: container management in ALICE,

    M. M. Storetvedt, M. Litmaath, L. Betev, H. Helstrup, K. F. Hetland, and B. Kileng, “Grid services in a box: container management in ALICE,” EPJ Web of Conferences, vol. 214, p. 07018, Jan. 2019, doi: 10.1051/epjconf/201921407018

    2019

  19. [26]

    Running ALICE Grid Jobs in Containers A new approach to job execution for the next generation ALICE Grid framework,

    M. M. Storetvedt, L. Betev, H. Helstrup, K. F. Hetland, and B. Kileng, “Running ALICE Grid Jobs in Containers A new approach to job execution for the next generation ALICE Grid framework,” EPJ Web of Conferences, vol. 245, p. 07052, Jan. 2020, doi: 10.1051/epjconf/202024507052

    2020

  20. [27]

    Running ALICE Grid Jobs in Containers A new approach to job execution for the next generation ALICE Grid framework,

    A. G. Grigoras, C. Grigoras, and V. Yurchenko, “Running ALICE Grid Jobs in Containers A new approach to job execution for the next generation ALICE Grid framework,” Journal of Physics. Conference Series, vol. 1525, no. 1, p. 012034, May 2020, doi: 10.1088/1742-6596/1525/1/0120...

    2020 doi

  21. [28]

    Distributed computing in practice: the Condor experience,

    D. Thain, T. Tannenbaum, and M. Livny, “Distributed computing in practice: the Condor experience,” Concurrency and Computation: Practice and Experience, vol. 17, no. 2 –4, pp. 323 – 356, Feb. 2005, doi: 10.1002/cpe.938

    2005 doi

Pith tools

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