Refactor Systems to Initialize Using Dictionaries

[michaelmckinsey1]

Refactor the way systems are initialized to be similar to how experiments are initialized, using dictionaries instead of multi-line strings and yaml files.

• Addresses Use dictionary to write yaml in system.py (similar to experiment.py) #654

• Write a python utility to read in file1 and file2 into a dictionary (does file1 get deprecated when we start using compilers as packages @becker33 ??)

  • This is yaml.safe_load(file).

• Adding/updating packages docs

  • Write docs on how to generate a package list on your system, and convert to a dictionary for defining a new system
  • Write docs on how to refresh a package list on your already defined system
    benchpark system external llnl-cluster cluster=ruby
    

• How to handle multiple versions of available libraries?

  • list-like

                   "externals": [
                       {"spec": "cmake@3.20.2", "prefix": "/usr"},
                       {"spec": "cmake@3.23.1", "prefix": "/usr/tce"},
                       {"spec": "cmake@3.24.2", "prefix": "/usr/tce"},
                   ],
  

• Write python utility to write out a dictionary to yaml (does the experiment example write a temporary file in a workspace?)

  • Not necessary as yaml.dump will do this.

• What is needed in bin to use it this way? Look at the experiment as an example.

  • Nothing additional is needed

• Update all system.py's which have yaml files stored

• For packages stored as a string right now, move the string to a file first? Packages stored as strings converted to dictionaries in-place.

• Create script to validate generated systems are the same as previous -- for the system using yaml files, this may be a yaml to dictionary comparison, which can also be useful for knowing when the package dict on the system needs to be updated.
  

Adding/modifying a system (docs: Adding a System)

Done (Migrate information in yamls systems/x/*.yaml to system.py)

• llnl-cluster
• aws-pcluster
• csc-lumi
• cscs-daint
• cscs-eiger
• generic-x86
• jsc-juwels
• lanl-venado
• llnl-elcapitan
• llnl-sierra
• riken-fugaku

Adding/modifying core functionality, CI, or documentation:

• Modify lib/benchpark/system/py and lib/benchpark/cmd/system.py
• Docs on generating a yaml file, converting to a dictionary to store in a system.py, updating

[michaelmckinsey1]

We want these refactored into the system.py, correct?

[pearce8]

Probably. @becker33, what do you think?

[michaelmckinsey1]

I've noticed how this is currently done in develop, some files have headers and some do not:

Case 1

# Copyright 2023 Lawrence Livermore National Security, LLC and other
# Benchpark Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: Apache-2.0

• {SYSTEM}/auxiliary_software_files/compilers.yaml
• {SYSTEM}/auxiliary_software_files/packages.yaml

Case 2

# SPDX-License-Identifier: Apache-2.0

• {SYSTEM}/variables.yaml

Case 3

No headers

• {SYSTEM}/software.yaml
• {SYSTEM}/software_id.yaml

Shouldn't this be consistent?

[pearce8]

@michaelmckinsey1 I added more tasks in this PR. Take a look and let me know what is already tackled - vs. needs to be added.

[michaelmckinsey1]

benchpark/systems/csc-lumi/externals/libsci/02-rocmcc-packages.yaml is apparently not being used, should this be deleted?

[michaelmckinsey1]

benchpark system external uses spack external find. for compilers, i.e. spack compiler find should this be the same command as external packages (benchpark system external) or its own command?