[Peter_600]

That was quick Thank you very much. I will have a look on it.

[Peter_600]

I didn t succeed in compiling the file you have attached. I get this error:

Making dependency list for source file derived/timeVaryingDisplacement/timeVaryingDisplacementPointPatchVectorField.C
SOURCE=derived/timeVaryingDisplacement/timeVaryingDisplacementPointPatchVectorField.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/triSurface/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/timeVaryingDisplacementPointPatchVectorField.o
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/triSurface/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/peter/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC Make/linux64GccDPOpt/timeVaryingDisplacementPointPatchVectorField.o -L/home/peter/OpenFOAM/OpenFOAM-1.6-ext/lib/linux64GccDPOpt \
-lOpenFOAM -liberty -ldl -lm -o OpenFOAM.out
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crt1.o: In function `_start':
/usr/src/packages/BUILD/glibc-2.11.2/csu/../sysdeps/x86_64/elf/start.S:109: undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [OpenFOAM.out] Error 1

[deepsterblue]

Please use 'wmake libso', and not 'wmake'

[Peter_600]

Thx. It worked. But still doesn t run.

Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh dynamicTopoFvMesh
--> FOAM Warning :
From function dlLibraryTable:pen(const fileName& functionLibName)
in file db/dlLibraryTable/dlLibraryTable.C at line 86
could not load libdynamicTopoFvMesh.so: cannot open shared object file: No such file or directory
Selecting metric Knupp
Selecting motion solver: mesquiteMotionSolver
Selecting quality metric: InverseMeanRatio
Selecting objective function: LPtoP
Selecting optimization algorithm: FeasibleNewton
Outer termination criterion (tcOuter) was not found. Using default values.
Time = 0.0001


--> FOAM FATAL IO ERROR:
file "/home/peter/OpenFOAM/peter-1.6-ext/run/simpleEngine/constant/pistonStroke.dat" does not exist

file: /home/peter/OpenFOAM/peter-1.6-ext/run/simpleEngine/constant/pistonStroke.dat at line 1.

From function IFstream:perator()
in file db/IOstreams/Fstreams/IFstream.C at line 168.

FOAM exiting

[deepsterblue]

Sorry about that. I've been running my development version. Comment out this line in constant/dynamicMeshDict:

dynamicFvMeshLibs ("libdynamicTopoFvMesh.so");

This should pick up the library version on 1.6-ext.

[Peter_600]

The same error.

[deepsterblue]

/home/peter/OpenFOAM/peter-1.6-ext/run/simpleEngine

Is this being run from that directory? Or have you extracted the tarball to another location? Please post the output error. This is really not that hard to figure out.

[Peter_600]

I shouldn t work so late Stupid mistake
It runs Thank you very much!!!!!

[kalle]

Really cool work, Sandeep! Thanks for sharing

Two questions: Can it run in parallel, and can it handle an opening and closing valve?

Regards,
Kalle

[deepsterblue]

Kalle,
- Parallel topo-changes: Not yet, but almost there - few bugs to iron out.
- Valve opening/closure: I think this one's a little easier to figure out. I like the approach of using a GGI interface for valves, along with a run-time modification of GGI patches to wall to define opening/closure events. This could even be as simple as maintaining the GGI patch as-is, and explicitly over-riding the fixedValue/fixedGradient fields to reflect a wall condition.

[kalle]

Thanks for your reply! Nice to hear that parallelization is under way.

I am having some contact with Martin Beaudoin regarding GGI. As it is now, the GGI cannot handle topological changes on the interfaces (as far as I could figure out). This would also be a problem for this case, except the issue with non-overlapping GGI patches you mentioned. Martin said he will have a look at it. Let's see what he comes up with!

Regards,
Kalle

[philippose]

Hello Sandeep (and everyone else),

A Good Day to you :-)!

First and foremost, I must say..... Hats Off to you Sandeep.... this new functionality in OpenFOAM-1.6-ext is really amazing :-)! And its great to see it in action :-)! Thanks a lot for all the effort you have put into it over the last few years!

After seeing the test-case which you posted on this thread, I decided that it is finally time for me to try out something which is more relevant to the areas where I would be using these dynamic re-meshing and mesh optimisation features.

I used the dynamicMeshDict in your test-case as a base, and built up a very simple Poppet Valve test-case with an initial mesh of around 75000 - 80000 tetrahedral cells.

I then prescribed a motion to the poppet using the same special boundary condition which you had included in your test-case.

Initially I focused purely on the dynamic-mesh part of it, and got it moving (along with the re-meshing) using moveDynamicMesh.

Next I included the Fluid part to the simulation :-)! An inlet and outlet pressure, and used pimpleDyMFoam to simulate the case.

And well .... :-)! I was pleasantly surprised to see it work like a charm right on the first try (with the fluid i.e.)..... :-)! Really cool....

I don't know yet if the fluid solution is accurate or not, and I did not pay too much attention to the initial mesh, but I can say.... I have never been able to move that particular simulation case by such a gross displacement without totally destroying the mesh.... Using your solver..... the mesh non-orthogonality never went above 52° :-)! And the simulation is still running as I write this....

As a small demonstration of my test-case, I have put in links to two videos.... one which shows a close-up of the area near the seat of the valve where you can see cells being destroyed and created.... and the second video which actually shows the evolution of the velocity with time...

The quality of the animations are not that great, and please let me know if the links do not work as expected :-)!


* Video - 1
https://docs.google.com/leaf?id=0B0s...0YWQ1&hl=en_GB

* Video - 2
https://docs.google.com/leaf?id=0B0s...xNDUz&hl=en_GB


Now.... for two questions:

1. Is there a small document which kind of roughly explains what each of the different options in the mesquiteSolver and dynamicMesh dictionaries do and how they influence the capabilities of the library?

2. What are the particular disadvantages of the current fluid side field mapping algorithms you have implemented, and are you looking at improving them significantly over the next year or so, or are these algorithms already robust and accurate enough for normal use?


I wish you a great day ahead :-)!

Philippose

[deepsterblue]

Philippose,
Great to see it being put to work... You could also do this in 2D, with a triangle-prism mesh.

1. The circCylinder3d tutorial should provide a rough guide for all available options. If something's not clear enough, post it here, and we can look into it.

2. The remapping in the current version on 1.6-ext is a simple inverse-distance based remap that's fast and reasonably accurate, but not conservative. My development version has an improvement that I'll put in at a later stage.

[abminternet]

@deepster: hey Sandeep, thanks for posting the case, I will have a look into it

@Peter: hi Peter, I ran the dieselFoam case, it crashes almost at the beginning. I guess it has something to do with the thermoPhysical properties, I hope it is nothing serious because I get a similar error when running sonicTurbDyMEngineFoam. I attach the log file here. As for the accordionEngineMesh class, does that mean they just put it in the description but didnt really implemented it? well and now to work on sandeeps test case!! let me know also about the accordionEngineMesh class, I will also try to have a look into it

[Peter_600]

I got exactly the same error. I also hope it is nothing serious.
Indeed it is written but not implemented. I am working on it. I think I am close to the solution. i keep you posted.
Peter

[Peter_600]

I think it is not necessary anymore to implement the piston layers to the accordionEngineMesh class. I think the thobois class is exactly that what I need. Does anyone knows something about it. I think it is the same as the accordionEngineMesh class, except it uses a layering for the piston movemoment.
I am struggling since one several weeks with implementing it into the accordionEngineMesh class. I hope this class can everything what I need

[abminternet]

@Josiah:

Hey Josiah,

I am making some modifications to the simpleEngine case, and would like to know how you found out the number (ID) of the detachFaces in the constant/engineGeometry file.

Thanks

[faithhidy]

Muller,

You can find them in polyMesh/faceZones file in ''constant" easily ( detachFaceZoneV1/V2). You can define them by setting faceSetsDict in "system".

Happy chinese new year~

Josiah

[abminternet]

hi foamers,

is anyone doing or has anyone done any simulations with mesh motion and topological changes for IC engine simulation??? i have done a few runs of the simpleEngine case with an incompressible solver just to observe the cold flow, but the results are still not good. Mesh moves and everything, but velocity field doesnt look very real, even for an incompressible solver. Then I decided to use a compressible one, sonicTurbDyMEgineFoam, which is the one I wanted to use anyway, but I keep getting the following error:

From function specieThermo<thermo>::T(scalar f, scalar T0, scalar (specieThermo<thermo>::*F)(const scalar) const, scalar (specieThermo<thermo>::*dFdT)(const scalar) const) const
in file /opt/software/openfoam/extend/OpenFOAM-1.6-ext/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 73
Maximum number of iterations exceeded. Rescue by HJ

Any suggestions??? I have been stuck here for a long while already, any help will be appreciated.

[Peter_600]

Hi abminternet

Yes, I succeed in doing an IC engine simulation with engineDyMFoam and the accordionEngineMesh class but wit 1.5-dev. I ve created an IC engine group at http://www.extend-project.de/ in order to discuss and gather all questions related to engines. I would like to have a look on your case.

With 1.6-ext I didn t run a case so far. I ve converted my stuff to 1.6-ext and it didn t work. I am working on it.
Peter