Pith. sign in

REVIEW 4 major objections 6 minor 47 references

Performance Impact of Containerized METADOCK 2 on Heterogeneous Platforms

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read Containerizing GPU docking software adds less than 1% runtime overhead.

desk verdict Useful and measured container-overhead data for METADOCK 2, but the <1% headline is not statistically supported as reported; worth refereeing with a request for repeats and error bars. read the letter →

arxiv 2506.06450 v1 pith:KUCL6QXF submitted 2025-06-06 cs.DC cs.PF

Antonio Jesús Banegas-Luna , Baldomero Imbernón Tudela , Carlos Martínez-Cortés , José María Cecilia , Horacio Pérez-Sánchez This is my paper
classification cs.DCcs.PF
keywords METADOCK2containersmoleculardockingvirtualscreeningGPUHPCmetaheuristicperformancebenchmarking
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

Molecular docking is one of the most compute-hungry steps in virtual screening for drug discovery, so any overhead from wrapping it in a container would matter for HPC users. This paper tries to establish that containerization does not cost performance for METADOCK 2, a GPU-accelerated metaheuristic docking program: across Docker, Singularity, and Apptainer, on two different CPU+GPU platforms and three metaheuristic configurations, execution times deviate from a non-containerized baseline by less than 1%. It further claims that the number of GPU kernel launches per run, from 610 to 1,208, does not change this picture, and that containerized METADOCK 2 can handle a receptor complex of 98,914 atoms that commercial tools such as AutoDock Vina cannot fully process. If the claim holds, researchers can deploy docking workloads on shared heterogeneous HPC clusters as portable, reproducible containers without sacrificing throughput.

What carries the argument

The load-bearing mechanism is a fixed execution pipeline shared by all four environments: input data is staged outside the container and copied to GPU memory once, METADOCK 2 then performs its metaheuristic search as a series of GPU kernel launches, and results are transferred back to the host only after the run completes. Around this pipeline, each container (Docker, Singularity, Apptainer) is bootstrapped from the same nvidia/cuda:11.8.0-base-ubuntu22.04 image with the same METADOCK 2 binaries, libraries, and environment variables, so the comparison isolates the container runtime rather than software differences. METADOCK 2 itself is a parallel metaheuristic docking program that searches the full protein surface rather than a predefined region; its three configurations (M1-M3) vary parameters that change the number of local searches and, consequently, the number of GPU calls.

What would settle it

Repeat the benchmark on one of the same platforms with, say, 30 runs per condition (bare metal, Docker, Singularity, Apptainer) and compare distributions; the central claim fails if the containerized median is not consistently within 1% of the native median, or if the native and container distributions overlap so heavily that the sub-1% difference is not distinguishable from noise.

Watch

Extended reading notes

Core claim

The paper's central claim is that running METADOCK 2 inside a container is effectively free: on both test platforms, the execution time of the containerized versions (Docker, Singularity, Apptainer) remained within 1% of the same binaries run directly on the host, and in some cases the container ran as fast or faster. The authors attribute this to the pipeline, in which input data is loaded onto the GPU once at the start, all docking calculations happen through GPU kernel launches inside the container, and output is copied out only at the end, so the container layer is not on the critical transfer path. They also report that the number of GPU launches (610 for configuration M1, 728 for M2, 1,208 for M3) did not degrade relative performance, that the two platforms' speed difference tracked the GPUs' theoretical peak (about 2.2x observed versus 2.3x theoretical), and that a 98,914-atom complex was processed in all container environments, a scale they say exceeds what AutoDock Vina can handle.

Load-bearing premise

The claim of under 1% overhead assumes that a single measured run per configuration is a trustworthy estimate of runtime, because the paper reports no repeated runs, standard deviations, or statistical comparisons, leaving the possibility that the observed differences are just run-to-run noise.

Editorial extensions

If this is right

  • Docker, Singularity, and Apptainer can be used interchangeably for METADOCK 2 deployments: none of the three measurably changes execution time.
  • Virtual-screening pipelines can adopt containers for portability and reproducibility on heterogeneous HPC clusters without trading away throughput.
  • Container overhead does not grow with the number of GPU kernel launches, so larger or more complex docking workloads should not see an increasing container penalty.
  • The platform-to-platform speed difference, about 2.2x, is explained by GPU hardware rather than the container layer, which supports cross-platform performance prediction using GPU peak rates.
  • METADOCK 2 in containers extends docking to very large complexes, such as the 98,914-atom receptor tested, a workload that the authors say AutoDock Vina cannot fully process.

Reading between the lines

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

  • Editorial inference: the near-zero overhead is measured for a pipeline that moves data to the GPU once and back once; workloads with frequent host-GPU transfers or container-internal file I/O could show larger container costs and need their own benchmarking.
  • Editorial inference: because the paper does not report repeat runs, the sub-1% figure is better read as an upper bound on observed difference rather than a statistically established effect; a replication with variance estimates would tighten or weaken the claim.
  • Editorial inference: if the result generalizes to other kernel-dominated GPU codes, containerization could become the default deployment mode for reproducible docking and similar bioinformatics pipelines on shared infrastructure.
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

4 major / 6 minor

Summary. The paper benchmarks the performance impact of containerization on METADOCK 2, a GPU-accelerated molecular docking tool, by comparing execution times of Docker, Singularity, and Apptainer containers against a non-containerized baseline on two heterogeneous CPU+GPU platforms (Cajal and Torrevieja). The authors report that containerization introduces negligible overhead, with deviations below 1%, and that METADOCK 2 can process a large 98,914-atom complex that commercial tools such as AutoDock Vina allegedly cannot. The paper concludes that containerized METADOCK 2 is a robust, portable, and scalable solution for virtual screening on HPC platforms.

Significance. If the quantitative claim of below-1% overhead were statistically supported, the result would be a useful practical datapoint for HPC practitioners considering container-based deployment of GPU-intensive docking workloads. The study covers three container technologies and two distinct hardware platforms, and the pipeline description (Section 3) is clear. However, the central quantitative claim is currently undermined by the absence of repeated measurements, error bars, or a defined deviation metric, and the dataset description contains internal inconsistencies. The comparative claim about AutoDock Vina is made without experimental support. The manuscript does not provide raw timing data or scripts, which further limits reproducibility. The qualitative conclusion that container overhead is small is plausible, but the specific <1% bound and the Vina comparison need stronger backing.

major comments (4)
  1. [Section 4.2 and abstract] The claim that containerization introduces deviations below 1% is not statistically supported by the reported measurements. The manuscript does not state the number of repetitions, does not report standard deviations or confidence intervals, and does not define how the '<1% deviation' is computed. Figures 2-5 show only single point values without error bars; on shared heterogeneous CPU+GPU nodes, single-run execution times can vary by more than 1%, so the sub-1% spread could be within run-to-run noise rather than evidence of negligible overhead. The conclusion's stronger statement that containers are 'as fast or faster' than the host is also not directly evidenced by the figures.
  2. [Section 4.1, Table 2, and figure captions] The dataset description is internally inconsistent. The text in Section 4.1 states that seven receptors (1B9J, 1ELW, 2B6N, 2OXW, 2OY2, 3BS4, and 3GQ1) were used, but Table 2 lists eight PDB entries including 3TDD, which is then used separately in Figure 5. Figures 2-4 captions refer to 'nine protein-flexible peptides,' which matches neither count. This inconsistency makes it impossible to determine the exact benchmark set behind the <1% claim and hampers reproducibility.
  3. [Section 4.1] The statement that 'the CUDA toolkit version 6.5 was used for compilation on the GPU' conflicts with the CUDA 11.8 base image described in Section 3.1. If this is a typo, it should be corrected; if the host compilation indeed used CUDA 6.5 while containers used CUDA 11.8, the mismatch and its potential effect on the results need to be justified.
  4. [Section 4.2 and Figure 5] The claim that 'Commercial software, like AutoDock Vina, cannot fully process that sort of complex' is made without running AutoDock Vina on the 3TDD complex and without citing evidence for this limitation. Since this is a comparative claim against a specific tool, it should either be supported by a direct experiment (and the failure mode described) or removed.
minor comments (6)
  1. [Figure 4 caption] The caption says 'M2 metaheuristic configuration' but the surrounding text and the figure content indicate this is the M3 configuration.
  2. [Figures 2-4 captions] The captions contain unresolved '??)' placeholders for subfigure labels and refer to 'nine protein-flexible peptides,' which is inconsistent with the counts given in the text and Table 2.
  3. [Section 4.1] The reported peak performance of the RTX 3090 is given as 286.4 TFLOPS in FP32, which is incorrect; the RTX 3090 FP32 peak is approximately 35.6 TFLOPS. The stated 2.3x theoretical peak ratio should be recalculated with correct hardware specifications.
  4. [Section 4.2] The claim that 'both platforms had an occupancy of 100% in all cases' is not defined or measured; GPU occupancy and utilization are distinct concepts, and no supporting data are provided.
  5. [Section 4.2] The numbers of GPU launches (610, 728, 1,208 for M1, M2, M3) are asserted without describing how they were counted or providing a table of launch counts, which makes this part of the analysis difficult to audit.
  6. [References] Reference [39] is cited as 'Singularity' by the developers, but the text in Section 2.4 discusses Apptainer (formerly SingularityCE); please verify the citation and clarify the relationship between Singularity and Apptainer in the references.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the container-overhead claim is an empirical comparison against a native baseline, with self-citations limited to software description.

full rationale

The paper is an empirical performance benchmark: it measures METADOCK 2 execution time natively and inside Docker, Singularity, and Apptainer containers on two CPU+GPU platforms, and reports deviations below 1%. The central claim is a comparison against an external baseline, namely the non-containerized execution, not a quantity derived from a fitted parameter or from a defining equation. Self-citations [40] and [41] describe the METADOCK 2 software and its parallel metaheuristic scheme; they do not supply the overhead result, and no load-bearing argument reduces to those references. No equation is reused as both premise and conclusion, and no fitted input is renamed as a prediction. The absence of repeated runs, standard deviations, and error bars is a measurement-validity and reproducibility concern, but it is not a circularity concern. Therefore no circular step is identified.

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

The benchmark depends on the authors' choice of metaheuristic configurations (free parameters) and on assumptions about measurement stability, fair comparison, and GPU occupancy. No new theoretical entities are introduced.

free parameters (1)
  • Metaheuristic configurations (M1, M2, M3) = M1: INEIni=64, IIEFlex=32; M2: INEIni=128; M3: INEIni=256 (full sets in Table 1)
    Chosen by the authors to create three workload sizes; they are experimental settings, not fitted to the overhead claim.
assumptions (3)
  • domain assumption Single-run timings are representative.
    The paper reports no repeats or error bars, so the central overhead figure assumes negligible run-to-run variability.
  • domain assumption Fair baseline comparison.
    The non-container run is assumed to use the same binaries, data, and GPU state as the container runs.
  • domain assumption Full GPU occupancy.
    Section 4.2 states occupancy was 100% in all cases, but no occupancy measurements are shown.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Performance Impact of Containerized METADOCK 2 on Heterogeneous Platforms." pith.science (2026). https://pith.science/paper/KUCL6QXF

@misc{pith2026250606450,
  author       = {Pith},
  title        = {Pith review of: Performance Impact of Containerized METADOCK 2 on Heterogeneous Platforms},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KUCL6QXF}},
  note         = {Machine review of arXiv:2506.06450}
}
read the original abstract

Virtual screening (VS) is a computationally intensive process crucial for drug discovery, often requiring significant resources to analyze large chemical libraries and predict ligand-protein interactions. This study evaluates the performance impact of containerization on METADOCK 2, a high-throughput docking software when deployed on heterogeneous high-performance computing (HPC) platforms. By testing three containerization technologies - Docker, Singularity, and Apptainer - across varying CPU and GPU configurations, the experiments reveal that containerization introduces negligible performance overhead, with deviations below 1%. Moreover, METADOCK 2 demonstrated the capability to efficiently process large molecular complexes, surpassing the limitations of commercial tools such as AutoDock Vina. The results underscore the advantages of container-based deployment for ensuring portability, reproducibility, and scalability in scientific computing. This study concludes that containerized METADOCK 2 is a robust and efficient solution for VS tasks on heterogeneous HPC platforms.

Figures

Figures reproduced from arXiv: 2506.06450 by the authors.

Figure 1
Figure 1. Pipeline implemented in this work: A) Input data, which is stored externally, is loaded onto GPU; B) MET ADOCK 2 performs all the calculations; C) Once the process is finished, the output data is transferred to an external directory. 8 [PITH_FULL_IMAGE:figures/full_fig_p008_1.png] view at source ↗
Figure 2
Figure 2. Comparative performance analysis of the different execution environments (With￾out container, Singularity, Docker, and Apptainer) with M1 metaheuristic configuration in MET ADOCK 2: This figure illustrates the execution time utilized in the screening of the nine protein-flexible peptides in ??) Cajal-server and ??). Torrevieja-server. All the experiments were carried out on two different computing platforms whose GP… view at source ↗
Figure 3
Figure 3. Comparative performance analysis of the different execution environments (With￾out container, Singularity, Docker, and Apptainer) with M2 metaheuristic configuration in MET ADOCK 2: This figure illustrates the execution time utilized in the screening of the nine protein-flexible peptides in ??) Cajal-server and ??). Torrevieja-server. are as expected due to the higher computational power of the RTX4090 GPU ver￾sus t… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Comparative performance analysis of the different execution environments (With￾out container, Singularity, Docker, and Apptainer) with M2 metaheuristic configuration in MET ADOCK 2: This figure illustrates the execution time utilized in the screening of the nine protei…
Figure 5
Figure 5. Figure 5: Comparative performance analysis of the different execution environments (Without container, Singularity, Docker, and Apptainer) with M1, M2 and M3 metaheuristic configura￾tions in MET ADOCK 2: This figure illustrates the execution time utilized in the screening of the…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

47 extracted references · 45 canonical work pages

  1. [1]

    In: International Conference on Product- focused Software Process Improvement, pp

    Koskinen, M., Mikkonen, T., Abrahamsson, P.: Containers in software develop- ment: A systematic mapping study. In: International Conference on Product- focused Software Process Improvement, pp. 176–191 (2019). Springer

    work page 2019

  2. [2]

    O’Reilly Media, Inc., Sebastopol, CA (2015)

    Mouat, A.: Using Docker: Developing and Deploying Software with Containers. O’Reilly Media, Inc., Sebastopol, CA (2015)

    work page 2015

  3. [3]

    Nature Reviews Methods Primers3(1), 50 (2023) 16

    Moreau, D., Wiebels, K., Boettiger, C.: Containers for computational repro- ducibility. Nature Reviews Methods Primers3(1), 50 (2023) 16

    work page 2023

  4. [4]

    Future Generation Computer Systems102, 562–573 (2020)

    Hu, Y., Zhou, H., Laat, C., Zhao, Z.: Concurrent container scheduling on hetero- geneous clusters with multi-resource constraints. Future Generation Computer Systems102, 562–573 (2020)

    work page 2020

  5. [5]

    The Journal of Supercomputing79(5), 5759–5827 (2023)

    Keller Tesser, R., Borin, E.: Containers in hpc: a survey. The Journal of Supercomputing79(5), 5759–5827 (2023)

    work page 2023

  6. [6]

    In: International Conference on High Performance Computing, pp

    Medeiros, D., Schieffer, G., Wahlgren, J., Peng, I.: A gpu-accelerated molec- ular docking workflow with kubernetes and apache airflow. In: International Conference on High Performance Computing, pp. 193–206 (2023). Springer

    work page 2023

  7. [7]

    In: Practice and Experience in Advanced Research Computing, pp

    Huff, T., Darrow, A., Medina, J., Ferlanti, E., Carson, J., Fonner, J., Tijerina, S., Watowich, S.J., Allen, W.J.: Scalable and reproducible virtual screening through an api-integrated workflow. In: Practice and Experience in Advanced Research Computing, pp. 196–199 (2023)

    work page 2023

  8. [8]

    Journal of Artificial Intelligence Research4(1), 196–219 (2024)

    Egbuna, O.P.: Machine learning applications in kubernetes for autonomous con- tainer management. Journal of Artificial Intelligence Research4(1), 196–219 (2024)

    work page 2024

Show all 47 references
  1. [9]

    Cluster Computing26(1), 13–23 (2023)

    Chiang, R.C.: Contention-aware container placement strategy for docker swarm with machine learning based clustering algorithms. Cluster Computing26(1), 13–23 (2023)

    2023

  2. [10]

    In: 2023 IEEE Interna- tional Conference on Service-Oriented System Engineering (SOSE), pp

    Theodoropoulos, T., Makris, A., Korontanis, I., Tserpes, K.: Greenkube: Towards greener container orchestration using artificial intelligence. In: 2023 IEEE Interna- tional Conference on Service-Oriented System Engineering (SOSE), pp. 135–139 (2023). IEEE

    2023

  3. [11]

    Nature methods21(5), 804–808 (2024)

    Renton, A.I., Dao, T.T., Johnstone, T., Civier, O., Sullivan, R.P., White, D.J., Lyons, P., Slade, B.M., Abbott, D.F., Amos, T.J.,et al.: Neurodesk: an accessible, flexible and portable data analysis environment for reproducible neuroimaging. Nature methods21(5), 804–808 (2024)

    2024

  4. [12]

    Gut Microbes15(1), 2192522 (2023)

    Ru, J., Khan Mirzaei, M., Xue, J., Peng, X., Deng, L.: Viroprofiler: a containerized bioinformatics pipeline for viral metagenomic data analysis. Gut Microbes15(1), 2192522 (2023)

    2023

  5. [13]

    Journal of Microscopy (2023)

    Weisbart, E., Tromans-Coia, C., Diaz-Rohrer, B., Stirling, D.R., Garcia-Fossa, F., Senft, R.A., Hiner, M.C., Jesus, M.B., Eliceiri, K.W., Cimini, B.A.: Cellprofiler plugins–an easy image analysis platform integration for containers and python tools. Journal of Microscopy (2023)

    2023

  6. [14]

    IEEE Transactions on Cloud Computing11(3), 2966–2982 (2023) 17

    Wang, X., Guo, P., Li, X., Gangopadhyay, A., Busart, C.E., Freeman, J., Wang, J.: Reproducible and portable big data analytics in the cloud. IEEE Transactions on Cloud Computing11(3), 2966–2982 (2023) 17

    2023

  7. [15]

    In: 2024 11th International Conference on Computing for Sustainable Global Development (INDIACom), pp

    Kumar, E.S., Ramamoorthy, R., Kesavan, S., Shobha, T., Patil, S., Vighnesh- wari, B.: Comparative study and analysis of cloud container technology. In: 2024 11th International Conference on Computing for Sustainable Global Development (INDIACom), pp. 1681–1686 (2024). IEEE

    2024

  8. [16]

    Nature605(7910), 551–560 (2022)

    Cao, L., Coventry, B., Goreshnik, I., Huang, B., Sheffler, W., Park, J.S., Jude, K.M., Markovi´ c, I., Kadam, R.U., Verschueren, K.H.,et al.: Design of protein- binding proteins from the target structure alone. Nature605(7910), 551–560 (2022)

    2022

  9. [17]

    Journal of Chemical Information and Modeling61(6), 2560–2571 (2021)

    Walker, A.S., Clardy, J.: A machine learning bioinformatics method to predict bio- logical activity from biosynthetic gene clusters. Journal of Chemical Information and Modeling61(6), 2560–2571 (2021)

    2021

  10. [18]

    Crunkhorn, S.: Screening ultra-large virtual libraries. Nat. Rev. Drug Discov 21(95), 10–1038 (2022)

    2022

  11. [19]

    Journal of chemical information and modeling53(8), 1967–1978 (2013)

    Yan, X., Li, J., Liu, Z., Zheng, M., Ge, H., Xu, J.: Enhancing molecular shape comparison by weighted gaussian functions. Journal of chemical information and modeling53(8), 1967–1978 (2013)

    2013

  12. [20]

    Progress in medicinal chemistry60, 273–343 (2021)

    Stanzione, F., Giangreco, I., Cole, J.C.: Use of molecular docking computational tools in drug discovery. Progress in medicinal chemistry60, 273–343 (2021)

    2021

  13. [21]

    The Journal of chemical physics154(10) (2021)

    Brooks, C.L., Case, D.A., Plimpton, S., Roux, B., Spoel, D., Tajkhorshid, E.: Classical molecular dynamics. The Journal of chemical physics154(10) (2021)

    2021

  14. [22]

    Pharmaceuticals15(1), 63 (2022)

    Murugan, N.A., Podobas, A., Gadioli, D., Vitali, E., Palermo, G., Markidis, S.: A review on parallel virtual screening softwares for high-performance computers. Pharmaceuticals15(1), 63 (2022)

    2022

  15. [23]

    The Journal of Physical Chemistry B125(4), 1049–1060 (2021)

    Fan, M., Wang, J., Jiang, H., Feng, Y., Mahdavi, M., Madduri, K., Kandemir, M.T., Dokholyan, N.V.: Gpu-accelerated flexible molecular docking. The Journal of Physical Chemistry B125(4), 1049–1060 (2021)

    2021

  16. [24]

    The Protein Journal, 1–11 (2022)

    Jayaraj, P., Sanjay, S., Raja, K., Gopakumar, G., Jaleel, U.: Ligand based virtual screening using self-organizing maps. The Protein Journal, 1–11 (2022)

    2022

  17. [25]

    IEEE Journal of Biomedical and Health Informatics (2023)

    Liu, H., Wang, C., Liu, P., Liu, C., Wang, Z., Wei, Z.: Efficient large-scale vir- tual screening based on heterogeneous many-core supercomputing system. IEEE Journal of Biomedical and Health Informatics (2023)

    2023

  18. [26]

    In: Proceedings of the Platform for Advanced Scientific Computing Conference, pp

    Banchelli, F., Garcia-Gasulla, M., Houzeaux, G., Mantovani, F.: Benchmarking of state-of-the-art hpc clusters with a production cfd code. In: Proceedings of the Platform for Advanced Scientific Computing Conference, pp. 1–11 (2020)

    2020

  19. [27]

    In: Proceedings of the Practice and Experience in Advanced Research Computing on Rise of the Machines (learning), pp

    Hutson, K., Andresen, D., Tygart, A., Turner, D.: Managing a heterogeneous 18 cluster. In: Proceedings of the Practice and Experience in Advanced Research Computing on Rise of the Machines (learning), pp. 1–6 (2019)

    2019

  20. [28]

    The Journal of supercomputing78(5), 6898–6943 (2022)

    Khallouli, W., Huang, J.: Cluster resource scheduling in cloud computing: lit- erature review and research challenges. The Journal of supercomputing78(5), 6898–6943 (2022)

    2022

  21. [29]

    lınea].[Junio de 2017]

    Docker, I.: Docker. lınea].[Junio de 2017]. Disponible en: https://www. docker. com/what-docker (2020)

    2020

  22. [30]

    IEEE Transactions on Cloud Computing10(2), 1386– 1401 (2020)

    Xie, Y., Jin, M., Zou, Z., Xu, G., Feng, D., Liu, W., Long, D.: Real-time prediction of docker container resource load based on a hybrid model of arima and triple exponential smoothing. IEEE Transactions on Cloud Computing10(2), 1386– 1401 (2020)

    2020

  23. [31]

    In: 2020 2nd International Conference on Innovative Mechanisms for Industry Applications (ICIMIA), pp

    Sharma, V., Saxena, H.K., Singh, A.K.: Docker for multi-containers web appli- cation. In: 2020 2nd International Conference on Innovative Mechanisms for Industry Applications (ICIMIA), pp. 589–592 (2020). IEEE

    2020

  24. [32]

    Advances on Smart and Soft Computing: Proceedings of ICACIn 2021, 247–259 (2021)

    Kithulwatta, W., Wickramaarachchi, W.U., Jayasena, K., Kumara, B., Rath- nayaka, R.: Adoption of docker containers as an infrastructure for deploying software applications: A review. Advances on Smart and Soft Computing: Proceedings of ICACIn 2021, 247–259 (2021)

    2021

  25. [33]

    Applied Sciences12(13), 6737 (2022)

    Kim, B.S., Lee, S.H., Lee, Y.R., Park, Y.H., Jeong, J.: Design and implementation of cloud docker application architecture based on machine learning in container management for smart manufacturing. Applied Sciences12(13), 6737 (2022)

    2022

  26. [34]

    Simon and Schuster, ??? (2017)

    Luksa, M.: Kubernetes in Action. Simon and Schuster, ??? (2017)

    2017

  27. [35]

    In: 2019 3rd International Conference on Trends in Electronics and Informatics (ICOEI), pp

    Marathe, N., Gandhi, A., Shah, J.M.: Docker swarm and kubernetes in cloud computing environment. In: 2019 3rd International Conference on Trends in Electronics and Informatics (ICOEI), pp. 179–184 (2019). IEEE

    2019

  28. [36]

    IEEE access7, 52976–52996 (2019)

    Sultan, S., Ahmad, I., Dimitriou, T.: Container security: Issues, challenges, and the road ahead. IEEE access7, 52976–52996 (2019)

    2019

  29. [37]

    In: Practice and Experience in Advanced Research Computing, pp

    Solis, A., Allen, W.J., Ferlanti, E.: Containerizing visualization software: Expe- riences and best practices. In: Practice and Experience in Advanced Research Computing, pp. 1–8 (2022)

    2022

  30. [38]

    PloS one12(5), 0177459 (2017)

    Kurtzer, G.M., Sochat, V., Bauer, M.W.: Singularity: Scientific containers for mobility of compute. PloS one12(5), 0177459 (2017)

    2017

  31. [39]

    https://doi.org/10.5281/zenodo.1310023 Accessed 2024-10-30

    Developers, S.: Singularity (2021). https://doi.org/10.5281/zenodo.1310023 Accessed 2024-10-30

    2021 doi

  32. [40]

    Bioinformatics37(11), 1515–1520 (2021)

    Imbern´ on, B., Serrano, A., Bueno-Crespo, A., Abell´ an, J.L., P´ erez-S´ anchez, H., 19 Cecilia, J.M.: Metadock 2: a high-throughput parallel metaheuristic scheme for molecular docking. Bioinformatics37(11), 1515–1520 (2021)

    2021

  33. [41]

    The International Journal of High Performance Computing Applications32(6), 789–803 (2018)

    Imbern´ on, B., Cecilia, J.M., P´ erez-S´ anchez, H., Gim´ enez, D.: Metadock: A paral- lel metaheuristic schema for virtual screening methods. The International Journal of High Performance Computing Applications32(6), 789–803 (2018)

    2018

  34. [42]

    Procedia Computer Science171, 1419–1428 (2020)

    Potdar, A.M., Narayan, D., Kengond, S., Mulla, M.M.: Performance evaluation of docker container and virtual machine. Procedia Computer Science171, 1419–1428 (2020)

    2020

  35. [43]

    IEEE Transactions on Parallel and Distributed Systems32(4), 918–930 (2020)

    Zhao, N., Tarasov, V., Albahar, H., Anwar, A., Rupprecht, L., Skourtis, D., Paul, A.K., Chen, K., Butt, A.R.: Large-scale analysis of docker images and perfor- mance implications for container storage systems. IEEE Transactions on Parallel and Distributed Systems32(4), 918–930 (2020)

    2020

  36. [44]

    Security and Communication Networks2022(1), 6819002 (2022)

    Alyas, T., Ali, S., Khan, H.U., Samad, A., Alissa, K., Saleem, M.A.: Container performance and vulnerability management for container security using docker engine. Security and Communication Networks2022(1), 6819002 (2022)

    2022

  37. [45]

    https://singularityhub.github.io/ Accessed 2024-10-30

    Hub, S.: Container Tools. https://singularityhub.github.io/ Accessed 2024-10-30

    2024

  38. [46]

    Journal of computational chemistry31(2), 455–461 (2010)

    Trott, O., Olson, A.J.: Autodock vina: improving the speed and accuracy of docking with a new scoring function, efficient optimization, and multithreading. Journal of computational chemistry31(2), 455–461 (2010)

    2010

  39. [47]

    0: New docking methods, expanded force field, and python bindings

    Eberhardt, J., Santos-Martins, D., Tillack, A.F., Forli, S.: Autodock vina 1.2. 0: New docking methods, expanded force field, and python bindings. Journal of chemical information and modeling61(8), 3891–3898 (2021) 20

    2021

Pith tools

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