Khamsin Virtual Racecar Challenge 2015

[CAEdevice]

Hi installed all the tools, but I received this message (see the link below for the log): it seems related to the geometry "structure" and names.

https://dl.dropboxusercontent.com/u/522 ... st.log.txt

[julien.decharentenay]

Is there a reason for using Openfoam v2.1? It's quite different to v2.3.1. Is it simply because that's what compiles on Windows right now?

I don't think that there is a significant difference between v2.1 and v2.3.1 for the type of solver that is used (incompressible, steady-state with k-omega SST). One of the potential source of difference may be in the mesher "snappyHexMesh" that seems to be twikked in every release.

The choice of openFoam v2.1 is driven:
- Choosing to have a framework that runs on Windows;
- Availability of a free Windows binary of v2.1 that also supports parallel processing.

Please note that we (on our side) will be using openFoam on Linux through Amazon. The openFoam version there will be 2.2 (and I have not made any back-to-back comparison between v2.1 windows and v2.2 linux). Mainly because my laptop is old and slow...

[julien.decharentenay]

Will boundary conditions of the CFD simulation be provided (wind speed, rotating wheels, etc)?

Sure. The speed is 100mph. Rotating wheels are modeled by applying a rotation velocity on the wall.

In addition, there will be some kind of pressure or flow outlet for the air intake and an inlet for the engine and cooling exhausts. The actual boundary conditions are not yet defined and hence I can't let you know. The simulation will be run in iso-thermal (ie the exhausts will be at the temperature as the ambient). If you have any opinion on quantities to use for air intakes (cooling and engine) and exhausts, we would be very happy to hear.

As a side note, I will be providing some "benchmark" simulation results based on some grabCAD geometries. It may be a good idea to run this scenarios to benchmark your results against ours. Matteo, would you like sharing your experience from last year?

[julien.decharentenay]

Hi installed all the tools, but I received this message (see the link below for the log): it seems related to the geometry "structure" and names.

Thanks a lot for sending me the error message. It is an issue that I was aware of when I developed, but assumed that it would not pop-up so soon.

The issue is that your geometry file is on a drive (R:) that is different from the openFoam distribution (C:) drive. Try copying the geometry on the C: drive and running the simulation there.

The "problem" is that when setting up the openFoam environment, it automatically change the directory to where openFoam is installed (ie C: drive). The framework changes the directory, but does not change the drive (yet). I will add this to my to-do list as it should not be too much work. Sorry about this. I will also add a test to make the simulation stops earlier...

[CAEdevice]

Hi Julien, I confirm that the problem does not appear when the simulation runs on C: ( but I still have some error messages: https://dl.dropboxusercontent.com/u/522 ... log.01.txt ).
The drive "R:" was a RAM disk I use to avoid stressing the SSD disk with heavy input/output, but it would not be a problem to run the simulation on C:

About the benchmark: you are free to use/publish in every way my 2014 data, including car geometry (I developed the car after the end of the season, if you need the new geoemtry, more realistic and more efficient, I can send it to you).

During 2014 I had the possibility to test two kind of CFD software:

1) Open foam based: with some tweaks I could replicate the results of the official solver with an approximation of about 10-15% for "lift" and 5% for "drag"
2) Other commercial codes: I could not use them for all the season because the where trial releases (30 day).

In the second case (other commercial) I really could not obtain a decent convergence, even if I tried to increase the mesh refinement (with an identical "boundary box" and "boundary contitions" I used from 10^6 to 10^7 cells). With a "steady state" solution I always obtained an under extimation of the ground effect. The approximation was not acceptable: 50-60% less downforce and 10% less drag. The solution at first reached the KVRC solver values (40-50 iterations) than it converged (70-80 iterations) to that low values.
I also tried to use a "transient solver" (only after the end of the season) and the results where quite good, even with only 10^6 cells (+10-20% lift +5% drag).
In this case, result depended on the time step (to long time step = the same of a steady state solution, to short time step = long time/iteration to converge.

I also had problems with the COP: I used a simplified scheme, I guessed the vertical position of the COP (between 0mm and 1000mm, starting around 500mm) and after two or three iteration of the simulation I could find reasonable values. The problem was that the result was affected by the result of the integration of local pressure and shear along the car that varies very much with mesh size, boundary conditions, STL refinement and many other parameters.

[MadMatt]

Thank you Julian! It would be interesting to compare with commercial codes yes. I am using Star-CCM+ so I could compare both, but I am afraid that I have no idea how to work with openfoam and the one-click-cfd package, so a user guide would definitely be helpful!

I will try to get you some values for the engine requirements as soon as I am back from holiday and have access to my work computer.

[julien.decharentenay]

Hi Julien, I confirm that the problem does not appear when the simulation runs on C: ( but I still have some error messages: https://dl.dropboxusercontent.com/u/522 ... log.01.txt ).

Thanks a lot for the feedback on the solver. The "error" is in the extension of the file. It looks like openFoam is case sensitive. Use a lower case extension ".stl" in place of ".STL". I add this one to my to-do list as it is something that I can work around...

[CAEdevice]

Hi Julien, this is the most recent log (case sentive error solved): https://dl.dropboxusercontent.com/u/522 ... ce.log.txt
Consider that the anaysis was run with a multibody file: https://dl.dropboxusercontent.com/u/522 ... device.zip

[CAEdevice]

Hi, is there any draft about the calendar? I'm going to start an intense period with the office, maybe I'll have to use a quite simple car for the first race.

[julien.decharentenay]

CAEdevice,

1) Race calendar: we are still working on it. We have a meeting next week-end (17th January) to finalise it. The first race is at least a couple of months away. The plan is for more space between races (compared to last season) - from memory, it should be a month.

2) CFD error: I am running into a couple of issues with your file:
- The name of the solid (and the file) should only be made of letter, numbers, "_", and "-". I have altered the code to return an error message when non valid name are used;
- The file is exported in millimeter units - one-click CFD assumes that the file is exported in meters. I rescaled;
- The file is a binary STL file. For some reason that I don't quite understand, openFoam does not use the name of the solid, but assign it as patch0. I need to check whether this is always the case or depends on some kind of parameters. At the moment, it is best to use ASCII STL files.

I am just running the case to make sure that there is no other issues with it. I have a new release candidate that covers the previously mentioned issues (R: drive and STL in uppercase).

[MadMatt]

The positioning of the cooling inlets and outlets will be challenging I think. I had a go at this and it is the area of the car which I find interesting as minimizing the drag penalty and meeting the regulations is not as easy as it seems!

[CAEdevice]

CAEdevice,

1) Race calendar: we are still working on it. We have a meeting next week-end (17th January) to finalise it. The first race is at least a couple of months away. The plan is for more space between races (compared to last season) - from memory, it should be a month.

2) CFD error: I am running into a couple of issues with your file:
- The name of the solid (and the file) should only be made of letter, numbers, "_", and "-". I have altered the code to return an error message when non valid name are used;
- The file is exported in millimeter units - one-click CFD assumes that the file is exported in meters. I rescaled;
- The file is a binary STL file. For some reason that I don't quite understand, openFoam does not use the name of the solid, but assign it as patch0. I need to check whether this is always the case or depends on some kind of parameters. At the moment, it is best to use ASCII STL files.

I am just running the case to make sure that there is no other issues with it. I have a new release candidate that covers the previously mentioned issues (R: drive and STL in uppercase).

Thank you, I tried with a different name and correct units: I receive a "geometry error" message.
The geometry was the same I used in the previous run (but exported as ASCII STL and using meters). I also tested this geometry (not multibody) with the same result.

https://dl.dropboxusercontent.com/u/522 ... D_test.log
https://dl.dropboxusercontent.com/u/52296215/test.zip

[MadMatt]

Is there any tutorial on how to run simulations with this package? I am quite savvy on computer stuff, but never tried Linux or this kind of stuff before, so could do with few guidelines!

[MadMatt]

Just a regulations clarification. It says no bodywork can be less than 10mm wide, but that a rounded leading edge is allowed (I prefer to use the word fillet but I think it is the same). But when it comes to the inlet or outlet surfaces, there is an additional rule: "These templates must be
entirely enclosed in bodywork". I have an example to show for clarification.

This is a valid engine intake surface (green). It is fully enclosed with 10mm of bodywork around it:


However, is it still legal to take advantage of the fillet rule and create the following structure, assuming the surface is still above the minimum surface size?


Technically the surface is not enclosed in bodywork for the first 10mm so I would say the first 10mm don't count, but I just want to be sure that we are all on the same page.

[cdsavage]

I'm not sure how the 10mm thickness rule would be relevant in this case - in both of those images, the bodywork appears to be well over 10mm thick.

The rule specifying that the templates must be enclosed in bodywork applies to the inner and outer templates. The actual inlet/outlet surface itself is not considered as a template, this should just form part of the outer surface of bodywork. Before submitting, it should be split off from the bodywork.