[KVRC] Khamsin Virtual Racecar Challenge 2016

[machin]

To change the max power may be not the most elegant way to do it, but it is ok for me.

I thought it was a pretty good way myself (before anyone thinks I'm blowing my own trumpet; the idea wasn't mine initially, but I do wholeheartedly support it). Other options we had were;

1. Generate "fantasy tracks" with the characteristics we wanted.
2. Alter the real track models to get the characteristics we wanted (e.g. Shorten/lengthen the straights).
3. Adjust the output of the CFD testing before putting it into Virtual Stopwatch to get the results we wanted.
4. Change the tyre characteristics.
5. Alter the power.

1 and 2 and 3 I'm dead against because I think we should maintain realism. 4 is pretty good, but hard to explain in a way that is totally clear without it sounding like we're trying to pull the wool over anyone's eyes. 5 is (in my opinion) the most transparent and the easiest to comprehend; "you have less power so you need less drag". In that respect I'd say it is pretty elegant... But I'm always open to other suggestions....

Re. The rules: At the moment Julien, Chris and I are just discussing how we implement the cooling and engine intake/exhaust idea. We want it to be realistic without the need to drastically change the design of the cars. Hopefully we'll release some guidance soon.

[julien.decharentenay]

The rules are coming soon. I was done with a cold last week and trying to keep on top of my day-to-day work (I had to look good at my yearly review, which went well).

Richard and I have been discussing the intake/exhaust idea. I like the proposal for the modelling the internal pods, but am concern with the meshing aspect. Not all participants use a solid modelling package...

Essentially the idea is based on an extension of the modelling done this year. Volumetric flow rates are applied to the intake and exhaust. From the CFD analysis, the pressure (static component) is extracted to confirm that the airflow performance is in accordance with the specified volumetric flow rates. If the airflow is in accordance or better, then the engine performance is as design, otherwise a derating is applied. It is not as sexy as modelling the cooling ducts, but has the following merits:

- It is an extension of the existing framework and has no surprise;
- It can be applied to the cooling and engine parts.

Mesh cleaning: I will need to revisit the openFoam mesh cleaning tool. One of the issue (as least with the intake and exhaust) is that the intake and exhaust surfaces have to be separated after the mesh cleaning step. This is one of the reasons that modelling the duct is attractive to me - but I am concern about the associated impact on the wider range of participants.

OCCFD: I will implement the change in x/y/z direction and increase the image resolution. There is no issue there. If you have any other requests, just send me an email.

Rules: Chris is looking at them. Essentially they are based on the 2015 version - and will probably be reduced after implementing some modelling based compliance for the intake/exhaust.

Thinking about it, we could offer the choice to submit using either an intake/exhaust or modelling of the duct.

[CAEdevice]

Hi Julien! Is there any news about the solver (2.3 for both Windows and Linux? Or 3.0.1?). The official Windows Virtualbox package seems interesting too. With the 2015 release of OCCFD I used most of times the "very stable" option, because the standard one diverged 4 times over 5... occasionally (50%) I had meshing problems before the second part of the simulation (step 500, refined mesh I suppose).

It would be useful the possibility to only write the OpenFoam case, without starting the solution, so in case of problems I could copy it on my Ubuntu workstation and run with the standard Linux version of OpenFoam.

Another thing that could be useful for beginners: in the automated report should be included the resultant forces over the wings (and the floor+ diffuser, but an optional new separation of that surfaces would be required).

[julien.decharentenay]

HI Matteo,

I made a couple of changes to OCCFD so that when divergence is reported it automatically revert to a very stable solution. I will look at the reporting of forces on individual components [the graph of drag and downforce at the end of the report can be used for a similarish purpose] - but it won't take me too much time to get this around.

Compiling openFoam for Windows is a real pain. I have been battling with it for a few weeks with the impression of doing one step forward and two step back - so no real progress there. I will however do a Linux version, which will be easier so that you can run directly on Linux (it may have to be a command line). In regards to just exporting an openFoam case, it can be done, but I have a feeling that this kind of revert to having a template to fill. Happy to do it though.

Julien

[CAEdevice]

You could work only in Linux and provide a virtual machine (ubuntu with minimum software installed): that is the same way choosen by ESI, since OpenFoam for Windows is actually a virtualbox.

Or, what about separating the tool to generate the OpenFoam case (windows) from the solver (linux or linux virtualbox running in a windws pc)?

[julien.decharentenay]

OCCFD is wrapping around the solver tools and it can be done as easily as run OCCFD as a pre-processor, copy the files, then run a batch command. But OCCFD for AWS runs a little more like you are trying to achieve. The case is "started" from Windows, but run on a remote Linux computer. The start process is essentially a copy of the files (and OCCFD) and a command to start OCCFD on the remote Linux computer.

I am not too keen on VMs and was surprised with ESI's claim that openFoam in VM+docker is 25% faster than native... But it may be a good idea - particularly if there is speed benefits. One of the issue that I have with ESI's port is that I do not know if it is possible to extend the VM to support some bits and pieces (a rsh server, ruby, pvbatch). I will need to have a look into it.

Porting on Ubuntu is going pretty well so far. I will be looking at adding openFoam 2.4.0 and 3.0 support and release.

[JJR]

Great news Julien. I dont use Windows so Linux version of OCCF would by great for me. In last days I update to Ubuntu Mate 15.10 and OpenFOAM 3.0
Thank you for your work.

[CAEdevice]

I can't wait for the new rules and CFD framework. In the meanwhile, I'm testing the "porous volumes" (not with OpenFOAM, I'm still learning it, but with Karalit). I can confirm that the increase of mesh elements is not significative (about 10%).



PS: Happy New year!

[julien.decharentenay]

I am back at my workstation (and in the UK and in reasonable health). OCCFD on Linux will be in the next release - although it will not support sending calculations to AWS (not an issue in my opinion) - and will support openfoam 3.0. I will run a few tests and if all goes well (it never does), KVRC 2016 will be run on openfoam 3.0.

Matteo, how is Karalit? Is it not supposed to be a LES based analysis rather than RANS?

KVRC 2016 status: In a nutshell, we are still in the process of organising bits and pieces which should hopefully show up in the next couple of weeks. Rule-wise we are moving towards having a performance based specification of intake and exhaust: in place of specifying free area in front of intake, intake area, etc we will be measuring performances based on the CFD results. This is likely to be done through either of the following (to the participant choice): (1) intake/exhaust faces are created with imposed flow rate as done in KVRC 2015. The CFD calculation is used to calculate the pressure at the intake/exhaust and assess the performance, or (2) the participant can model the cooling duct (engine is done as per 1) and the CFD calculation is used to predict the flow rate. Based on the performance, the engine performance is derated in VirtualStopwatch. So overall the rules should be lighter, but would rely more on simulations...

Race wise we are probably looking at 5 races with the first race in April with one race every 6 weeks. Race tracks: if you have a favorite track that you would like to see, please send me an email (or a PM).

Marketing: it is still the last horse of the carriage, but I had a few ideas in mind: having a monthly participant profile and introduce a team section to the website, linking with universities, and we are still looking at providing a compliant design on which front, rear wings and underfloor can be modified to allow for a lower start-up investment. If anyone is keen to give a hand, it would be greatly appreciated.

Hopefully some more concrete information and data coming soon...

[CAEdevice]

I am back at my workstation (and in the UK and in reasonable health). OCCFD on Linux will be in the next release - although it will not support sending calculations to AWS (not an issue in my opinion) - and will support openfoam 3.0. I will run a few tests and if all goes well (it never does), KVRC 2016 will be run on openfoam 3.0.

Matteo, how is Karalit? Is it not supposed to be a LES based analysis rather than RANS?

KVRC 2016 status: In a nutshell, we are still in the process of organising bits and pieces which should hopefully show up in the next couple of weeks. Rule-wise we are moving towards having a performance based specification of intake and exhaust: in place of specifying free area in front of intake, intake area, etc we will be measuring performances based on the CFD results. This is likely to be done through either of the following (to the participant choice): (1) intake/exhaust faces are created with imposed flow rate as done in KVRC 2015. The CFD calculation is used to calculate the pressure at the intake/exhaust and assess the performance, or (2) the participant can model the cooling duct (engine is done as per 1) and the CFD calculation is used to predict the flow rate. Based on the performance, the engine performance is derated in VirtualStopwatch. So overall the rules should be lighter, but would rely more on simulations...

Race wise we are probably looking at 5 races with the first race in April with one race every 6 weeks. Race tracks: if you have a favorite track that you would like to see, please send me an email (or a PM).

Marketing: it is still the last horse of the carriage, but I had a few ideas in mind: having a monthly participant profile and introduce a team section to the website, linking with universities, and we are still looking at providing a compliant design on which front, rear wings and underfloor can be modified to allow for a lower start-up investment. If anyone is keen to give a hand, it would be greatly appreciated.

Hopefully some more concrete information and data coming soon...

Hi Julien, thank for all these good news and best wishes for 2016!

Here are my comments:

COOLING DUCTS: I think that the next season will be much more interesting!I agree with all your plans.

TRAKCS/RACES: I hope the "Efficiency track" will be 3 or 4 and "Extreme DF tracks" 2 or 1. Efficiency car set up is much more funny to design and to see, since it allows different design strategies. What about a final (efficiency) race with double or triple points? It would help teams with not many time and cpu reosurces, the have a slower development. It would help to keep the competition open untill the last race.
What about simulating to kinds of fast lap: "qualify lap" with all the power available, and "race lap" with the power allowed by the cooling efficiency. The faster "qualify" lap could receive some additional points (3,2,1): it would introduce more variables, with no computational costs (only a smal amount of work for Machin and VirtualStopWatch).

MARKETING: I think that your plans are very good, but the KVRC team is a bit too small. It would be great if every partecipant provided pictures and pre/post race comments. Some times I had the impression that only two or three teams collaborated about it.

FRAMEWORK: Ok for OF 3.0.0 (3.0.1). I have an Ubuntu Virtual Machine running with VirtualBox and I can provide it to partecipants that are not familiar with Linux.

OTHER: I have some more suggestions, about the car setup: working on a project involving my 2015 car (I'll have some news soon), I have been convinced that, to improve realism, the ride height would be slightly reduced (30mm instead of 40mm) and so the maximum height of the rear diffuser (275mm instead of 320mm).

Finally, you asked about Karalit. The solver is quite conventional (RANS based), but the mesher is "cartesian" and less influenced by the geometry (STL) quality (immersed boundary). I attach a new picture below, showing the effects of the heat exchangers on air temperature (I used a too big value for the energy dissipated by the heat exchangers, but it gives a qualitative idea of the results).

[CAEdevice]

Another small thing about marketing/visualization: it would be good to adopt a uniform way to show the podium cars after the race (same views, same sections, same details). Actually, I would avoid sections at all.

[CAEdevice]

Standard car: sorry to answer about it a bit late.
A 90% complete version of my 2015 car is available on Grabcad (keywords: kvrc, caedevice) in step and stl format.

I'm thinking about releasing a "customer" version of my 2016 car, with these differences from the official car:

- model cutted (capped) in front of the front of the front wheels and behind the rear wheels
- no rear wing
- cooling intakes a bit conservative, to make it less sensitive to front wing design
- only an update during season (probably after the summer break)

It would be great to have customer names like "x team powered by CAEdevice).

As a sponsor, I could provide also a more complete car, but only by request... I don't want to reveal too much too the best opponents (Mantium, JJR, Variante, TF, Kineuton, ... ). Niki would agree, but Toto did not

I think that (60% of the possibilities) my 2016 car will use the same 2015 layout (high nose and full open sidepods, it depends on the new rules). It would be great to have an alternative customer car with more classical lmp/c-group design.

[graham.reeds]

I would suggest putting it on GitHub. To get anything off grabcad you have to sign up. At least on GH you have a big download as zip button.

[CAEdevice]

I would suggest putting it on GitHub. To get anything off grabcad you have to sign up. At least on GH you have a big download as zip button.

I can use my website (or the KVRC official one) and a direct link, once the idea has been approved and refined.

[LVDH]

If requested I could also provide a car.