reaxkit 3.0.3__tar.gz → 3.2.0__tar.gz

reaxkit-3.2.0/PKG-INFO

@@ -0,0 +1,248 @@
+Metadata-Version: 2.4
+Name: reaxkit
+Version: 3.2.0
+Summary: A toolkit for parsing, analyzing, and visualizing ReaxFF simulation data.
+Home-page: https://ali-m-dinani.github.io/reaxkit/
+Author-email: Ali Mohammadi Dinani <alimohammadi2265@gmail.com>, Adri van Duin <acv13@psu.edu>, Yun Kyung Shin <yks2@psu.edu>, Alireza Sepehrinezhad <alireza.sepehri@psu.edu>, Seyed Mahmoud Mortazavi <mahmoud.mortazavi72@gmail.com>, Anirban Phukan <akp6421@psu.edu>, Jupjeet Dhingra <jvd6198@psu.edu>, Swarit Dwivedi <Swarit.Dwivedi@monash.edu>, Asma Ul Hosna <abh6073@psu.edu>, Mozhdeh Mirakhory <mjm8816@psu.edu>
+License-Expression: MIT
+Project-URL: Homepage, https://ali-m-dinani.github.io/reaxkit/
+Project-URL: Documentation, https://ali-m-dinani.github.io/reaxkit/
+Project-URL: Repository, https://github.com/ali-m-dinani/reaxkit
+Project-URL: Issues, https://github.com/ali-m-dinani/reaxkit/issues
+Requires-Python: >=3.9
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: numpy
+Requires-Dist: pandas
+Requires-Dist: scipy
+Requires-Dist: matplotlib>=3.6
+Requires-Dist: tqdm
+Requires-Dist: rich
+Requires-Dist: tabulate
+Requires-Dist: PyYAML
+Requires-Dist: rapidfuzz
+Requires-Dist: openpyxl>=3.1
+Requires-Dist: pyarrow
+Requires-Dist: threadpoolctl>=3.1
+Requires-Dist: psutil>=5.9
+Provides-Extra: profiling
+Requires-Dist: yappi<2,>=1.6; extra == "profiling"
+Provides-Extra: plot
+Requires-Dist: seaborn; extra == "plot"
+Requires-Dist: plotly; extra == "plot"
+Requires-Dist: imageio[ffmpeg]; extra == "plot"
+Provides-Extra: webui
+Requires-Dist: dash<5,>=3.1; extra == "webui"
+Requires-Dist: dash_bootstrap_templates; extra == "webui"
+Requires-Dist: fastapi; extra == "webui"
+Requires-Dist: duckdb<2,>=1.1; extra == "webui"
+Provides-Extra: trajectory
+Requires-Dist: MDAnalysis; extra == "trajectory"
+Requires-Dist: freud-analysis; extra == "trajectory"
+Requires-Dist: ovito; extra == "trajectory"
+Provides-Extra: materials
+Requires-Dist: ase; extra == "materials"
+Requires-Dist: mp_api; extra == "materials"
+Requires-Dist: pymatgen; extra == "materials"
+Provides-Extra: graph
+Requires-Dist: networkx; extra == "graph"
+Requires-Dist: igraph; extra == "graph"
+Provides-Extra: ml
+Requires-Dist: dscribe; extra == "ml"
+Requires-Dist: spacy; extra == "ml"
+Requires-Dist: scikit-learn; extra == "ml"
+Provides-Extra: io
+Requires-Dist: h5py; extra == "io"
+Requires-Dist: python-docx; extra == "io"
+Requires-Dist: zstandard; extra == "io"
+Provides-Extra: engines
+Requires-Dist: lammps; extra == "engines"
+Requires-Dist: plams; extra == "engines"
+Provides-Extra: all
+Requires-Dist: reaxkit[engines,graph,io,materials,ml,plot,profiling,trajectory,webui]; extra == "all"
+Dynamic: license-file
+
+# ReaxKit
+
+**ReaxKit** is a modular, extensible Python toolkit for **pre‑processing, post‑processing, and analysis of ReaxFF** molecular dynamics simulations.
+It provides a clean separation between file parsing, analysis routines, and reproducible workflows, with **Python APIs**, a **CLI interface**, and a **Dash-based GUI**.
+
+ReaxKit is designed for researchers who want a transparent, scriptable bridge between raw ReaxFF data and quantitative, publication‑ready results.
+
+---
+
+## Key Capabilities
+
+### Engine
+- Shared engine abstractions for consistent parsing and generating input/output files across 3 different ReaxFF simulation engines, namely `ams`, `lammps`, `reaxff`
+- Example IO and generator modules under the `reaxff` engine:
+  - ReaxFF input and output files such as `xmolout`, `fort.7`, `fort.13`, `molfra`, and more
+  - Input generators for `control`, `geo`, `eregime`, `tregime`, and related files
+
+### Analysis
+- `get-potential-energy --relative --num-atoms N --export energy.csv` exports `potential_energy`, `relative_potential_energy`, `potential_energy_per_atom`, and `relative_potential_energy_per_atom` alongside the existing axes and plotting columns. Relative values use source frame 0 by default (or `--reference-frame`), before sampling. `--per-atom` can instead use each frame's atom count; relative per-atom energy is the difference between the normalized frame and normalized reference energies.
+- Successful checkpointed CLI/workflow analyses consolidate their full recovery data into one verified `*.results.zip` file in the analysis cache, then remove their recovery checkpoint files after all requested outputs are saved. Repeating the same scientific options reuses this cache directly, without extracting batches or rerunning calculations. Interrupted analyses and failed output/cache writes keep their checkpoints for `--resume`. Explicit `--resume` takes precedence over cache reuse. With analysis caching disabled, checkpoints remain available; direct Python executor calls outside a workflow also retain them. Existing checkpoint folders are not swept automatically; successfully resuming one with caching enabled applies the same consolidation and cleanup.
+- `get-hbn-reference-local-polarization` skips the large local, cell, and layer CSV tables by default; add `--export-local-csv` to request them. Summary/mapping output and requested plots or `--write-extxyz` remain available. This only changes exports, not calculations or checkpoint data, and does not delete older CSVs. Per-atom displacement exports remain separately controlled by `--write-displacements` and the output profile.
+- AMS analyses can combine KF/RKF coordinates and charges with an external `fort.78` field schedule: use `--engine ams --input reaxout.kf --fort78 /path/to/fort.78`. Without an override, the adapter looks beside the KF/RKF file. The existing ReaxFF field reader preserves field components and MD iteration numbers; field-dependent analyses require matching iterations, not matching row numbers. Streaming parses the field schedule once. This supports charged-trajectory field export, local potential/field analyses, and charge-versus-field analysis. Missing fields are not replaced with zero.
+- Engine-agnostic analyzers built on ReaxKit's domain data models
+- Analyzer tasks organized around separated request, result, and task objects
+- Analysis components separated from engine IO so the same computations can be reused across scripts, workflows, web UI, and presentation modules
+
+### Workflows
+- Reproducible workflows organized by data handling, file tools, meta orchestration, presentation, and study design
+- Automation paths for common ReaxFF pre-processing, analysis, post-processing, and presentation tasks
+
+### Web UI
+- Dash-based interface components for interactive ReaxFF data inspection
+- Backend, UI, and presentation layers for browser-driven workflows
+
+### Presentation
+- Publication-ready plotting utilities:
+  - 2D plots, dual-axis plots, tornado plots, 3D scatter, and heatmaps
+- Video generators
+
+### Utilities
+- Shared data, media, and numerical utilities
+- Common infrastructure used by analysis, workflows, web UI, and presentation modules
+
+See the full documentation (API reference, tutorials, examples) on [ReaxKit Site](https://ali-m-dinani.github.io/reaxkit/).
+
+---
+
+## Project Layout
+
+```
+src/reaxkit/
+├── analysis/        # Engine-agnostic analysis tasks
+├── cli/             # Command-line entry points
+├── core/            # Registries and shared core infrastructure
+├── data/            # Packaged reference data and resources
+├── domain/          # Central data models, requests, and results
+├── engine/          # IO handlers and input generators
+├── help/            # Introspection and help system
+├── presentation/    # Plotting, active-site views, and media presentation
+├── utils/           # Shared data, media, and numerical utilities
+├── webui/           # Dash/web interface backend, UI, and presentation layers
+└── workflows/       # Workflow orchestration and automation
+```
+
+---
+
+##  Testing
+
+Run unit tests with:
+
+```bash
+pytest -s tests/
+```
+
+to test the package and get the timing for their execution.
+
+---
+
+## Command diagnostics
+
+Diagnostics are disabled by default for every CLI command. Pass `--diagnostics`
+after the command name to write a unique report folder under
+`reaxkit_workspace/logs/diagnostics/<command>_<UTC timestamp>_<unique suffix>/`
+(or beneath your `--project-root`). Its location is printed at command startup.
+Help and argument-parsing errors do not create reports. Recording starts after
+CLI imports and argument parsing, before command execution.
+
+- `report.json`: command arguments, interpreter/module paths, host, Slurm allocation,
+  timestamps, exit status, and the execution-step report.
+- `console.log`: Python stdout/stderr, including progress, also displayed normally.
+- `stacks.log`: Python stacks for all threads every 60 seconds, annotated with
+  UTC timestamps and elapsed seconds. Sample headers contain collection times;
+  observer annotations follow within roughly 0.25 seconds. The sampler's own
+  stack is excluded, and each stack is limited to 100 frames.
+- `stacks.raw.log`: original cooperative Python stack samples, retained
+  independently of the observer.
+- `stack_summary.txt` and `stack_summary.json`: live per-function tables grouped
+  by thread, with self/inclusive sample counts and estimated seconds (count times
+  sampling interval). Self means the top Python frame; inclusive means anywhere
+  in that thread's stack, counting recursive occurrences once per sample.
+  These are observations, not function-call counts or exact profiler timings.
+  Waiting time is included; inclusive and cross-thread times overlap and must
+  not be summed as command elapsed time. Short work between samples is missed.
+- `resources.jsonl`: approximately five-second samples of process CPU time,
+  resident memory, and thread count. CPU values are cumulative seconds, not percentages;
+  measurements cover the command process, not its subprocesses.
+- `steps.log`: finalized human-readable execution report; `exception.log` records
+  Python exceptions when present. `observer.log` contains observer errors, if any.
+
+Use `--diagnostics --diagnostic-interval-seconds 30` to enable diagnostics with a
+different stack interval. Place these flags after the command
+name. A Python thread collects referenced frames through `sys._current_frames()`.
+Native code holding the GIL delays stack sampling; missed samples are not
+backfilled, and estimated times can undercount that work. A separate lightweight
+observer continues resource monitoring even while analysis holds the GIL.
+Stack traces are written to files, not repeated on the console.
+
+Periodic diagnostics no longer use `faulthandler.dump_traceback_later`: its native
+watchdog can race with thread/frame teardown and crash the interpreter itself.
+ReaxKit does not install or cancel process-wide faulthandler timers or change
+fatal-signal handlers. `PYTHONFAULTHANDLER=1` can still record fatal errors in the
+scheduler log. Remove legacy watchdog wrappers such as `formal_diagnostic.sh`
+when using these built-in diagnostics.
+
+On forced termination (including Slurm time limits), finalization may not run.
+Existing console, stack, and resource samples remain; a `running` report with no
+finish time means **unfinished reporting**, not proof the job is still active.
+Native/subprocess writes that bypass Python streams stay in the scheduler logs.
+Reports contain supplied command arguments; inspect them before sharing.
+
+### Deterministic profiling (optional)
+
+Install from your clone with `python -m pip install -e '.[profiling]'`, using the
+same interpreter as the ReaxKit executable. Add `--diagnostics --profile` after the command name to
+record actual function-call events and measured durations with Yappi, across the
+main thread and Python worker threads. This is opt-in because instrumentation
+adds overhead. `--profile-clock wall` (default) includes waiting; use
+`--profile-clock cpu` for thread CPU time instead. Only one clock is recorded per run.
+
+The same per-command **diagnostics** folder contains `profile_summary.txt`
+(all functions sorted by cumulative time, with calls, primitive/nonrecursive
+calls, self seconds, cumulative seconds, and thread timings), `profile.json`
+(machine-readable equivalent), and `profile.pstat` (call graph for pstats-compatible
+viewers). These files are separate from the estimated `stack_summary.*` tables.
+Self time excludes callees; cumulative time includes them. Inclusive/thread wall
+times overlap and must not be added as job elapsed time. Timings are measured,
+not sampling estimates, but are not overhead-free or infinitely precise.
+
+Profiling begins just before command execution and is finalized on normal exit
+or a handled Python error. Startup imports/argument parsing, subprocesses, and
+internal C/Fortran/BLAS stacks are not profiled; visible native call boundaries
+are included. Forced termination can prevent profile files being saved; the
+periodic stack diagnostics still help investigate hangs. `--profile` requires
+diagnostics enabled and a fresh process without another active profiler or
+retained Yappi session. No extra profiler dependency is needed without `--profile`.
+
+## Citation
+
+If you use ReaxKit in your work, please cite:
+
+```text
+Mohammadi Dinani, A., et al. (2026).
+ReaxKit: A Modular Python Toolkit for Preparing, Parsing, and Analyzing ReaxFF Molecular Dynamics Simulations.
+arXiv:2609.22019. https://arxiv.org/abs/2609.22019
+
+Source code: https://github.com/ali-m-dinani/reaxkit
+Software archive: https://doi.org/10.5281/zenodo.18485384
+```
+
+---
+
+## Future Directions
+
+* Implement machine learning-based surrogate models for rapid property prediction and active-site identification.
+* Develop a plugin system for user-contributed analysis routines and visualization components.
+* Integrate with Jupyter notebooks for interactive analysis and visualization.
+
+If you have any feature request, you can submit it through the ReaxKit's GitHub page, or directly sending an email to `Dinani@psu.edu`.
+
+---
+## Additional resources:
+
+- [AUTHORS.md](AUTHORS.md) —  Full credits and acknowledgments.
+- [LICENSE](LICENSE) — Full license terms under the **MIT License**

reaxkit-3.2.0/README.md

@@ -0,0 +1,184 @@
+# ReaxKit
+
+**ReaxKit** is a modular, extensible Python toolkit for **pre‑processing, post‑processing, and analysis of ReaxFF** molecular dynamics simulations.
+It provides a clean separation between file parsing, analysis routines, and reproducible workflows, with **Python APIs**, a **CLI interface**, and a **Dash-based GUI**.
+
+ReaxKit is designed for researchers who want a transparent, scriptable bridge between raw ReaxFF data and quantitative, publication‑ready results.
+
+---
+
+## Key Capabilities
+
+### Engine
+- Shared engine abstractions for consistent parsing and generating input/output files across 3 different ReaxFF simulation engines, namely `ams`, `lammps`, `reaxff`
+- Example IO and generator modules under the `reaxff` engine:
+  - ReaxFF input and output files such as `xmolout`, `fort.7`, `fort.13`, `molfra`, and more
+  - Input generators for `control`, `geo`, `eregime`, `tregime`, and related files
+
+### Analysis
+- `get-potential-energy --relative --num-atoms N --export energy.csv` exports `potential_energy`, `relative_potential_energy`, `potential_energy_per_atom`, and `relative_potential_energy_per_atom` alongside the existing axes and plotting columns. Relative values use source frame 0 by default (or `--reference-frame`), before sampling. `--per-atom` can instead use each frame's atom count; relative per-atom energy is the difference between the normalized frame and normalized reference energies.
+- Successful checkpointed CLI/workflow analyses consolidate their full recovery data into one verified `*.results.zip` file in the analysis cache, then remove their recovery checkpoint files after all requested outputs are saved. Repeating the same scientific options reuses this cache directly, without extracting batches or rerunning calculations. Interrupted analyses and failed output/cache writes keep their checkpoints for `--resume`. Explicit `--resume` takes precedence over cache reuse. With analysis caching disabled, checkpoints remain available; direct Python executor calls outside a workflow also retain them. Existing checkpoint folders are not swept automatically; successfully resuming one with caching enabled applies the same consolidation and cleanup.
+- `get-hbn-reference-local-polarization` skips the large local, cell, and layer CSV tables by default; add `--export-local-csv` to request them. Summary/mapping output and requested plots or `--write-extxyz` remain available. This only changes exports, not calculations or checkpoint data, and does not delete older CSVs. Per-atom displacement exports remain separately controlled by `--write-displacements` and the output profile.
+- AMS analyses can combine KF/RKF coordinates and charges with an external `fort.78` field schedule: use `--engine ams --input reaxout.kf --fort78 /path/to/fort.78`. Without an override, the adapter looks beside the KF/RKF file. The existing ReaxFF field reader preserves field components and MD iteration numbers; field-dependent analyses require matching iterations, not matching row numbers. Streaming parses the field schedule once. This supports charged-trajectory field export, local potential/field analyses, and charge-versus-field analysis. Missing fields are not replaced with zero.
+- Engine-agnostic analyzers built on ReaxKit's domain data models
+- Analyzer tasks organized around separated request, result, and task objects
+- Analysis components separated from engine IO so the same computations can be reused across scripts, workflows, web UI, and presentation modules
+
+### Workflows
+- Reproducible workflows organized by data handling, file tools, meta orchestration, presentation, and study design
+- Automation paths for common ReaxFF pre-processing, analysis, post-processing, and presentation tasks
+
+### Web UI
+- Dash-based interface components for interactive ReaxFF data inspection
+- Backend, UI, and presentation layers for browser-driven workflows
+
+### Presentation
+- Publication-ready plotting utilities:
+  - 2D plots, dual-axis plots, tornado plots, 3D scatter, and heatmaps
+- Video generators
+
+### Utilities
+- Shared data, media, and numerical utilities
+- Common infrastructure used by analysis, workflows, web UI, and presentation modules
+
+See the full documentation (API reference, tutorials, examples) on [ReaxKit Site](https://ali-m-dinani.github.io/reaxkit/).
+
+---
+
+## Project Layout
+
+```
+src/reaxkit/
+├── analysis/        # Engine-agnostic analysis tasks
+├── cli/             # Command-line entry points
+├── core/            # Registries and shared core infrastructure
+├── data/            # Packaged reference data and resources
+├── domain/          # Central data models, requests, and results
+├── engine/          # IO handlers and input generators
+├── help/            # Introspection and help system
+├── presentation/    # Plotting, active-site views, and media presentation
+├── utils/           # Shared data, media, and numerical utilities
+├── webui/           # Dash/web interface backend, UI, and presentation layers
+└── workflows/       # Workflow orchestration and automation
+```
+
+---
+
+##  Testing
+
+Run unit tests with:
+
+```bash
+pytest -s tests/
+```
+
+to test the package and get the timing for their execution.
+
+---
+
+## Command diagnostics
+
+Diagnostics are disabled by default for every CLI command. Pass `--diagnostics`
+after the command name to write a unique report folder under
+`reaxkit_workspace/logs/diagnostics/<command>_<UTC timestamp>_<unique suffix>/`
+(or beneath your `--project-root`). Its location is printed at command startup.
+Help and argument-parsing errors do not create reports. Recording starts after
+CLI imports and argument parsing, before command execution.
+
+- `report.json`: command arguments, interpreter/module paths, host, Slurm allocation,
+  timestamps, exit status, and the execution-step report.
+- `console.log`: Python stdout/stderr, including progress, also displayed normally.
+- `stacks.log`: Python stacks for all threads every 60 seconds, annotated with
+  UTC timestamps and elapsed seconds. Sample headers contain collection times;
+  observer annotations follow within roughly 0.25 seconds. The sampler's own
+  stack is excluded, and each stack is limited to 100 frames.
+- `stacks.raw.log`: original cooperative Python stack samples, retained
+  independently of the observer.
+- `stack_summary.txt` and `stack_summary.json`: live per-function tables grouped
+  by thread, with self/inclusive sample counts and estimated seconds (count times
+  sampling interval). Self means the top Python frame; inclusive means anywhere
+  in that thread's stack, counting recursive occurrences once per sample.
+  These are observations, not function-call counts or exact profiler timings.
+  Waiting time is included; inclusive and cross-thread times overlap and must
+  not be summed as command elapsed time. Short work between samples is missed.
+- `resources.jsonl`: approximately five-second samples of process CPU time,
+  resident memory, and thread count. CPU values are cumulative seconds, not percentages;
+  measurements cover the command process, not its subprocesses.
+- `steps.log`: finalized human-readable execution report; `exception.log` records
+  Python exceptions when present. `observer.log` contains observer errors, if any.
+
+Use `--diagnostics --diagnostic-interval-seconds 30` to enable diagnostics with a
+different stack interval. Place these flags after the command
+name. A Python thread collects referenced frames through `sys._current_frames()`.
+Native code holding the GIL delays stack sampling; missed samples are not
+backfilled, and estimated times can undercount that work. A separate lightweight
+observer continues resource monitoring even while analysis holds the GIL.
+Stack traces are written to files, not repeated on the console.
+
+Periodic diagnostics no longer use `faulthandler.dump_traceback_later`: its native
+watchdog can race with thread/frame teardown and crash the interpreter itself.
+ReaxKit does not install or cancel process-wide faulthandler timers or change
+fatal-signal handlers. `PYTHONFAULTHANDLER=1` can still record fatal errors in the
+scheduler log. Remove legacy watchdog wrappers such as `formal_diagnostic.sh`
+when using these built-in diagnostics.
+
+On forced termination (including Slurm time limits), finalization may not run.
+Existing console, stack, and resource samples remain; a `running` report with no
+finish time means **unfinished reporting**, not proof the job is still active.
+Native/subprocess writes that bypass Python streams stay in the scheduler logs.
+Reports contain supplied command arguments; inspect them before sharing.
+
+### Deterministic profiling (optional)
+
+Install from your clone with `python -m pip install -e '.[profiling]'`, using the
+same interpreter as the ReaxKit executable. Add `--diagnostics --profile` after the command name to
+record actual function-call events and measured durations with Yappi, across the
+main thread and Python worker threads. This is opt-in because instrumentation
+adds overhead. `--profile-clock wall` (default) includes waiting; use
+`--profile-clock cpu` for thread CPU time instead. Only one clock is recorded per run.
+
+The same per-command **diagnostics** folder contains `profile_summary.txt`
+(all functions sorted by cumulative time, with calls, primitive/nonrecursive
+calls, self seconds, cumulative seconds, and thread timings), `profile.json`
+(machine-readable equivalent), and `profile.pstat` (call graph for pstats-compatible
+viewers). These files are separate from the estimated `stack_summary.*` tables.
+Self time excludes callees; cumulative time includes them. Inclusive/thread wall
+times overlap and must not be added as job elapsed time. Timings are measured,
+not sampling estimates, but are not overhead-free or infinitely precise.
+
+Profiling begins just before command execution and is finalized on normal exit
+or a handled Python error. Startup imports/argument parsing, subprocesses, and
+internal C/Fortran/BLAS stacks are not profiled; visible native call boundaries
+are included. Forced termination can prevent profile files being saved; the
+periodic stack diagnostics still help investigate hangs. `--profile` requires
+diagnostics enabled and a fresh process without another active profiler or
+retained Yappi session. No extra profiler dependency is needed without `--profile`.
+
+## Citation
+
+If you use ReaxKit in your work, please cite:
+
+```text
+Mohammadi Dinani, A., et al. (2026).
+ReaxKit: A Modular Python Toolkit for Preparing, Parsing, and Analyzing ReaxFF Molecular Dynamics Simulations.
+arXiv:2609.22019. https://arxiv.org/abs/2609.22019
+
+Source code: https://github.com/ali-m-dinani/reaxkit
+Software archive: https://doi.org/10.5281/zenodo.18485384
+```
+
+---
+
+## Future Directions
+
+* Implement machine learning-based surrogate models for rapid property prediction and active-site identification.
+* Develop a plugin system for user-contributed analysis routines and visualization components.
+* Integrate with Jupyter notebooks for interactive analysis and visualization.
+
+If you have any feature request, you can submit it through the ReaxKit's GitHub page, or directly sending an email to `Dinani@psu.edu`.
+
+---
+## Additional resources:
+
+- [AUTHORS.md](AUTHORS.md) —  Full credits and acknowledgments.
+- [LICENSE](LICENSE) — Full license terms under the **MIT License**

reaxkit-3.2.0/pyproject.toml

@@ -0,0 +1,108 @@
+[build-system]
+requires = ["setuptools>=77.0.3", "wheel"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "reaxkit"
+version = "3.2.0"
+description = "A toolkit for parsing, analyzing, and visualizing ReaxFF simulation data."
+authors = [
+    { name = "Ali Mohammadi Dinani", email = "alimohammadi2265@gmail.com" },
+    { name = "Adri van Duin", email = "acv13@psu.edu" },
+    { name = "Yun Kyung Shin", email = "yks2@psu.edu" },
+    { name = "Alireza Sepehrinezhad", email = "alireza.sepehri@psu.edu" },
+    { name = "Seyed Mahmoud Mortazavi", email = "mahmoud.mortazavi72@gmail.com" },
+    { name = "Anirban Phukan", email = "akp6421@psu.edu" },
+    { name = "Jupjeet Dhingra", email = "jvd6198@psu.edu" },
+    { name = "Swarit Dwivedi", email = "Swarit.Dwivedi@monash.edu" },
+    { name = "Asma Ul Hosna", email = "abh6073@psu.edu" },
+    { name = "Mozhdeh Mirakhory", email = "mjm8816@psu.edu" },
+]
+readme = "README.md"
+license = "MIT"
+license-files = ["LICENSE"]
+
+requires-python = ">=3.9"
+
+dependencies = [
+    "numpy",
+    "pandas",
+    "scipy",
+    "matplotlib>=3.6",
+    "tqdm",
+    "rich",
+    "tabulate",
+    "PyYAML",
+    "rapidfuzz",
+    "openpyxl>=3.1",
+    "pyarrow",
+    "threadpoolctl>=3.1",
+    "psutil>=5.9",
+]
+
+[project.urls]
+Homepage = "https://ali-m-dinani.github.io/reaxkit/"
+Documentation = "https://ali-m-dinani.github.io/reaxkit/"
+Repository = "https://github.com/ali-m-dinani/reaxkit"
+Issues = "https://github.com/ali-m-dinani/reaxkit/issues"
+
+[project.optional-dependencies]
+profiling = ["yappi>=1.6,<2"]
+plot = [
+    "seaborn",
+    "plotly",
+    "imageio[ffmpeg]",
+]
+webui = [
+    "dash>=3.1,<5",
+    "dash_bootstrap_templates",
+    "fastapi",
+    "duckdb>=1.1,<2",
+]
+trajectory = [
+    "MDAnalysis",
+    "freud-analysis",
+    "ovito",
+]
+materials = [
+    "ase",
+    "mp_api",
+    "pymatgen",
+]
+graph = [
+    "networkx",
+    "igraph",
+]
+ml = [
+    "dscribe",
+    "spacy",
+    "scikit-learn",
+]
+io = [
+    "h5py",
+    "python-docx",
+    "zstandard",
+]
+engines = [
+    "lammps",
+    "plams",
+]
+all = [
+    "reaxkit[plot,webui,trajectory,materials,graph,ml,io,engines,profiling]",
+]
+
+[project.scripts]
+reaxkit = "reaxkit.cli_startup:main"
+
+[tool.setuptools]
+package-dir = { "" = "src" }
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+reaxkit = ["**/*.yaml", "**/*.xlsx", "**/*.cif", "webui/**/*.json", "webui/assets/*.js", "webui/assets/*.css", "webui/assets/*.svg"]
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]
+

reaxkit-3.2.0/setup.cfg

@@ -0,0 +1,7 @@
+[metadata]
+url = https://ali-m-dinani.github.io/reaxkit/
+
+[egg_info]
+tag_build = 
+tag_date = 0
+

{reaxkit-3.0.3 → reaxkit-3.2.0}/src/reaxkit/analysis/__init__.py

@@ -10,6 +10,7 @@ from reaxkit.analysis import (
     connectivity,
     control,
     electrostatics,
+    ferroelectrics,
     force_field,
     kinematics,
     molecular_analysis,
@@ -23,6 +24,7 @@ __all__ = [
     "connectivity",
     "control",
     "electrostatics",
+    "ferroelectrics",
     "force_field",
     "kinematics",
     "molecular_analysis",

{reaxkit-3.0.3 → reaxkit-3.2.0}/src/reaxkit/analysis/active_sites/event_diagnostics.py

@@ -18,6 +18,7 @@ from reaxkit.analysis.active_sites.models import (
     ActiveSiteEventDiagnosticsResult,
 )
 from reaxkit.analysis.active_sites.pbc import frame_cell_matrix, pairwise_min_image_distances
+from reaxkit.core.runtime.frame_tables import selected_frame_envelopes
 from reaxkit.analysis.base import AnalysisTask
 from reaxkit.core.registry.analysis_task_registry import register_task
 from reaxkit.domain.data_models import ConnectivityTrajectoryData, TrajectoryData
@@ -100,6 +101,7 @@ class ActiveSiteEventDiagnosticsTask(AnalysisTask):
 
     VERSION = "3"
     required_data = TrajectoryData
+    supports_selective_streaming = True
 
     def required_data_for(self, request: object, args: dict | None = None):
         return TrajectoryData
@@ -287,9 +289,8 @@ class ActiveSiteEventDiagnosticsTask(AnalysisTask):
         every = max(1, int(request.every))
         limit = max(1, int(request.max_diag_frames))
 
-        for stream_index, data in enumerate(frames):
-            if stream_index % every:
-                continue
+        for envelope in selected_frame_envelopes(frames, request):
+            stream_index, data = envelope.source_frame, envelope.payload
             if analyzed >= limit:
                 break
             if isinstance(data, ConnectivityTrajectoryData):

{reaxkit-3.0.3 → reaxkit-3.2.0}/src/reaxkit/analysis/active_sites/events.py

@@ -23,6 +23,7 @@ import pandas as pd
 from reaxkit.analysis.active_sites.models import ActiveSiteEventsRequest, ActiveSiteEventsResult
 from reaxkit.analysis.active_sites.pbc import frame_cell_matrix, pairwise_min_image_distances
 from reaxkit.analysis.active_sites.tract_compat import to_tract_events_table
+from reaxkit.core.runtime.frame_tables import selected_frame_envelopes
 from reaxkit.analysis.base import AnalysisTask
 from reaxkit.core.registry.analysis_task_registry import register_task
 from reaxkit.domain.data_models import ConnectivityTrajectoryData, TrajectoryData
@@ -179,6 +180,8 @@ def _rkf_like_input(args: dict) -> bool:
 class ActiveSiteEventsTask(AnalysisTask):
     """Extract persistent C-O and C-Si active-site events over trajectory frames."""
 
+    VERSION = "1"
+    supports_selective_streaming = True
     required_data = ConnectivityTrajectoryData
 
     def required_data_for(self, request: object, args: dict | None = None):
@@ -582,9 +585,8 @@ class ActiveSiteEventsTask(AnalysisTask):
         use_bo = False
         every = max(1, int(request.every))
 
-        for stream_index, data in enumerate(frames):
-            if stream_index % every:
-                continue
+        for envelope in selected_frame_envelopes(frames, request):
+            stream_index, data = envelope.source_frame, envelope.payload
             if isinstance(data, ConnectivityTrajectoryData):
                 trajectory = data.trajectory
                 connectivity_data = data

{reaxkit-3.0.3 → reaxkit-3.2.0}/src/reaxkit/analysis/active_sites/structural.py

@@ -554,6 +554,7 @@ def _label_edge_atoms(
 class ActiveSiteStructuralTask(AnalysisTask):
     """Compute per-atom active-site structural descriptors on one frame."""
 
+    VERSION = "1"
     required_data = ConnectivityTrajectoryData
 
     def required_data_for(self, request: object, args: dict | None = None):