vibeflow-calculix

name	vibeflow-calculix
description	Use when preparing, running, debugging, post-processing, or extending VibeFlow/VibeCAE CalculiX finite-element structural workflows from 0-caseDict/caseDict, including Abaqus-style .inp files, ccx solver runs, cgx visualization handoff, materials, sections, contacts, loads, constraints, .frd/.dat/.sta outputs, and reusable CalculiX case templates.

VibeFlow CalculiX

This skill is responsible for using CalculiX as VibeCAE's open-source structural finite-element backend, mainly covering linear/nonlinear structures, thermo-structural analysis, contact, modal analysis, buckling, and quasi-static/transient analysis.

• Usage mode: generate .inp files from caseDict, run ccx, and read .dat, .frd, .sta, and log files.
• Development mode: develop CalculiX input templates, material/contact libraries, result converters, or user subroutines/external coupling tools when explicitly needed.

When to Use

• The task concerns structural strength, displacement, stress, modal behavior, buckling, thermal stress, contact, bolts/connections, or part-level FEM.
• The user already has an Abaqus-style .inp file or wants a lightweight open-source structural solver.
• A Gmsh/FreeCAD/Netgen mesh needs to be converted into CalculiX input.
• .frd files need to be inspected or converted into a ParaView-readable format.

First Decide: Usage Mode or Development Mode

• Current structural case generation, execution, and post-processing: use usage mode.
• Template libraries, .inp generators, result converters, user materials/subroutines, or Studio adapters: use development mode.
• If ccx, cgx, or mesh-conversion tools are unavailable, switch to vibeflow-toolchain first.
• For complex multiphysics coupling, compare whether Elmer, Code_Aster, or MOOSE is more appropriate.

What to Read First

• The geometry regions, materials, sections, constraints, loads, contacts, solution steps, and output objectives in 0-caseDict/caseDict.
• references/calculix-playbook.md
• references/calculix-practical-tips.md: software knowledge base, key concepts, failure interpretation, and adapter design points.
• Element types, node/element sets, and surface sets in B-mesh/.
• Existing .inp files or benchmarks under C-run/calculix/ and Ref/.

Inputs

• 0-caseDict/caseDict
• Abaqus/CalculiX .inp
• Meshes, materials, boundary conditions, loads, contact pairs, and output requests

Outputs

• C-run/calculix/case-*/job.inp
• C-run/calculix/case-*/Allrun / Allclean
• .dat, .frd, .sta, .cvg, and log files
• D-post/calculix_postprocess.py
• Charts or field files for displacement, stress, reaction force, modal data, contact status, and related quantities

Recommended Structure

C-run/calculix/
└── case-1/
    ├── job.inp
    ├── include/
    ├── logs/
    ├── results/
    ├── Allrun
    └── Allclean

Usage Mode Workflow

1. Map caseDict into CalculiX input blocks: *NODE, *ELEMENT, *MATERIAL, *SOLID SECTION, *BOUNDARY, *CLOAD, *DLOAD, *STEP, *STATIC, *FREQUENCY, *CONTACT PAIR, *NODE FILE, and *EL FILE.
2. Check that node sets, element sets, and surface sets correspond to the regions/boundaries in caseDict.
3. Generate job.inp, preferably splitting mesh, materials, boundaries, and steps into include/.
4. Run a smoke test with ccx -i job, checking input parsing, constraints, and element types.
5. After the production run, read .dat, .sta, and .frd, then extract displacement, stress, reaction force, energy, and convergence status.
6. Write results and error status back to caseDict.

Development Mode Workflow

1. Define the development target: .inp generator, material library, contact template, result converter, user subroutine, or coupling interface.
2. Write the development notes first, recording the CalculiX version, interfaces, input format, output format, and validation examples.
3. For user materials or subroutines, document the compilation method, variable meanings, units, and validation path.
4. For template generators, preserve set names and ID mappings.
5. Validate with at least a very small case such as a cantilever beam, tensile block, or heat-conduction block.

Core Rules

• .inp is the executable artifact; caseDict is the source of truth for engineering intent.
• Element types, integration schemes, material models, and boundary constraints strongly affect the results, so the selection rationale must be recorded.
• Do not hide rigid-body motion with over-constraint; check both reaction forces and displacements.
• For contact problems, validate stability on a simplified model first.

Validation

• ccx is available.
• job.inp parses successfully.
• .sta or the log shows that the solve completed or gives a clear failure reason.
• .dat / .frd outputs exist and are readable.
• Post-processed results can answer the user's objective.

Fallback Rules

• Unclear set/boundary IDs: return to the mesh stage.
• Unclear materials or loads: return to vibeflow-case-dict.
• CalculiX environment unavailable: return to vibeflow-toolchain.
• Nonlinear non-convergence: check constraints, contact, load steps, materials, and mesh.