iRacing – Dynamic Track Model in Progress

Dan Garrison, Senior Software Engineer with iRacing, was on the most recent episode of the iRacing’s podcast, iRacing Downshift.

https://twitter.com/iRacing/status/1162016677049110529

Dan wrote an awesome and complete post discussing some of the science/math that goes into the next Dynamic Track Model and how it will be evolving.

“My name is Dan Garrison, and I am a Senior Software Engineer with iRacing. I was recently on the iRacing Downshift weekly podcast discussing some exciting changes coming to the dynamic track model. The feedback has been great, and I wanted to take a few moments to follow up with more detail. For those who are interested in the more technical aspects of how the sim works, I hope you find the following discussion enjoyable!

The initial implementation of the dynamic track model featured the server maintaining surface temperatures all over the racetrack, and sending this information to the clients. Temperature from one spot to another would vary according to things like the albedo of the surface, the orientation of the surface with respect to the sun, the intensity of solar radiation as a function of the solar elevation angle, shadows, clouds, and finally from the influence of cars. Areas of inactivity in the shadow would be cool, areas in the sun would be warm, and anywhere cars were dumping heat from engines and tires would warm up further. This gave us a model that would actively respond to many of the real-life factors that one would encounter, and provide a range of conditions to deal with as a race engineer and/or driver.

When the dynamic track was first released, the weather in the sim was rather static: air temperature and wind might shift a little if the settings allowed such, but the sun did not move and neither did the clouds. This meant that it was possible to calculate the equilibrium temperature of an area on the ground, as it was simply that temperature which created a perfect balance of solar energy being added and the energy lost by conduction and convection. Since the weather was known and the sky was static, if no one was driving on the track the temperatures would remain essentially unchanged save for some small changes that would roughly correspond to changes in the ambient air temperature.

Once the sun and the clouds started moving, however, one of the major shortcomings of this model became apparent: namely, that the server only kept track of the temperature on the top surface. As a result, as the sun sets or if a cloud comes by, the track temperature cooled rapidly with the incoming solar energy gone. Fluctuation in the rate of heat loss was introduced, as a function of time of year and time of day, to try to account for what would be happening under the surface. However it was a rough approximation of what was really going on, and the overall variation in the cooling rate was kept relatively small in order to avoid strange behavior.

The new implementation of the dynamic track addresses this by maintaining temperature in multiple layers under the ground, which means that the surface temperature will behave more realistically. With the new model, heat that is stored in the layers below from hours of sunlight will work its way back up and warm the surface. Similarly, built-up heat from cars will last longer if a lot of laps have been driven instead of just a handful. The end result compared to the original model is that temperatures will typically be cooler in the morning and early afternoon, but warmer in the late afternoon. But in general the multi-layer approach will stabilize the temperature on the surface to some degree, in that it will change more slowly in most circumstances.

Put another way, the layers allow a realistic recording of history that the old model simply could not reflect. Think especially about a hot day that has a hint of a late-afternoon monsoon that is only a very short, mild rain shower: in the old model, the track temperature would have plummeted and stayed cold, even after all the water was gone. With the new model, the heat that was stored in the lower layers beforehand can slowly return to the surface and allow it to regain some of the lost temperature, even if the skies stay cloudy. In fact it was working through this type of scenario that motivated the update to the dynamic track model.

One of the problems that must to be solved in this approach is the initialization of the temperature in the various layers. If the layers are set up incorrectly, temperature at the surface will drift and fluctuate unrealistically until things eventually settle towards the correct temperatures. To handle this, the server creates a number of samples for each type of material found at the track, and uses an empirical formula to estimate the temperature in each layer that takes into account time of year, the thermal conductivity of the material, and the depth of each sample point where temperature is being tracked. It then goes one step further, and simulates the weather for a few days before the event actually starts, updating the temperature profile of each sample. This ensures that the layers will be at the proper temperatures given the conditions and will behave correctly once the first session starts.

It then continues to move forward in time and periodically storing additional data points, so that any additional sessions that start after a delay will also begin with appropriate temperatures at all depths. If an event has a two-hour practice scheduled in the morning, qualifying that afternoon and a race the following day, the temperature model will handle that because it has run the weather and modeled the changes already. When a session starts and a piece of the ground needs to know its initial set of temperatures, it finds the data for its material type and the current time, and uses its orientation on the ground to choose and interpolate between a few saved samples.

This helps address a second shortcoming of the original model that became apparent with the moving sky: at the start of a session, if a fair amount of time had elapsed since the end of the previous one, the server simply looked at the amount of solar energy coming in at that time in order to calculate the starting temperature. If the sun was behind a cloud, it did not attempt to guess at how long or how often it had been behind the cloud, nor did it simulate the conditions leading up to the session. As such, in this case the track would usually start off unrealistically cool, as if the cloud was there all day. In the new model, if the sun was out most of the time leading up to that moment, that will be captured and the track will still be hot but cooling off.

The new model also features a much better interaction between water and temperature, as the evaporation and removal of heat from that process is calculated more accurately than before. A dirt track in constant shade, perhaps say in Oklahoma, will typically have a track temperature below that of the surrounding air because of the heat lost due to evaporation. Of course the rate of evaporation varies depending upon the temperature of the surface and the air, the humidity, the wind, and the availability of “free” water at the surface. On a chilly, humid, windless day you would expect the track temperature to be close to the air temp, while on a hot, dry, windy day you might expect several degrees of difference between the air and the ground. The upgrade to the dynamic track provides this behavior as a natural consequence of the improved evaporation model.

Although these changes to the track model are inspired by the anticipation of rain in the sim, hopefully it is clear that the update is beneficial across the board. By modeling heat transfer between the surface and the ground beneath, the reaction of the track temperature due to different events is influenced by what has already occurred. As such, the surface temperature may be relatively persistent or variable depending upon the history that is essentially stored in the layers below. Finally, by running the weather forward during initialization and recording the results, the server is better prepared to handle session transitions that can include large gaps in time and start the track in the appropriate state.”