[Piterhawk16]

Hello everyone!

I have a problem regarding the new ACMI-Patch which was introduced in the latest Open-FOAM version 2.3.0.

I want to simulate the velocity distribution in a journal bearing with a static inlet and a rotating outlet hole.
Therefore, I’ve tried to use the tutorial oscillatingInletACMI2D and to transform it on my journal bearing example. After I had created my mesh (consists of 10 blocks - see mesh.jpg) using blockMesh utility, I made some necessary changes in the file dynamicMeshDict (the most important: oscillatingLinearMotion -> rotatingMotion). In my example, the outlet hole (block no. 0) should rotate with a constant angular velocity (omega). Unfortunately, the simulation interrupts after some time steps. I only get an error message: “Floating point exception” (see: error.jpg) because the timePrecision significantly increased (see: time.jpg).

Does anyone of you know if it is possible to simulate a rotating movement (with a rotatingMotion function) using the new ACMI-patch? Or does anyone know the solution to my problem?

I would be very grateful for any help! Thank you in advance.

[wyldckat]

Greetings Piterhawk16 and welcome to the forum!

Sorry for the late reply, but only today did I manage to look into this.

Although since so much time has passed, I don't know if you've managed to solve this issue already or not. If not, I strongly suggest that you upgrade to OpenFOAM 2.3.x, because some bugs have already been fixed in the ACMI related code, since 2.3.0 was released.

Best regards,
Bruno

[Piterhawk16]

Thank you wyldckat for your reply. I tried to solve my problem with OpenFOAM 2.3.x, but unfortunately unsuccessfully.

I also tried to solve my issue (journal bearing example) using MRF-algorithm (tutorial: mixerVessel2D; solver: simpleFoam). But this method has brought any rewarding results too.

Do you know if it is possible to simulate the velocity distribution in a journal bearing with a static inlet and a rotating outlet hole using MRF-algorithm? Or is this method useful only for symmetric geometries such as tutorial mixerVessel2D?

Thank you in advance for your reply!

Best regards,

Piotr

[wyldckat]

Hi Piotr,

Sorry for the really long delay, but only today did I finally manage to come back to your question I have no idea if you've managed to solve your problem, either way, here's what I know...

From what I can understand, the ACMI patch with dynamic meshing is what you're looking for. Problem is that ACMI in OpenFOAM 2.3.x still has several flaws and it's possible that this is one of those untested situations. I did some checking of how it works and wrote it here: http://www.openfoam.org/mantisbt/view.php?id=1450#c3770 - essentially there are actually 4 patches needed for each "cyclicACMI" pair or patches: 1 wall and 1 cyclic for each side.
The other detail is that your moving outlet cannot be simply an outlet patch, it will have to be at least a small tunnel/box, so that the opposite side of the tunnel/box is a standard outlet.

MRF is mostly used for rotating blades, i.e. rotating environments with objects inside the zones that are rotating. In theory, it can be used for what you're trying to do.

If you still have problems with this and if your geometry/mesh cannot be shared publicly, then if you could share a simple test case, I or anyone else can have a look into this. Otherwise, setting up such a test case takes quite sometime to do and I personally don't have enough time to do it

Best regards,
Bruno

[mneben]

Hello Bruno and Piotr,

I've created a test case with a similar geometry. With this test case you can see that the simulation will always fail until you've reached a rotation angle of around 90 degrees. I've checked it with different boundary conditions and angular velocities

Greetings
Matthias

[wyldckat]

Greetings Matthias,

Many thanks for the awesome test case!

I tested with 2.3.x, although not with the latest source code, but it's a build from about a month ago. Here's what I know and managed to figure out:

1. The ACMI implementation in 2.3 has issues. It doesn't work in every possible situation.
2. One such example, which is similar to to this test case is this: http://www.cfd-online.com/Forums/ope...interface.html - in which case, it's as if it were the test case you have, but with an infinite radius. The problem there is when using compressible flow.
3. After examining the example you've provided and the reference tutorial case in OpenFOAM, namely "incompressible/pimpleDyMFoam/oscillatingInletACMI2D", here's what I can figure out:
   1. Attached is the tarball "myTestCase2WithIO.tar.gz", which provides a modification of your case, based on your test case, as well as based on the tutorial case.
   2. The rotation speed is lower than the one you had and there is inlet and outlet flow.
   3. If I remember correctly, in 5 seconds of simulation time, it did not diverge.
4. I've also attached the modified variant with all closed walls "myTestCase2Walls.tar.gz", which is configured similarly to your case. I've tried to improve a bit more on the boundary conditions, time step, maximum Courant number and so on, without success. The problem is usually related to a weird vortex being generated close to the blockage wall in the inner side of the ring, but away from pipe that is rotating. The issue occurs within 0.1 to 0.2 seconds and seems to be related to two reasons:
   1. Insufficient mesh refinement.
   2. Time step too large.
5. The conclusion I draw from this is that:
   • There is something missing in the ACMI implementation that can properly handle high speed or high tangential tension values near the walls where the open ACMI boundary overlaps the wall boundary.
   • This would explain why the first modified test case "myTestCase2WithIO.tar.gz" and the tutorial case "incompressible/pimpleDyMFoam/oscillatingInletACMI2D" work just fine, since the flow is mostly perpendicular to the ACMI boundary.

I'm not familiar enough with foam-extend, but you might want to try out foam-extend 3.1, which has GGI implemented a lot more time ago than OpenFOAM, and I think it has this feature as well.

Best regards,
Bruno

[mneben]

Hello Bruno,

I’m quite impressed of your efforts you spend to this topic.

At first I had the same idea, that there is a problem with strong tangential flows on the surface. So I’ve created a modified test case with an inflow and outflow channel. In this simulation the flow is at first dominated by the normal flow but later on it is tangential to the acmi patch. So it crashed in the same way like in the old test case.

Accidentally I started the case from the latest timestep and surprisingly the simulation went on and reached a greater angle until it stopped again --> Restart again from the latest timestep and wait until it crashes and so on …
Thi phenomenon led me to the conclusion that there is maybe surface normal variable, which won’t be updated during the run.

Now I try the same with of-extended and will report it to you.

Thanks for you help
Matthias

[Tobi]

Very nice discussion, thanks for that.
I am also interessted in such a case for a new tutorial that fits the ACMI with rotation (: Tomorrow I will check out your cases but at the moment I only have a problem in the ACMI faces. My static patch is also moving and it seems that the patches are not sliding. If you know a simple answer just tell me. Maybe I will find the answer in your cases.

I will check it out.

[akidess]

Could be related to this bug:
http://openfoam.org/mantisbt/view.php?id=2057

[Tobi]

Thanks for the hint.
It seems to be the same problem. I will further investigate into that.

[wyldckat]

Quick note: AFAIK, ACMI in OpenFOAM is still in need of some repairs. I don't know if this has been solver in OpenFOAM+ or not.

A list of bug reports about ACMI are under this tag: http://openfoam.org/mantisbt/tag_vie....php?tag_id=77 - have a look at the upper right corner "Attached Issues".

[Tobi]

Dear Bruno & all,

today I finished the project of ACMI and I published a tutorial. See here: http://www.cfd-online.com/Forums/ope...tml#post599355

[mneben]

Dear Bruno&Tobias,

I recently checked this old testcase with the latest OpenFOAM version and now its working perfect

Additionally I successfully checked wether ACMI is working with the movingWalls boundary condition.In the attachment you can see the two testcases and two corresponding videos.

Greetings

Matthias

[Tobi]

Dear Matthias,

thanks for the contribution. For me it was already clear, as I posted in the last second post (counted from here). But anyway, I think it is good for other people to know. However, ACMI cannot handle other stuff like that:

https://www.youtube.com/watch?v=XC-_F42CZjg

But it is working nice like here:

https://www.youtube.com/watch?v=KCIBzVWyqzg

https://www.youtube.com/watch?v=RqgKgcnZtrg

and of course the best case:

https://www.youtube.com/watch?v=ZsdoAQ9hQUM

[KateEisenhower]

Originally Posted by Tobi

[...]

and of course the best case:

https://www.youtube.com/watch?v=ZsdoAQ9hQUM

Hello Tobi and thanks for your post. One question regarding the above mentioned video: Why do you need ACMI for it? Can't this be accomplished with the normal AMI?

Best regards,

Kate

[Tobi]

Hi Kate,

you can use AMI but then you have to make the AMI between the rotor blades and the stator which forces us to make a very fine mesh here in order to get the AMI. The problem here was, that the blades are very close to the stator walls and therefore ACMI is in my opinion the better choice. To reduce the number of cells and avoid bad mesh quality here, we can use ACMI to make the interface directly in the plane of the stator walls. I hope that I explained it a way that you get the point. Another possibility would be using AMI with MRF but this would only be working, if the fan is moving very fast. Otherwise, the velocity and thus the pressure field will be complete different and therefore the results. This was proofed by some colleagues from Linz.

By the way, with stator walls I mean this small connection part which holds the electro engine in the middle (hope it is clear).

[Tobi]

Hey all and Kate,

just one comment. For MRF we do not need to use AMI - it is possible but not needed. So it would be better to avoid it (AMI -> cost resources).

[KateEisenhower]

HI Tobi,

MRF is no option for me at the moment, but ACMI works fine in my case. Thanks, Kate

I had a look at your video again. It looks like the blades are not even touching the stator plane. Hence I don't see a reason why you need ACMI then, or how you could get away with fewer cells than using AMI.
One cell between the blade and the interface should theoretically be enough for both AMI and ACMI.
You don't have to spend your time answering this. I have solved my case anyway, but it would be really interesting.

Best regards,

Kate

Edit: Okay, I thought about it again, it would probably look like this:

Stator 1cell AMI-interface 1cell blades

With ACMI the following is possible:

Stator ACMI-interface blades

Right?

[Tobi]

Hi Kate,

yea you are going to the correct direction
Instead of explaining it, I made a draft - hope it is understandable.



The AMI and ACMI is like a processor BC. We do not have any information of the neighbor cell center value, so having only one or two cells might be not a good choice.

[greel]

To run ACMI using mesh made in salome.

Hi guys. I'm trying run ACMI tutorial of "oscillatingInletACMI2D" with some different things.

My cases and goals in this project are:

- To run the tutorial using a mesh made in salome. (It's a restriction of this project)

- Case 1 = To run the simulation with a quad mesh made in salome (I add salome case). Result C1: IT DONE with any type of issue!

- Case 2 = To run the case 1, but creating a tag of the movil part of the mesh in salome called "inletmovil" in order to not modicate the box coordinate into "topoSetDict". The goal is make a movil domain automatic.
Ex:

// Create cellZone for moving cells in inlet channel
{
name inletChannelCellSet;
type cellSet;
action new;
// source boxToCell;
source zoneToCell;
sourceInfo
{
name inletmovil;
// box (-100 -100 -100) (1.0001 100 100);
}

Result C2: The case runs well. But It necessary after run "createBafflesDict" to reemplace in cell/polymesh/cellZones "inletmovil" for "inletChannel". DONE, but I would like that word in cellZones to be reemplazed automaticly before run pimpleFoam!

- Case 3 = To run the case with a tetra mesh created using salome. In order to create this mesh I used NETGEN 1D-2D-3D method (mandatory) because I want then convert that mesh in polyhedrical mesh in a future case when this tetra case working well.
The tetra mesh was created in this way. Mesh of movil and static parts separatly, afterward I composed both. This procediment was created in this way because I needed to create "couple1" and "couple2" for the interfase.

Result C3: The mesh create all of boundary and the cellZone, but for some reason the mesh in the interfase between both domain are connected. Therefore, the case is not sliding and finaly diverge because deformation. (This case need also change cell/polymesh/cellZones "inletmovil" for "inletChannel" before run)

- Case 4: To run case 3 using polyhedrical mesh. Result C4: WAITING!

--
I add the case of quad and tetra cases, and salome setup. I hope that you can help me to resolve this issue or give me some hint that might be helpfull.

https://drive.google.com/open?id=1Gn...YjVkJQJCD3cKz4


Thank you in advance !!