Portfolio

Accumulator Cooling: Ducting Design and CFD

Monash Motorsport · Senior Aerodynamics Engineer, Head of Cooling subsection · Ansys Fluent 25R1, PyFluent, M3 MASSIVE HPC · 2026

Why are we Cooling?

The M26 accumulator for the 2026 Monash Motorsport car is a 120s1p, 6.38 kWh air-cooled pack. The problem is that the cooling configuration presented in January has poor flow management and no consideration of airflow at the vehicle level. My solution for the project aims to develop a more vehicle-flow-focused cooling system, reducing the overall accumulator temperatures without impacting the overall vehicle-flow and integration.

Cooling exists so the pack is able to run a full endurance duty cycle at a reduced capacity. PACSIM simulations showed a 4.8 kWh pack is able to match the endurance performance of a 9.4kg heavier uncooled pack. Following 2026 points sensitivities, it was estimated that a reduction in mass by 9.4 kg provided a competition points gain of 20.57, a high sensitivity parameter vital for overall car performance.

Developing the Ducting

Airflow has to be brought into the accumulator from somewhere, and through preliminary simulations, the ducting was competing for air volume from the side diffuser and undertray, which are aerodynamically very costly parts. The side diffuser CLA dropped from 1.369 to 0.963, and the undertray dropped from 0.980 to 0.686, compared with a regular sealed duct reference case.

Following more targeted design iterations, a “sidepod” esque external duct was investigated, inspired by the ground-effect era Formula 1 cars. This proved to be a vital stepping stone in solving the CLA drop, pushing it to an overall 5.174, from a costly 4.406 in the sealed duct case. The aerodynamic balance of the car also shifted from 48.8% to 50%, an overall benefit there as well. The sidepod also contains angled louvres towards the bottom, providing a water ingress concern solution.

Investigating the external ducts, studies were done on the positioning of the inlet hole, inlet hole and other performance enhancers. Investigating the overall inlet positioning in the x direction was a key factor in maximising the flow into and through the accumulator.

Another concern, brought up during design reviews was water ingress into the accumulator. To account for this 2 options were looked into, a waterproof mesh and louvres. Physically speaking if there was no airflow impact the waterproof mesh was the most viable option. Ordering a waterproof mesh and conducting some tests in an wind-tunnel esque set-up below showed to block approximately 85-90% of the airflow, proving the mesh to be infeasible.

The louvres were looked at from then onwards at the bottom of the sidepod design. Taking 3 louvres with dimensions 50mm x 100mm. Provided the best water pathway per preliminary testing. During investigation of the louvres, a sweep of various angles with reference to the original positioning was conducted, unfortunately during the sweep the 12 degree angled louvre failed during the mesh process. However the following results were gathered. Noting the results as the louvre angle increased the mass flow into the monocoque did decrease, however very minimally. On the opposite end the CLA did increase through air leaking onto the side diffuser and consequently into the undertray. Taking both factors into consideration the CLA benefit overrode the overall mass flow deficit due to it being so small and thus a louvre angle of 15 degrees.

Vortex generators were a final late addition onto the external ducts, for 2 reasons generating high energy vortices to reduce air flow separation in the ducts, since water being more dense than air pushing the air upwards while the water would leak down through the louvres with gravity.

In parallel with these external ducts, internal ducting from the monocoque to the accumulator and from the accumulator outletting through the rear bulkhead were developed. In tandem with the external ducts, the key indicators of a good design were maximising the mass flow of air entering the accumulator and the overall uniformity of the velocity. Why? The mass flow is a key indicator of the volume of air being pushed through; the higher the mass flow, the greater the heat rejection available, bounded by what the fan can deliver. The uniformity is a scale from 0-1 showing how the velocity varies over a surface, with a value of 1 indicating perfectly uniform velocity over a surface, with lower values increasing the variation in velocity, using an area-weighted uniformity. By comparing these 2 metrics from the monocoque internal hole to the entrance of the accumulator, we were able to identify how the changes in ducting design impacted the hypothesised cooling performance.

The design of the internal ducting had a reverse ducting system due to the entrance of the accumulator being further forward than the monocoque internal wall. To account for any energy losses in the air that might occur, an investigation into turning vanes was conducted, improving the overall airflow uniformity and mass flow of the air entering the accumulator.

CFD Simulation Set-Up

The CFD simulation was conducted using a half-car symmetry model, taking into account ground effect and rotating wheels. The cooling pipeline, in particular, treated the accumulator as a container with segments split into the cell tabs and overall cells. The monocoque was hollowed out to account for any internal flow that may occur while unlikely in a sealed ducting system. A pressure-jump fan boundary condition was applied to the radiator and rear bulkhead fans, with a realizable k-epsilon with enhanced wall treatment turbulence model being used. Convergence was driven via report monitors on CLA & CDA, using PRESTO! for pressure interpolation, pseudo-transient continuation, and a velocity inlet specified by 5% intensity and a viscosity ratio of 10.

The final mesh contained 35.5M cells, with a skewness of 5.54E-11 and an orthogonal quality of 0.94. During the course of the campaign, multiple mesh debugs were taken into consideration through various self-intersection methods when defining fans and ensuring interior zones were properly defined to solve the fans.

Summary of Project

Over the course of the project, 94 design runs were completed, averaging approximately 5 hours per run. The mass flow rate through the accumulator was recorded at 0.021 kg/s, a massive improvement over the previously presented 0.008 kg/s, and a velocity uniformity of 0.943. Furthermore, the CLA had increased by 0.768, with the centre of pressure of the car moving from 48.8% to 50% from initial cooling runs. Current work focuses on manufacturing the ducts and finalising the thermal values, a direct measure of the work.

Scope: the thermal resistance modelling and cooling-method trade study (cell body vs tab vs PCM) were produced by teammates in the electrical powertrain group, and the mesh independence study by a peer. My contribution was the duct design, the CFD setup and boundary conditions, and the meshing and solver debugging.

Building Cooling into the CFD workflow

Monash Motorsport · Ansys Fluent 25R1, PyFluent, SLURM, M3 MASSIVE cluster · 2026

What didn’t exist

To conduct Project 01 a workflow containing the fans, thermal simulation and accumulator ducting was required to run design iterations. The existing TUI workflow had none of it. Any cooling decision was therefore impossible to quantify, either thermally or in terms of its overall impact on the car. This project built that capability: an automated, integrated cooling CFD workflow able to quantify cooling decisions and support design iteration.

Defining the fan boundary condition

The fan boundary condition was an unknown region being explored for the first time, so understanding how Fluent handles it was the starting point. Testing on isolated block fan models established the requirement: for a fan boundary condition to be applied to a face, cells must exist both in front of and behind that face.

Simple in theory, difficult in practice. Once geometry is imported, our pipeline completes the surface mesh through a “wrap”, an arbitrarily large blanket laid over the geometry at a set drapeability index to define its edges. A material point placed somewhere in the domain then grows volume cells outwards, stopping when it reaches the wrapped surface. The problem this creates is that when growth reaches a solid such as a fan cylinder, no volume cells are defined behind the fan face, so the boundary condition cannot be applied.

Fix 1: The Infinitely Thin Face

The first attempt modelled the fan face as an infinitely thin circle. In theory this is exactly right: with no thickness, cells should propagate both in front of and behind the face, allowing the boundary condition to be placed on it. The theory held as cells were defined on both sides; but the same property that made it work was its downfall. The cells in front and behind overlapped and intersected one another. Tetrahedral initialisation failed, followed by a segmentation fault. A topological error, and not worth pursuing further.

Fix 2: Material Points Inside the Fan

The second attempt modelled the fan as a 3D solid, the obvious choice being a cylinder. By convention the face toward the front of the car is the fan face, and the rearward face the fan outlet. Since a material point grows volume cells outwards until it meets a wall defined by the wrap, defining an additional material point inside the fan cylinder should generate the cells needed to define the boundary condition. The process was to find the coordinate at the centre of the fan cylinder, let Fluent convert it through the applied vehicle attitudes, and define the material point there.

In initial trials some fans defined correctly and others did not. Comparing the coordinates Fluent recorded after the attitude definitions against hand-calculated values gave the deviations in Table 1, and several fans show significant discrepancies; the hypothesised reason the material points were not performing their function. Refining the mesh around the region and increasing the drapeability of the wrap were both tested, to no avail. This fix did not work.

Table 1: Deviation between Fluent-recorded and hand-calculated material point coordinates [mm]

	x	y	z
Rad fan	0.269	0.000	−0.147
Akku fan 1	−2.236	0.100	−0.236
Akku fan 2	−2.036	0.000	−0.336
Akku fan 3	−2.136	0.000	−0.336
RBH fan	−9.918	−0.300	0.075

<0.1 0.1–0.5 0.5–2 2–5 >5

From these deviations the most troubled section was the RBH fan an almost 10mm deviation in the x-direction. This error was incredibly difficult to diagnose, with the solution to leave it and find a different fix. While this wasn't the ideal path to follow due to the rigorous time constraint set to solve this issue, it was the only option to move forward with the project. The next fix was to step back and look at the problem from a different perspective.

Fix 3: Two Wraps

The third attempt stepped back from the problem. Rather than taking the CFD architecture as given and adding to it, I looked at adjusting the architecture itself: instead of one wrap over the geometry, use two. The first wrap includes all geometry as normal, defining the exterior of the fan cylinder. The second includes all geometry except the fans, which leaves their interiors open. When the volume mesh grows, the interior of each fan is now defined, and the boundary condition can be applied.

With this fix the fan boundary conditions could be defined, the solving sequence proceeded, and mass flow values and the overall impact of cooling design runs on car flow became quantifiable for the first time.

Applying the Fan Curve

In Fluent the fan boundary condition is defined through a fan curve defined as static pressure against volumetric airflow, describing how much air the fan can move at varying levels of resistance. As resistance rises, deliverable airflow falls.

During testing, setting the fans to their full operating point immediately diverged the solution. Staging the fans over the course of the run prevented the divergence without affecting the continuity of the solution.

Migrating to PyFluent

Mid-year the team began migrating the existing TUI workflow to PyFluent. Hosting it on GitHub gave version-controlled files that could be safely saved, reviewed and merged. PyFluent also allowed individual CAD imports with individually defined scoped sizing and BOIs, where previously a group import was done with general scoped sizing and BOIs applied across it. The change had no significant impact on the SLURM files beyond requiring a virtual environment to host the PyFluent modules.

My role was implementing the proven TUI cooling workflow into the PyFluent workflow being built. This allowed further mesh optimisation in specific regions, refining the accumulator while not over-refining regions that did not need it. Once merged, runtime fell by 54%.

I also added unit tests, tailored to the errors I had personally hit when making code changes and only discovering the problem late into a run, losing all progress. 22 tests run in around 0.40 seconds and catch those failures before a case is submitted.

Post-processing

All of this is useless without being able to visualise and quantify the impact of a design run. The existing pipeline included a working ParaView model generating video contour sweeps for CpT and other parameters. CpT is the coefficient of total pressure which is a measure of the energy in the air, the sum of dynamic and static pressure, or the kinetic and potential energies respectively. It is what you manipulate to guide duct flow and generate downforce. I adapted the script to produce sweeps including the hollowed monocoque and the ducting system, which the cooling design runs depended on.

Two regions needed closer inspection than a full-car sweep gives: the entrance to the monocoque and the entrance to the accumulator. The monocoque inlet flow follows directly from the external duct geometry and sets a ceiling on what can enter the accumulator. The accumulator inlet is the last look at the air before it begins cooling the cells. The aim was to maximise monocoque inlet flow and minimise losses between the two, keeping the contours as similar as possible.

To do this I defined planes in Fluent via attitude-transformed CAD coordinates, exporting key parameters to CSV. A MATLAB script then filters the data, orders it by coordinate, and maps it onto a contour plot with a fixed colour map so cases are directly comparable. The parameters of interest were velocity and CpT. The same planes provide the mass flow and uniformity values used throughout Project 01. This script proved vital during design runs, allowing duct performance to be compared at a local scale rather than the whole-car scale the ParaView sweeps give.

Scope: the PyFluent migration was a team effort, with my contribution the cooling sections and the integration of the existing TUI cooling workflow. The fan boundary condition work, the cooling architecture, the unit tests and the MATLAB post-processing are my own.

Australian Centre for Sports Aerodynamics: CFD Validation

Monash Motorsport · Ansys Fluent 25R1, PyFluent, SLURM, M3 MASSIVE cluster · 2026

Wind Tunnel Testing

Earlier this year the aerodynamics department attended the Australian Centre for Sports Aerodynamics in Adelaide with our 2024 and 2025 car for a week. The purpose of this testing session was to validate our current CFD and turbulence modelling settings in conjunction with one of our FYP groups and bringing 2 cars to establish geometric independence with the CFD model. Why does a tunnel allow this? Through real life on-track testing similar tests can be conducted within similar attitudes to what is being simulated, with the addition of various uncontrollable variables that can skew results. Examples of these variables being weather, track conditions, and so many more that the use of a wind tunnel eliminates providing a significantly more controlled environment.

Pre-Wind Tunnel Preparation

I helped manufacture a required tapped wing set in particular the front wing, rear wing, & keel step. The overall manufacturing was similar to what I had done previously, identical layup methods; the only difference being drilling holes as required in high interest CpT zones and then hot gluing air flow tubes into said holes to connect to custom Dynamic Pressure Measurement Systems (DPMS) boxes developed by the FYP group, and validated in a smaller wind tunnel available at the university. This was jigged onto the car in preparation for the wind tunnel.

Further I helped develop MATLAB scripts in 2 major areas. The first one focused on looking at ideal locations to place wool tufts, in particular identifying high velocity, swirling and low pressure locations based on post processing data to visually identify and validate hypotheses in the flow structure noted in our then current CFD model. The second script again taking into account various flow structures created an automated transverse probe movement behind the rear wing, movement done by an actuated system available from the wind tunnel. The transverse probe was key in getting values behind the rear wing at various yaw angles and wind speeds.

Testing at the Wind Tunnel

The tests conducted varied, with the first test being a baseline with all aerodynamic devices removed and incrementally added on over various wind tunnel speeds, and yaw angles. Further tests were run with DRS open, closed cockpit tests and with the various tapped devices. A similar test was run with the 2024 car and in conjunction with Adelaide FSAE team AUMT, on the final day due to having extra time and to trade geometry. The tunnel did have blockage which was accounted for via CFD and the ground plane treated using a false floor made to account for any boundary layer generation that may occur and to avoid that. Limitations included no moving ground plane making it hard to measure true rolling road, the load cells within the tunnel limited the tunnel to 12 degrees yaw and a maximum wind speed of 19 m/s, with the tunnel containing a blockage ratio of 28% where it is recommended to have 5%.

Post-Wind Tunnel Analysis

Overall downforce repeatability was within 2% over multiple days which was key providing consistent results to compare with. Within the current CFD model there was 14% increase in CLA compared to wind tunnel data which was consistent over the overall yaw sweeping range; providing a performance positive, however in terms of CFD correlation is something to be analysed more. Between the 2024 and 2025 cars the CDA a 0 degrees yaw was exactly the same which was extremely interesting to note considering the geometry difference between the 2.

The CFD model was over-estimating drag reduction in comparison to wind tunnel data, with the tunnel showing a 33% drag reduction in the 2025 car with all aerodynamic devices and DRS on & off tests, whereas the CFD model noted a 42% decrease.

Overall improvements made to the current CFD model, in particular looking at moving from a closed wheel CFD model to an open wheel CFD model. This was not done previously due to the increase in computational time however with further discussed changes the script was optimised to allow quicker meshing and run time. The turbulence model is to be switched from the long-standing used k-epsilon model to k-omega SST. Further y-plus targets switched from more than 20 to aiming for a y-plus less than 5. Overall lift force accuracy went from a 23% discrepancy to approximately 10%, averaged over the yaw sweep. As the FYP is still running more data is to be collected and understood to further optimise the CFD model but there have been significant improvements as of now.