[MVRC] Mantium Virtual Racecar Challenge 2025 (Grand Prix Cars)

[CAEdevice]

MVRC is also on LinkedIn — support us by reposting and helping spread the word!

https://www.linkedin.com/posts/mantium- ... 39777-3EGS

[LVDH]

Yes, great comeback from JJR! Congratulations, you deserve it.

Big thank you to the staff. Getting the races done within a week is always a challenge and it worked out once more.
This time we had a lot of discussions behind the scenes.

One of the things, we had to realize is that we were not 100% happy with the laptime calculation. Because of this, we made some modifications, which are best explained by Max.

Also, we found out that there is something not quite right with the CAD files, we provide. This seems to have affected only CAEdevice and Koldskaal. We will try to fix this as quickly as possible.

[janci_kp]

Congratulations to JJR on a remarkable comeback and a dominant victory
Congratulations to Variante who has demonstrated outstanding performance once again and to Panthera for confirming the improving trend.

Very consistent performance shown by the new teams as well: the competition will be tough this year.

I am happy with the performance of my car, despite it being classified near the bottom of the standings.
The actual performances are significantly better than the officially computed ones, due to an inconsistency in the geometry of the “common parts” provided by MVRC.

This issue was not caused by a modelling or interpretation mistake on my side, but rather by a mismatch between the different formats of files supplied by the organisers. Specifically, the suspension layout (cover and inner arms) differs between the official assembly file (MVRC_R09.STEP) and the single-part STEP and STL files. These inconsistencies appear to have originated during the file conversion process handled by the MVRC staff.

https://www.caedevice.net/SERVER/MVRC/2 ... _issue.jpg

Unfortunately, I relied on MVRC_R09.STEP as the reference for development, while the official simulations were conducted using the STL parts, which present a different geometry.

The staff should consider re-running the simulation of my car with the inner arm protrusions removed, using the official suspension components. While this would still be a disadvantage, since the car was optimised based on an alternate suspension placement, it would be considerably less penalising than the current configuration.

Additionally, given we are close to the next race, it would be advisable to promptly update the STL and STEP files of the single parts, especially considering that the survival cell (chassis), provided as a “common part”, was designed with reference to the suspension positioning in the MVRC_R09.STEP assembly.

That’s really weird. I just checked quickly and for me in the CATIA V5 step and stl files are at the same position.

[spacehead3]

One of the things, we had to realize is that we were not 100% happy with the laptime calculation. Because of this, we made some modifications, which are best explained by Max.

Yes, the staff had a bunch of discussion about this over the weekend and it became clear that the CoP effect was still much too strong. So, rather than guess again we decided to get some actual data. I did some tests on my home driving simulator running Automobilista (rfactor) with varying levels of aero balance, and Andre did some trials with another LTS program from TU Munich.

We’ve now adjusted our CoP curve to better fit this data, which you can see below. The curve is now much smoother overall, however there is a large jump at CoP = 1.7 (~50% aero balance) as the car would be likely to spin below that point.



The latest version of the spreadsheet is available here: https://docs.google.com/spreadsheets/d/ ... WS7yw/copy or on my website.

Apologies for the many revisions of this, but I think now we can be reasonably confident that we have a good solution.

(P.S. if a mod sees this, can we please fix the constant errors on this site? Took like 5 trys to be able to post this successfully.)

[CAEdevice]

That’s really weird. I just checked quickly and for me in the CATIA V5 step and stl files are at the same position.

You have to compare Assembly MVRC_R09 (STEP) with Parts (both STEP and STLS). Here is what happens with Creo (I use Solidworks for my MVRC Car):



The same happens with Design Spark (SpaceClaim/Ansys Modeler)

[Ft5fTL]

Congratulations to JJR on a remarkable comeback and a dominant victory
Congratulations to Variante who has demonstrated outstanding performance once again and to Panthera for confirming the improving trend.

Very consistent performance shown by the new teams as well: the competition will be tough this year.

I am happy with the performance of my car, despite it being classified near the bottom of the standings.
The actual performances are significantly better than the officially computed ones, due to an inconsistency in the geometry of the “common parts” provided by MVRC.

This issue was not caused by a modelling or interpretation mistake on my side, but rather by a mismatch between the different formats of files supplied by the organisers. Specifically, the suspension layout (cover and inner arms) differs between the official assembly file (MVRC_R09.STEP) and the single-part STEP and STL files. These inconsistencies appear to have originated during the file conversion process handled by the MVRC staff.

https://www.caedevice.net/SERVER/MVRC/2 ... _issue.jpg

Unfortunately, I relied on MVRC_R09.STEP as the reference for development, while the official simulations were conducted using the STL parts, which present a different geometry.

The staff should consider re-running the simulation of my car with the inner arm protrusions removed, using the official suspension components. While this would still be a disadvantage, since the car was optimised based on an alternate suspension placement, it would be considerably less penalising than the current configuration.

Additionally, given we are close to the next race, it would be advisable to promptly update the STL and STEP files of the single parts, especially considering that the survival cell (chassis), provided as a “common part”, was designed with reference to the suspension positioning in the MVRC_R09.STEP assembly.

I have the same issue both on front and rear suspensions. This could maybe explain the lack of cooling on my car.

[yinlad]

I used the STP as reference and it was centred in the volume so unless both were wrong I think I should be ok, just odd that the issue is not global for all

[The Rusted One]

Hi everyone, I have a question about rule 7.1.3 regarding the power unit inlet:
"This template must not intersect any other parts or templates with the exception of the engine intake plenum."

I cannot find any part named "engine intake plenum" among the supplied parts/volumes. Is it referring to the "MAND_Engine_inlet_Volume_V01" part?
Thanks in advance and happy developing to all!

I don't believe there's a engine intake plenum that interferes with the template anymore so that shouldn't be something to worry about anymore with 7.1.2 in place

[LVDH]

Yes, the staff had a bunch of discussion about this over the weekend and it became clear that the CoP effect was still much too strong. So, rather than guess again we decided to get some actual data. I did some tests on my home driving simulator running Automobilista (rfactor) with varying levels of aero balance, and Andre did some trials with another LTS program from TU Munich.

Yepp, these are the lengths we go for you guys.
As engineer it is always important to have a good feeling about what numbers mean in reality. Sadly, I personally, have no idea how a bad CoP feels like.
I suggested that we test it in a simulator (besides that we might not have good race cars with enough down force at hand in reality, I assume, it would take driving skills way above mine), so this was the only option. Turns, out Max was way ahead already. So, I just added some data from another LTS, that I found on the internet.


Regarding the CAD, position error:
It became clear that we are missing something very important in our rules. Just like the FIA writes rules in French and English, they define which is the relevant version in case of issues.
We supply three different pieces of CAD: We have the stp assembly, separate step files and stl.
I know, there are other views on this, but the common sense default version in this case is stl.
Why is that? The step versions cannot be, because OpenFOAM requires stl. Stl is a discretized version of the step files. As there are many different ways to create the stl (different algorithms and parameters), having this supplied version, created by MVRC, of the mandatory geometries, is the standard we need to follow.
And this is in your best interest, as it means you can run your simulations with the same conditions as the official ones are.
Sadly this is a bit unfortunate because, this time there was an unintended translation of the geometries between assembly to separate parts. This is what we will have to fix. But fix or no fix, the stl files are and will always be the ones to go by. We will also mention this in the technical regulations to avoid any misunderstandings in future.

[CAEdevice]

Although I have decided to accept the race result, so as not to complicate things or diminish the enjoyment of the other teams, who fully deserved their results, I would like to make a clarification regarding the matter of STEP versus STL format precedence.

The official data exchange format for 3D geometry is STEP (as certified by ISO 10303). The fact that many software tools generating meshes for CFD simulations require conversion to STL format, which is a tessellated representation with significant loss of information, does not mean that STL is a standardised format. Therefore, the parallel with the rules being written in French does not hold.

In particular, André wrote: "Just like the FIA writes rules in French and English, they define which is the relevant version in case of issues." But no such indication was given in the context of MVRC. In my view, it would have been more appropriate to accept both versions, simply removing or repositioning the inner suspension arms (not from the rules, but only from the simulations where they were not properly aligned), considering that MVRC provided two versions, both potentially and equivalently valid, in the absence of an explicit prioritisation, expcially considered that all the single part files derive from the MVRC_R09.STEP file included into the official package.

In any case, the matter is closed with this message: the championship (with a zero) is effectively over for my team, but it’s fun and motivating to look ahead to the upcoming races, with the goal of building the fastest car, which is by no means guaranteed, as the performance of JJR, Variante, and Panthera has been absolutely outstanding.

[LVDH]

...The fact that many software tools generating meshes for CFD simulations require conversion to STL format, which is a tessellated representation with significant loss of information, does not mean that STL is a standardised format. Therefore, the parallel with the rules being written in French does not hold.

I fully understand that this is frustrating and the source of the issue is that nowhere it is stated which is the CAD file / format you should take as reference. But as you say, many CAE software solutions need stl for the meshing process. So, I do think it makes a lot of sense to use the official stl files to run your own local simulations. If no, you run the risk of doing something completely different than what is done during the race.
Stl meshes can cause bad cells in the CFD volume mesh which can potentially result in numbers that completely through you off. Then there could even be intentional cheating. And I sure do not want to start discussing with others how they expect the stl files should get generated specifically for their car. The stl files simply have to be the reference for our simulations.
If you would have used the official stl files, you would have noticed the issue way in advance.

[CAEdevice]

I have two questions about the rulebook.

10.5 fw_strake must:

be fully contained within RV-FW_Endplates_V*
when cut by any Z-plane in the interval Z = (75mm, 200mm) produce up to 4 sections.
when cut by any Y-plane in the interval Y = (450mm, 555mm) produce up to 2 sections.

The sections are those of the strakes or the wing profiles are included (i.e. we can have more than one strake, provided that they are both included into the ruled volume RV-FW_Endplates_V)?

12.1 floor_body must:

be fully contained within RV-Floor_V*
when cut by any Z-plane in the interval Z = (35mm, 275mm) produce up to five sections.

Are the sections of the strakes included into the ruled volumes "RV-FLOOR-LED_V*" and "RV_FLOOR-FENCE_V*" included into that limited number?

[yinlad]

I have two questions about the rulebook.

10.5 fw_strake must:

be fully contained within RV-FW_Endplates_V*
when cut by any Z-plane in the interval Z = (75mm, 200mm) produce up to 4 sections.
when cut by any Y-plane in the interval Y = (450mm, 555mm) produce up to 2 sections.

The sections are those of the strakes or the wing profiles are included (i.e. we can have more than one strake, provided that they are both included into the ruled volume RV-FW_Endplates_V)?

12.1 floor_body must:

be fully contained within RV-Floor_V*
when cut by any Z-plane in the interval Z = (35mm, 275mm) produce up to five sections.

Are the sections of the strakes included into the ruled volumes "RV-FLOOR-LED_V*" and "RV_FLOOR-FENCE_V*" included into that limited number?

Dont take this as the absolute truth but for the first question I believe the intent is that rule limits us to a maximum 2 strakes per side.

The second question pertains only to the main floor body. I posted questions about that some pages ago with some supporting screenshots of floor sections in Z

[CAEdevice]

I have two questions about the rulebook.

10.5 fw_strake must:

be fully contained within RV-FW_Endplates_V*
when cut by any Z-plane in the interval Z = (75mm, 200mm) produce up to 4 sections.
when cut by any Y-plane in the interval Y = (450mm, 555mm) produce up to 2 sections.

The sections are those of the strakes or the wing profiles are included (i.e. we can have more than one strake, provided that they are both included into the ruled volume RV-FW_Endplates_V)?

12.1 floor_body must:

be fully contained within RV-Floor_V*
when cut by any Z-plane in the interval Z = (35mm, 275mm) produce up to five sections.

Are the sections of the strakes included into the ruled volumes "RV-FLOOR-LED_V*" and "RV_FLOOR-FENCE_V*" included into that limited number?

Dont take this as the absolute truth but for the first question I believe the intent is that rule limits us to a maximum 2 strakes per side.

The second question pertains only to the main floor body. I posted questions about that some pages ago with some supporting screenshots of floor sections in Z

Thanks, I agree with you about Q1.

I am still confused about Q2

[The Rusted One]

I have two questions about the rulebook.
The sections are those of the strakes or the wing profiles are included (i.e. we can have more than one strake, provided that they are both included into the ruled volume RV-FW_Endplates_V)?

Are the sections of the strakes included into the ruled volumes "RV-FLOOR-LED_V*" and "RV_FLOOR-FENCE_V*" included into that limited number?

Dont take this as the absolute truth but for the first question I believe the intent is that rule limits us to a maximum 2 strakes per side.

The second question pertains only to the main floor body. I posted questions about that some pages ago with some supporting screenshots of floor sections in Z

Thanks, I agree with you about Q1.

I am still confused about Q2

The rule doesn't affect the volumes in the Floor LED and Floor Fence. Those are seperate parts.