What we do
Our work spans a range of areas, most of it rooted in the HVAC industry and the kinds of projects we've delivered before. That said, we're glad to take on work in new fields too, as long as it sits within our skillset.
MGNA Oy develops calculation and design tools that help engineers size, evaluate, and optimise heating, ventilation, and air-conditioning systems. We tailor each solution to your needs, from a DLL for your own software to full web, desktop, and mobile applications.
MGNA is a software company focused primarily on HVAC-related software. We build selection tools, calculation DLLs, Revit Add-Ins, visualisations, and more. In short, we know how to model the physics, build the software, and create genuinely useful additions to existing tools. Depending on what you need, we may be a great fit, so feel free to get in touch. And when something falls outside our expertise, we'll say so plainly and, where we can, point you toward a company better suited to the job.
Our work spans a range of areas, most of it rooted in the HVAC industry and the kinds of projects we've delivered before. That said, we're glad to take on work in new fields too, as long as it sits within our skillset.
We bring broad experience centred on, but not limited to, the HVAC industry. Our competence ranges from general software engineering to more specialised areas, such as understanding heating and cooling coils at a deep physical level.
We've built a wide variety of tools, from calculation DLLs and selection software to Revit Add-Ins and beyond. Below you'll find a selection of our recent work and soon-to-be-released software, presented as demos. Feel free to explore.
We call this a Semi-Computational Fluid Dynamics demo — rather than plain CFD — because it combines a traditional diffuser throw-pattern model with a CFD-style room solve.
The throw pattern describes how a diffuser behaves in a large, undisturbed room; it can come from an engineering formula, from laboratory measurement data, or from a mix of both.
CFD then takes over once those jets meet a real room — handling wall attachment, jet-to-jet interaction, and return flow toward the exits.
You keep a reliable, reproducible characterisation of each diffuser as your starting point, and you skip writing fragile correction formulas for every kind of wall and jet collision.
This is a technology demo: it recomputes everything from scratch the moment you touch a slider.
It is not a production module — it is a working sketch of the architecture.
Please note that this demo is done against ISO 7730:2005 which is currently "withdrawn" (Stage: 95.99) new version being ISO 7730:2025 (Stage 60.60).
A DLL version is planned for release in 2027. Built to the ISO 7730:2025 standard, it can be integrated as a DLL in desktop applications or consumed via a Web API.
A technology demo of one way to approximate airflow in a room. The room is always U-shaped — you can tweak its dimensions within limits. Three ceiling diffusers are placed in it, and for each you can choose the diffuser / throw pattern type, change its flow rate, and slide it a little along its segment. The result gives a feel for how airflow can be simulated under several different methods.
The pipeline breaks into four questions:
The Room — what is the geometric representation of the volume?
The Throw Pattern Data — formulas, measurement data, or both?
The Calculation — which numerical method, and how much compute do we spend?
The Visualization — what should the user see?
In principle, the room can be any shape and size — volume is the more precise word, but rooms are the volumes we care about. The demo uses a U-shape with chamfered inside corners: simple enough to keep the controls minimal, complex enough to make the airflow interesting — multiple flow regimes, dead-ends at the leg tops, and exits on the far end walls.
The system is designed to take multiple kinds of input. The idea is freedom of choice: if you have validated formulas, plug them in; if you have laboratory measurements, plug those in; if you have both, mix them. The patterns shipped in this demo are generated on the fly from general formulas — but a measured pattern would slot into the same interface.
The same flexibility applies to new products. If you are building diffuser-selection software, your carefully crafted formulas drop straight in. If you are bringing a new diffuser to market, the laboratory measurements you already collect are all that is needed to show how it behaves — the system consumes either, out of the box.
How the simulation is run depends on the budget — how precise you need to be against how fast you need an answer, and how much memory and compute you are willing to spend. The pipeline is built so it can be simplified for speed or extended for accuracy as needed. The demo exposes two of those choices: a quality tier (two voxel-grid resolutions) and a display mode that ranges from the raw throw pattern, through the same pattern squeezed into the room, to the full CFD reconciliation.
Which visualisation looks best is partly a matter of taste. The point that matters most, though, is whether the occupied zone — the part of the room where people actually stand and sit — sees too much air movement. The demo draws streamlines coloured by temperature with width and opacity scaled to air speed, an iso-surface for air speed, an iso-surface for warm-air reach, and a red draught-risk surface that lights up wherever ISO 7730 says people would feel a draught. Together they make the airflow story easy to read at a glance.
The whole reason for simulating airflow is to find out whether the room is comfortable. The demo answers that with the ISO 7730 Draught Rate — the percentage of people predicted to be dissatisfied by draught at each location — evaluated over the standardised occupied zone (the room floor inset from the walls and capped at 1.8 m head height, with a larger setback from exterior walls). You pick a comfort category — the demo reports the worst draught point and the share of the zone that fails the chosen limit. The flow viewer becomes a design tool: move a slider, see whether your layout meets your category.
Comfort Category — A, B, or C. Picks the ISO 7730 Draught-Rate limit that the draught-risk surface, the hotspots, and the headline verdict are judged against.
Categories:
A (strict, DR ≤ 10 %)
B (standard, DR ≤ 20 %)
C (lenient, DR ≤ 30 %)
With the same simulation data available to a higher-level program, diffusers can be selected and adjusted automatically against the airflow outcome — picking the best diffuser type, position and flow rate for a given room without manual iteration. The demo provides the raw material; an outer optimiser drives it.
The Room section adjusts the room itself — leg lengths, connector length, corridor width, ceiling height, and the inside-corner chamfer. The slider ranges are deliberately limited, but wide enough to show how the rest of the pipeline reacts to a changing volume.
Three diffusers sit on the ceiling: one in the connector at the centre of the U, and one along each leg. For each, the pattern dropdown picks the diffuser type — Swirl, 2-way, or Vertical — the offset slider slides it along its segment, and the flow slider sets its supply-air volume in m³/s.
Two quality tiers:
Standard — the default. A coarser voxel grid and a shorter solver budget; still a full simulation, just faster.
Accurate — a finer voxel grid and a longer solver budget. More precise, proportionally slower.
The grid resolution adapts to the room size at each tier, so the small under-door exits stay properly resolved at every slider setting.
The Display section controls what you see, in four layers.
Flow mode — how much of the pipeline runs:
Pattern data — the raw throw pattern of each diffuser, drawn unbounded with the room ignored.
Raw patterns — the same patterns squeezed into the room, before the solver runs.
Simulated — the full CFD reconciliation: how the air actually flows.
The air-speed iso-surface threshold (defaults to the ISO 7730 0.2 m/s draught level), the iso-temperature threshold, and the number of streamlines drawn (0 hides them).
Toggle each visualisation independently: streamlines, the iso-velocity surface, the iso-temperature surface, the red draught-risk surface, the floor draught-rate heat-map, the draught hotspots, and the occupied-zone outline. A Clip to occupied zone toggle restricts the airflow visualisations to that volume.
Eurovent 6/19-1 – 2024 is a Eurovent recommendation (first edition, March 2024) that defines a standardised way to calculate the Life Cycle Cost (LCC) of an Air Handling Unit —
the total cost of owning and operating the unit across its service life (15 years by default), not just its purchase price.
The goal is a fair, like-for-like comparison between competing AHU designs.
The recommendation has two parts; this software implements Part 1: the detailed calculation of annual energy consumption.
Part 1 uses a degree-hour method — the AHU is simulated for all 8760 hours of a reference year, using local climate data, an operating schedule,
and temperature/moisture setpoint scenarios. Each hour, the component functions run in a sequence fixed by the AHU's configuration — one of 22,
spanning four heat-recovery types (plate, rotary, run-around-coil, or none) with optional cooling, humidification and adiabatic cooling.
The hourly results are summed into annual totals for electricity, heating, cooling and water, then discounted into costs.
The DLL
This calculation module is based on the Eurovent specification.
The calculation is delivered as a .NET Standard 2.0 library.
Each of the 10 AHU component types is its own class, and an orchestration engine drives the 8760-hour loop and the 22 configuration sequences.
It consumes an AHU specification, climate data, schedule, scenarios and economic parameters,
and returns the annual energy figures plus the net-present-value LCC (investment cost + energy/utility running cost + end-of-life cost;
maintenance and occasional repair belong to Part 2 and are out of scope).
This web application is a demonstration and verification front-end:
each accordion below exercises one part of the DLL on its own, and the last runs a complete LCC calculation.
If you're pursuing Eurovent certification, or want a standardised approach to LCC calculations that compares cleanly against other results, this module can help you get there.
The shared moist-air physics used by every other function. Given a dry-bulb temperature and relative humidity, it computes water-vapour saturation pressure, moisture content, enthalpy and dew point using the ASHRAE equations of Section 3.2. It is not an AHU component but the foundational utility layer; the demo exposes it so the psychrometric building blocks can be checked directly.
Cross- or counter-flow plate heat exchanger (Function 4). Recovers heat between exhaust and supply air, computing the supply outlet temperature and moisture and the recovered heating/cooling power for the hour. It determines the frost-risk temperature from actual conditions and, if freezing would occur, reduces recovery and engages an anti-freeze preheater (electric or water). Efficiency is corrected for actual airflow.
Rotary wheel heat exchanger (Function 5). Handles three rotor types — condensation, hygroscopic and sorption — recovering heat and, for hygroscopic/sorption rotors, moisture as well. Computes the supply outlet conditions, recovered power, moisture recovery and the rotor drive's electric power. Temperature and moisture efficiency are corrected for actual airflow and condensation potential; frost risk depends on rotor type.
Run-around coil loop (Function 6): a coil in the exhaust and a coil in the supply, linked by a pumped fluid loop that carries heat between them. Computes the supply outlet conditions, recovered power and pump electric power. Like the PHE it checks freezing risk and reduces recovery if it occurs; efficiency is corrected for actual airflow.
Heating coil or electric heater (Function 7). Raises the supply-air temperature toward the setpoint, computing the outlet conditions and the required heater output — thermal (water coil) or electric. It applies the logical conditions that decide whether heating is actually needed in a given hour, based on the incoming air and the supply setpoint.
Cooling coil (Function 8), water or DX. Two modes: temperature control (cooling coil only) and moisture control (cooling coil plus a reheater that re-warms over-cooled air). Computes the outlet conditions, cooling power and reheat power. It detects dry versus wet (condensing) operation and passes a wet/dry flag to the fan function, because a wet coil changes the pressure drop.
Adiabatic (evaporative) humidifier (Function 9). Adds moisture by evaporating water into the airstream, which also cools it. Computes the outlet moisture, the thermal power needed to offset the evaporative cooling, water consumption and the water pump's electric power. Humidification heating power is calculated jointly for all heaters applied, which must all be of the same type.
Steam humidifier (Function 10). Adds moisture as steam, raising humidity without the cooling effect of adiabatic humidification. Supports electric, gas-fired and central-steam supply. Computes the outlet moisture, water consumption, humidifier power input, and the small temperature rise the steam causes — which is passed on to other functions.
Indirect adiabatic cooling (Function 11). Cools the supply air without adding moisture to it: an adiabatic humidifier on the exhaust side cools the exhaust air, and a heat-recovery exchanger (PHE, RAC or condensing ROT) then transfers that coolth to the supply. Computes the indirectly-cooled supply conditions, cooling effect, water consumption and pump power. It calls the relevant heat-recovery function internally.
Heat recovery with a recirculation/mixing section (Function 12). Mixes return air back into the fresh air while still accounting for the heat-recovery exchanger's effect, computing the mixed-air temperature and moisture. Because mixing combined with HRS is complex (variable efficiency, freezing, finding the mixing point under enthalpy control), the function applies defined simplifications. It calls the PHE function internally.
Supply and exhaust fans (Function 13). Computes each fan's electric power input and the air temperature rise it causes, for the hour's actual airflow and defined operating points. It accounts for motor type (AC / EC / PM), variable-speed-drive part-load behaviour, and whether the cooling coil is running wet or dry — wet operation raises the pressure drop and so the fan power.
The complete end-to-end calculation. It assembles a full AHU specification, a configuration (1 of 22), a heat-recovery type, climate data for a chosen location, an operating schedule, setpoint scenarios and economic parameters, then runs the 8760-hour degree-hour loop. The output is the annual electricity, heating, cooling and water consumption, converted by discounting into the Life Cycle Cost — the net present value of the investment cost, the annual energy and water running costs, and the end-of-life cost over the unit's lifetime.
This demo is not available yet. Estimated release date for the demo is June-August 2026.
This demo is not available yet. Estimated release date for the demo is Q4 2026.
This demo is not available yet. Estimated release date for the demo is Q1-Q2 2027.
Get in touch — Have a question or a project you'd like to discuss? Drop us a message and we'll be in touch shortly.
+358 40 537 5158
MGNA Oy, Lemminkäisenkatu 14-18 B, 20520 Turku, Finland