[abminternet]

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)

[abminternet]

Got kEpsilon running (well til 730 CAD but still )

[RalphS]

Originally Posted by abminternet

Got kEpsilon running (well til 730 CAD but still )

With deformAngle 5 , the simulation will run til 990

[hjasak]

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

[hjasak]

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

Signing off,

Hrv

[abminternet]

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 I was working with uncompressed files, so in case you work with compressed files, minor modifications may be needed.

Best regards,
abm

[abminternet]

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

[Peter_600]

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

--> FOAM FATAL IO ERROR:
keyword dynamicFvMesh is undefined in dictionary "/home/peter/OpenFOAM/peter-1.6-ext/run/simpleEngine/constant/dynamicMeshDict"

file: /home/peter/OpenFOAM/peter-1.6-ext/run/simpleEngine/constant/dynamicMeshDict from line 17 to line 24.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 396.

FOAM exiting

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

[abminternet]

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

[Peter_600]

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

[Peter_600]

Works like a charm Thank you!

[Peter_600]

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

[kalle]

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

[abminternet]

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.

[Peter_600]

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

[abminternet]

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

[Peter_600]

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

[Peter_600]

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

[abminternet]

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 )

[Peter_600]

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

engineTopoChangerMesh verticalValves