Hi Peter,

Is the solver you used compressible or incompressible? Is it for laminar or turbulent flow? Did you obtain accurate results? I am trying to use the compressible solver but it still won't work. Why don't you use the solvers provided in the extend version? I am not sure about the 1.5-ext version, but in the 1.6-ext there are solvers for turbulent and laminar flow, also compressible and incompressible, all with mesh motion and topological changes for ic-engines. Well here is a sample of my case, I ran it first with an incompressible solver, icoDyMEngineFoam, and got it working, but the results didn't seem to logical (I am trying to do a cold flow simulation). But this case is a compressible one with turbulence, ran with sonicTurbDyMEngineFoam, had to change the turbulence model to kOmegaSST because kEpsilon kept giving problems, perhaps you also have a suggestion there. Now I am stuck with this temperature error, looks like it diverges, can't get past the first iteration. Any Advice??

I posted the file in your ic-engine group in the extend-project community, since it was not small enough to fit here. the link is:

http://www.extend-project.de/compone...ble-solver#163

best regards

Sorry, I didn t read your post herer. Indeed it is strange.
I ve encountered difficulties in 1.6-ext with dieselFOAM and attachdetach meshmodifiers. My solver wont run with 1.6-ext.
So far I succeed in doing the meshmotion class I ve spoken about. If you are interested let me know.
Furthermore, I am about writting dieselEngineDyMFoam for 1.5-dev. It works but without valve closure (attachdetach approach) :(.
I think I need to update the boundary conditions arter introducing the attachdetach faces.
Any ideas?

To your problem, try to downgrade to 1.5-dev, if you do not have 1.5-dev, I can test it for you.
Peter

Hi Peter,

yeah I would appreciate it if you could try it with 1.5-dev. Maybe u can send me your code, let's see if I can catch the bug with the attachDettach by lookin at it :)

Hi

I checked your case with 1.5-dev (without a turbulence model, laminar) and it worked.

Peter

Hi Peter,

Sorry, I thought I've answered this, but it seems the response did not go through. I have fixed this in the preparation of the next release, but there is a bug in 1.6-ext that is causing you trouble.

It is to do with the state of turbulence on newly created patches after detach, where I have no data to map from.

Here is a quick fix for you:
- go to the turbulence model you are using (I assume compressible k-e)
- look for the beginning of the ::correct() function in kEpsilon.C
- add the following two lines at the very beginning:

k_.correctBoundaryConditions();
epsilon_.correctBoundaryConditions();

- recompile.

Please let me know if it works.

Apologies for the trouble,

Hrv

Hi Mr. Jasak

Thank you very much for your reply. I ve added your lines in the turbulence model I am using. Your suggest was right with the compressible kepsilon model.

After recompiling the turbulence libraries and rerunning my case the following message appeared just when the turbulence->correct() line is called in my solver.

Any suggestions?

Thanks in advance :)
Peter

I had a problem with my boundary conditions. I disabled all the wall functions.
Works now.
Thank you very much again.
Peter

Hi Peter,

Thanks for testing it. It worked with laminar solver in 1.6-ext too, but only up to 217 CAD :S. With turbulence model kOmega SST it gave some error when calculating temperature T, and kEpsilon didn't work, so I am going to make the changes proposed by Prof. Jasak and see what happens. Also, did the results you got look reasonable in this case or any of the others you have run? In my case, pressure is not changing!! :( So of course velocity doesn't change either, which is not very good because I am interesting in the cold flow... I will keep you posted of what happens :)

Hi Peter,

How did you disable your wall functions? Change them into "fixedValue" or ...?
I try the "fixedValue" BC for k and epsilon,but the janafError still exist. (I have added the two sentences which were provided by Prof. Jasak)

Thank you!

Josiah

Hi Josia

I ve put everywhere zeroGradient.

Peter

Hi Peter,

have you found a way to run the simulation without having to set zeroGradient all over after doing Prof. Jasak's modifications to kEpsilon and/or kOmegaSST ? I did the modifications on both, and I get the same error as you, it looks like the only way to get it to run is to set zeroGradient to all walls.

Hi Guys,

I just did a full day's work with a client doing internal combustion engines simulations in parallel with OpenFOAM and it all works fine. Can I please have one of the cases that is causing problem, because we've got the old gem: "it all works for me!" :)

The case would be used to debug the problem and I am happy to delete if afterwards if you have concerns about sharing it further.

I guess you know how to contact me - a Dropbox or similar file transfer would be best.

Hrv

Hello Prof. Jasak,

I have put together a copy of the simpleEngine case I am working with for you. So far, I think Everything works until I include the turbulence modeling. You can find the case under:
http://cid-7756d13637c02835.office.l...mpleEngine.tar

abm

By the way, I am using OpenFOAM-1.6-ext, and the solver is sonicTurbDyMEngineFoam, I also tried the changes you suggested above to kEpsilon.C (kOmegaSST ran the same way with or without the changes, it crashed after a few iterations)

Best regards

Got it, thank you - I will keep you posted.

Hrv

Hello again. I have fixed the problem and the two files you need are attached. I have also done a bit of clean-up in other parts of the library, but that will wait for the merge.

BTW, the case you gave me looks distinctly like someone playing with one of my old cases from ~2004 but it is really badly set up, with poor choice of discretisation schemes and boundary conditions. In any case, it works now...

Hrv

Missing attachments? Second attempt (apologies).

Hrv

Hello abm,

Thanks for your case. I have studied it.
First i run "moveDyMEngineMesh" to simulate and understand the mesh motion.
But the case didn't run to the end.

Regards,
Ralph


Time = 730
DICPCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for motionUz, Initial residual = 0.328438, Final residual = 6.0442e-11, No Iterations 13
DICPCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for motionUz, Initial residual = 4.00401e-11, Final residual = 4.00401e-11, No Iterations 0
Volume: new = 1.0007e-05 old = 9.99292e-06 change = 1.40833e-08
Motion continuity errors : sum local = 2.78751e-16, maximum = 9.5838e-15
ExecutionTime = 979.19 s ClockTime = 989 s
Time = 730.2

--> FOAM FATAL ERROR:
Face 2970 contains vertex labels out of range: 4(-1 -1 3917 3938) Max point index = 4048
From function polyMesh::polyMesh::resetPrimitives
(
const Xfer<pointField>& points,
const Xfer<faceList>& faces,
const Xfer<labelList>& owner,
const Xfer<labelList>& neighbour,
const labelList& patchSizes,
const labelList& patchStarts
)
in file meshes/polyMesh/polyMesh.C at line 757.
FOAM aborting

Yes - as I said, the case is badly set up. Go to the last time you have available and you will see that the layer addition/removal interface on the piston has ruined the last mesh layer - compare that with the mesh at the beginning and you will see what happened.

To fix this, you need to either adjust the stroke OR change the min and max layer thickness in the mesh modifier.

As a matter of fact, I got worried about this 2 days ago before I saw the error in setup, but this is all it is: poor setup. The code is correct and has been re-checked by the author (= me!) :)

Hrv

Hi Prof. Jasak,

Thanks for the fix. kEpsilon works now, although it stops at around 430 CAD (as soon as the exhaust valve opens). But as you mention, I still need to set up the case correctly so hopefully that will get the case running smoothly :). With the kOmegaSST model the simulation fails at the first iteration :S. In debug mode, the error is:

Program received signal SIGSEGV, Segmentation fault.
0x00002b3a7a460dfa in Foam::fvPatchField<double>::db (this=0x163b0190) at /home/albertom/software/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude/fvPatchField.C:160
160 return patch_.boundaryMesh().mesh();

@RalphS:
Indeed the case definitely does not have the best setup. I took this case from the internetnet, it came with a solver called icoDyMFoamEngine, which doesn't work in the current version of OpenFOAM any more. So many of the setup comes from that case, and for now I am trying to make it work with the current version of OpenFOAM ext, and with a compressible solver and turbulence modeling as well :) Also my experience is a bit limited, but as soon as I get to optimize the case, I guess that will change :D
In the meantime, any suggestions will be very helpful, I am still new to ICE simulation.

Hey Ralph,

i am guessing u ran the case with laminar flow right? Cause I got the same error when I ran it with laminar flow (it ran longer)

Got kEpsilon running :) (well til 730 CAD but still :D )

With deformAngle 5 , the simulation will run til 990 :)

Yeah, I've made one myself - attached. It has got proper boundary conditions a MUCH nicer layering mesh, I've checked the motion for fill 990 and solver is still running.

I will put this in as a tutorial. You may see little changes because I am changing the code at the same time to make things prettier, but this is what the setup should look like. I did not automate the case setup using Allrun - can someone please have a look. Regarding the sets and zones, please use setSet and give it batch command file - it is better than the dictionary.

Thank you all for kicking my vack side to do this :) BTW, in the next release you will get topological changes and engine simulations running in parallel, special engine parallel decomposition classes and a rewrite of domain decomposition and reconstruction tools in the presence of topo changes. All this courtesy of a sponsored project at Wikki (Thank You for supporting us).

Enjoy,

Hrv

All done and dusted - 990 degrees of flow running nicely.

Signing off,

Hrv

Allrun Allclean
 

Ok guys, I put together an Allrun and Allclean scripts, I add the attach/detach faces in the faceSets created to the engineGeometry file in the script, so that made it a bit more complicated, but now it is fully automated :D I was working with uncompressed files, so in case you work with compressed files, minor modifications may be needed.

Best regards,
abm

Correct Allclean.sh
 

oops, Allclean.sh doesn't seem to be doing the job, here goes a corrected version.

HI abm

I had a look on your case (cleaned up by Mr Jasak). Nevertheless, when I use your Allrun file, I get the following error

Before I will try to fix it by myself, I just wanted to clarify some things.
Do you use exactly the same case which Mr Jasak has uploaded? Otherwise would you mind to upload your case.

Thank you very much
Peter

Hey Peter,
sure thing, here goes the case, in fact I will send u one where I added the stems to the valves. U r right, the case as Prof. Jasak sent it does not run, this is because as he said in an earlier message, he is modifying the code at the same time for the next release, so some things may be in different places. If i remember correctly, it was just adding the motion solver to the dynamicMeshDict, because he put it in engineGeometry for the next release.

So I will post the case with the stem, it is exactly the same but with the stems for the valves :D

Thx !
I will have a look on it!
cheers peter

Works like a charm :) Thank you!

I was wondering if anyone of you managed to run an engine simulation with topological changes in parallel like it is announced for the the 1.6-ext version?

Peter

Hi! I think 1.6-ext is not much more parallel than 1.5-dev when it comes to engines. Parallelization of topological changes is for 1.7-ext (as Jasak mentions above)

Regards,
K

Hey guys, so I am trying to do a simulation of a real engine now, but there is a complication, the pistons are typically not flat but they have a bowl. So I was wondering if anybody has done this, or any ideas on how to do it? I was thinking using tetras for the inner bowl, and at the top of it, continue with prisms (that would make the connection between the tetras and prisms doable without a ggi). But then, I would need to move the bowl as a whole, and start doing the layering only in the prism part (cylinder). Does anyone know what I would need to change for this? I noticed a very early engine solver icoDyMFoamEngine, which also did topological changes (not to be confused with icoDyMEngineFoam) used to variables, offset and delta, to choose which cell layers to do the layering on.

Thank you for the answer kalle!

@abminternet The accordionEngine class has this feature what you are looking for. You can specify cells in the piston bowl which will move without being deformed but it has no layering for the swept volume.
Please tell me what kind of engine do you want to simulate. Probably I can help you out. I have added to the accordionclass the piston layer function. Since the piston of my engine is flat, I haven t tested the bowl function, but it s supposed to work as well.
Peter

Hi Peter,

The engine is a diesel engine with straight valves. So how did you go about the accordion engine mesh class? I mean, at the moment, the solver, sonicTurbDyMEngineFoam, uses the simpleEngineTopoFvMesh class, which uses the simpleEnginePiston class. Which solver are you using, is it also sonicTurbDyMEngineFoam? and how did you get it to use the accordionEngineMesh? if I try to set dynamicFvMesh to accordionEngineMesh instead of simpleEngineTopoFvMesh, I get an error, it says it is not a valid dynamicFvMesh.
Another question is, the description of the class says it is for canted valves, does this functionality work well? and can it do stright valves too?

Also, I saw that the layerAR class has this offset and delta funcitonality too for the layering, but I don't know where to implement it, any ideas?

Thanx :)

In order to use the accordionEngineMesh you have to take the engineTopoChangerMesh instead of the simpleEngineTopoFvMesh. Since you are modeling diesel engines, the accordionEngineMesh won t be the right class for you in my opinion. It has the capability for canted valves, which is a great feature, but in your case unnecessary. It uses an automatic mesh motion solver. It works very nice but requires in my opinion a lot of computational recources. I think with vertical valves, you can circumvent it and go for layering, as you are anyway already doing.
Nevertheless, the piston points movement what are you looing for is there implemented. I think it needs the entry in the engineGeometry file "pistonAuxPoints". In my case the piston is flat, hence I specify just an empty list for the piston points.
If you are lucky you will find this feature already implemented with the stuff you need. Just have a look in all of the engine classes. Otherwise, take it from there and make your own class.
I hope there is someone out there who can help you more. I am pretty sure a lot of useres have beenn faced by this issue already.


cheers peter

check the engineTopoChangerMesh class ->verticalValves.
This can be probably a good start.

Hey Peter,

Thanx for the tips, one question though, I seem to be a bit confused. So I am using sonicTurbDyMEngineFoam and it includes engineTopoChangerMesh.H already, so simpleEngineTopoFvMesh is selected in the dynamicMeshDict, but there, if I select accordionEngineMesh it gives me an error
Valid dynamicFvMesh types are :

19
(
dynamicTopoFvMesh
simpleEngineTopoFvMesh
attachDetachFvMesh
linearValveLayersFvMesh
multiMixerFvMesh
linearValveFvMesh
dynamicBoxFvMesh
dynamicMotionSolverFvMesh
mixerGgiFvMesh
movingConeTopoFvMesh
turboFvMesh
dynamicBodyFvMesh
subsetMotionSolverFvMesh
solidBodyMotionFvMesh
dynamicRefineFvMesh
mixerFvMesh
dynamicInkJetFvMesh
movingBoxFvMesh
staticFvMesh
)
any ideas?

(BTW, I am also interested in tilted valves :), hence the problem )

If you want to use the verticalValves class you need use in the engineGeometry file ->

engineTopoChangerMesh verticalValves