What he did was the equivalent to what Aston Martin did, bringing untested parts to a race.
I wonder if anyone at all tests the car using the official settings
I was also pretty surprised by this. I thought this race would as well align with the real F1 race in the sense that we release the results while that one is taking place. However as that is not the case, we should delay this race by a full month. This gives you more time to develop and also shortens the winter break, which is way too long every year.
In what sense? I had tested all parts submitted. Just not at 5000 iterations as it's impractical...LVDH wrote: ↑28 Oct 2023, 09:27What he did was the equivalent to what Aston Martin did, bringing untested parts to a race.
I have an important announcement to make:
As I am wondering if the surprise for the final race will work out and we will not have to option of a late delay,
I will delay the final race by one week.
Submission date for Interlagos will be 12.11.2023!
Well, you did not test it all the way in the environment it would run. Keep in mind, the full simulation runs a while with first order accuracy and switches at some point. I think your simulation crashes a bit after the switch.
I'm not the Mflow guy, but which template did you run them in? I think the Fast mesh is quite coarse and probably masks a lot of issues. I've had really good correlation this year with the "MVRC" template which gives you a good mesh but doesn't take forever like the "Long" one.
From what I understand, what you reported here a few weeks ago (see your quote above) is exactly what happened during "the race" : solver divergence just after switching to 2nd order equations. It's usually because of poor mesh, which can be due to poor quality STL surface, but not always. It might be because there is a too acute or too sharp corner somewhere, or faces too close to each other. Not easy to debug.
Now you have got me intrigued! Better accuracy for same computing cost sounds very exciting.LVDH wrote: ↑28 Oct 2023, 21:49Now, on one hand, we have rather coarse simulations to make this challenge accessible to as many people as possible with a trade-off to realism. On which side of the scale are we? Well, good question. But, I do understand, it is a bit much hardware requirement for some of the contenders, we do have.
The small surprise coming up, will help on this part of the challenge and hopefully drive us more to the direction of realism while keeping the challenge open for as many people as possible.
Still, I think the main challenge is not CFD computing time but modelling the car in your CAD tool.
The guy on top by far, is apparently only using MFlow in the fast setting...
I run a variety of settings and iteration counts through development and before the race. Just never to 5000 iterations.spacehead3 wrote: ↑28 Oct 2023, 21:55I'm not the Mflow guy, but which template did you run them in? I think the Fast mesh is quite coarse and probably masks a lot of issues. I've had really good correlation this year with the "MVRC" template which gives you a good mesh but doesn't take forever like the "Long" one.
Anyway, you probably need to figure out which part is causing the issue and fix it if you don't want it to happen again...
Yeah, like I said, I think it's unlikely that the number of iterations is the issue but rather the mesh. It would be very strange for it to blow up at 4950 iterations, probably it happens very early on (and it sounds like Andre confirmed this). Maybe he can tell you exactly how far your run got so that you can try to replicate. Could always just kill it after 1000 iterations or whatever if everything is looking good.
To an extent it was a joke.
This is what I tend to do anyway, it may be that I submitted an untested part in error but I don't think that's the case.LVDH wrote: ↑01 Nov 2023, 18:21To an extent it was a joke.
But, testing parts all the way does reduce risks.
So what can you do if the 5000 iterations are not feasible for you?
Well, you can have a look at how the simulation is set up and maybe fine tune it to get realistic results in a shorter time. If I am not mistaken, the first order settings are for the first 2000 iterations. And after switching the crash does happen rather fast. So maybe it is worth trying to modify the settings to only something like 750 iterations using the first order settings and then watching if the sim blows up within the next 1500 iterations using second order settings. This is just a suggestion, the numbers will be different for every car.
Today, I finally released the results on the homepage. Mostly this is important for you to check, if you got caught violating any rules:
https://mantiumchallenge.com/results-mvrc-cota-2023/
This year, you guys are doing a great job, there is usually not much to find.
If someone wanted to pre-check a part for legality, would emailing yourself by the best course of action?LVDH wrote: ↑01 Nov 2023, 18:21To an extent it was a joke.
But, testing parts all the way does reduce risks.
So what can you do if the 5000 iterations are not feasible for you?
Well, you can have a look at how the simulation is set up and maybe fine tune it to get realistic results in a shorter time. If I am not mistaken, the first order settings are for the first 2000 iterations. And after switching the crash does happen rather fast. So maybe it is worth trying to modify the settings to only something like 750 iterations using the first order settings and then watching if the sim blows up within the next 1500 iterations using second order settings. This is just a suggestion, the numbers will be different for every car.
Today, I finally released the results on the homepage. Mostly this is important for you to check, if you got caught violating any rules:
https://mantiumchallenge.com/results-mvrc-cota-2023/
This year, you guys are doing a great job, there is usually not much to find.
congrats G-raph, a step above the field this year!
