Check that Kratos Multiphysics is available and report version, paths, thread count and the list of compiled applications.

Install Kratos Multiphysics via pip into this server's own Python environment -- a local compiled build (KRATOS_ROOT) is not required. Installs the 'KratosMultiphysics' core plus any named applications (e.g. ["StructuralMechanicsApplication", "ConvectionDiffusionApplication", "LinearSolversApplication"]); pass all=true instead for the 'KratosMultiphysics-all' omnibus package covering essentially every application. Official wheels are only published for Linux and Windows x86_64 -- there is no Kratos wheel for macOS, where a local KRATOS_ROOT build is still required. This can take several minutes and download hundreds of MB (KratosMultiphysics-all is the largest); prefer naming only the applications you need. Once it returns ok, Kratos is importable immediately -- no server restart needed.

List all Kratos applications found in the source tree, flagging which ones are compiled (importable) in the current build.

List element type names registered in Kratos (parsed from KRATOS_REGISTER_ELEMENT macros in the C++ sources). Optionally filter by application name (e.g. 'StructuralMechanicsApplication') or by a substring of the element name (e.g. 'SmallDisplacement').

List condition type names registered in Kratos (surface/line/point conditions used for loads and boundary terms), with optional filters as in kratos_list_elements.

List constitutive law names registered in Kratos (material models such as LinearElastic3DLaw or Newtonian2DLaw), with optional filters as in kratos_list_elements.

List Kratos variables (DISPLACEMENT, TEMPERATURE, ...) grouped by type (double, array_1d_3, bool, ...), introspected from the live build. type_filter selects one group; name_filter is a substring.

List the known solver_type values per analysis type (structural, thermal, fluid, potential_flow) together with the Python solver module implementing each, plus all *_solver.py modules found in the application source tree.

List Python process modules (boundary conditions, loads, output, utilities) discoverable in the Kratos source tree. These are the values usable as 'python_module' in ProjectParameters process lists. With with_defaults=true, each entry also carries the process' default_settings and param_types parsed from its source (best effort; modules whose defaults cannot be parsed are still listed without them). Use kratos_get_process_defaults for a single module's full schema.

Return a Kratos process' default settings -- parameter names, default values, coarse types (bool/number/string/array/json/null) and which parameters are model-part references -- parsed from its Python source' ValidateAndAssignDefaults block. This is the schema you need to author a process block in a ProjectParameters process list. python_module is a value from kratos_list_processes (e.g. 'assign_scalar_variable_process', 'vtk_output_process'). Returns {"error": ...} when the Kratos source is unavailable, the module is not found, or its defaults use a non-standard declaration.

Return the complete default solver_settings parameters for a solver, as reported by its GetDefaultParameters(). analysis_type is one of structural/thermal/fluid/potential_flow; solver_type one of the values from kratos_list_solvers (e.g. 'Static', 'transient', 'Monolithic').

List the available case templates (structural_static, thermal_transient, fluid_transient, ...) with their descriptions, required applications and placeholder defaults.

Generate a ProjectParameters.json from a template (see list_templates). overrides replaces placeholder defaults, e.g. {"end_time": 2.0, "fix_model_part": "Structure.left"}. When output_file is given the JSON is written there; the content is always returned.

List the curated material presets usable as 'preset' in create_materials. Each carries a constitutive_law name and default Variables for a physical material model (linear elastic, Von Mises plasticity, isotropic damage, Newtonian fluid). Cross-check law names with kratos_list_constitutive_laws for your compiled build.

List curated linear_solver_settings presets (serial: sparse_lu, skyline_lu, amgcl, cg, bicgstab; MPI/Trilinos: amgcl_mpi, amesos, aztec, ml). Each 'settings' block is a drop-in for solver_settings.linear_solver_settings in a ProjectParameters.

Write a Kratos Materials.json. Each entry needs 'model_part_name' (e.g. 'Structure.domain'). Provide either a 'preset' (a name from list_material_presets, which fills constitutive_law + default variables) or an explicit 'constitutive_law' (e.g. 'LinearElasticPlaneStrain2DLaw') plus 'variables' (e.g. {"YOUNG_MODULUS": 2.1e11}). With a preset, any 'variables' you pass override the preset's defaults; 'constitutive_law' is optional (thermal problems have none).

Scaffold a complete Kratos case directory from a template: ProjectParameters.json + Materials.json (+ optionally a small demo rectangle mesh wired to the template defaults, so the case runs out of the box). Returns the created file paths and next steps.

Scaffold a Kratos multi-stage (orchestrated) case that chains several analyses in sequence, e.g. a continuation run or a coupled workflow where a later physics reads fields the earlier one wrote on the same mesh. Each element of 'stages' is {"name": "", "template": "", "overrides": {...}} (overrides optional). Stages are composed via Kratos' SequentialOrchestrator (orchestrator + stages + execution_list) and run with run_simulation like any case.

Mesh sharing: the first stage imports its mesh (mdpa); a later stage whose solver model_part_name matches an earlier stage's REUSES that already-populated model part (input_type 'use_input_model_part'), which is how state flows between stages. A later stage with a distinct model_part_name imports its own mesh instead.

Insert a boundary condition / load process block into an existing ProjectParameters.json. kind is one of: fix_displacement, prescribed_displacement, fix_velocity, inlet_velocity, outlet_pressure, fix_temperature, point_load, line_load, surface_load, pressure_load, surface_heat_flux, volume_heat_source, self_weight. Loads with modulus+direction (point/line/surface_load, self_weight) apply along a direction vector; the others take 'value' (vector or scalar).

Add an output process to a ProjectParameters.json. format: 'vtk' (ParaView files, needs output_path), 'json' (time series of variables to a JSON file, needs output_file), or 'point' (probe variables at a coordinate, needs position and output_file). variables defaults to the ones already used elsewhere in the file or ["DISPLACEMENT"].

Validate a ProjectParameters.json: JSON syntax, required keys, referenced files (mesh, materials) exist, model part names match the mesh submodelparts, and (deep=true, needs Kratos) the solver_settings against the solver's GetDefaultParameters().

Inspect a Kratos .mdpa mesh file: node/element/condition counts by type, bounding box, property ids and the SubModelPart tree with entity counts.

Validate a .mdpa file: dangling node/element/condition references and empty submodelparts (pure-Python lint). With deep=true the file is additionally round-tripped through the real Kratos ModelPartIO.

Generate a structured mesh and write it as .mdpa. kind: 'line' (size=[L], divisions=[n], submodelparts start/end), 'rectangle' (size=[W,H], divisions=[nx,ny], edge parts left/right/bottom/top, quads or triangles), or 'box' (size=[Lx,Ly,Lz], divisions=[nx,ny,nz], hexahedra, face parts xmin/xmax/ymin/ymax/zmin/zmax). All variants include a 'domain' submodelpart with every node and element; boundary parts carry conditions of condition_name for applying surface loads. Defaults: rectangle SmallDisplacementElement2D4N + LineLoadCondition2D2N, box SmallDisplacementElement3D8N + SurfaceLoadCondition3D4N.

Return node ids and coordinates from a .mdpa file, optionally restricted to one submodelpart (dotted path like 'domain' or 'outer.inner') or an explicit id list. At most 'limit' nodes are returned (with a truncation flag).

Start a Kratos simulation as a background job and return its job_id. The analysis class is taken from the 'analysis_stage' key in the parameters, or inferred from solver_type; override with analysis_type (structural/fluid/thermal/potential_flow) or analysis_class ('module.path:ClassName'). If wait_seconds > 0, poll up to that long and return the final status if the job finishes in time. Track progress with job_status/job_logs.

Dry-run check of a case directory without running the time loop: JSON validity, required keys, mesh and materials files exist and parse, model part references match the mesh, and the solver settings validate against Kratos defaults.

Get the state of a simulation job (queued/running/succeeded/ failed/cancelled), elapsed time, and current step/time parsed from its log.

List all known simulation jobs, optionally filtered by state (queued, running, succeeded, failed, cancelled).

Return the last 'tail' lines of a job's simulation log, optionally only lines containing the 'grep' substring (case-insensitive).

Cancel a running simulation job (SIGTERM, escalating to SIGKILL after a grace period).

Discover result artifacts in a case directory (recursively): VTK/VTU files, GiD post files, HDF5, JSON results and point-output .dat/.csv files, sorted by name so timesteps appear in order.

Summarise a VTK/VTU result file: number of points/cells, the variables present, and per-variable statistics (min/max/mean, or magnitude stats for vector fields). Optionally restrict to one variable.

Read the value of a variable at one location of a VTK/VTU result: either the mesh point nearest to 'point' [x, y, z], or the point at 0-based index 'node_index'. Returns the value and the actual coordinates used.

Extract convergence information from a simulation log (by job_id or explicit log file path): per-step nonlinear iteration counts, residual ratios, and which steps converged.

Render a VTK/VTU result file to a PNG screenshot, returned inline (requires the optional pyvista 'viz' extra). Colors the mesh by 'variable' (point or cell data; vector fields default to magnitude, or pick component 'x'/'y'/'z'), optionally warps the geometry by a vector field such as DISPLACEMENT scaled by warp_factor. Camera presets: xy, xz, yz, iso. crop_bounds clips to a region of interest before framing the camera -- [xmin,xmax,ymin,ymax] or [xmin,xmax,ymin,ymax,zmin,zmax] -- essential for e.g. a small body in a huge far-field CFD domain, otherwise invisible at full-domain zoom. The PNG is saved next to the input file unless image_path is given.

Render a time series of VTK/VTU results into an animated GIF (requires the optional pyvista 'viz' extra). 'files' is a directory (e.g. the case's vtk_output/) or a glob; frames are ordered by the numbers in their names. Coloring/warping/crop_bounds options as in results_render, with one color range, crop and camera across all frames. Small GIFs are returned inline; the file path is always returned.

Parse an existing ProjectParameters.json and return a structured summary of what it configures: analysis type, solver + linear solver, mesh and material import, and the flattened boundary-condition / load / output process lists (with the model parts each targets). Multi-stage (orchestrator/stages) cases are summarized per stage. Use this to understand a case you did not scaffold before editing or running it.

Convert a ProjectParameters.json into a Flowgraph (litegraph) graph.json that can be opened in the Kratos FlowGraph visual node editor. Returns the graph; when output_file is given it is also written there. Round-trips with import_flowgraph_to_case.

Convert a Flowgraph (litegraph) graph.json -- as saved by the Kratos FlowGraph editor -- back into a ProjectParameters.json. Returns the parameters; when output_file is given it is also written there. Round-trips with export_case_to_flowgraph.