Posted by: drracing | October 21, 2016

Setup optimization at the Simulator and 24H Race Technology article

It is always the same story: I always promise myself I will post more often here but the time is always playing against me!

Again a long time since my last post, so I thought I could maybe write some updates about my latest projects and some of the things I have done during the last months.

First of all, I am extremely glad to say that, as it happened in 2015, an article I wrote will be published in the “24H Race Technology” magazine this year too. As for my latest post here, it will cover some performance studies I did with the simulator about LMP1-L cars. I hope many of you will have a chance to read it without getting too bored!

Beside this, I was pretty busy lately, both on fun (technical) and private side. I moved into a new apartment, this meaning that for a certain time I could not really access my pc freely and all the simulation work had to stop. Anyway, the new apartment offers me a new room for my simulation hardware, this meaning I could even post some videos sometime in the future because I know have some space for some interesting upgrades and I should be able to have something to show on video without having to shame myself!
Luckily, before I moved, I had some time to both perform the simulations required for the above mentioned article and to support an LMP2 team I came into contact during the season.

The latter has really been a very interesting task, first of all because these cars are really amazing pieces of engineering and show some incredible performance, but also because a new project always means coming into contact with new data, acquiring new knowledge, experience and new perspectives even when looking to known problems.
What made this project even more interesting though is that, for the first time, I was involved in a study only and exclusively focused on setup optimization.
As you may know, I worked already on other LMP2 cars during the last two years, but the whole work was always focused on creating something mainly aimed to driver training. This doesn’t mean that the previous projects had no interest from an engineering perspective or that the modeling had been approached differently, since the goal is always creating a model that performs as close as possible to the real vehicle.
This basically means following some basic, important steps:

  1. analyzing the available car data
  2. creating a vehicle model that matches these data as good as possible
  3. validating the model against track logged data to be sure there are no unexpected differences
  4. using the model for training (or other) purposes

This is exactly the same thing I did this time too. What was substantially different was mainly how the fourth point of the above list was tackled, since the final goal was to help the team to improve their setup and, finally, their lap times.

Before we go on describing shortly how the project has been run and the results we obtained, I would like to focus the attention on what I consider an extremely interesting point.
As you may know, the software I currently use for this kind of projects is rFactor, since I think that its physics is still among the best available on the market in this price range.
Since some time, looking to the matching between simulation results and logged data I achieved, I started thinking that actually, up to a certain point, it must be possible to use a “simple” software like rFactor (which actually is not that simple) to perform more “engineering related” simulations, more or less what an engineer could need to improve, at least directionally, its car’s setup.
Of course, as we said thousands times, such a software have some limitations, mainly connected to rFactor being still a cheap product, which must have a much lower complexity than professional programs like the ones used by OEMs or big teams (which also require a completely different computing power); this very expensive tools surely offer much more flexibility also in terms of igniting subsystem models built up in external environment.
As I briefly mentioned in some previous articles, there are some areas where the user must be careful in order to get accurate results (see, for example, setting suspension geometry and angles, like camber and caster, or the way some strongly non-linear devices like the bump stops are modeled).
Some of these limitations can be overcome, knowing how the software works and how certain things are calculated. Paying attention to some aspects, it is possible to achieve extremely low errors, both when comparing vehicle data during the modeling phase (like tire forces and stiffness, aeromaps, suspension kinematics, etc) and when checking simulation results against real logged data.

Having the chance to use a commercial software like rFactor to perform engineering work opens to a different approach when using “home” driving simulation.
Of course, there is still a point in running multimillion simulators with extremely complex (and heavy) software and models and I am in no way saying that all of this can be simply exchanged for a much easier tool. On the other hand, it is now clear to me that, even for people/teams not able to access the expensive and complex tools that big teams have, there is still room to run productive simulator sessions with the aim to also better understand how the car works and where it can be improved.
In general there are still some phenomenon which are extremely complex if not impossible to simulate properly, mainly because there are no real data about them (see for example how much tire behavior change for a certain temperature variation, or how much aerodynamic properties change with roll angle) and conditions which are nearly impossible to replicate (we discussed already, for example, how much track conditions could change during a weekend, depending on different factors; different cars running on the track during the same day could even change the ideal driving line from one day to another). Experience surely help to replicate all these aspects in a realistic way, but perfection, of course, doesn’t exist and there is always a point behind the team being ready to do more or less everything to have more track time.
A simulator will always be a simulator, not the real thing. But being able to understand and to investigate how certain things work and (maybe more important) why something happens can be a really exciting and useful experience, at any level.

Something that further confirmed that driving simulation (even in our “simple form”) can still be an extremely useful tool even from an engineering perspective has come to me last May, in Spa, during the WEC race weekend, where I had the chance to speak to the drivers of Strakka (LMP2 team running a Gibson car in WEC this year). Strakka runs a professional simulator and they are also using rFactor (as far as I know). The simulator is mainly used by the team for his own programs (they have also cars running in the Formula Renault 2000 and in the Formula Renault 3.5 V8 series), but is also hired to private customers from time to time.
Strakka drivers confirmed to me that they not only use the simulator to evaluate setup solutions before a race weekend or a test, but also rerun the solutions they found on the track at the simulator after event, to double check them and further confirm that they went in the right direction (the simulator offers a “disturbance free” environment for testing). Moreover, a certain setup setting can thus be evaluated more in details, also looking to the effects they have on parameters that would be hard to measure and trace at the racetrack. Again, it could be an invaluable help to understand not only what happens but also why.

Of course, in order to use the simulator for setup investigations, it is even more important to have an accurate and reliable model that produces realistic results. This point cannot be stressed enough. Accurate data are key for whatever simulation, doesn’t matter if it is run on a driving simulator or with other tools.
The good thing is that building up a vehicle model and running simulation can sometimes also be a way to better understand your car and your data, even when they are affected by any sort of flaw. Sometimes, comparing simulation results with real data is the best way to identify measurements inaccuracies, or the areas where the model or the available car data could be wrong.

The project I was involved with has actually started with a study mainly related to tire data analysis, to try to understand why what was working pretty well in 2015, was not doing the same in 2016.
Analyzing purely the tire data (so ignoring a lot of other issues also connected to tires, see for example their thermal behavior and assuming the tire data were telling the truth!), was immediately evident how much different they were behaving compared to 2015 and the balance upset they could produce on the car. Even only looking to the vertical stiffness, it was already possible to identify some of the required setup changes needed to try to compensate for the different characteristics and come dynamically to similar ride heights.
We already pointed out in other articles how important ride heights are for LMP cars and how the ride heights sensitivity is for overall downforce and balance. So it is immediately evident how important even a basic chance, like the tire vertical stiffness, can be on cars final performance.

Anyway, a deeper look to the Pacejka coefficients set and to the relative plots was enlightening to understand where and how car’s balance and behavior could have changed and which performance differences to expect.
Above all at the front, 2016 tires were producing completely different friction levels and trends compared to the 2015 ones.
The team I worked with was somehow hit by these changes and wanted to confirm what they saw on the track through data analysis with some simulation.

As described in the list above, the first step has been going through all the available data and creating a vehicle model as accurate as possible. Of course, the validation phase has also played a central role about this, above all to be sure about how much exactly the tire forces needed to be scaled down to obtain realistic performance. Luckily enough, previous experiences came to help and the results were very close to the real car already at the first attempt, as confirmed comparing real and simulated data (here in Imola).


The light blue trace refers to the real car, while the orange one is the simulated one. Not too much effort was spent to fix the small difference in top speed (probably a small flaw on drag data, to go back to what we discussed above and an example of a situation where, simulating, you could spot an error on the provided car information compared to the real car logged data), since this particular issue was not going to influence how useful this study could be. Anyway, I still think that this graph confirms once more how close you can get in terms of vehicle performance to the real thing using rFactor and a good vehicle model.

Once the validation phase was over and matching between real and virtual vehicle was acceptable, I started working on the setup. The approach agreed with the team was for me to know nearly nothing about how they were setting the car, not to be influenced in anyway on the direction to be taken.
Basing also on my previous experience, I set up the car at first “on paper” (or, better said, in excel!), using some reference metrics like the roll gradient, Lateral Load Transfer Distribution, dynamic ride heights, corner and axle natural frequencies and targeting from the beginning values that, based on previous experience and on the analysis of the available data, I would expect to work.
For some “non-linear influenced” parameters, like ride heights, I did some checks calculating the load I would expect during certain maneuvers, evaluating the dynamic ride heights basing on these loads and using a certain setting for each subsystem (in this case, for example, springs, bump stops, static ride heights, etc). This allowed to also have a basic settings for parameters like the bump stops and their free gaps.

Once the car finally hit the track (or, better, the vehicle model was driven on the virtual track) the work I did was pretty much similar to the one of a “normal” race engineer, basically running sessions, evaluating logged data and driver feedback, trying to understand which areas could be improved or, simply, which differences there were between a session and another and, based on the conclusions I came to, finding and testing new solutions. And then repeat again and again, till the time I had at my disposal was over!
The interesting thing about doing something similar with a simulator is that you have perfectly repeatable conditions (track conditions, track temperatures, tires wear, engine power, atmospheric conditions, etc), so you can potentially really isolate the effect of each change on the car-driver package performance. Another important point is, of course, that, if time allows, you can test a lot of solutions and do as many back-to-back tests as you want, without having to pay anything or without having to explain to your boss about why you are testing the same thing again!
Since a driver is a human being (even professional ones) back to back tests can sometimes be a good idea to isolate driver’s effect on final performance and understand if a certain setup modification has really produced an improvement and why. It is also good to remember that race cars (and an LMP2 car in particular) are complex systems, where each parameter could potentially influence also many others. This means, it could well happen that a certain change produces a different consequence when married with a certain base setup than what it would do starting from another basic setup. Another good reason to do back-to-back tests is thus to really understand if a certain final solution, where we came after many small changes is really our optimum or not.
And now, we could start a philosophical discussion to decide if an optimum really exists, but I will avoid it.

The simulation work has focused on nearly every area of the setup, excluding the aerodynamics hardware settings (like wing angle, for example) which was basically taken as an input. The reason behind this is that the team already had a chance to perform its own evaluation and simulation (mainly lap time simulations) to define the best aero solution for the track they would be going to race in.
Effectively, saying I didn’t work on the aerodynamics at all would anyway not be true, since some mechanical settings have an influence on other parameters which directly define how much downforce and drag and which balance you have (see ride heights, for example).
Areas where we particularly focused were vertical stiffness (both in terms of corner springs and third elements, with particular focus also on the bump stop), dynamic ride heights, roll stiffness and total lateral load transfer distribution and differential settings.
There have been initially an “adaptation time” for the driver to find the most effective way of driving the car on the chosen track. As every driver probably knows, “practice makes perfect”, thus meaning that actually, nearly every driver would probably continuously improve him/herself for the whole time he/she goes on driving on the same track with the same car, but normally this happens at the beginning at a substantially higher rate than after some track time, thus allowing us to assume that after a certain practice time (its length depends strongly on driver’s skills and experience), if we log an improvement on the lap times following a setup change, that should be really a result of the car-driver package achieving a better performance and not only of the driver improving his technique.

As a side note about this point, it is worth to say that, sometimes, a setup making theoretically the overall car performance envelope bigger (see, producing better laptimes in a lap time simulation) could even not be the one achieving the best performance with the driver in the loop. This happens more often with non-professional drivers than with professional ones, but could also be the case with very expert ones. These situations are exactly the ones that make having access to driving simulation (even if in a “simplified” form, as in our case) even more useful.

I will not go through every setup change we tested, since it would take too much time and too much space. But I would like to focus on some specific corners and just one setup modification, to show the effects of a certain change on car behavior, driving style and overall performance.

I will try to keep it simple and just analyze the effect of a change on the rear roll stiffness, with a difference between the two cases of 17% of the rear antiroll bar stiffness contribution (this meaning that, in our second case, the rear antiroll bar has 1.17 times the stiffness it has in case 1). This is just a very simple case which doesn’t actually show the full potential I have seen and, more important, the parameters influencing the final performance the most, but I think it is still useful to identify if and how to obtain some setup related results (even at our “easy” level) and which intricacies could come from such a simple setup change in a complex car like an LMP2.
The final lap time gap between the two setups was around 2 tenths (the stiffer being the quicker); nonetheless, as we are going to see, some corners show very different performance and some handling surprises.

The first track section on which we will focus is a slow corner, driven in second gear, which is located at the end of a straight where the car travels downhill. In this turn, the car normally exhibits understeer, above all in corner entry.
The advantage of the stiffer rear antiroll bar here is immediately clear looking at the speed trace.


In the above picture and in the following ones, the red trace refers always to the softer rear antiroll bar setup, while the blue one always to the stiffer one.
As we may immediately see, the advantages brought by the stiffer setups are here evident: the driver is able to hit the brakes a tiny bit later, let the car turn in more easily, thus having a higher minimum corner speed and still being able to go on the throttle a bit easier.
The steering trace confirms that the car has better balance, with less understeer in corner entry and at the apex. Namely, the steering angle is smaller, still being the cornering speed higher, as we saw.


Looking at the corner exit, we can also notice a very small steering correction, underlining how the car tends to now have even some on-power oversteer in corner exit. In this particular event, hitting a curb in corner exit was also destabilizing the rear end of the vehicle a bit.
Also the throttle trace, here below, seems to confirm what we saw. The driver get away from the throttle a bit later coming to the braking zone and goes again on the throttle a tiny bit before, with only a small hesitation at the same instant when the steering correction takes place.


On a more technical side, it is interesting to take a look at how the front and rear roll (here calculated as a difference in mm between left and rear wheel travel) changed because of our setup modification.
Looking at the Front Roll trace, we see a small difference, practically only driven by the overall roll stiffness being changed because of the different rear antiroll bar setting.


At the rear the difference is more evident:


Regarding the roll angle, it is worth to mention that the simulations don’t consider any chassis flexibility and all the components are simulated as ideally stiff.

Let’s now take a look at what happens in two left, mid speed corners, one following another and with cornering speeds in the 140-170 km/h range.
In this case, the softer roll antiroll bar (red trace) seems to work better, with the driver carrying more speed inside both of the two corners.


The difference seems to be even more accentuated in the second turn, where the driver even brakes a bit later and with less energy, carrying more speed during the complete corner duration.
In the first one, which is the slower one between the two, we see the stiffer rear setting producing an effect somehow similar to what shown in the previous example in corner entry, with the driver being able to brake later; but here it happens at the cost of a lower apex speed.
In the second corner, as we mentioned, the driver seems to simply have more confidence (as per his subjective feedback) and/or grip with the lower roll stiffness setup, being able to brake later, decelerate less and carry more speed.
In general, the lower rear roll stiffness solution seems to work much better in these two corners, improving significantly driver’s confidence and overall performance.
The steering trace, anyway, reserves some surprises: we would expect the driver using a lower steering angle with the stiffer antiroll bar, confirming a less understeering tendency. But actually the steering angle doesn’t differ too much in its magnitude between the two cases, with actually the softer bar setup showing a slightly lower steering angle in both corners.
This seems to show a car with a less pronounced understeer in these two corners when using the lower rear antiroll bar stiffness setup. How is it possible?
This is confirmed by the following picture too, showing a channel I always use as a kind of “understeer-oversteer index” and which compares the actual steering angle to the ideal one, normalizing the difference between the two on lateral acceleration. When this channel is positive, we have “understeer” (or, anyway, a steering angle bigger than the ideal one).


All what we see here seems to go against what we would theoretically expect, when reducing the rear axle roll stiffness (namely, more understeer because of a more front biased Lateral Load Transfer Distribution).
The reason for this is probably to search in the higher speed that the driver carries into the corner with the softer rear antiroll bar, as a consequence of “trusting” the car more: this means, among other things, more downforce (ignoring how much downforce changes with ride heights, more speed means normally more downforce, as aero loads depend on the square of speed) and, because of different dynamic ride heights, a slightly different Aero balance (downforce distribution between front and rear axle), as shown in the following picture (where we show the front downforce distribution as a ratio between front vertical loads and overall vertical loads: higher values mean an higher portion of downforce acting on the front axle). Please focus your attention on the areas highlighted by the green circles, since these are the points corresponding, more or less, to the two corners apexes.


Beside this, the driver is also driving slightly differently, as we may see not only looking to the braking points and to the steering trace, but also to the instant cornering radius of the path he is traveling on:


Above all in the first corner, it is evident how the cornering radius reduces quicker and a bit before with the lower rear antiroll bar stiffness setup. This means the driver closes the line, pointing the car to the apex, a bit before, than with the stiffer solution. As a consequence, he tends to release the car a bit before, leaving it sliding toward the outside of the corner.
As a sanity check, the two pictures below depict the front and rear roll respectively, calculated, as already explained, as the difference between left and right wheel travel.



As we already saw analyzing the previous corner, both plots show an higher roll angle in the “lower stiffness” case, as we would expect, with the difference between the two cases being bigger at the rear, where we actually decrease the antiroll bar stiffness.

What all of this show is that, while in the first corner the stiffer bar seems to work better and the car has less understeer, as we would think, in these two particular corners more factors are contributing together leading to exactly the opposite reaction than what we would expect on paper, when setting a softer/stiffer rear antiroll bar, at least from a handling perspective. Not only the vehicle is quicker with a setup that produces overall slower lap times, but we actually identify a handling reaction which seems to go against basic vehicle dynamics theory.
As you may have seen, also the driver is playing a key role here in defining how the car reacts and this is something that a session in a simulator can show at best, while such a thing would be difficult to predict or simulate with a different kind of software. How the car behaves and performs on track is always influenced by how the driver can manage certain handling features and how he reacts to them (we have seen in this case how our driver was most probably using slightly different lines with the two setups).
At this stage, as we said, we are also not really simulating complex phenomenon like aerodynamics roll sensitivity, just to say one. Still, even such a simple setup change has shown a reaction that we would “normally” not expect.
Still, there is an objective change in how the car handles depending directly on vehicle dynamics and aerodynamics reasons, which not only is somehow counterintuitive basing on a simple reasoning focused on lateral load transfer distribution, but also can only really be identified in a simulation environment where also the driver is playing a role.

The conclusion is that, even with a cheap software, we could still extract a lot of useful indications about car setup and we can work also on technical aspects, not only on driver training.
For the record, the setup we came to using the simulation was extremely close to the one the team finally used on track, even after the “day specific” tuning.
As I said probably more than a thousand times, it is absolutely key to have an accurate, reliable and well validated vehicle model, to be sure to be capturing as much as possible what the car really does on track. For a study involving setup investigations, this is even more important than when working on driver training “only”.

What I find amazing after conducting this study is that it proved (to me in the first place) that, at least up to a certain point, a cheap simulation software like rFactor can even be used for pretty useful setup investigations, leading to results which are both close to the real world and helpful for the preparation/development work. Of course, track time is always the best a driver and an engineer could wish, but when this is not possible and/or when certain phenomenon needs to be analyzed in more “controlled condition”, the simulation can be a real deal. In general, it always helps to understand not only what happens but, even more important, why.

I am now even more convinced than before that a similar tool could be of real benefit for every team, not only for driver training but also from an engineering perspective.


  1. Another great post! Out of interest, why don’t you use rFactor2?

    • Hi! Thanks for your kind words.

      I am not excluding switching to rF2 at some point in time, but till now i didn’t do it because of the tire model rF2 uses.

      It is a very complex (and surely valid) model, but it is simply not usable in an engineering way, because it is based on the tire structure information and not on tire performance and behavior (which is the data actually measured by tire manufacturers and provided to teams).

      If rF2 would allow an rF1-like tire model at some point in time, i would surely consider it.

      • We’ll you might be in luck – the new Dec house taking over development of rF2 have said they will be incorporating the rF1 tyre model into the sim as well as the dedicated rF2 one. When that happens would be fascinating to see a data comparison of real car / rF2 / rF2

      • …I mean real car / rF1 / rF2 – using your test with the F3000 at Monza.

  2. i am really looking forward to that rF2 update! 🙂 I am in good contact with the “new” rF2 guys, i am following their activities with great interest!

  3. great stuff to read. I love rFactor it’ still the best

  4. Thanks for sharing. It’s always interesting to see how other race engineers approach simulation. Crawl…walk…run works for me and your approach is similar.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


%d bloggers like this: