[MVRC] Mantium Virtual Racecar Challenge 2016

[LVDH]

I wanted to have a good look at what is happening at the monitored surfaces during the first race. It is possible that something is wrong with my implementation. It could be that the face orientation affects the integrals. Maybe what is positive and negative depends on that. On my car it works but that does not mean it will for every car and stl file.

Regarding your crash it looks like the coarser mesh somehow closed your exhaust. OF crashes when specified monitoring surfaces are not present. As this one seems to have disappearing during meshing MWFlow could not know in advance. You could manually modify the snappyHexMeshDict to confirm my suspicion. Somewhere it will say engine_exhaust followed by something like this (5 5), I do not know the exact number right now. Increase both numbers with one. So if it was (5 5) to (6 6). If the case now works, we spotted the problem and I can put a fix into MWFlow.

[CAEdevice]

I wanted to have a good look at what is happening at the monitored surfaces during the first race. It is possible that something is wrong with my implementation. It could be that the face orientation affects the integrals. Maybe what is positive and negative depends on that. On my car it works but that does not mean it will for every car and stl file.

Regarding your crash it looks like the coarser mesh somehow closed your exhaust. OF crashes when specified monitoring surfaces are not present. As this one seems to have disappearing during meshing MWFlow could not know in advance. You could manually modify the snappyHexMeshDict to confirm my suspicion. Somewhere it will say engine_exhaust followed by something like this (5 5), I do not know the exact number right now. Increase both numbers with one. So if it was (5 5) to (6 6). If the case now works, we spotted the problem and I can put a fix into MWFlow.

In the SnappyHexMesh dict, the refinement of the engine inlet/exhaust is already set to (6 6).

[LVDH]

So try (7 7) and see if the case then runs.
Or have a look at the mesh in Paraview and try to see if you have a patch called engine_exhaust.
Just from reading what you posted it seems as if it somehow disappeared.

[CAEdevice]

So try (7 7) and see if the case then runs.
Or have a look at the mesh in Paraview and try to see if you have a patch called engine_exhaust.
Just from reading what you posted it seems as if it somehow disappeared.

ok, I modified the refinement level, but I will launch the simulation this evening (I need all the cores of my ws now...)

[CAEdevice]

I added the suspensions to my model: in which folder should I place them? Should I combine them with the body? Are interferences allowed?

[LVDH]

You can add as many parts as you want into any folder. There is no necessity to combine everything into one file.
So, once more I have to direct you to the readme (yes, it has been pointed out now that it has its missing elements) but I think to remember that as example of how the fill the vehicle_body folder there were parts like main_body, floor etc.
So, yes, add the suspension parts to the vehicle_body folder.

[CAEdevice]

Ok, sorry about not reading the readme accurately, but I still have a doubt (I don't have the document on the smartphone): it is ok if the solids (not the surfaces defining a solid) are intersecting (es. a rod that extends inside the body)?

[CAEdevice]

I have another doubt, not related to WFlow, but to VirtualBox.

I noticed that, despite I assigned a huge quantity of RAM (24gb) to the linux virtual machine where OF is installed, the virtualbox process uses a small quantity of RAM (less then 300mb!!!). On the contrary it writes very often on the (physical) disk. The simulations of the old KVRC required about 6-8gb of RAM, I think that the virtual machine needs similar values...

[Ft5fTL]

0

I have another doubt, not related to WFlow, but to VirtualBox.

I noticed that, despite I assigned a huge quantity of RAM (24gb) to the linux virtual machine where OF is installed, the virtualbox process uses a small quantity of RAM (less then 300mb!!!). On the contrary it writes very often on the (physical) disk. The simulations of the old KVRC required about 6-8gb of RAM, I think that the virtual machine needs similar values...

It doesnt show correctly on task manager. I had around %90 ram usage but the virtualbox was shown around 350-400 mb on my task manager.

[LVDH]

Ok, sorry about not reading the readme accurately, but I still have a doubt (I don't have the document on the smartphone): it is ok if the solids (not the surfaces defining a solid) are intersecting (es. a rod that extends inside the body)?

Yes, I would even recomend having a bunch of intersecting closed geometries to form the car. It is much easier to design that way.

[CAEdevice]

Ok, sorry about not reading the readme accurately, but I still have a doubt (I don't have the document on the smartphone): it is ok if the solids (not the surfaces defining a solid) are intersecting (es. a rod that extends inside the body)?

Yes, I would even recomend having a bunch of intersecting closed geometries to form the car. It is much easier to design that way.

It is not usual for me, I have a too parametric and associative mind

I have good news about the "exhausts" surface iusse: increasing the "refinement level" (snappyHexMesh settings) to (7 7) the simulation runs without problems.
Another good news is that with a high quality STL, the inlet and outlet cooling flows converge.

I still have doubts about the direction (+/-) of the flows: I would expect positive pressur eintegral on the engine intake, and opposite signs for the flow passing thorugh the inlet and outlet coolling surfaces.

Here are the coefficinets:

Code: Select all

forceCoeffs forceCoeffs output:
    Coefficients
        Cm       : 0.65407	(pressure: 0.63739	viscous: 0.0105969	porous: 0.00608306)
        Cd       : 1.75994	(pressure: 1.62579	viscous: 0.0976902	porous: 0.0364564)
        Cl       : -5.46846	(pressure: -5.45329	viscous: 0.0119401	porous: -0.0271042)
        Cl(f)    : -2.08016
        Cl(r)    : -3.3883

faceSource faceSource_engine_intake output:
    areaIntegrate(engine_intake) for p = -19.9438 *** Should it be positive?

faceSource faceSource_engine_exhaust output:
    areaIntegrate(engine_exhaust) for p = -0.563386

faceSource mSurf_cooling_inlet output:
    areaNormalIntegrate(sampledSurface) for U = (-0.821413 0 0)

faceSource mSurf_cooling_outlet output:
    areaNormalIntegrate(sampledSurface) for U = (-0.816774 0 0) *** Should it be positive?

This is the engine intake pressure distribution (imposed flow = -0.15 m3/s)

[CAEdevice]

0

I have another doubt, not related to WFlow, but to VirtualBox.

I noticed that, despite I assigned a huge quantity of RAM (24gb) to the linux virtual machine where OF is installed, the virtualbox process uses a small quantity of RAM (less then 300mb!!!). On the contrary it writes very often on the (physical) disk. The simulations of the old KVRC required about 6-8gb of RAM, I think that the virtual machine needs similar values...

It doesnt show correctly on task manager. I had around %90 ram usage but the virtualbox was shown around 350-400 mb on my task manager.

Thanks! Is there a way to measure the Virtualbox actual RAM consumption?

[CAEdevice]

Is someone using SurfaceLIC with Paraview 5.1.2? It seems there is a issue (the app hangs). Could it be caused to the "not reconstructed" structure of the results?

[RicME85]

I have had it hang with other versions. I find Paraview to be a bit temperamental with some things like that

[CAEdevice]

I have had it hang with other versions. I find Paraview to be a bit temperamental with some things like that

I would try by recostructing the case, but I prefer to wait for LDVH's opinion.

http://www.openfoam.com/version-v3.0+/parallel.php