human: Given a node-centered hypergraph: <hypergraph>, where nodes represent papers and hyperedges represent sets of papers co-cited by a source paper.

Details of the hypergraph:
Center node: "best practices for scientific computing"
  Abstract: Scientists spend an increasing amount of time building and using software. However, most scientists are never taught how to do this efficiently. As a result, many are unaware of tools and practices that would allow them to write more reliable and maintainable code with less effort. We describe a set of best practices for scientific software development that have solid foundations in research and experience, and that improve scientists' productivity and the reliability of their software.#R##N##R##N#Software is as important to modern scientific research as telescopes and test tubes. From groups that work exclusively on computational problems, to traditional laboratory and field scientists, more and more of the daily operation of science revolves around developing new algorithms, managing and analyzing the large amounts of data that are generated in single research projects, combining disparate datasets to assess synthetic problems, and other computational tasks.#R##N##R##N#Scientists typically develop their own software for these purposes because doing so requires substantial domain-specific knowledge. As a result, recent studies have found that scientists typically spend 30% or more of their time developing software [1],[2]. However, 90% or more of them are primarily self-taught [1],[2], and therefore lack exposure to basic software development practices such as writing maintainable code, using version control and issue trackers, code reviews, unit testing, and task automation.#R##N##R##N#We believe that software is just another kind of experimental apparatus [3] and should be built, checked, and used as carefully as any physical apparatus. However, while most scientists are careful to validate their laboratory and field equipment, most do not know how reliable their software is [4],[5]. This can lead to serious errors impacting the central conclusions of published research [6]: recent high-profile retractions, technical comments, and corrections because of errors in computational methods include papers in Science [7],[8], PNAS [9], the Journal of Molecular Biology [10], Ecology Letters [11],[12], the Journal of Mammalogy [13], Journal of the American College of Cardiology [14], Hypertension [15], and The American Economic Review [16].#R##N##R##N#In addition, because software is often used for more than a single project, and is often reused by other scientists, computing errors can have disproportionate impacts on the scientific process. This type of cascading impact caused several prominent retractions when an error from another group's code was not discovered until after publication [6]. As with bench experiments, not everything must be done to the most exacting standards; however, scientists need to be aware of best practices both to improve their own approaches and for reviewing computational work by others.#R##N##R##N#This paper describes a set of practices that are easy to adopt and have proven effective in many research settings. Our recommendations are based on several decades of collective experience both building scientific software and teaching computing to scientists [17],[18], reports from many other groups [19]–, guidelines for commercial and open source software development [26],, and on empirical studies of scientific computing [28]–[31] and software development in general (summarized in [32]). None of these practices will guarantee efficient, error-free software development, but used in concert they will reduce the number of errors in scientific software, make it easier to reuse, and save the authors of the software time and effort that can used for focusing on the underlying scientific questions.#R##N##R##N#Our practices are summarized in Box 1; labels in the main text such as “(1a)” refer to items in that summary. For reasons of space, we do not discuss the equally important (but independent) issues of reproducible research, publication and citation of code and data, and open science. We do believe, however, that all of these will be much easier to implement if scientists have the skills we describe.#R##N##R##N##R##N#Box 1. Summary of Best Practices#R##N##R##N#Write programs for people, not computers.#R##N##R##N##R##N#A program should not require its readers to hold more than a handful of facts in memory at once.#R##N##R##N##R##N#Make names consistent, distinctive, and meaningful.#R##N##R##N##R##N#Make code style and formatting consistent.#R##N##R##N##R##N##R##N##R##N#Let the computer do the work.#R##N##R##N##R##N#Make the computer repeat tasks.#R##N##R##N##R##N#Save recent commands in a file for re-use.#R##N##R##N##R##N#Use a build tool to automate workflows.#R##N##R##N##R##N##R##N##R##N#Make incremental changes.#R##N##R##N##R##N#Work in small steps with frequent feedback and course correction.#R##N##R##N##R##N#Use a version control system.#R##N##R##N##R##N#Put everything that has been created manually in version control.#R##N##R##N##R##N##R##N##R##N#Don't repeat yourself (or others).#R##N##R##N##R##N#Every piece of data must have a single authoritative representation in the system.#R##N##R##N##R##N#Modularize code rather than copying and pasting.#R##N##R##N##R##N#Re-use code instead of rewriting it.#R##N##R##N##R##N##R##N##R##N#Plan for mistakes.#R##N##R##N##R##N#Add assertions to programs to check their operation.#R##N##R##N##R##N#Use an off-the-shelf unit testing library.#R##N##R##N##R##N#Turn bugs into test cases.#R##N##R##N##R##N#Use a symbolic debugger.#R##N##R##N##R##N##R##N##R##N#Optimize software only after it works correctly.#R##N##R##N##R##N#Use a profiler to identify bottlenecks.#R##N##R##N##R##N#Write code in the highest-level language possible.#R##N##R##N##R##N##R##N##R##N#Document design and purpose, not mechanics.#R##N##R##N##R##N#Document interfaces and reasons, not implementations.#R##N##R##N##R##N#Refactor code in preference to explaining how it works.#R##N##R##N##R##N#Embed the documentation for a piece of software in that software.#R##N##R##N##R##N##R##N##R##N#Collaborate.#R##N##R##N##R##N#Use pre-merge code reviews.#R##N##R##N##R##N#Use pair programming when bringing someone new up to speed and when tackling particularly tricky problems.#R##N##R##N##R##N#Use an issue tracking tool.#R##N##R##N##R##N##R##N##R##N##R##N##R##N##R##N##R##N#Write Programs for People, Not Computers#R##N#Scientists writing software need to write code that both executes correctly and can be easily read and understood by other programmers (especially the author's future self). If software cannot be easily read and understood, it is much more difficult to know that it is actually doing what it is intended to do. To be productive, software developers must therefore take several aspects of human cognition into account: in particular, that human working memory is limited, human pattern matching abilities are finely tuned, and human attention span is short [33]–[37].#R##N##R##N#First, a program should not require its readers to hold more than a handful of facts in memory at once (1a). Human working memory can hold only a handful of items at a time, where each item is either a single fact or a “chunk” aggregating several facts [33],[34], so programs should limit the total number of items to be remembered to accomplish a task. The primary way to accomplish this is to break programs up into easily understood functions, each of which conducts a single, easily understood, task. This serves to make each piece of the program easier to understand in the same way that breaking up a scientific paper using sections and paragraphs makes it easier to read.#R##N##R##N#Second, scientists should make names consistent, distinctive, and meaningful (1b). For example, using non-descriptive names, like a and foo, or names that are very similar, like results and results2, is likely to cause confusion.#R##N##R##N#Third, scientists should make code style and formatting consistent (1c). If different parts of a scientific paper used different formatting and capitalization, it would make that paper more difficult to read. Likewise, if different parts of a program are indented differently, or if programmers mix CamelCaseNaming and pothole_case_naming, code takes longer to read and readers make more mistakes [35],[36].

Connected through hyperedge HE-1 (induced by source paper "gpu computing with python performance energy efficiency and usability"):
  with members:
    - "benchmarking opencl openacc openmp and cuda programming productivity performance and energy consumption"
    - "a comparative study of programming languages in rosetta code"
    - "pycuda and pyopencl a scripting based approach to gpu run time code generation"
    - "a performance comparison of cuda and opencl"

Connected through hyperedge HE-2 (induced by source paper "a compositional framework for scientific model augmentation"):
  with members:
    - "teaching machines to understand data science code by semantic enrichment of dataflow graphs"
    - "julia a fresh approach to numerical computing"
    - "typing linear algebra a biproduct oriented approach"
    - "ologs a categorical framework for knowledge representation"

Connected through hyperedge HE-3 (induced by source paper "moose enabling massively parallel multiphysics simulation"):
  with members:
    - "mfem a modular finite element methods library"
    - "a general purpose hierarchical mesh partitioning method with node balancing strategies for large scale numerical simulations"
    - "firedrake automating the finite element method by composing abstractions"

Connected through hyperedge HE-4 (induced by source paper "challenges for verifying and validating scientific software in computational materials science"):
  with members:
    - "metamorphic testing a new approach for generating next test cases"
    - "testing scientific software a systematic literature review"

Connected through hyperedge HE-5 (induced by source paper "bertha project skeleton for scientific software"):
  with members:
    - "good enough practices in scientific computing"

Connected through hyperedge HE-6 (induced by source paper "enforcing public data archiving policies in academic publishing a study of ecology journals"):
  with members:
    - "journal of open source software joss design and first year review"
    - "the availability of research data declines rapidly with article age"
    - "mandated data archiving greatly improves access to research data"

Connected through hyperedge HE-7 (induced by source paper "the types roles and practices of documentation in data analytics open source software libraries a collaborative ethnography of documentation work"):
  with members:
    - "beyond opening up the black box investigating the role of algorithmic systems in wikipedian organizational culture"

Connected through hyperedge HE-8 (induced by source paper "ciw an open source discrete event simulation library"):
  with members:
    - "re run repeat reproduce reuse replicate transforming code into scientific contributions"
    - "top tips to make your research irreproducible"
    - "share and enjoy publishing useful and usable scientific models"
    - "the numpy array a structure for efficient numerical computation"

Question: Please tell me which class the center node belongs to. The 40 classes are: cs.NA(Numerical Analysis), cs.MM(Multimedia), cs.LO(Logic in Computer Science), cs.CY(Computers and Society), cs.CR(Cryptography and Security), cs.DC(Distributed, Parallel, and Cluster Computing), cs.HC(Human-Computer Interaction), cs.CE(Computational Engineering, Finance, and Science), cs.NI(Networking and Internet Architecture), cs.CC(Computational Complexity), cs.AI(Artificial Intelligence), cs.MA(Multiagent Systems), cs.GL(General Literature), cs.NE(Neural and Evolutionary Computing), cs.SC(Symbolic Computation), cs.AR(Hardware Architecture), cs.CV(Computer Vision and Pattern Recognition), cs.GR(Graphics), cs.ET(Emerging Technologies), cs.SY(Systems and Control), cs.CG(Computational Geometry), cs.OH(Other Computer Science), cs.PL(Programming Languages), cs.SE(Software Engineering), cs.LG(Machine Learning), cs.SD(Sound), cs.SI(Social and Information Networks), cs.RO(Robotics), cs.IT(Information Theory), cs.PF(Performance), cs.CL(Computation and Language), cs.IR(Information Retrieval), cs.MS(Mathematical Software), cs.FL(Formal Languages and Automata Theory), cs.DS(Data Structures and Algorithms), cs.OS(Operating Systems), cs.GT(Computer Science and Game Theory), cs.DB(Databases), cs.DL(Digital Libraries), cs.DM(Discrete Mathematics). Directly output the class name.

gpt: cs.MS(Mathematical Software)