Merge pull request #95 from glotzerlab/row

Migrate to row.

.github/workflows/requirements-test.in

@@ -0,0 +1,6 @@
+h5py
+matplotlib
+numpy
+rtoml
+scipy
+signac

.github/workflows/requirements-test.txt

@@ -1,6 +1,45 @@
-h5py==3.10.0
-gsd==3.2.1
-numpy==1.26.4
-PyYAML==6.0.1
+# This file was autogenerated by uv via the following command:
+#    uv pip compile requirements-test.in
+contourpy==1.2.1
+    # via matplotlib
+cycler==0.12.1
+    # via matplotlib
+filelock==3.15.4
+    # via signac
+fonttools==4.53.1
+    # via matplotlib
+h5py==3.11.0
+    # via -r requirements-test.in
+kiwisolver==1.4.5
+    # via matplotlib
+matplotlib==3.9.2
+    # via -r requirements-test.in
+numpy==2.1.0
+    # via
+    #   -r requirements-test.in
+    #   contourpy
+    #   h5py
+    #   matplotlib
+    #   scipy
+packaging==24.1
+    # via
+    #   matplotlib
+    #   signac
+pillow==10.4.0
+    # via matplotlib
+pyparsing==3.1.2
+    # via matplotlib
+python-dateutil==2.9.0.post0
+    # via matplotlib
+rtoml==0.11.0
+    # via -r requirements-test.in
+scipy==1.14.1
+    # via -r requirements-test.in
 signac==2.2.0
-signac-flow==0.28.0
+    # via -r requirements-test.in
+six==1.16.0
+    # via python-dateutil
+synced-collections==1.0.0
+    # via signac
+tqdm==4.66.5
+    # via signac

.github/workflows/stale.yaml

@@ -0,0 +1,11 @@
+name: Close stale issues and PRs
+
+on:
+  schedule:
+    - cron: '0 19 * * *'
+
+  workflow_dispatch:
+
+jobs:
+  stale:
+    uses: glotzerlab/workflows/.github/workflows/stale.yaml@ea2e25d07af862a1c696a932c2bd6b242d142049 # 0.2.0

.github/workflows/test.yaml

@@ -0,0 +1,38 @@
+name: Unit test
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+on:
+  pull_request:
+
+  push:
+    branches:
+    - "main"
+
+  workflow_dispatch:
+
+jobs:
+  status:
+    name: Initialize and show status
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout
+      uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4.1.6
+    - name: Set up Python
+      uses: actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d # v5.1.0
+      with:
+        python-version: "3.12"
+    - name: Set up Python environment
+      uses: glotzerlab/workflows/setup-uv@ae7e7c6931098a313ef8069ef04b88a55c3a40f6 # 0.3.0
+      with:
+        lockfile: ".github/workflows/requirements-test.txt"
+    - name: Initialize workspace
+      run: python3 hoomd_validation/project.py init
+    - name: Show workflow
+      run: cat --number workflow.toml
+    - name: Set up row
+      uses: glotzerlab/workflows/setup-row@ae7e7c6931098a313ef8069ef04b88a55c3a40f6 # 0.3.0
+    - name: Show project status
+      run: row show status

.gitignore

@@ -1,13 +1,10 @@
-workspace
-templates
+__pycache__
+.row
+.signac_sp_cache.json.gz
+.signac
 *.out
 *.svg
 hoomd_validation/__pycache__
-hoomd_validation/config.json
-signac.rc
 signac_project_document.json
-.signac_sp_cache.json.gz
-__pycache__
-.signac
-.bundles
-*.code-workspace
+workflow.toml
+workspace

ARCHITECTURE.md

@@ -6,32 +6,44 @@ The code in this repository is designed to run validation tests using HOOMD-blue
 for longer periods of time than CI testing can handle. Users of this repository
 should be able to:
 
-1. Run a set of validation test workflows on a variety of hardware setups.
+1. Run a set of validation test workflows on the machine of their choice (workstation
+   and/or HPC).
 
-2. Choose specific validation workflows to run, and be able to select subsets of
-the operations in one workflow to run.
+2. Choose specific validation workflows to run and be able to select subsets of
+   the actions in one workflow to run.
 
-3. Visualize the validation test output and analysis using signac-dashboard.
+3. Visualize the test output and analysis using signac-dashboard.
 
 ## Implementation
 
 To minimize the amount of effort needed to execute all test workflows (1),
-Each validation test workflow is defined as a "subproject" of a single signac-flow
-project. All operations on a subproject are prefixed with the subprojet's name
-to allow for regex selection of operations at the command line (2). All operations
-in a subproject use a precondition or `select` argument to limit their operations
-only to the signac jobs specific to that subproject.
-
-To further facilitate (2), all subprojects that require it will have an operation
-`<subproject>_create_initial_state` as the first step in the workflow to prepare the
-initial conditions used for later steps. All subprojects will also suffix operation
+Each validation test workflow is defined as a "subproject" of a single row
+project. All actions on a subproject are prefixed with the subprojet's name
+to allow for glob selection of actions at the command line (2). All actions
+in a subproject limit their actions to the signac jobs specific to that
+subproject.
+
+To further facilitate (2), all subprojects that require it will have an action
+`<subproject>.create_initial_state` as the first step in the workflow to prepare the
+initial conditions used for later steps. All subprojects will also suffix action
 names with `_cpu` or `_gpu` according to the HOOMD device they execute on.
 
 Each subproject is defined in its own module file (e.g. `lj_fluid.py`). Each module
-must have a function `job_statepoints` that generates the statepoints needed for the job.
-Each statepoint must have a key `"subproject"` with its name matching the subproject.
-The subproject module file also includes all the flow operations for that subproject.
+must have a function `job_statepoints` that generates the state points needed for the
+job. Every state point must have a key `"subproject"` with its name matching the
+subproject. The subproject module file implements all the actions.
 
 To add a subproject, implement its module, then:
 1. Import the subproject module in `project.py`.
 2. Import the subproject module in `init.py` and add it to the list of subprojects.
+
+## Configuration
+
+`hoomd-validation` allows user configuration of many parameters (such as walltime,
+cores per job, etc...). Therefore, the row `workflow.toml` file must be dynamically
+generated which is facilitated by the module `workflow.py`. Each subproject file (e.g.
+`lj_fluid.py`) adds actions to the global list of actions in `action.py` with the
+computed parameters based on the configuration file. The list of actions is used in
+two ways. First, `init.py` will write out the `workflow.toml` that corresponds to
+the current configuration. Second, `project.py` will dispatch actions to the methods
+registered in `action.py`.