It is best to start by ensuring you are obtaining accurate results before getting into running automated design space exploration (garbage in = garbage out). More on this can be found in here and here.
CAD to mesh process:
The software needs to be able to use exposed CAD parameters (length, angle, position, etc) to change the geometry automatically. This can be done in various ways as seen in this article:
If you already use another CAD software like NX, we can link STAR-CCM+ and NX together. See the CAD clients (section 2.1 in the linked article). However, keep in mind that if you plan to run your case on a cluster which are often linux based, this often creates incompatibility issues with CAD programs because they are often based only in Windows. Therefore you will need to tunnel your run on the cluster back to a different machine which runs windows. This way the cluster can run STAR-CCM+ (with the CAD client add-on and Optimate, Optimate+, or HEEDS) since this has a linux version, and the other windows based machine can run the CAD program.
If you want to avoid this potential hurdle, you can use the STAR-CCM+ 3D-CAD (section 2.2 in the linked article). This allows the CAD to mesh process to all happen inside one program (STAR-CCM+). While using this approach requires that you build new CAD in STAR-CCM+, it doesn’t mean that you have to rebuild the entire car --- only aspect that you want to change (wings, undertray, etc). Also keep in mind that when it comes to CFD, a lot of the geometry needs to be excluded and simplified for meshing purposes. Therefore, most teams elect to rebuild a simplified CAD of their car that captures all major aerodynamic aspects.
“Boiling oceans” and refining design spaces:
It can be tempting to leverage this technology to expose a large number of design parameters, set each with a wide range of constraints, and crank up the number of design iterations so that the program can find the best designs for you (so you don’t need to do any work). Trying to “boil the ocean” is going to take forever and is not the best use of your time. There is a balancing act between allow the program explore too much (it will search the allowed design space and will likely return something logical that the user could have come up with in less time because the program is being fed allowed constraint values which the user knew beforehand would not work) and over constraining the design space (which can eliminate good designs that are counterintuitive to the user). It’s best to not eliminate or include too many design constraints. Likewise, it’s best to not allow the range for the design constraints to be too large nor too small. From my experience, it’s best to widen the design constraints just past which I believe would be reasonable so that it can quickly find the best designs. From this you can see trends/relationships between the best designs and the range of design constraint values that led to these best designs. From here, you may want to run the optimization case again, but this time reducing the design constraint ranges further. This will allow it to further refine the design space.
Consider the run time needed for each simulation to fully converge (keep in mind cell count, physics, etc). If you are limited on hardware it may be best to focus on a component in your system, and not the entire system (to save on cell count and run time). If you cannot focus on a subsystem, it may be best to manually test the design space to help identify the approximate design constraint ranges needed, upstream up using automated design space exploration.