vibeflow-moose

name	vibeflow-moose
description	Use when preparing, running, debugging, validating, or developing VibeFlow/VibeCAE workflows for MOOSE-based applications, including HIT .i input files, MOOSE app executables, materials/kernels/boundary conditions, TestHarness, custom app/module development, and traceability to 0-caseDict/caseDict.

VibeFlow MOOSE

This skill is responsible for integrating the MOOSE ecosystem into VibeCAE. MOOSE is a multiphysics application framework, not a single solver; the actual runtime target is usually a specific MOOSE app.

• Usage mode: run the current case with an existing MOOSE app.
• Development mode: develop or modify a MOOSE app, module, Kernel, BC, Material, Action, or input template.

When to Use

• The current backend selects MOOSE or a MOOSE-based application.
• .i input files need to be generated and <app>-opt -i input.i needs to be run.
• HIT input syntax, MOOSE objects, materials, kernels, BCs, Executioner, or Outputs need to be debugged.
• run_tests or the MOOSE TestHarness needs to be used.

First Decide: Usage Mode or Development Mode

• If an app already exists and only .i generation and execution are needed: use usage mode.
• If C++ development of MOOSE objects or a custom app is needed: use development mode.
• If the MOOSE app executable is not specified: switch to vibeflow-toolchain first or ask the user to provide VIBEFLOW_MOOSE_APP.

What to Read First

• 0-caseDict/caseDict
• references/moose-playbook.md
• references/moose-practical-tips.md: software knowledge base, key concepts, failure interpretation, and adapter design points.
• Current MOOSE app documentation, examples, and tests
• Existing inputs and logs under C-run/moose/
• If development is needed, read the app source, src/, include/, and test/tests

Inputs

• Physics, materials, initial/boundary values, mesh, and solve controls from caseDict
• MOOSE .i templates or the target app object catalog
• Exodus meshes or mesh formats supported by the app

Outputs

• C-run/moose/case-1/input.i
• C-run/moose/case-1/mesh.e
• C-run/moose/case-1/results/
• C-run/moose/case-1/logs/
• If developing: UDF/moose/<app>/ or patch notes for the target app

Usage Mode Workflow

1. Specify the app executable, for example VIBEFLOW_MOOSE_APP=/path/to/app-opt.
2. Confirm available objects from the app's --help, --dump, or documentation.
3. Map mesh, Variables, Kernels, BCs, Materials, Executioner, and Outputs from caseDict.
4. Generate input.i and avoid hiding defaults.
5. Run <app> --check-input -i input.i if the app supports it, or perform a lightweight startup.
6. Execute the production run, saving logs and Exodus/CSV outputs.
7. Write backend, app, input, output, and status information back to caseDict.

Development Mode Workflow

1. Define the development target: Kernel, BC, Material, AuxKernel, Action, UserObject, Postprocessor, or complete app.
2. Write UDF/README.md or app development notes first, recording interfaces and validation.
3. Copy the minimal skeleton from a similar MOOSE object.
4. Update registration, CMake/Make files, tests, and gold files.
5. Use run_tests to validate the target tests.
6. If integrating into the current case, return to usage mode and update input.i.

Core Rules

• Do not assume that a generic moose command exists; a specific app must be specified.
• The .i input is the runtime source of truth, but the physical intent still comes from caseDict.
• For each MOOSE object, state clearly which caseDict field it comes from.
• Complex development must have tests and must not rely only on one real-case run.
• Multiphysics coupling, MultiApps, and Transfers must make the data exchange and time-advancement relationship explicit.

Validation

• The app executable exists and --help can run.
• --dump or an equivalent method can confirm object availability.
• The input file can be parsed.
• The run outputs Exodus/CSV/log files.
• run_tests passes or the failure reason is clear.

Fallback Rules

• App unspecified or environment unavailable: return to vibeflow-toolchain
• Input physics unclear: return to vibeflow-case-dict
• Mesh incompatible: return to vibeflow-mesh
• Post-processing/reporting needed: hand off to vibeflow-postprocess / vibeflow-report