The "official" one has completely different numbers ("private" >>> "official" ):
DRAG: 2400 >>> 2000 N
DOWNFORCE: 8200 >>> 7000 N
COP: 1.65 >>> 1.40 m (not corrected yet)
Looking at the images, I am convinced that the problem is the absence of the wheels in the "private" simulation (not "absence of rotating wheels", but the whole wheels are not present). This disoriented me because I dedicated so much time to run the official OCCFD than to develop the car (CPU 20h to run "calibration models" and only 5h to the submitted car), so I would have expected the same results. Maybe I did something wrong, but I correctly remeber we were not asked to include wheels in the model used to run the simulation with OCCFD.
Also consider that *with the same stl* OCCFD fails 4 times over 5 beacuse of the "mesh mapping" issue...
I think I will take a vacation from KVRC for at least two weeks to let off some disappointment (hoping that in the meantime the " framework" will become more reliable).
In particolar, I have that questions:
- 1 - Should I include the wheels in the model I use for OCCFD "local"? In the submitted files they are not required
- 2 - What about sospension elements?
- 3 - I tried everything to aboid the mesh mapping error with OCCFD: I'm sure that the STL I'm using is clean and refined (I'm using SpaceClaim that has dedicated tools, but also ProE/Creo can export very good stl. What about trying a different approach for the meshing? May with a less complicated, even if accurate, refining, considering that the meshing/refining is "single core" and the "brute force" solution is multi core?
In the real races, the development is done with CFD or wind tunnel or imagination and it has to be related/compared to the "reality" (the air that impacts on the car). That "air" is an absolute environement: our "absolute environement" is OCCFD (the "framework"): we need to have it reliable and stable to develop the car without guessing
Well: it is clear that it is a game, but it would be more and more fun