Mesh quality preflight checker before solver runs

Engineers describe 'solving different errors due to mesh quality' as time-consuming not because mesh quality checking is impossible, but because it happens after the solver fails rather than before it starts. The workflow today is: spend hours meshing, submit the job, wait for a lengthy solve (complaints cite solve times as already high compared to alternatives), then get a failure with a vague error, then trace it back to a bad element somewhere in a million-element model.

The structural reason this isn't built into preprocessors like HyperMesh is that the preprocessor and solver are sold as a bundle — fixing this gap too well inside HyperMesh would implicitly acknowledge that the solver is fragile with poor meshes, which is not a message Altair wants embedded in its own UI. Ansys has the same conflict of interest: the mesher and solver are the same product family, so a hard 'your mesh will fail' warning feels like the product calling itself broken.

The specific complaints here aren't about mesh quality metrics being unavailable — they're about the feedback loop being too long. You don't find out about the problem until after a multi-hour compute run. What's missing is a job that runs in minutes before solver submission, checks the actual mesh against known failure modes for the target solver (because OptiStruct has different failure thresholds than Mechanical), and returns a ranked list of likely problem regions with element IDs before any compute time is spent.

This is a business because engineering teams running jobs on cloud HPC or internal cluster time pay per CPU-hour. A failed job on a large model is not just an engineer's wasted afternoon — it's direct compute cost with zero output. That cost recurs every time a new model geometry comes in. The buyer — an engineering team lead or HPC resource manager — can quantify this in dollars, which makes it a purchasable line item rather than a quality-of-life request.

What to build

Build a standalone CLI and web UI that reads HyperMesh .hm or Nastran .bdf files, runs solver-specific mesh quality checks calibrated for OptiStruct and Ansys Mechanical failure thresholds, and produces a pre-run report listing suspect elements by ID with the specific quality metric that exceeds the solver's known tolerance — before a single core-hour is consumed.

Where to start

Go in through HPC teams at engineering consultancies that charge clients per CPU-hour — they have direct financial pain from failed jobs and strong motivation to adopt anything that reduces wasted compute before they can win on broader mesh QA features.

The hard part

Calibrating mesh quality thresholds to actual solver failure probability — not just generic Jacobian or aspect ratio limits — requires building or licensing a dataset of known-failed meshes per solver version, and solver vendors don't publish their internal tolerance tables publicly, so you're reverse-engineering them from user-submitted failures.

How it makes money

Usage-based pricing per model checked, with a monthly cap option for teams running high job volumes; enterprise flat-rate annual contracts for firms running more than 500 jobs per month.