[{"content":"The problem Feeding decisions depend on where and when the metal freezes last: where risers go, where a chill helps, whether a sleeve is needed. A full process simulation answers that, but it takes setup time and licences, so early in design many of these decisions are still made by rule of thumb.\nWhat I built FoundryFlash takes a STEP model to a solidification answer in the browser. It has two engines. The GNN surrogate screens a design in seconds; that is the version described in the trade articles below. The full solver described here is for the final check.\nSolidification time on a flanged casting in the FoundryFlash viewer.\nThe solver is written in Julia. It uses control-volume finite elements on linear tetrahedra and an enthalpy formulation, so the latent heat released during freezing needs no special handling. Time stepping is implicit, solved with a preconditioned conjugate-gradient method, and the mould is a region of its own with a heat-transfer coefficient at the interface. The same code runs on CPUs and on NVIDIA GPUs through CUDA.jl, and the two give results identical to round-off (10⁻¹⁵). Gmsh meshes the casting and the sand mould with its parallel HXT mesher.\nOn the web side, a FastAPI backend keeps a solver process warm, and a React and three.js viewer shows solidification time, fraction liquid, temperature and thermal modulus. The viewer masks hot spots, helps size feeders and writes a PDF report.\nResults What Measured Full solve, 1.6M elements 9.9 s on an RTX 3060, 44.9 s on 8 CPU threads 3D meshing, 1.6M-element test body 57 s before, 4 s after (14× faster) Job start-up about 27 s before, under 0.1 s after Verification against an independent FEniCSx reference solid-fraction MAE 0.0086 Comparison with a commercial simulation of a production casting +51% at first, 3.7% after a sensitivity study traced the gap to the mould's thermal properties Automated tests about 7,500 in Julia, Python and TypeScript Read more: Validating a GPU solidification solver: from \u0026#43;51% to within 3.7%\nStatus FoundryFlash is my own product and is still in development. The source code is private; I can share technical details on request.\nPublished in the trade press\nA Faster First Look at Casting Solidification, Foundry Management \u0026amp; Technology, Sep 2026 Certainty in the Early Design Stages of Foundry Engineering, Foundry-Planet, Sep 2026 ","permalink":"https://eugenmik.github.io/projects/foundryflash/","summary":"\u003ch2 id=\"the-problem\"\u003eThe problem\u003c/h2\u003e\n\u003cp\u003eFeeding decisions depend on where and when the metal freezes last: where risers go, where a chill helps, whether a sleeve is needed. A full process simulation answers that, but it takes setup time and licences, so early in design many of these decisions are still made by rule of thumb.\u003c/p\u003e\n\u003ch2 id=\"what-i-built\"\u003eWhat I built\u003c/h2\u003e\n\u003cp\u003eFoundryFlash takes a STEP model to a solidification answer in the browser. It has two engines. The \u003ca href=\"/projects/castsolid-gnn/\"\u003eGNN surrogate\u003c/a\u003e screens a design in seconds; that is the version described in the trade articles below. The full solver described here is for the final check.\u003c/p\u003e","title":"FoundryFlash: GPU casting simulator"},{"content":"The problem A full solidification simulation takes minutes to hours. Early in design, an engineer wants to compare many variants in seconds and see where the metal freezes last, and will give up some precision for that.\nThe model The model takes a tetrahedral mesh of a casting with its alloy and mould properties, and returns the time at which every node solidifies. The nodes that solidify last are the hot spots, where feeding problems and shrinkage usually start.\nIt is a hybrid of three trained parts. A 12-block MeshGraphNet-style network with FiLM conditioning predicts the shape of the field, two gradient-boosted heads predict its overall level and its spread, and a fixed recomposition step combines them. The network alone is weaker on absolute magnitude, which depends on alloy and part size: adding the heads brought nodal error on held-out geometry families from 5.77 s down to 4.26 s. Together it is about 1.85 M parameters.\nTraining data came from a pipeline I wrote: parametric geometry in CadQuery, meshing in Gmsh, and enthalpy-method simulations in FEniCSx. The corpus is 14,937 simulations in three sets, 9,710 primitives across 42 geometry families, 4,727 multi-alloy cases and 500 real production parts, and the model was built as a chain of fine-tunes across them. Training ran on one RTX 3060.\nA predicted field played back in the viewer. The last liquid contracts toward the hot spot. Examples from the 42 parametric geometry families used to generate training data.\nThe pipeline around it The code takes a STEP file to a result you can open in ParaView. It heals the CAD through the OpenCASCADE kernel in Gmsh, meshes it at the density the model was trained on, caches the mesh, runs the model, and checks the part against the training envelope. A screening layer turns the predicted field into a Niyama proxy, a porosity-risk mask, macro-shrinkage regions, gravity-aware sinks and feeder modulus suggestions. There is also a local browser viewer built with trame and PyVista: upload a STEP file, pick the alloy, scrub a time slider and export a playback.\nResults Evaluation n Nodal MAE Hot-spot overlap Held-out geometry families family split 4.26 s 0.917 Unseen real castings 6 80.3 s median 0.738 median Two caveats travel with those numbers. One of the six real parts reached a hot-spot overlap of only 0.035, so the median says nothing certain about any single part. And the training data and the references come from the same FEniCSx model with the same material and boundary assumptions, so these figures show how well the surrogate carries over to new geometry. They are not evidence of physical accuracy against instrumented castings. A hot spot is a shrinkage-risk indicator, not a porosity label.\nThe release covers one setup: a single casting cooling into a green-sand mould over its whole outer surface, in ductile iron, cast steel or a custom property set.\nWhile building the training set I found a defect that shaped the whole project. The solver stored temperatures in one node ordering and the geometry features in another, so about 60% of the targets were silently attached to the wrong positions. Every early model failure traced back to it. If you train on solver output, check node identity across every mesh interface before you tune anything.\nLinks The weights are public under Apache-2.0 on Hugging Face: huggingface.co/eugenmik/castsolid-gnn. The card there documents the architecture, the training data and the limits in full.\nThe inference code and the STEP-to-result pipeline are at github.com/eugenmik/castsolid-gnn, also Apache-2.0, with 154 tests. Training code and the raw simulation corpus are not published.\nRead more: Publishing a casting model: what it took to make the weights runnable\nPublished in the trade press\nA Faster First Look at Casting Solidification, Foundry Management \u0026amp; Technology, Sep 2026 Certainty in the Early Design Stages of Foundry Engineering, Foundry-Planet, Sep 2026 ","permalink":"https://eugenmik.github.io/projects/castsolid-gnn/","summary":"\u003ch2 id=\"the-problem\"\u003eThe problem\u003c/h2\u003e\n\u003cp\u003eA full solidification simulation takes minutes to hours. Early in design, an engineer wants to compare many variants in seconds and see where the metal freezes last, and will give up some precision for that.\u003c/p\u003e\n\u003ch2 id=\"the-model\"\u003eThe model\u003c/h2\u003e\n\u003cp\u003eThe model takes a tetrahedral mesh of a casting with its alloy and mould properties, and returns the time at which every node solidifies. The nodes that solidify last are the hot spots, where feeding problems and shrinkage usually start.\u003c/p\u003e","title":"castsolid-gnn: solidification surrogate"},{"content":"The problem In many foundries, shop-floor data arrives late or not at all. Nobody types a report on a terminal in foundry gloves, so heats, moulds, scrap and chemistry get reconstructed from paper at the end of the shift.\nWhat I built GussCore follows a casting from catalogue and order through the weekly plan, the production batch, the melt shop and quality control to shipment, and compares planned with actual cost.\nWeekly work plan in the public demo build, with generic data.\nOn top of that sits an AI layer that never writes anything by itself. A worker says \u0026quot;poured 10 moulds of pump housing, heat 5\u0026quot;. Speech-to-text and a local language model turn this into fields of a fixed JSON schema, a resolver matches the words to real stages, batches and heats, and the result appears as a proposal that a person confirms. Photos of lab chemistry protocols and of defects go through a vision model into the same loop. The models (Whisper and Qwen, served by Ollama) run on the plant's own GPU, so production data stays in the plant, and every confirmed proposal becomes an example for later prompts.\nA recognised voice report waiting for confirmation.\nThe backend uses FastAPI, Pydantic v2, SQLAlchemy 2 and PostgreSQL, and the frontend is a SvelteKit web app for phones. The architecture is hexagonal, every change goes into an append-only log of more than 60 event types, and 8 roles have field-level permissions. The code has more than 300 tests and 15 recorded architecture decisions.\nStatus GussCore has been piloted at a two-plant foundry group. A public evaluation build with generic data is on GitHub: github.com/eugenmik/gusscore-erp.\nRead more: Human-in-the-loop AI on the foundry floor\n","permalink":"https://eugenmik.github.io/projects/gusscore/","summary":"\u003ch2 id=\"the-problem\"\u003eThe problem\u003c/h2\u003e\n\u003cp\u003eIn many foundries, shop-floor data arrives late or not at all. Nobody types a report on a terminal in foundry gloves, so heats, moulds, scrap and chemistry get reconstructed from paper at the end of the shift.\u003c/p\u003e\n\u003ch2 id=\"what-i-built\"\u003eWhat I built\u003c/h2\u003e\n\u003cp\u003eGussCore follows a casting from catalogue and order through the weekly plan, the production batch, the melt shop and quality control to shipment, and compares planned with actual cost.\u003c/p\u003e","title":"GussCore: AI-assisted foundry ERP/MES"},{"content":"Why I built it I have a very large library of old scanned books on metallurgy and foundry practice. Most of it exists only as DjVu and PDF scans: I can read a page, but I cannot search across books, copy a table or link one handbook to another. I built techbookocr for myself, to turn that library into a knowledge base on my subject in Obsidian.\nWhat it does techbookocr reads a DjVu or PDF file in Russian, English or German and writes a Markdown book. Tables become HTML with their merged header cells, formulas become LaTeX, and figures are cropped into separate files, including the small drawings that old handbooks put inside table cells. Every page starts with an anchor that points back to the scan, and a quality report lists each correction the pipeline made and each word the spell checker did not know. Each finished book also carries front matter and a table-of-contents note for Obsidian.\nA test page from a 1955 U.S. National Bureau of Standards paper (public domain). techbookocr read all 48 numbers in its table correctly and 13 of the 14 equations exactly.\nEverything runs on my own computer with one 12 GB GPU, so no book leaves the machine. A layout model (dots.mocr) reads each page, a second detector finds drawings inside tables, and a vision-language model (Qwen3.5-9B in llama.cpp) settles the blocks where readings disagree. Fixed rules then check every change that model wants to make: a changed digit, deleted text or a technical term replaced by an everyday word is rejected, and the printed text stays. A queue daemon works through the library one book after another and can run for weeks, and a terminal panel shows its progress.\nResults On 31 hand-checked pages from Russian foundry handbooks, mostly tables with formulas and figures, compared with the best single model:\nCharacter error rate Numbers F1 Table structure (TEDS) Seconds per page dots.mocr alone 0.148 0.882 0.824 26 techbookocr, default mode 0.027 0.997 0.883 43 A 750-page handbook takes about 11 hours on an RTX 3060. Formulas are the weak spot: their character error rate (0.41) is no better than the single model's. A value printed once for several table columns is also sometimes assigned to only one of them. The code has more than 600 tests.\nLinks The code is on GitHub under the MIT licence: github.com/eugenmik/techbookocr.\n","permalink":"https://eugenmik.github.io/projects/techbookocr/","summary":"\u003ch2 id=\"why-i-built-it\"\u003eWhy I built it\u003c/h2\u003e\n\u003cp\u003eI have a very large library of old scanned books on metallurgy and foundry practice. Most of it exists only as DjVu and PDF scans: I can read a page, but I cannot search across books, copy a table or link one handbook to another. I built techbookocr for myself, to turn that library into a knowledge base on my subject in Obsidian.\u003c/p\u003e\n\u003ch2 id=\"what-it-does\"\u003eWhat it does\u003c/h2\u003e\n\u003cp\u003etechbookocr reads a DjVu or PDF file in Russian, English or German and writes a Markdown book. Tables become HTML with their merged header cells, formulas become LaTeX, and figures are cropped into separate files, including the small drawings that old handbooks put inside table cells. Every page starts with an anchor that points back to the scan, and a quality report lists each correction the pipeline made and each word the spell checker did not know. Each finished book also carries front matter and a table-of-contents note for Obsidian.\u003c/p\u003e","title":"techbookocr: scanned technical books to Markdown"},{"content":"What it does AlloyForge takes an alloy composition and checks it in three ways. A PHACOMP engine computes Md, Bo and Nv and estimates the risk of TCP phases. A CALPHAD check with pycalphad and an open thermodynamic database looks at phase stability. A search over metallurgy textbooks, using pgvector and bge-m3 embeddings, finds what the literature says about similar alloys. The results come together in a shortlist with trade-offs and cost, drawn from a reference database of 40 alloys.\nHow AlloyForge combines the three checks.\nStatus AlloyForge is a work in progress.\nLinks The code is on GitHub under the AGPL-3.0 licence: github.com/eugenmik/alloyforge.\n","permalink":"https://eugenmik.github.io/projects/alloyforge/","summary":"\u003ch2 id=\"what-it-does\"\u003eWhat it does\u003c/h2\u003e\n\u003cp\u003eAlloyForge takes an alloy composition and checks it in three ways. A PHACOMP engine computes Md, Bo and Nv and estimates the risk of TCP phases. A CALPHAD check with pycalphad and an open thermodynamic database looks at phase stability. A search over metallurgy textbooks, using pgvector and bge-m3 embeddings, finds what the literature says about similar alloys. The results come together in a shortlist with trade-offs and cost, drawn from a reference database of 40 alloys.\u003c/p\u003e","title":"AlloyForge: superalloy design assistant"},{"content":"What it does The app reads a resume as PDF, DOCX or text, pulls out the foundry experience, estimates seniority and finds the gaps. From that it writes interview questions across technical, metallurgical, quality and behavioural topics, then runs a live mock interview in chat. A second model call scores each answer from 0 to 10 and suggests a better one.\nThere are two modes. A candidate practises against their own resume. A recruiter uploads someone else's and gets an interview plan, a weighted scorecard and a list of things to probe. The interface runs in English, German and Russian, and the chosen language is passed to the model so the generated questions match.\nFrom a resume to a scored mock interview.\nPrompting and guards The app carries five prompting strategies that you can switch between while using it: zero-shot, few-shot, chain of thought, persona and a structured contract. Running the same resume through each one shows the differences directly, which was the point of building it.\nIt also has three guards against prompt injection in an uploaded resume: input validation, a regex filter and a moderation call. A resume is a file from a stranger, so an interview app that feeds it straight into a model is an obvious target.\nStatus This was my first sprint project on the Turing College AI Engineering programme, and it stayed at that scope: no test suite, no licence file and no hosted demo. It is here as the place where I started working with language models, not as production software.\nLinks The code is at github.com/eugenmik/foundry-interview-prep.\n","permalink":"https://eugenmik.github.io/projects/foundry-interview-prep/","summary":"\u003ch2 id=\"what-it-does\"\u003eWhat it does\u003c/h2\u003e\n\u003cp\u003eThe app reads a resume as PDF, DOCX or text, pulls out the foundry experience, estimates seniority and finds the gaps. From that it writes interview questions across technical, metallurgical, quality and behavioural topics, then runs a live mock interview in chat. A second model call scores each answer from 0 to 10 and suggests a better one.\u003c/p\u003e\n\u003cp\u003eThere are two modes. A candidate practises against their own resume. A recruiter uploads someone else's and gets an interview plan, a weighted scorecard and a list of things to probe. The interface runs in English, German and Russian, and the chosen language is passed to the model so the generated questions match.\u003c/p\u003e","title":"Foundry Interview Prep: practice from a resume"},{"content":"The solidification surrogate behind castsolid-gnn is now public under Apache-2.0, weights included. I had expected that to be an afternoon of uploading a checkpoint. It was not. The model had lived in my training setup for months, and a training checkpoint is not something a stranger can run.\nHere is what stood between the checkpoint and a model someone else can use.\nA checkpoint carries the training rig with it My internal artifacts were a PyTorch .pt file and two scikit-learn models saved with joblib. All three were written by my own code and read by my own code, so they were full of assumptions I had stopped seeing: how features were normalized, what the architecture config was, which node ordering the mesh used, which scikit-learn version wrote the file.\nUnpacking that is most of the work. The published GNN carries its normalization statistics and its architecture config inside the file metadata, so the loader does not need my training repository to rebuild the network. The alloy and mould properties became eight named numbers with documented units instead of positional arguments.\nProving the published file is the same model A converted file is a new file, and I did not want to find out later that it had drifted from the checkpoint it came from.\nFor the network, I checked every tensor against the internal checkpoint for bit identity, along with the config and the normalization statistics. The gradient-boosted heads cannot be compared that way, because the file format differs, so I compared behaviour instead: 10,002 probe rows spanning the training range of each input feature, with identical predictions required. Then I ran the published inference code beside the internal pipeline on five production parts, two of them in both alloys, plus a mesh with a custom property set. Every output field matched.\nThat last check is the one I would skip if I were in a hurry, and it is the one that would have caught a mistake in the loading path rather than in the weights.\nFile formats that cannot run code A pickle file executes code when you load it. Asking a foundry engineer to download a pickle from the internet and open it is asking them to run a stranger's code on their workstation.\nThe network ships as safetensors, which stores tensors and nothing executable. The two boosted heads use skops, and before the loader opens one it checks every type named in the file against an allowlist of scikit-learn and NumPy types. Neither file can execute anything when loaded.\nThe cost is a version constraint. The heads were trained with scikit-learn 1.5.2, and other versions may refuse to load them. That is stated on the card rather than discovered at runtime.\nReporting the evaluation so it cannot be misread This was the part I rewrote most often.\nThe headline numbers are good: nodal error of 4.26 s and hot-spot overlap of 0.917 on held-out geometry families. On six real castings the median overlap is 0.738. A median over six parts invites the reader to treat it as typical, so the card also says that one of those six reached an overlap of 0.035. Someone deciding whether to trust this on their own part needs the bad case more than the median.\nThe more important caveat is structural. The training data and the real-part references come from the same FEniCSx heat-transfer model, the same material database and the same boundary assumptions. The evaluation measures how well the surrogate carries over to geometry it has not seen. It is not evidence of physical accuracy against instrumented castings, and the card says so in those words. A foundry engineer reading an overlap of 0.917 could otherwise reasonably assume someone had poured the part and measured it.\nWhat is not in the release Training code and the simulation corpus, about 100 GB, stay unpublished. The release is the model, the inference code and the pipeline that goes from a STEP file to a field you can open in ParaView.\nA surrogate like this is useful for screening: comparing early concepts, finding candidate last-to-solidify regions, and deciding which designs are worth a full simulation. It does not sign off a process. Keeping that line visible in the documentation matters more to me than the accuracy numbers, because the numbers are only meaningful to someone who knows which question they answer.\nIf you try it on a casting of your own, especially one where it fails, the discussions tab is the place I would most like to hear about it.\n","permalink":"https://eugenmik.github.io/posts/publishing-a-casting-model/","summary":"\u003cp\u003eThe solidification surrogate behind \u003ca href=\"/projects/castsolid-gnn/\"\u003ecastsolid-gnn\u003c/a\u003e is now public under Apache-2.0, weights included. I had expected that to be an afternoon of uploading a checkpoint. It was not. The model had lived in my training setup for months, and a training checkpoint is not something a stranger can run.\u003c/p\u003e\n\u003cp\u003eHere is what stood between the checkpoint and a model someone else can use.\u003c/p\u003e\n\u003ch2 id=\"a-checkpoint-carries-the-training-rig-with-it\"\u003eA checkpoint carries the training rig with it\u003c/h2\u003e\n\u003cp\u003eMy internal artifacts were a PyTorch \u003ccode\u003e.pt\u003c/code\u003e file and two scikit-learn models saved with joblib. All three were written by my own code and read by my own code, so they were full of assumptions I had stopped seeing: how features were normalized, what the architecture config was, which node ordering the mesh used, which scikit-learn version wrote the file.\u003c/p\u003e","title":"Publishing a casting model: what it took to make the weights runnable"},{"content":"In many foundries the hardest data problem is capture. Nobody types a report on a terminal in foundry gloves, so heats, moulds, scrap and chemistry get reconstructed from paper at the end of the shift, and that is where errors come in.\nGussCore lets shop-floor workers report by voice or photo. It has been piloted at a two-plant foundry group, and five rules shaped it.\n1. The AI proposes and a person confirms Nothing reaches the database without human confirmation. A wrong heat number spreads into metal traceability, costing and the weekly plan, so the model takes over the typing and the person keeps the responsibility.\n2. Constrain the model, then check against real records The language model must answer in a fixed JSON schema: intent, quantity, stage, heat and defect kind. A separate resolver then maps the words to entities that exist, using fuzzy matching in PostgreSQL. The model cannot invent an ID. At worst it fails to find one, and the person sees that.\n3. Keep the data in the plant Voice recordings, photos of lab chemistry protocols and production numbers are all sensitive. Speech recognition (Whisper) and the language and vision models (Qwen, served by Ollama) run on the plant's own GPU. Planning GPU memory for this was one of the first architecture decisions I recorded.\n4. Learn from confirmations Each proposal a person confirms becomes an example in later prompts, so recognition improves with use and no model needs retraining.\n5. Record events and derive states Nobody types stage progress by hand. It is derived from events: the open quantity is planned minus good minus scrap. A correction is a negative event, so costing rolls back cleanly, and every change has an author in an append-only log of more than 60 event types.\nWhat it took Getting from a chat-bot prototype to a web app for phones took about three months, with more than 300 tests and 15 recorded architecture decisions along the way. The AI was the easier part. The harder part was the foundry itself: learning which words melters actually use, and which mistakes cost money.\nPublished in the trade press\nA Faster First Look at Casting Solidification, Foundry Management \u0026amp; Technology, Sep 2026 Certainty in the Early Design Stages of Foundry Engineering, Foundry-Planet, Sep 2026 ","permalink":"https://eugenmik.github.io/posts/human-in-the-loop-ai-foundry-floor/","summary":"\u003cp\u003eIn many foundries the hardest data problem is capture. Nobody types a report on a terminal in foundry gloves, so heats, moulds, scrap and chemistry get reconstructed from paper at the end of the shift, and that is where errors come in.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/projects/gusscore/\"\u003eGussCore\u003c/a\u003e lets shop-floor workers report by voice or photo. It has been piloted at a two-plant foundry group, and five rules shaped it.\u003c/p\u003e\n\u003ch2 id=\"1-the-ai-proposes-and-a-person-confirms\"\u003e1. The AI proposes and a person confirms\u003c/h2\u003e\n\u003cp\u003eNothing reaches the database without human confirmation. A wrong heat number spreads into metal traceability, costing and the weekly plan, so the model takes over the typing and the person keeps the responsibility.\u003c/p\u003e","title":"Human-in-the-loop AI on the foundry floor"},{"content":"A fast solver that gives a wrong answer makes a wrong feeding decision look certain. When I wrote the solidification solver behind FoundryFlash, I spent as much time checking it as writing it. This post covers that checking and the error that mattered most.\nWhat the solver computes The solver integrates the transient heat equation in enthalpy form, which handles the latent heat released during freezing without special treatment:\n$$\\rho \\frac{\\partial H}{\\partial t} = \\nabla \\cdot \\left( k \\nabla T \\right), \\qquad T = T(H)$$It uses control-volume finite elements on linear tetrahedra and balances energy on the dual volume around each node. Time stepping is implicit backward Euler, solved with a Jacobi-preconditioned conjugate-gradient method. The mould is a region of its own: heat crosses the metal-mould interface through a heat-transfer coefficient \\(h\\), with flux \\(q = h \\, (T_\\text{metal} - T_\\text{mould})\\).\nStep 1: verification First I checked that the equations are solved correctly. I solved the same enthalpy problem in FEniCSx, an independent open-source finite-element library, on a small verification test case (about 900 nodes, explicit time stepping) where the two codes can be compared node by node. These were the acceptance limits and the results:\nCheck Limit Measured Energy imbalance 10⁻⁴ 5.6 × 10⁻¹⁵ Solid-fraction MAE 0.01 0.0086 Solidification time, relative error 0.01 0.00088 The CPU and GPU backends agree to round-off (10⁻¹⁵). With the implicit scheme, a 20 s time step stays within 1.3% of the reference; an explicit scheme at the same step was off by 15.6%.\nStep 2: validation Next came the question whether these are the right equations for a real casting. The reference was a commercial simulation of a ductile-iron (EN-GJS-400-15) production casting, which reached full solidification at 964 s. My first result was 51% longer.\nBefore touching the solver, I changed one input at a time and measured how far each one moved the total solidification time:\nInput changed Change Shift in total time Interface heat-transfer coefficient 4× (500 to 2000 W/m²K) −5.5% Alloy data freezing range 21 K to 89 K −12.3% Mould thermal effusivity \\(b = \\sqrt{k \\rho c}\\) 1.5× −43.8% The mould dominates. The sand data I had used described a soft sand: \\(k = 0.484\\) W/(m·K) and \\(\\rho c = 1.466 \\times 10^6\\) J/(m³·K), which gives \\(b \\approx 842\\). Typical published green-sand data (\\(k = 0.7\\), \\(\\rho = 1500\\), \\(c_p = 1100\\)) gives \\(b \\approx 1075\\), 1.28 times higher. With \\(b\\) raised by a factor of 1.30, the solver gives 1000 s against the reference 964 s, a difference of 3.7%. Nothing in the numerics changed.\nWhat this means for a foundry In this case the number that drove the feeding decision came from the sand data. Measuring the plant's own moulding material (thermal diffusivity by laser flash, plus heat capacity and bulk density, which together give the conductivity) would do more for accuracy than any change to the code, and it costs less than a software licence.\nSpeed On a consumer RTX 3060, a case with 1.6 million elements solves in 9.9 s, against 44.9 s on eight CPU threads. A parallel mesher cut 3D meshing from 57 s to 4 s, and keeping the solver process running cut job start-up from about 27 s to under 0.1 s.\nOpen points One casting is one casting. A second validation package is ready: six runs on five castings against another commercial code, with acceptance criteria fixed in advance. The shrinkage model is a volume balance over liquid pools without melt flow or pressure, so it shows where defects form, but its percentages are only qualitative.\nPublished in the trade press\nA Faster First Look at Casting Solidification, Foundry Management \u0026amp; Technology, Sep 2026 Certainty in the Early Design Stages of Foundry Engineering, Foundry-Planet, Sep 2026 ","permalink":"https://eugenmik.github.io/posts/validating-gpu-solidification-solver/","summary":"\u003cp\u003eA fast solver that gives a wrong answer makes a wrong feeding decision look certain. When I wrote the solidification solver behind \u003ca href=\"/projects/foundryflash/\"\u003eFoundryFlash\u003c/a\u003e, I spent as much time checking it as writing it. This post covers that checking and the error that mattered most.\u003c/p\u003e\n\u003ch2 id=\"what-the-solver-computes\"\u003eWhat the solver computes\u003c/h2\u003e\n\u003cp\u003eThe solver integrates the transient heat equation in enthalpy form, which handles the latent heat released during freezing without special treatment:\u003c/p\u003e\n$$\\rho \\frac{\\partial H}{\\partial t} = \\nabla \\cdot \\left( k \\nabla T \\right), \\qquad T = T(H)$$\u003cp\u003eIt uses control-volume finite elements on linear tetrahedra and balances energy on the dual volume around each node. Time stepping is implicit backward Euler, solved with a Jacobi-preconditioned conjugate-gradient method. The mould is a region of its own: heat crosses the metal-mould interface through a heat-transfer coefficient \\(h\\), with flux \\(q = h \\, (T_\\text{metal} - T_\\text{mould})\\).\u003c/p\u003e","title":"Validating a GPU solidification solver: from +51% to within 3.7%"},{"content":"Many casting simulation codes discretise the part on a structured cubic grid. That made sense on the hardware of the 1980s, and for many parts it still works. It is a weak base for two things foundries want now: simulating the free-form shapes that 3D-printed moulds and cores make possible, and training AI that proposes casting technology.\nWhere the staircase hurts A cubic grid turns a curved or inclined surface into a staircase. On a plane inclined at 45°, the staircase overstates the wetted area by \\(\\sqrt{2} \\approx 1.41\\), and doubly curved surfaces are worse. The surface normal also points along a grid axis everywhere instead of following the real surface.\nInterface heat flux is \\(q = h \\, A \\, (T_\\text{metal} - T_\\text{mould})\\), so both errors go straight into the local cooling rate, which is what feeding decisions rest on. The error is largest on organic, undercut shapes, the same parts customers order printed moulds and cores for.\nWhat my voxel prototype measured Voxels have real advantages, so I built a voxel prototype for my own solver. It used a cut-cell correction (true volume fractions and clipped interface areas), and I compared it with the tetrahedral solution on a production casting at 4, 3 and 2 mm cells.\nThe first comparison was far off because of my own mistake: the rule for conductance across the casting-mould contact layer was wrong by a factor that did not depend on cell size. After fixing it I got these numbers:\nCell size 4 mm 3 mm 2 mm Total solidification time vs tetrahedral +4.2% +1.4% +4.1% Field median of \\(\\lvert \\Delta t \\rvert / t\\) 10.1% 3.4% 9.6% Halving the cell did not halve the error, and on this casting it did not reduce it at all. The remaining error sits in thin sections that freeze early (20 to 46% in the first 200 s band), while heavy sections stay within 2 to 6%. I kept the tetrahedral mesh.\nVoxels do have strengths. The voxel path meshed three castings with defective CAD that the tetrahedral path could not mesh at all, and its stencil is well behaved by construction. In the tetrahedral mesh of the reference casting, 16.5% of the edge conductances were negative. I keep measuring both.\nWhy the mesh matters for AI A graph neural network learns on nodes and edges, and an unstructured tetrahedral mesh already has that form: its nodes carry temperatures and solidification times, and its edges carry the geometry. My GNN surrogate learns directly on the simulation mesh, following the MeshGraphNets pattern.\nA voxel grid leads to 3D convolutions instead. Their memory grows with the cube of the resolution, and the network has to learn the staircase along with the physics. For AI that proposes gating and feeding on free-form castings, the choice of discretisation decides what the model can learn.\nPublished in the trade press\nA Faster First Look at Casting Solidification, Foundry Management \u0026amp; Technology, Sep 2026 Certainty in the Early Design Stages of Foundry Engineering, Foundry-Planet, Sep 2026 ","permalink":"https://eugenmik.github.io/posts/voxels-or-tetrahedra/","summary":"\u003cp\u003eMany casting simulation codes discretise the part on a structured cubic grid. That made sense on the hardware of the 1980s, and for many parts it still works. It is a weak base for two things foundries want now: simulating the free-form shapes that 3D-printed moulds and cores make possible, and training AI that proposes casting technology.\u003c/p\u003e\n\u003ch2 id=\"where-the-staircase-hurts\"\u003eWhere the staircase hurts\u003c/h2\u003e\n\u003cp\u003eA cubic grid turns a curved or inclined surface into a staircase. On a plane inclined at 45°, the staircase overstates the wetted area by \\(\\sqrt{2} \\approx 1.41\\), and doubly curved surfaces are worse. The surface normal also points along a grid axis everywhere instead of following the real surface.\u003c/p\u003e","title":"Voxels or tetrahedra: what casting AI needs from the mesh"},{"content":"I am a foundry engineer. Since 2006 I have designed casting technology, run casting simulations and brought new foundries into production. Over my career I have developed about 1,000 casting technologies.\nI did not retrain as an AI engineer. I learned modern AI, from graph neural networks to language models, so that I could combine it with what I know about casting. I use it to build software tools for foundries and metallurgy: a GPU solidification solver, a neural network that predicts hot spots from a STEP file in seconds, and shop-floor software where workers report by voice and a person stays in control of what gets saved.\nMy dream is to bring about a revolution in the modern foundry: a casting engineer gets a solidification answer in seconds, AI suggests the gating and feeding, and the engineer makes the final call with years of practice behind it.\nDownloads: CV (English, PDF) · Lebenslauf (German, PDF)\nExperience Founder and AI engineer, FoundryFlash (independent R\u0026amp;D), Senftenberg, since May 2026. I build a GPU casting simulator, a GNN surrogate and an AI-assisted foundry ERP/MES. See Projects. Foundry engineer, project management, SLR-Elsterheide GmbH, Sep 2022 to Apr 2026. I introduced AI technology into production, designed gating and feeding in MAGMASOFT, and brought 3D printing into the pattern shop, which cut tooling lead times several-fold. Foundry engineer, project management, Kunstgiesserei Lauchhammer KG, Aug 2020 to Aug 2022. I led the commissioning of an induction melting plant and an investment casting line. Equipment I designed halved the cycle time and cut energy use by about 30%, and I built a large-format wax 3D printer for patterns. Head of Design \u0026amp; Metallurgy, Giesserei Elsterberg GmbH, Mar 2015 to Jul 2020. I developed more than 400 complete casting technologies for complex industrial castings, simulated in WinCast, and ran design, metallurgy and production as one team. Foundry projects alongside employment, 2016 and 2020. I commissioned a greenfield foundry for uranium-mining pump systems in Kazakhstan and developed FEM-supported casting technology for diesel-engine castings in Latvia. Foundry technology engineer, Kyiv and Malyn, Ukraine, 2010 to 2014. I developed a lost-foam technology for metro tunnel segments, about 20% cheaper than no-bake moulding, and commissioned a V-process moulding line. Skills Casting and metallurgy: gating and feeding design, defect analysis, investment, sand, lost-foam and die casting, MAGMASOFT, ProCAST, WinCast, SolidWorks 3D printing: printed sand moulds and cores, large-format wax patterns, 3D printing in the pattern shop Simulation: FEM and CVFEM, enthalpy solidification models, implicit solvers, CUDA.jl, FEniCSx, Gmsh Physics-based machine learning: graph neural networks (MeshGraphNets), PyTorch, PyTorch Geometric, surrogate models Language models: structured output, agents, human-in-the-loop design, models running on premises (Ollama, Qwen, Whisper) Software: Python, Julia, TypeScript, SQL, FastAPI, React, SvelteKit, three.js, PostgreSQL, Docker, test-driven development Education and certificates M.Sc. Foundry Engineering, National Technical University of Ukraine \u0026quot;Igor Sikorsky Kyiv Polytechnic Institute\u0026quot;, 2003 to 2009. The degree was recognised by the Saxony Chamber of Engineers (Ingenieurkammer Sachsen) in 2020. AI Engineering, Turing College, 2026: 520 hours on LLM applications, retrieval-augmented generation, AI agents and a capstone project. A Deep Dive into Claude Code, Profile Virtual School, 2026. ","permalink":"https://eugenmik.github.io/about/","summary":"\u003cp\u003eI am a foundry engineer. Since 2006 I have designed casting technology, run casting simulations and brought new foundries into production. Over my career I have developed about 1,000 casting technologies.\u003c/p\u003e\n\u003cp\u003eI did not retrain as an AI engineer. I learned modern AI, from graph neural networks to language models, so that I could combine it with what I know about casting. I use it to build software tools for foundries and metallurgy: a GPU solidification solver, a neural network that predicts hot spots from a STEP file in seconds, and shop-floor software where workers report by voice and a person stays in control of what gets saved.\u003c/p\u003e","title":"About"},{"content":"Contact Eugen Miknevic\nSenftenberg, Germany\nEmail: eugenmiknevic@gmail.com\nThis is a private, non-commercial website. It presents information about my professional background, my projects and my articles. Nothing is sold or offered here.\nPrivacy The site is hosted on GitHub Pages, operated by GitHub, Inc. When you open a page, GitHub's servers process technical data such as your IP address to deliver it. GitHub may process this data on servers in the United States. This is described in the GitHub General Privacy Statement. I use no cookies, no analytics, no tracking and no third-party embeds. Fonts and scripts are served from this site. If you email me, I use your message only to reply. Links to external websites lead to content for which their operators are responsible.\n","permalink":"https://eugenmik.github.io/legal/","summary":"\u003ch2 id=\"contact\"\u003eContact\u003c/h2\u003e\n\u003cp\u003eEugen Miknevic\u003cbr\u003e\nSenftenberg, Germany\u003cbr\u003e\nEmail: \u003ca href=\"mailto:eugenmiknevic@gmail.com\"\u003eeugenmiknevic@gmail.com\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThis is a private, non-commercial website. It presents information about my professional background, my projects and my articles. Nothing is sold or offered here.\u003c/p\u003e\n\u003ch2 id=\"privacy\"\u003ePrivacy\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eThe site is hosted on GitHub Pages, operated by GitHub, Inc. When you open a page, GitHub's servers process technical data such as your IP address to deliver it. GitHub may process this data on servers in the United States. This is described in the \u003ca href=\"https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement\"\u003eGitHub General Privacy Statement\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eI use no cookies, no analytics, no tracking and no third-party embeds. Fonts and scripts are served from this site.\u003c/li\u003e\n\u003cli\u003eIf you email me, I use your message only to reply.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLinks to external websites lead to content for which their operators are responsible.\u003c/p\u003e","title":"Legal \u0026 Privacy"}]