diff --git a/.cursorrules b/.cursorrules index 81af038be..f57b0d6e9 100644 --- a/.cursorrules +++ b/.cursorrules @@ -56,3 +56,11 @@ contract should be committed. - **No Development Slang**: Do not use release or development slang such as "ships with", "hack", "epic", or "fix this later". - **No Process-Derived Claims**: Do not use issue numbers, pull-request numbers, ticket identifiers, or private workflow phases as scientific explanation. Describe the implemented behavior and evidence directly. - **No Emoticons**: Do not use emojis or emoticons in the documentation or source code. + +## Trajectory storage + +Default new trajectory/dataset writers and sample configurations to HDF5 +(`training_data.h5`; `trajectory_format: h5`). Zarr or both formats must be +explicitly requested, never selected as a silent fallback. Preserve existing +Zarr readers/results. Apply the same convention to notebooks and documentation; +see `docs/user_guide/example_contract.md`. diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index d48cd08ba..3e2de4898 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -27,3 +27,11 @@ PYTHONPATH=src python -m phast run --validate-only ``` - When changing solver code, preserve autograd, dtype, and device semantics. + +## Trajectory storage + +- Use HDF5 (`training_data.h5`, `trajectory_format: h5`) by default for new + trajectory/dataset writers, configurations, notebooks, and documentation. +- Zarr requires explicit selection; do not add automatic Zarr fallbacks. +- Preserve existing Zarr readers and artifacts. Follow + `docs/user_guide/example_contract.md` for output conventions. diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 62ecd798c..272b20da8 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -41,7 +41,7 @@ the implementation. - [ ] No raw HPC result bundles, unpublished meeting material, or heavy generated media were added to git. -- [ ] New trajectory output is Zarr-first, or legacy H5 use is explicitly - compatibility-only. +- [ ] New trajectory output defaults to HDF5 (`training_data.h5`); any Zarr + output is explicitly requested and documented, not an automatic fallback. - [ ] New/changed benchmark configs are documented in the relevant README or contract. diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index becff143a..d8300f9d4 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -39,6 +39,12 @@ jobs: run: | python -m phast run examples/dynamic/B2_kalthoff_winkler/config.yaml --validate-only python -m phast run examples/solid_mechanics_beta/linear_plate/config.yaml --validate-only + python -m phast run examples/standard_workflow/quasistatic_sent/config.yaml --validate-only + python -m phast run examples/standard_workflow/dynamic_sent/config.yaml --validate-only + python -m phast run examples/two_material_dcb_beta/config.yaml --validate-only + + - name: Replot the retained DCB comparison + run: python examples/two_material_dcb_beta/compare_results.py --output-dir runs/public_comparison_check supported-python-range: name: Python ${{ matrix.python-version }} / Ubuntu diff --git a/AGENTS.md b/AGENTS.md index 4ee25ecfa..d18b92ac1 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -114,3 +114,16 @@ generated artifacts and must not be committed. - **No Development Slang**: Do not use release or development slang such as "ships with", "hack", "epic", or "fix this later". - **No Process-Derived Claims**: Do not use issue numbers, pull-request numbers, ticket identifiers, or private workflow phases as scientific explanation. Describe the implemented behavior and evidence directly. - **No Emoticons**: Do not use emojis or emoticons in the documentation or source code. + +## Default Trajectory Storage + +- Default new trajectory and dataset output to HDF5 (`training_data.h5`). + Keep trajectory saving opt-in where it is currently opt-in. +- Do not create directory-based Zarr stores unless the user or configuration + explicitly requests `zarr` or `both`. Never use Zarr as a silent fallback. +- Apply this convention to runtime defaults, schema defaults, examples, + notebooks, READMEs, documentation, and generated output manifests. +- Preserve existing Zarr readers and results. Do not convert, rename, or + delete previous result stores without a separate request. +- Follow the trajectory storage section of + `docs/user_guide/example_contract.md` when introducing a writer. diff --git a/CONFIGURATION_STYLE.md b/CONFIGURATION_STYLE.md new file mode 100644 index 000000000..3a6002525 --- /dev/null +++ b/CONFIGURATION_STYLE.md @@ -0,0 +1,107 @@ +# Configuration authoring rules + +These rules are mandatory for new public YAML examples, their READMEs, and +tutorials. Use them with [DOCUMENTATION_STYLE.md](DOCUMENTATION_STYLE.md) and +the [example contract](docs/user_guide/example_contract.md). Write for an +undergraduate who knows forces and displacements but is new to PhAST. + +## One layout, supported execution routes + +Use `schema_version: 2` for new standard-workflow teaching problems when the +required execution adapter exists and has passed its checks. Keep this +top-level order, omitting only genuinely unused optional sections: + +| Order | Key | Question answered | +|---|---|---| +| 1 | `schema_version` | Which input format is this? | +| 2 | `name` | What problem is being solved? | +| 3 | `reference` | What is the source or teaching scope? | +| 4 | `geometry` | What domain and mesh are used? | +| 5 | `regions` | Which elements and nodes belong to each selection? | +| 6 | `materials` | What properties does each material have? | +| 7 | `assignments` | Which material belongs to each element region? | +| 8 | `initial_conditions` | What starting state or maintained damage is prescribed? | +| 9 | `boundary_conditions` | What is restrained or loaded? | +| 10 | `analysis_steps` | What physical analysis and loading are requested? | +| 11 | `solver` | How is the analysis solved numerically? | +| 12 | `outputs` | Where are histories, fields, and visuals written? | + +Use actual parser keys, two-space indentation, descriptive region names, and +brief section comments. In schema 2, do not substitute the legacy singular +`material`, `loading`, or `output` sections. Put units and the effect of +changing a value next to the input. Label partial YAML excerpts as partial; +use a complete checked-in file for runnable instructions. + +A common layout is not a promise that every solver supports every section. +Check the [capability matrix](docs/user_guide/capability_matrix.md). The +documented multi-material route is a CPU float64, structured-T3 rectangle, +quasi-static Amor AT2 model with elementwise `E` and `Gc`, shared `nu` +and `l0`, and Dirichlet conditions. It is not dynamic multi-material +fracture or an independent interface law. + +Keep existing schema-1 benchmark inputs explicitly labelled. Do not migrate +frozen course assets or separate 3D research merely to make inputs uniform. +Unsupported routes remain separate until an adapter and evidence exist. + +## Explain editable choices + +- Separate geometry from mesh resolution. Name the boundary, crack, and + material selectors that must change when dimensions or mesh change. +- Explain `E` as elastic stiffness and `Gc` as fracture resistance. + A tougher region need not be stiffer; vary one property at a time. +- State a consistent unit system. A `units` label does not repair + inconsistent bare numbers. Dynamics requires meaningful density and time. +- Separate physical analysis from integration. Quasi-static analysis omits + inertia; dynamics includes inertia, and explicit integration needs a + CFL-limited time step. +- Separate final physical time, step limits, load increments, solver + iterations, and output cadence. Use the selected adapter's actual keys. +- Define the mesh measure in `h/l0`. Neither one resolution ratio nor a + smaller time step is a universal convergence or physical-validation test. + +## Use the same command sequence + +Run from the installed repository root. Replace `CONFIG` with the YAML +path and `RUN` with a new output directory; neither is a literal filename. + +```bash +python -m phast explain-config CONFIG +python -m phast run CONFIG --validate-only +python -m phast run CONFIG --output_dir RUN +``` + +Explain, check the supported input contract, then solve. Confirm all three +commands for the selected schema before promoting the example. Do not +present legacy `precheck --config` as a universal schema-2 command. + +## README and tutorial minimum + +Use this sequence: physical question; prerequisites and installation; exact +commands; input-section map; safe edits; outputs; evidence and limitations; +help. Source-install instructions require Python 3.10 or newer, separate +macOS/Linux and Windows environment commands, editable installation, and +the optional dependency route using `requirements.txt`. Do not claim a +checkout is the latest release. + +The main teaching sequence is the small single-material quasi-static SENT, +small single-material dynamic SENT, and full layered DCB configuration. +Identify their execution-check status. A setup exercise need not propagate +a crack; initial `damage = 1` is not new growth. Distinguish algebraic +convergence, discretisation checks, matched controls, independent scientific +review, and experimental validation. + +Compact complete comparison inputs are permitted duplication of model data, +not duplicated solver code. Keep the same section order, change only the +declared comparison inputs, use the common CLI and separate output directories, +and state what is held fixed. Do not add a comparison-specific solver driver. + +When trajectory saving is requested, default to HDF5 (`training_data.h5`). +Preserve existing opt-in behaviour and keep large raw stores out of the public +payload. Show retained PNG/GIF assets with captions and a static fallback; +use repository-relative MyST figure paths that Sphinx can collect, not +unverified public raw URLs. + +Before publication, record exact command checks and the documentation build; +identify checks not run. End substantial tutorials with a +[GitHub issue invitation](https://github.com/CEMS-Lab/PhAST/issues/new/choose) +requesting the config, command, OS, Python/PhAST version, and full error. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 89c9ede44..5ee7450aa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,7 +27,8 @@ machine: pip install -e ".[dataset]" ``` -PETSc, MUMPS, cuDSS, AmgX, and vendor solvers are optional backend checks and are not required for the default CPU confidence suite. +PETSc, MUMPS, cuDSS, AmgX, and vendor solvers are optional. They are not +required for the standard CPU test suite. ## 2. First Contribution @@ -45,9 +46,9 @@ All participation is governed by [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md). ## 3. Coding Standards -- **Type Hinting**: All new Python functions must use strict type hints. -- **Device Safety**: Ensure tensor operations are device-agnostic (`cpu`/`cuda`). -- **Autograd Compatibility**: Preserve and document autograd compatibility for +- **Type hinting**: All new Python functions must use strict type hints. +- **Device safety**: Ensure tensor operations are device-agnostic (`cpu`/`cuda`). +- **Autograd compatibility**: Preserve and document autograd compatibility for supported smooth tensor pathways. Identify nonsmooth history updates, projections, bounds, active sets, and external sparse-backend boundaries. @@ -57,8 +58,10 @@ All participation is governed by [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md). welcome, but public changes are merged only after maintainer review and approval. - Run the relevant validation commands locally. -- Keep high-fidelity volumetric datasets (Zarr/H5), local diagnostic logs, and generated heavy media out of git. -- Provide parity checks against established analytical or commercial benchmarks when modifying physics kernels. +- Keep large volumetric datasets (Zarr/H5), local debugging logs, and generated + media out of git. +- Compare changes to physics kernels against an appropriate analytical, + numerical, or published reference problem. - Update relevant documentation, such as `README.md`, YAML schemas, example READMEs, and capability pages, with user-facing changes. @@ -78,7 +81,7 @@ For changed YAML examples or benchmark configs, also run: PYTHONPATH=src python -m phast run --validate-only ``` -For generated visuals or retained example artifacts, inspect the output folder +For generated visualisations or example results, inspect the output folder and update the relevant README or public contract file. The public repository includes the tests intended for public review. Run any additional, project-specific checks documented in the pull request or issue that motivated @@ -91,6 +94,19 @@ folders also contain public-facing `README.md` files, so changes to example commands, inputs, outputs, or visuals usually require both docs and example README updates. +All documentation, README, tutorial, and notebook prose must follow +[`DOCUMENTATION_STYLE.md`](DOCUMENTATION_STYLE.md). The guide defines the +project's academic tone, terminology, capability labels, command conventions, +and checks for avoiding internal development language in public text. + +New YAML inputs, example READMEs, and tutorials must additionally follow +[`CONFIGURATION_STYLE.md`](CONFIGURATION_STYLE.md). Keep the same schema-2 +section order across supported student problems, define units and editable +choices, and use the explain/check/run sequence. A common layout does not +imply an execution adapter: require adapter and command checks before +promotion. Preserve numerical inputs in documentation-only edits. Frozen +course assets and separate 3D research are not migration targets. + Install the documentation dependencies: ```bash @@ -118,7 +134,8 @@ When editing curated examples, use `docs/user_guide/example_contract.md` as the source of truth for required files, README content, visuals, and artifact conventions. -AI-assisted contributions are welcome when they follow `AGENTS.md`, `llms.txt`, +AI-assisted contributions are welcome when they follow `DOCUMENTATION_STYLE.md`, +`AGENTS.md`, `llms.txt`, `.cursorrules`, and `docs/agent-contribution-guide.md`. Agents should verify commands where possible and must not invent solver capabilities, benchmark results, paper metadata, or local/HPC provenance. @@ -132,13 +149,21 @@ available, manifests, lightweight CSV outputs, setup/final-state visuals, and an evolution animation appropriate to the physics. The README should document the problem definition, exact run command, expected -artifacts, evidence boundary, and result-inspection snippet. Do not commit raw +results, scope of validation, and result-inspection snippet. Do not commit raw HPC run trees, large H5/Zarr stores, or unpublished diagnostic archives. -## 8. Asking For Help +## 8. Trajectory Storage Convention + +New trajectory and dataset writers, example configurations, notebooks, and +documentation must use HDF5 (`training_data.h5`) by default. Zarr is an explicit +opt-in, not a fallback. Keep existing Zarr readers and previously generated +artifacts intact. Match the selected format in output manifests and follow +the [example contract](docs/user_guide/example_contract.md). + +## 9. Asking For Help Open an issue if you are unsure how to install PhAST, interpret a configuration, run an example, or contribute a change. A useful help request includes the -command, configuration path, operating system, PyTorch version, and the first -warning or traceback. It is acceptable to open an issue before diagnosing the -solver internals. +command, configuration path, PhAST version or commit, operating system, Python +and PyTorch versions, and the complete first warning or traceback. It is +acceptable to open an issue before diagnosing the solver internals. diff --git a/DOCUMENTATION_STYLE.md b/DOCUMENTATION_STYLE.md new file mode 100644 index 000000000..e1367bd3e --- /dev/null +++ b/DOCUMENTATION_STYLE.md @@ -0,0 +1,771 @@ +# PhAST Public Documentation Style and Conventions + +This guide applies to all public-facing prose in the PhAST repository. Check +it whenever creating or reviewing: + +- the root `README.md`; +- a README under `examples/`, `configs/`, `scripts/`, or another subdirectory; +- pages under `docs/`; +- tutorial and notebook narrative cells; +- public configuration comments; +- public release notes and changelog entries. + +The objective is clear, accurate, academic documentation that an undergraduate +student can follow without prior knowledge of PhAST. Documentation must also +state the implemented scope honestly so that readers can decide whether the +software is suitable for their work. + +This file governs public software documentation. Journal manuscripts, +responses to reviewers, private research notes, and generated API text may +have additional requirements. + +New YAML examples, example READMEs, and tutorials must also follow +[`CONFIGURATION_STYLE.md`](CONFIGURATION_STYLE.md). It defines the common +schema-2 section order, student-facing explanations, command sequence, and +checks required before promoting an execution route. Preserve numerical +inputs during writing-only edits; do not migrate frozen course assets or +separate 3D research simply to make inputs uniform. + +Sections 19 and 20 provide transferable writing directives for scientific +explanations and, when requested, research proposals. Apply the structure +appropriate to the document: a proposal describes work to be tested, whereas +public software documentation describes verified capabilities. Writing +examples below do not establish implemented features or numerical results. + +## 1. Required working practice + +Before writing: + +1. Identify the reader and the task the page supports. +2. Check the current implementation, command help, schema, and runnable + examples before describing a capability. +3. Decide whether the page is a tutorial, explanation, reference, example + README, or installation guide. +4. Use the relevant page structure in Section 4. + +Before merging: + +1. Read the page once from beginning to end as a new user would. +2. Run every new command and runnable configuration when the change requires + execution verification. +3. Confirm that paths, command-line options, configuration keys, units, and + output filenames match the repository. +4. Check all capability statements against the public capability matrix. +5. Remove internal project-management language and unsupported claims. +6. Confirm that links, equations, tables, images, and code blocks render. +7. Keep limitations and experimental status visible. + +Passing a documentation build confirms that the page renders. It does not +confirm that a scientific claim or numerical result is correct. + +## 2. Voice and audience + +Write as a researcher explaining a numerical method to another researcher. +Use direct, neutral language. Be precise without assuming that the reader +already knows the repository. + +- Put one main idea in each sentence. +- Prefer sentences shorter than 30 words. Split sentences longer than 40. +- Introduce a term before using its abbreviation. +- State what the software does before discussing implementation details. +- Explain why a command, parameter, or numerical choice matters. +- Give a limitation once in the most relevant location. +- Use positive statements without hiding unsupported cases. +- Distinguish mathematical properties, implementation choices, numerical + results, and physical validation. +- Avoid conversational filler, exaggerated language, and sales language. +- Address the reader as `you` in step-by-step instructions when this improves + clarity. Use impersonal academic prose for theory and method descriptions. + +A technical paragraph should normally follow this order: + +1. Setup or question. +2. Method or operation. +3. Result or expected output. +4. Meaning and stated scope. + +## 3. Academic language + +### 3.1 UK English + +Use UK English except in code identifiers, software names, quotations, and +external taxonomy names. + +Preferred forms include: + +- optimisation, regularisation, discretisation, normalisation; +- behaviour, colour; +- centre, centred; +- modelling, labelled; +- analyse, summarise; +- artefact in ordinary prose. + +Do not rename code identifiers to enforce UK spelling. + +### 3.2 Punctuation and typography + +- Do not use em dashes. Use a comma, parentheses, or a separate sentence. +- Use hyphens consistently in terms such as `phase-field`, `finite-element`, + `load-displacement`, and `matrix-free`. +- Use commas as thousands separators in Markdown, for example `10,300`. +- Put spaces between numerical values and units in prose. +- Define symbols and units at first use on each self-contained page. +- Use `$G_c$` for fracture toughness and `$\ell_0$` for the regularisation + length in Markdown equations. +- Do not use raw LaTeX commands outside supported mathematics delimiters. + +### 3.3 Remove filler + +Delete phrases that delay the technical statement: + +- importantly; +- notably; +- crucially; +- it is worth noting that; +- it can be observed that; +- it is clear that; +- needless to say; +- as everyone knows. + +Write the fact directly. + +## 4. Page structures + +### 4.1 Tutorial + +A tutorial should contain: + +1. Purpose and learning outcome. +2. Prerequisites. +3. Required files and working directory. +4. Geometry and mesh. +5. Material and phase-field parameters. +6. Loads and boundary conditions. +7. Solver selection and convergence settings. +8. Exact execution command. +9. Expected outputs. +10. Visualisation and physical interpretation. +11. Limitations and supported variations. +12. A small next experiment. + +Do not hide essential setup in an earlier tutorial unless the dependency is +explicitly linked. + +### 4.2 Installation guide + +An installation guide should contain: + +1. Supported or tested operating systems and Python versions. +2. The recommended installation route first. +3. Alternative routes and their additional requirements. +4. Exact commands from a clean environment. +5. A short verification command. +6. Expected success output. +7. Common errors and recovery steps. +8. Optional backend requirements. + +Do not call installation easy, simple, or one-command unless the documented +procedure demonstrates that statement on the stated platforms. + +### 4.3 Reference page + +A reference page should contain: + +1. Purpose. +2. Capability status. +3. Inputs, types, defaults, and units. +4. Supported combinations. +5. Outputs and side effects. +6. Errors and failure conditions. +7. A minimal valid example. +8. Links to relevant tutorials and implementation notes. + +Reference pages should be complete enough to use without reading source code. + +### 4.4 Explanation or theory page + +An explanation page should proceed from the physical model to the numerical +method and then to the PhAST implementation: + +1. Physical question and assumptions. +2. Governing equations. +3. Definition of every symbol and unit. +4. Spatial and temporal discretisation. +5. Coupling and solution procedure. +6. Configuration keys controlling the implementation. +7. Numerical limitations and validation scope. + +Do not present a mathematical formulation as implemented unless the code and +configuration route support it. + +### 4.5 Root README + +The root README should remain concise. It should contain: + +1. A one-paragraph description of PhAST. +2. Current supported scope and important boundaries. +3. The shortest verified installation and first-run commands. +4. Links to the documentation, examples, capability matrix, citation, + licence, contribution guide, and issue tracker. +5. One representative result or visual with a precise caption. + +Do not duplicate the complete theory, configuration reference, or every +example in the root README. + +### 4.6 Example README + +Every runnable example README should state: + +1. The physical problem and benchmark identifier. +2. Geometry and dimensionality. +3. Material and phase-field formulation. +4. Loading and boundary conditions. +5. Mesh scale relative to `$\ell_0$`. +6. Solver route and important tolerances. +7. Exact command from a stated working directory. +8. Expected runtime only when measured on stated hardware. +9. Expected output files. +10. Which outputs are included in the repository. +11. What comparison or validation supports the example. +12. Known limitations. + +Clearly distinguish runnable inputs from retained outputs, manifests, +contracts, schemas, and templates. + +## 5. Internal vocabulary and public replacements + +Do not expose release engineering, issue tracking, or private research +shorthand in ordinary public prose. + +| Avoid in narrative prose | Prefer | +| --- | --- | +| gate, configured gate | verification criterion, validation condition | +| lane | solver path, execution path, workstream | +| tracker | issue, task list, status page | +| receipt | run record, metadata record | +| smoke test | installation check, short verification calculation | +| paper-grade | publication-quality | +| production route | supported solver path | +| production-ready | supported for the documented scope | +| promote, demote | change the documented capability status | +| claim boundary | stated scope or limitation | +| payload | released files, package contents | +| accepted target | converged load increment | +| accepted state | converged state | +| source-locked result | result tied to the stated source revision | +| fail closed | stop with an error when verification cannot be completed | +| safe subcycling | damage subcycling with the stated interval | +| job ID in visible prose | omit it or place it in a reproducibility record | + +Use the exact filename or identifier when the reader needs it to run a +command, inspect an output, or reproduce a result. + +## 6. Words to avoid + +Avoid these words in authored narrative because they are usually vague, +promotional, or associated with formulaic writing: + +```text +beacon +bespoke +cornerstone +crucial +delve +foster +game-changing +groundbreaking +harness +holistic +interplay +leverage +leveraging +massive +meticulous +notably +novel +paradigm +paramount +pivotal +revolutionise +seamless +showcase +streamlined +tapestry +testament +underscores +utilise +vital +``` + +Replace the word with the exact technical statement. For example, replace +`a groundbreaking acceleration strategy` with `the method reduced wall time +from X to Y for the stated benchmark and hardware`. + +The list is a writing prompt, not a blind text-replacement rule. Verbatim +quotations, titles, citations, filenames, code, and external project names +are exempt. + +## 7. Context-sensitive technical words + +The following words are valid when they have a precise software or numerical +meaning. Do not ban them globally. + +| Word | Appropriate use | +| --- | --- | +| diagnostic | the documented purpose of `phast doctor`, `precheck`, or a numerical check | +| trajectory | a defined stored time or load sequence | +| provenance | source revision, configuration, and data origin needed for reproducibility | +| artefact or artifact | a generated package, CI artefact, or literal API/file-format term | +| workflow | a GitHub Actions workflow or a clearly defined sequence of operations | +| terminal | instructions that require a command-line terminal | +| proxy | a defined mathematical or computational surrogate measure | +| evidence | an academic argument supported by stated results, not a synonym for files | +| protocol | a formally defined numerical or experimental procedure | + +Prefer a more specific term whenever one exists. + +## 8. Canonical PhAST terminology + +| Concept | Public wording | +| --- | --- | +| Package name | PhAST | +| Framework | modular tensor-based finite-element framework | +| Primary application | phase-field fracture | +| Coupling | staggered solution scheme | +| Damage equation | damage subproblem or phase-field subproblem | +| Mechanics equation | mechanics subproblem | +| Amor model | Amor tension-compression split at first use, then Amor split | +| Miehe model | Miehe spectral split | +| AT2 bound treatment | post-solve projection to `$[d_n,1]$`, then post-clamping | +| AT1 bound treatment | projected conjugate gradients, then projected CG | +| Explicit route | explicit dynamics with the integrator named | +| Quasi-static route | implicit equilibrium solve within the staggered scheme | +| Learned proposal | learned damage proposal followed by the documented checks | +| Learned replacement | audited learned damage replacement with classical fallback | +| Subcycling | damage subcycling with interval `$N$` | +| Fracture toughness | `$G_c$`, with units defined | +| Regularisation length | `$\ell_0$`, with units defined | + +Use `subproblem` rather than `sub-problem`. + +## 9. Capability and validation statements + +Use the public maturity labels consistently: + +- **Supported** means the public pathway is documented and covered by the + stated tests and examples. +- **Beta** means an implemented pathway is available but requires + case-specific verification. +- **Experimental** means the interface may change and claims must remain + narrow. +- **Scaffold** means partial infrastructure exists without a complete public + workflow. +- **Unsupported** means the public solver does not provide the capability. + +Do not convert a passing test into a physical-validation claim. Keep these +statements separate: + +1. The code executed. +2. The nonlinear or linear solver converged to the stated criterion. +3. The result agrees with a numerical reference. +4. The result agrees with experimental measurements. +5. The method is supported beyond the tested configuration. + +Only state the levels demonstrated by the cited result. + +When comparing performance, report: + +- the complete operation being timed; +- hardware and software environment; +- precision and backend; +- mesh and problem size; +- number of repetitions and summary statistic; +- setup, solve, transfer, inference, and output costs when relevant. + +Do not describe one backend as universally fastest. + +## 10. Differentiability and learned models + +Avoid unqualified statements that PhAST differentiates every fracture +calculation. Prefer: + +> Supported tensor operations can participate in PyTorch autograd. History +> updates, bounds, active-set changes, remeshing decisions, and other +> non-smooth operations require case-specific interpretation. + +For learned damage updates, state who remains responsible for the physical +solution: + +- A learned proposal supplies an initial damage estimate. +- PhAST checks bounds, irreversibility, phase-field boundary conditions, and + the projected residual where the selected route provides those checks. +- The classical damage solver remains available as the fallback. +- No trained model is implied unless a checkpoint is distributed and linked. + +Do not call a learned model faster without measuring its complete inference, +checking, rejection, and fallback cost against the matched classical solve. + +## 11. Commands and configurations + +- Copy commands from the current CLI help. +- State the working directory when it is not the repository root. +- Use copy-ready fenced code blocks. +- Do not include shell prompts such as `$` inside copy-ready commands. +- Explain placeholders such as `CONFIG` and `OUTPUT_DIR`. +- Use public repository paths rather than private machine paths. +- Show the recommended command before optional variants. +- State whether a command validates, generates files, or executes a solve. + +For example: + +```bash +python -m phast explain-config CONFIG +python -m phast run CONFIG --validate-only +python -m phast run CONFIG --output_dir RUN +``` + +Every runnable YAML file should declare its schema version and use only +supported public keys. A file that is not directly runnable must identify +itself as a manifest, contract, schema, or template in both its filename or +heading and its surrounding documentation. + +Here `CONFIG` is an input path and `RUN` is a new result directory. +Check this sequence for the selected schema/adapter; legacy +`precheck --config` is not a universal schema-2 command. Separate physical +analysis from integration, and a step limit from final physical time. + +## 12. Inputs, outputs, and reproducibility + +Document the complete path from input to result: + +- geometry source and mesh-generation method; +- named boundaries and physical groups; +- material parameters and units; +- phase-field model and energy split; +- loads and boundary conditions; +- solver type, backend, tolerances, and step count; +- output directory and generated files; +- configuration and source revision recorded with the result. + +Do not imply that a retained image proves that its generating calculation can +be reproduced. Distinguish: + +- runnable input; +- retained numerical output; +- visualisation generated from retained output; +- manifest describing expected files; +- reference or comparison data; +- template requiring user values. + +## 13. Equations, numbers, and tables + +- Introduce each equation in prose. +- Define every symbol immediately after the equation or in a nearby table. +- State units and sign conventions. +- Connect equations to the corresponding configuration keys. +- Put more than three related numerical values in a table where practical. +- Use meaningful precision. Do not copy more digits than the result supports. +- Explain a value when it changes the scientific conclusion. +- Do not describe convergence solely through a plot. State the criterion. + +## 14. Figures and accessibility + +- Use descriptive alternative text. +- Explain what the reader should notice. +- Label axes with quantities and units. +- Use a neutral, high-contrast palette. +- Do not rely on colour alone to distinguish curves or regions. +- Use consistent symbols and colours across related pages. +- Keep captions self-contained and concise. +- Do not write `computed`, `simulated`, or `calculated` before a noun when the + context already makes this clear. +- Check figures at desktop and mobile widths. + +Animations must have a static fallback image and a short explanation of the +displayed time or load interval. + +## 15. Citations and links + +- Cite the original paper for a mathematical model or benchmark. +- Prefer primary sources and official software documentation. +- Link to the relevant PhAST page rather than duplicating long explanations. +- Check that repository URLs use `CEMS-Lab/PhAST` and documentation URLs use + `https://cems-lab.github.io/PhAST/`. +- Do not cite a paper as proof of a PhAST implementation unless the public + code and documentation implement the stated method. +- Keep the citation instructions and software citation metadata consistent. + +## 16. Limitations and user support + +State unsupported combinations directly. For example: + +> Three-dimensional fracture is not supported by the current public solver +> pathway. + +Do not hide limitations in vague positive language. Do not repeat the same +qualification after every sentence. + +End installation guides and substantial tutorials with a support statement: + +> If a documented step fails, open a GitHub issue and include the +> configuration, command, operating system, Python version, PhAST version or +> commit, and complete error output. + +Invite contributions without implying that an unsupported feature is already +planned or promised. + +## 17. Final checklist + +### Accuracy + +- [ ] Every described capability exists in the current public code. +- [ ] Maturity labels agree with the capability matrix. +- [ ] Commands and paths are current. +- [ ] Configuration keys agree with the schema. +- [ ] Units and defaults are stated correctly. +- [ ] Numerical and physical validation are not conflated. +- [ ] Optional dependencies are identified. + +### Usability + +- [ ] The intended reader and task are clear. +- [ ] Prerequisites and working directory are stated. +- [ ] Inputs, commands, and outputs form a complete sequence. +- [ ] A new user can identify the next step. +- [ ] Runnable files are separated from manifests and templates. +- [ ] Failure recovery or support information is present where needed. + +### Language + +- [ ] The prose uses UK English. +- [ ] Sentences contain one main idea. +- [ ] Internal project vocabulary has been removed. +- [ ] Promotional and formulaic words have been removed. +- [ ] Technical terms are defined and used consistently. +- [ ] Limitations remain visible. +- [ ] No em dashes are present. +- [ ] Physical mechanisms and concrete actions replace abstract promises. +- [ ] Each paragraph adds information rather than restating the aim. + +### Presentation + +- [ ] Headings describe the content below them. +- [ ] Equations and tables render correctly. +- [ ] Figures have useful captions and alternative text. +- [ ] Links resolve to public locations. +- [ ] Code blocks are copy-ready. +- [ ] The page remains readable on desktop and mobile. + +## 18. Exceptions + +Code, command output, filenames, configuration keys, API identifiers, quoted +errors, paper titles, and verbatim quotations retain their original spelling +and punctuation. Do not alter a technically meaningful identifier merely to +match prose style. + +When this guide conflicts with a file format, external standard, citation, +or required software identifier, preserve the technically correct form and +explain the exception if readers may be confused. + +## 19. Scientific writing design directives + +The preferred voice is analytical, explanatory, and restrained. Build the +argument through physical causes, named operations, observable consequences, +and appropriately limited conclusions. Precision should make the prose easier +to follow, not merely increase its technical density. + +### 19.1 Lead with the physical question + +For a research narrative, introduce the material behaviour or unresolved +question before listing computational methods. Explain why the question +matters and what existing descriptions cannot yet resolve. Then introduce +the method as a means of answering it. + +Avoid opening with a stack of descriptors such as differentiable, multiscale, +multiphysics, data-efficient, and generalisable. Retain each term where its +specific role is explained. In command references and installation pages, +continue to lead with the user's task rather than a research motivation. + +### 19.2 Make causal relationships explicit + +Prefer a short physical sequence to a list of interacting phenomena. Name +what changes, what it acts on, and what consequence is expected. Distinguish +a proposed mechanism from an observed one. + +For example, a hypothetical account might read: + +> Cracks open transport paths. Reaction at the exposed interface changes +> sliding resistance, which can alter load transfer during subsequent loading. + +Do not use a model sensitivity alone to establish a physical mechanism. +Explain which comparison, field observation, or measurement supports that +interpretation. Homogenisation transfers effective responses between scales; +differentiation evaluates how those responses depend on specified inputs. + +### 19.3 Give each paragraph a distinct job + +Use a topic sentence followed by the explanation or evidence needed to +support it. End with an implication or limitation only when it adds meaning. +Vary sentence length to preserve a readable argument; do not turn the +sentence-length guidance into disconnected short statements. + +In proposals, distinguish the jobs of adjacent sections: + +- The research gap identifies what existing work cannot yet explain. +- The question identifies what the study will investigate. +- The hypothesis states a proposition that a comparison could contradict. +- The aim states the intended contribution. +- The objectives identify the work needed to test the proposition. +- The approach explains how that work will be carried out and assessed. + +Do not make each section another version of "we will establish a framework". +Repeat a technical term when needed for accuracy, but remove repeated claims. +Do not substitute loose synonyms merely to make the prose appear varied. + +### 19.4 Replace abstract promises with actions and observations + +Use verbs such as compute, compare, calibrate, withhold, measure, and test +when they describe the actual work. Specify their objects. Words such as +establish, enable, preserve, and generalise are not prohibited, but require +an explanation of what would demonstrate the claim. + +Make the comparison legible: what is varied, what is held fixed, what is +measured, and what result would challenge the interpretation? Include a +numerical target only when it is justified. Never invent a threshold to make +a sentence sound more precise. + +Keep physical and methodological hypotheses distinct. A hypothesis about +damage mechanisms differs from a hypothesis that derivative supervision +improves prediction at a given computational cost. A negative result for +one need not invalidate the other. + +### 19.5 Match the verb to the evidence + +Use present tense for verified capabilities and established descriptions, +past tense for completed work, and future tense for proposed actions. Use +conditional language for outcomes that remain hypotheses. A confident plan +can say "we will compare" without promising "the comparison will prove". + +Keep these distinctions visible in the prose: + +- Calibration fits parameters; independent measurements test the resulting + predictions under specified conditions. +- Agreement with a reference solver assesses numerical or approximation + error; it does not independently validate the physical model. +- An unseen combination within sampled ranges differs from extrapolation + beyond those ranges or transfer to another material. +- A preliminary calculation demonstrates only the operations and responses + actually assessed, even if its visualisation resembles a final result. + +Place a material limitation next to the claim it qualifies. State it once +clearly, and repeat it only where a figure or section must stand alone. +Preserve unresolved convergence, energy balance, validation, and scope +limitations during editing. Do not replace them with vague assurances. + +### 19.6 Use technical terms according to their role + +| Term | Writing directive | +| --- | --- | +| Differentiable | Describe the formulation or verified mathematical property, with its domain of validity. | +| Automatic differentiation | Name the computational technique when that is the technique used. | +| Sensitivity | Identify the response and physical input being differentiated. | +| Constitutive tangent | Identify the constitutive update and which prior states are held fixed. | +| Gradient | Name the differentiated quantity; distinguish optimisation gradients from physical-response sensitivities. | +| History dependence | State which earlier changes affect the later response and how this is assessed. | +| Generalisation | Identify the withheld conditions, sampled ranges, and any extrapolation. | + +Use the simplest accurate term for the passage. Do not add implementation +details unless they explain the method, its assessment, or a limitation. + +### 19.7 Describe feasibility and impact through concrete commitments + +For proposed work, connect each difficult step to its required input, +assessment, and useful outcome. If success is uncertain, explain what narrower +result remains achievable. "Revise the model" is a possible activity, not a +complete description of a fallback outcome. + +Distinguish a measured runtime for one example from the estimated workload +of a research programme. Identify assumptions when extrapolating costs. +Do not turn a writing edit into a new scientific or resource commitment. + +For impact, name the intended user, the decision the output could inform, +and the further testing or adoption needed. Keep long-term sector benefits +separate from project deliverables. Use policy and investment figures +selectively; they establish context but do not substitute for a use case. + +### 19.8 Make tables and figures carry specific information + +Use a table for repeated mappings, such as measurement source, calibration +use, independent assessment, and conditions. Do not repeat every table entry +in the surrounding paragraph. Explain the relationship or gap that matters. + +A scientific figure caption should identify the problem, quantities, +conditions, and interpretation needed to read the result. Distinguish +schematics, hypotheses, preliminary calculations, and validated comparisons. +Define visual alterations such as smoothing, exaggerated geometry, or lines +joining discrete states when they affect interpretation. + +Keep essential limitations with the figure. Move routine configuration +detail to a linked method description when appropriate; do not achieve a +shorter caption by hiding unresolved scientific issues. + +### 19.9 Remove formulaic writing without flattening the science + +Review repeated abstract nouns, identical paragraph openings, method lists, +unsupported superlatives, and stock transitions. Repair the missing meaning +before substituting words. Formal language, repetition, or polished syntax +alone cannot establish whether a person or an AI wrote a passage. + +Do not mechanically remove every passive construction or specialist term. +Use active voice to clarify who performs an action. Use passive voice when +the measured quantity or operation is the relevant subject. Preserve logical +connections and qualifications even when a shorter sentence is possible. + +## 20. Writing examples and revision checks + +The pairs below illustrate editing decisions. They are not quotations from +a manuscript, statements of current PhAST support, or approved research +commitments. Use a replacement only when its scientific content is accurate. + +| Less informative wording | More specific wording | +| --- | --- | +| We will establish a generalisable framework for coupled evolution. | We will test whether a model trained on one set of exposure histories predicts the response under withheld histories. | +| The method captures complex interactions across scales. | The tow model supplies stress and transport response to the woven equations, which determine the next local loading and exposure conditions. | +| Extensive validation will demonstrate accuracy. | Separate measurements will test the calibrated model; reference simulations will assess the additional error introduced by learning. | +| Sensitivities reveal the governing mechanism. | Sensitivities identify influential inputs within the model; paired histories and damage fields test the proposed mechanism. | +| Preliminary results demonstrate reliable failure prediction. | The preliminary calculation produces a damage field; its post-peak energy balance has not yet been established. | +| The model will generalise to new materials. | Predictions for a second material will use independently specified properties without refitting the learned weights. | +| The work will transform sustainable aerospace design. | The results could help researchers select interphase properties for subsequent material testing. | + +Before completing a scientific prose revision: + +1. Read only the opening sentences. They should form a coherent argument + without repeating the same promise. +2. Underline the main claim in each paragraph and identify its supporting + mechanism, comparison, or source. +3. Check that every proposed method has a stated purpose and that existing + results are not written as evidence for an untested extension. +4. Check that a reader can distinguish physical validation, numerical + verification, learning accuracy, and computational performance. +5. Remove duplicated explanations before deleting substantive caveats. +6. Compare the revision with the original for changes in certainty, scope, + attribution, and proposed commitments. Flag scientific changes explicitly. +7. Read the result aloud for long noun sequences, abrupt transitions, and + repeated sentence patterns. Prefer connected explanation over slogans. + +## Trajectory And Dataset Storage + +Use HDF5 (`training_data.h5`, configuration value `h5`) as the default +trajectory format in documentation, READMEs, examples, and teaching notebooks. +State that trajectory saving must be enabled where applicable; do not imply +every run writes a trajectory. + +Show Zarr only as an explicit alternative for a workflow that requires it. +Do not describe HDF5 as legacy-only or Zarr as the preferred default. Keep +commands, expected filenames, readers, and manifests consistent with the +selected format. Preserve the recorded format of historical results, and do +not relabel saved notebook output as evidence of an HDF5 run without rerunning +it. Clear stale outputs when changing a notebook's storage backend. + +A single HDF5 file reduces the number of files to synchronise. It does not +make simultaneous writes from different machines safe. diff --git a/README.md b/README.md index 791adff7d..ff950dd86 100644 --- a/README.md +++ b/README.md @@ -6,9 +6,7 @@

Phase-field Autograd Solver in Torch
- A matrix-free, differentiable PyTorch solver for phase-field fracture and FEM benchmarks. -

- PhAST is a matrix-free, differentiable PyTorch solver for phase-field fracture. + A matrix-free, differentiable PyTorch finite-element solver for two-dimensional phase-field fracture.

@@ -55,9 +53,10 @@ controls, and requested outputs in one reviewable file. with PyTorch autograd where documented, enabling carefully interpreted sensitivity studies. - **Phase-Field Fracture Focus:** Dynamic impact, crack branching, and quasi-static fracture workflows share a consistent mechanics/damage formulation and output schema. -- **Public Benchmark Bundles:** Public examples provide `config.yaml`, setup figures, final field plots, response histories, manifests, and compact animations. Numerical fields are reloadable only when the result bundle retains a trajectory store. +- **Documented Examples:** Examples provide `config.yaml`, setup figures, final field plots, response histories, manifests, and compact animations. Numerical fields can be reloaded when the result directory contains a trajectory store. - **YAML Plus Fluent API:** Use declarative YAML for reproducible runs and `phast.Problem` for programmatic model authoring. -- **Standardized Post-Processing:** `phast.load_result` handles stored manifests, CSV histories, visuals, and retained trajectory fields. +- **Standardised Post-Processing:** `phast.load_result` reads stored manifests, CSV histories, visualisations, and available trajectory fields. +- **Single-File Trajectories:** When enabled, trajectory output defaults to HDF5 (`training_data.h5`). Zarr remains available by explicit selection. ## How The Solver Works @@ -65,8 +64,8 @@ controls, and requested outputs in one reviewable file. For a phase-field fracture run, PhAST constructs or imports a two-dimensional finite-element mesh, evaluates the mechanical state, updates the tensile -history field, solves the regularized damage problem, enforces damage bounds -and irreversibility, and writes fields, histories, manifests, and provenance. +history field, solves the regularised damage problem, enforces damage bounds +and irreversibility, and writes fields, histories, manifests, and run metadata. Explicit dynamics and quasi-static fracture use different mechanics updates; the [solver overview](docs/user_guide/overview.md) and [formulation guide](docs/user_guide/physics.md) describe both pathways. @@ -77,19 +76,25 @@ If you are new to PhAST, follow this sequence: 1. Read the [phase-field primer](docs/tutorial/01_phase_field_primer.md) if the formulation is new to you. -2. Follow the [installation and first-run guide](docs/getting-started.md). -3. Validate a fracture YAML before allocating a full simulation. -4. Run the small linear-elastic example to verify end-to-end execution and - result loading. +2. Follow the [standard simulation tutorial](docs/tutorial/07_standard_simulation_workflow.md) + for source installation and the common editable YAML layout. +3. Explain and check a fracture input before allocating a full simulation. +4. Run the small linear-elastic example to check solver execution and result + loading on the current machine. 5. Consult the [capability matrix](docs/user_guide/capability_matrix.md) before selecting a model for research use. ## Quickstart +Install Python 3.10 or newer and Git first. These commands install the source +checkout you clone; they do not assert that it is the latest release. + +On macOS or Linux: + ```bash git clone https://github.com/CEMS-Lab/PhAST.git cd PhAST -python3.11 -m venv .venv +python3 -m venv .venv source .venv/bin/activate python -m pip install --upgrade pip python -m pip install -e . @@ -97,10 +102,36 @@ python -m pip install -e . python -m phast doctor ``` -PhAST requires Python 3.10 or newer; Python 3.11 is recommended for a first -source installation. Continuous integration currently verifies Python -3.10-3.12, so later Python versions are permitted but not yet part of the -regular test matrix. +On Windows PowerShell: + +```powershell +git clone https://github.com/CEMS-Lab/PhAST.git +cd PhAST +py -3 -m venv .venv +.\.venv\Scripts\python.exe -m pip install --upgrade pip +.\.venv\Scripts\python.exe -m pip install -e . +.\.venv\Scripts\Activate.ps1 +python -m phast doctor +``` + +Ensure `python3` or `py -3` selects Python 3.10 or newer. If activation +is blocked on Windows, use `.\.venv\Scripts\python.exe` instead of +`python` in subsequent commands; do not change system policy. + +Editable installation already installs runtime dependencies. To install +them separately in the same environment, use: + +```bash +python -m pip install -r requirements.txt +python -m pip install -e . +``` + +The main student route is the small single-material quasi-static SENT, +small single-material dynamic SENT, and full layered DCB example in the +[standard tutorial](docs/tutorial/07_standard_simulation_workflow.md). +The new adapters and schema-2 explanation command require combined checks +before those sequences are labelled verified. Existing compatibility +examples below provide a separate established first-check route. Validate a public fracture configuration without launching a full solve: @@ -146,6 +177,14 @@ first workflow. ## Reproducible Workflows +The [standard simulation workflow](docs/tutorial/07_standard_simulation_workflow.md) +uses one schema-2 layout for editable geometry, mesh, materials, and loading. +It includes retained DCB PNG/GIF evidence and complete coarse comparison +inputs using the same CLI, not new solver drivers. The DCB result is +qualitative layered-material interaction, not calibrated inclusion bypass. +Its multi-material route is limited to CPU float64, structured-T3, +quasi-static Amor AT2, and prescribed-displacement conditions. +
@@ -178,6 +217,7 @@ Browse the full [example gallery](docs/example-gallery.md) for the complete list | Objective | Interface | Documentation Link | |---|---|---| +| Learn one editable input layout | Schema-2 student workflow | [Standard Simulation Workflow](docs/tutorial/07_standard_simulation_workflow.md) | | Author a forward model | Fluent `phast.Problem` API | [Python API](docs/user_guide/python_api.md) | | Execute public benchmarks | Declarative `config.yaml` | [YAML Workflow](docs/user_guide/yaml_workflow.md) | | Post-process simulation data | `phast.load_result(path)` | [Public API Reference](docs/user_guide/public_api_reference.md) | @@ -238,6 +278,10 @@ with [CONTRIBUTING.md](CONTRIBUTING.md), then use the [capability matrix](docs/u and [example contract](docs/user_guide/example_contract.md) to keep public claims, examples, and artifacts consistent. +New YAML examples and their READMEs/tutorials must follow +[CONFIGURATION_STYLE.md](CONFIGURATION_STYLE.md) alongside +[DOCUMENTATION_STYLE.md](DOCUMENTATION_STYLE.md). + Students, researchers, scientific-software developers, and users evaluating PhAST are invited to review the code and documentation, propose reproducible examples, and report unclear instructions. If you become stuck at any point, @@ -292,4 +336,4 @@ Official code for the manuscript is hosted in this repository: The theoretical formulations, phase-field continuum equations, constitutive assumptions, and numerical discretization choices in PhAST are derived from the established computational solid mechanics literature and were selected, interpreted, and validated by the human authors, as described in the associated article and documentation. AI coding assistants, including Codex, Claude, Gemini, and GitHub Copilot, were used as auxiliary software-engineering tools for repository organization, documentation editing, boilerplate generation, and code-review support; they did not define the physics, benchmark claims, validation criteria, or scientific conclusions. The authors reviewed and verified the computational mechanics kernels, benchmark configurations, and validation artifacts, and take full responsibility for the correctness, limitations, and scientific content of the codebase. -PhAST is organized with reproducible scientific computing in mind. Machine-readable manifests, structured result metadata, headless CLI/API entry points, and repository-level guidance files are provided so researchers can inspect, reproduce, and extend simulations without relying on hidden local state. These files are engineering aids; the scientific claims and solver validity remain governed by the documented formulations, tests, and validation artifacts above. +PhAST is organised to support reproducible scientific computing. Machine-readable manifests, structured result metadata, command-line and Python interfaces, and repository guidance allow researchers to inspect, reproduce, and extend simulations without relying on undocumented local settings. Scientific claims remain limited to the formulations, tests, and validation cases described in the documentation. diff --git a/configs/REFERENCE.yaml b/configs/REFERENCE.yaml index 84c09c573..6594a436c 100644 --- a/configs/REFERENCE.yaml +++ b/configs/REFERENCE.yaml @@ -406,7 +406,7 @@ output: # output_dir: null # str or null # h5: false # bool # trajectory: false # bool - # trajectory_format: zarr # str + # trajectory_format: h5 # str # h5_every: 20 # int, range: [1, +inf] # vtu: false # bool # vtu_every: 10 # int, range: [1, +inf] diff --git a/configs/benchmarks/dynamic/B7_dynamic_crack_branching_comsol.yaml b/configs/benchmarks/dynamic/B7_dynamic_crack_branching_comsol.yaml index 814b685f6..3bf1f6da7 100644 --- a/configs/benchmarks/dynamic/B7_dynamic_crack_branching_comsol.yaml +++ b/configs/benchmarks/dynamic/B7_dynamic_crack_branching_comsol.yaml @@ -31,7 +31,7 @@ acceptance: required_outputs: - run_lockfile.json - config.yaml - - training_data.zarr + - training_data.h5 - energy.csv - crack_tip.csv - compare_report.txt diff --git a/configs/phast.schema.json b/configs/phast.schema.json index aa0a9252b..8b853691f 100644 --- a/configs/phast.schema.json +++ b/configs/phast.schema.json @@ -725,7 +725,7 @@ }, "trajectory_format": { "type": "string", - "default": "zarr" + "default": "h5" }, "h5_every": { "type": "integer", diff --git a/docs/api/public_workflow.md b/docs/api/public_workflow.md index fa52e70f4..43a5a154d 100644 --- a/docs/api/public_workflow.md +++ b/docs/api/public_workflow.md @@ -103,7 +103,7 @@ It does not select individual files or store reloadable tensor fields. Every curated public example should expose a flat, predictable result bundle: `config.yaml`, `run_manifest.json`, `visual_manifest.json`, representative -PNG/MP4 artifacts, CSV histories where relevant, and Zarr-first trajectory +PNG/MP4 artifacts, CSV histories where relevant, and HDF5 trajectory (the default) outputs when the run stores fields. See [Curated example contract](../user_guide/example_contract.md) for the artifact contract. diff --git a/docs/community.md b/docs/community.md index 99c5e78f4..3324a7aef 100644 --- a/docs/community.md +++ b/docs/community.md @@ -28,17 +28,20 @@ you do not need to identify the underlying code defect first. When opening bugs or documentation gaps, include: -- exact command and config file (if any), -- reproducibility details (PyTorch/CUDA/OS), -- minimal output snippet or traceback, -- the first failing file or assertion. +- the exact command and configuration file, if applicable; +- the PhAST version or Git commit; +- the operating system and Python, PyTorch, and CUDA versions; +- the complete first warning or traceback; and +- the first failing file or assertion, if known. Questions and partial reports are welcome. Maintainers can request additional -reproducibility information during triage. +information when investigating the issue. ## Contributing - Use `CONTRIBUTING.md` for workflow expectations and code review requirements. +- Follow `DOCUMENTATION_STYLE.md` for README, documentation, tutorial, and + notebook prose. - Keep new capability claims aligned with [capability matrix](user_guide/capability_matrix.md). - Add or update docs pages in one commit with any user-facing behavior change. diff --git a/docs/example-gallery.md b/docs/example-gallery.md index 3eb072a81..08c18416c 100644 --- a/docs/example-gallery.md +++ b/docs/example-gallery.md @@ -16,6 +16,12 @@ today. Each example-local README is authoritative for its exact command, runtime, outputs, limitations, and evidence boundary. +For the main student route, use the +[standard simulation workflow](tutorial/07_standard_simulation_workflow.md): +small quasi-static SENT, small dynamic SENT, and full layered DCB with one +schema-2 section order. New adapter checks remain a promotion gate; a short +setup exercise is not automatically a crack-growth benchmark. + ## Representative results The panels below are lightweight documentation thumbnails, not raw benchmark @@ -30,6 +36,8 @@ archives. They point to the same workflows listed in the sections that follow. | Linear plate | Supported | YAML-first | `python -m phast run examples/solid_mechanics_beta/linear_plate/config.yaml --output_dir runs/linear_plate` | response curve, displacement, von Mises, strain energy, manifests | `phast.load_result("runs/linear_plate")` | | Kalthoff-Winkler | Supported | YAML-first | `python -m phast run examples/dynamic/B2_kalthoff_winkler/config.yaml --output_dir runs/B2_kalthoff_winkler` | setup preview, damage image, energy/history CSVs, manifests | `phast.load_result("runs/B2_kalthoff_winkler")` | | Heterogeneous fields | Teaching example | Script contract | `python examples/heterogeneous_fields/run.py --config examples/heterogeneous_fields/parameters.yaml --output-dir runs/heterogeneous_fields` | elementwise `E`/`Gc` CSV, nodal damage CSV, field plots, manifests | `phast.load_result("runs/heterogeneous_fields")` | +| Layered DCB with tough disk | Beta; retained qualitative evidence | Schema-2 YAML | `python -m phast run examples/two_material_dcb_beta/config.yaml --output_dir runs/dcb_fine_reference` | HDF5, CSV, PNG/GIF, VTU, manifests | `phast.load_result("runs/dcb_fine_reference")` | +| Heterogeneous SENT | Beta configuration | Schema-2 YAML | `python -m phast run examples/heterogeneous_sent_beta/config.yaml --output_dir runs/heterogeneous_sent` | CSV, PNG/GIF, VTU, manifests; trajectory opt-in | `phast.load_result("runs/heterogeneous_sent")` | Use the [capability matrix](user_guide/capability_matrix.md) before assuming a workflow status. Use the @@ -127,6 +135,50 @@ The quasi-static family provides documented pathways for selected literature com validated microstructure-fracture study. See the example README before adapting image or segmentation data. +### DCB-style layered fracture (beta) + +- `python -m phast run examples/two_material_dcb_beta/config.yaml --output_dir runs/two_material_dcb` + runs the standard schema-v2 staggered quasi-static AT2 workflow in which a + mid-plane crack in a weak bulk layer approaches a circular Material 2 + inclusion between fracture-resistant outer regions. +- The example uses elementwise `E(x)` and `Gc(x)`, records the crack-front + coordinate and material-region damage measures, and writes a damage + animation with material boundaries and a single-file HDF5 trajectory. +- This is a beta teaching example, not ASTM D5528 calibration or + a validated bimaterial crack-deflection benchmark. The inclusion is tougher + than the weak layer, not the outer regions; its confinement is part of this + teaching model. + +```{figure} ../examples/two_material_dcb_beta/results/damage_final.png +:alt: Retained DCB final damage showing a forked crack in a weak layer near a circular tougher region. +:width: 100% + +Retained state at 0.30 mm total opening. No seed-connected nodes with +`d >= 0.80` enter the disk. Neither penetration nor completed bypass is +demonstrated; this is qualitative layered-material interaction. +``` + +The fine `160 x 48` reference has 120 accepted increments, no cutbacks, +maximum projected damage residual `6.91e-6`, and reaction `0.61495` +in the recorded unit-thickness convention. The separate `120 x 48` matched +pair changes only disk `Gc`: reactions are `0.60938` (tough region) and +`0.45847` (uniform-layer control), with shorter final advance for the tough +region. Both fork early; the disk cannot be credited with causing branching. +The control retains the weak layer and outer regions. + +Complete inputs are `examples/two_material_dcb_beta/comparisons/tough_region.yaml` +and `examples/two_material_dcb_beta/comparisons/uniform_layer.yaml`. +The [standard tutorial](tutorial/07_standard_simulation_workflow.md) gives +exact commands with separate output directories, a retained animation, and +numerical records. These inputs reuse the common runner. Independent fixed-field +review is not a solver rerun; input guards and combined execution checks +remain separate. Historical generating source identity is unknown, and the +coarse historical runs did not write HDF5. + +The documented multi-material route is structured T3 rectangles, CPU float64, +quasi-static Amor AT2, elementwise `E`/`Gc`, common `nu`/`l0`, and +Dirichlet conditions, not dynamic multi-material or independent-interface physics. + ### Beta plasticity, cohesive, and PF-CZM validation - **J2 plasticity and ductile PF-plasticity**: diff --git a/docs/getting-started.md b/docs/getting-started.md index 86bd2ac13..c8caa0394 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -1,7 +1,7 @@ # Getting Started -This is the canonical installation and first-run route. The README and tutorial -index summarize this page rather than defining separate installation contracts. +This page defines the recommended installation and first-run sequence. The +README and tutorial index provide shorter summaries of the same procedure. ## Installation Route Selector @@ -19,9 +19,9 @@ conda activate phast python run_sanitizer.py ``` -The supplied environment is a portable Python 3.11 CPU baseline. PETSc/MUMPS, +The supplied environment is a portable Python 3.11 CPU configuration. PETSc/MUMPS, CUDA, AmgX, and site-specific MPI stacks remain optional installations and are -not implied by this environment. +not included in this environment. ### CPU Docker image @@ -120,9 +120,9 @@ OK: examples/dynamic/B2_kalthoff_winkler/config.yaml passes schema validation. ``` This message means that the YAML satisfies the schema and the implemented -semantic preflight checks. It does not run a fracture solve and does not prove +consistency checks. It does not run a fracture solve and does not prove mesh convergence, benchmark reproduction, or physical validity. Review the -example README, `explain-config` warnings, retained comparison evidence, and +example README, `explain-config` warnings, published comparison results, and mesh-to-length-scale ratio before making a scientific claim. For a readable summary of the model before execution: @@ -147,8 +147,8 @@ PhAST contains several kinds of YAML file: | `examples///config.yaml` | `python -m phast run ` | Recommended starting point; a complete example-local solver input. | | `configs/benchmarks//.yaml` | `python -m phast run ` | Complete benchmark solver input. | | `configs/REFERENCE.yaml` | Not intended for execution | Field-by-field reference and template. | -| `examples/PUBLIC_EXAMPLES_CONTRACT.yaml` | Not a solver input | Documentation and artifact inventory for public examples. | -| `configs/benchmarks/plasticity_interface/reproducibility_contracts.yaml` | Requires `--validation-id` | Dispatcher manifest for beta validation scripts, not a single fracture deck. | +| `examples/PUBLIC_EXAMPLES_CONTRACT.yaml` | Not a solver input | Documentation and file inventory for published examples. | +| `configs/benchmarks/plasticity_interface/reproducibility_contracts.yaml` | Requires `--validation-id` | Index for beta validation scripts, not a single fracture input. | | `configs/phast.schema.json` | Not YAML and not executable | JSON Schema for editors and external validation. | If a file is not named `config.yaml` and is described as a contract, manifest, @@ -166,9 +166,9 @@ python -m phast run examples/solid_mechanics_beta/linear_plate/config.yaml \ ``` The example is a supporting solid-mechanics check rather than a phase-field -fracture validation case. It is used here because it provides a compact first -execution. It writes response data, metadata, manifests, and field plots; it -does not retain reloadable displacement or stress arrays in a trajectory store. +fracture validation case. It is used here because it provides a small first +simulation. It writes response data, metadata, manifests, and field plots; it +does not store reloadable displacement or stress arrays in a trajectory store. The expected finite-element tip displacement is approximately `-2.024e-6 m`, about `-14.98%` relative to the documented Euler-Bernoulli estimate. Reproducing that recorded value indicates that the compact example @@ -220,7 +220,7 @@ For a fracture simulation, PhAST: 5. updates the tensile history field used to enforce crack irreversibility; 6. solves the AT1, AT2, or documented beta damage formulation; 7. enforces damage bounds and configured boundary conditions; and -8. writes fields, histories, manifests, configuration provenance, and visuals. +8. writes fields, histories, manifests, resolved configuration data, and visualisations. Read [User Guide Overview](user_guide/overview.md) for the software pathway and [Physics, Units, and Formulation](user_guide/physics.md) for the governing @@ -268,8 +268,9 @@ the problem remains or the instructions are unclear. Include: - the exact command; - the YAML path; - operating system and Python/PyTorch versions; +- the PhAST version or Git commit; - relevant `python -m phast doctor` output; and -- the first warning or traceback. +- the complete first warning or traceback. Students and first-time users are explicitly welcome to ask installation and usage questions. An unclear step is a documentation defect worth reporting. diff --git a/docs/index.md b/docs/index.md index 75cecf860..a013a8a6e 100644 --- a/docs/index.md +++ b/docs/index.md @@ -26,6 +26,7 @@