[ADGlassby]

Hi everyone, I'm having real problems getting a 2D moving mesh to work using SnappyHexMesh. I have looked though various examples of either 2D or moving mesh (using AMI) but I don't seem to be able to make the connection between the two concepts.

My mesh is (very basically at the moment) a circular (cylindrical) boundary with a rotor at the centre. I can create the basic geometry using snappyHexMesh to get the cylindrical mesh with the central rotor and it looks pretty good. I have used the sHM (castellatedMesh only run), flattenMesh, extrudeMesh, sHM (Snap only run). This produces a really good quality mesh. If I try to introduce the AMI interface, following the AMI (3D) examples, using an STL geometry file as the AMI location. This all disappears when I carry out the extrude step so the whole process fails.

I think I'm failing to understand the construction of the AMI interface. My understanding is that the AMI interface is made up of (in my case a circular rotating zone) a fixed FaceZone facing onto a moving (rotating) CellZone in which the rotor should be embedded. The rotor wall should be set up as a nonMovingWall which then causes it to rotate at the speed of the rotating mesh. The rotating cellZone slides past the faceZone and is allowed to do this because of the mesh construction and the declaration of cyclcAMI in the BC files and other relevant locations.

I have attached a basic picture of my geometry. Note that I am using sHM because the geometry I have in mind is a little more complex than the jpg I have attached.

If this is right.... How can I do this AFTER snappyHexMesh has developed the basic mesh?

I could REALLY do with some help now, does anyone have experience with 2D moving meshes (AMI style) using sHM??

Your help would be greatly appreciated. I have been going round in circles now with this for over a month and my head is beginning to spin. I'm sure this isn't as hard as I'm finding it!!

Best Regards

Andrew

[ADGlassby]

I have tried the following.... Instead of using a tube as the AMI interface STL geometry I have used a 3 dimensional Cylinder Primitive in my CAD application and then exported this as an STL file with vertical extent the same as my background mesh. I had noticed that the refinement stage in snappyHexMesh was complaining about the geometry not being closed. This hasn't improved the failure , however looking at the log file for sHM I have noticed that during the snap phase (morphing stage) there are no baffles created for the AMI zone which I find a little puzzling because baffles are created in the new annularThermalMixer tutorial.

Not sure what to make of this but I think this could be a pointer to the problem??

Andrew

[ADGlassby]

Sorry to keep posting.... when I try to run the solver (pimpleDymFOAM) I see that the rotor turns, which to me means that the rotatingZone has been recognised. But the AMI interface stretches rather than slides. This causes the solver to crash, obviously. so perhaps sHM is creating the cellZone but not the faceZone for the baffle creating I mentioned in the last post.

Andrew

[A.Wendy]

hi

have you created to seperate meshes?

maybee this thread could be usefull for you
http://www.cfd-online.com/Forums/ope...tml#post426084

best wishes

Andy

[ADGlassby]

Andy,

Thank you for your suggestion. I will rework my meshes as you suggest in your other post.

In short I have been trying to do all the meshing in one file which I suspect was the wrong way to do it.

I will repost here when I have results.

Best Regards

Andrew

[ADGlassby]

Hi Andy,

I'm running 2.2.x on Mac OS X and I get the following when I try to run pimplDymFOAM

--> FOAM FATAL ERROR:
Attempt to cast type wall to type lduInterface

From function refCast<To>(From&)
in file /Users/andrewglassby/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/lnInclude/typeInfo.H at line 114.

FOAM aborting

Don't know it you've seen this ?

I have managed to create the mesh so I'm going to follow it through more closely now to understand your logic.

Best Regards

Andrew

[A.Wendy]

Originally Posted by ADGlassby

--> FOAM FATAL ERROR:
Attempt to cast type wall to type lduInterface

hi,

it looks like you trying to set a boundary condition wich is made for walls to a non defined wall. so check the boundary file (constant/polyMesh/boundary) and compare it with you boundary condition in the 0-folder.

Andy

[ADGlassby]

Hi Andy,

I noticed in your mixer example (which is just about what I needed btw!!) that the mesh creation stops prior to changing the AMI_moving and AMI_static walls to cyclicAMI. I noticed that you commented out a line in you root Allrun file to copy a boundary file into the AMI directory. Should I be using createPatch to redeclare the AMI walls??

I can feel that I am almost there I've just got a small step to make to get there!

Your help is much appreciated!

Andrew

[A.Wendy]

Originally Posted by ADGlassby

Hi Andy,

I noticed in your mixer example (which is just about what I needed btw!!) that the mesh creation stops prior to changing the AMI_moving and AMI_static walls to cyclicAMI. I noticed that you commented out a line in you root Allrun file to copy a boundary file into the AMI directory. Should I be using createPatch to redeclare the AMI walls??

I can feel that I am almost there I've just got a small step to make to get there!

Your help is much appreciated!

Andrew

Hi,

i am not familar with the createPatch method. But you can split for example the script in two parts.

1st part before copy the boundary file
then modify the boundary file by hand
2. after copy the file.

best wishes

Andy

[ADGlassby]

Hi Andy,

I think I have done something horribly wrong! I managed to create the meshes and merge them into one then manipulate it to give AMI interface patches as your example does, however when I run the model I find that the WHOLE domain rotates not just the internal zone!!?? I'm a bit lost now because this looked like the way to go and it made real sense to me.

Do you think you could have a look at my model and see if you can find my slip? I have zipped it up but it is quite large, the rotor geometry file is quite big, but I have uploaded it into my dropbox here

https://dl.dropboxusercontent.com/u/...rgeTestAMI.zip

I've probably made a dumb slip somewhere but I'm not sure where!

The model creation is a bit complex because I'm trying to get a smooth 2D mesh for each part so there is a separate directory for the two sHM steps for each part of the model. The prep.sh files in each of the modelDomain and Rotor directories will build this happily.

Thanks for your help!

Best Regards

Andrew

[ADGlassby]

Hi Andy,

Did you manage to download my model zip file? Have you any thoughts yet?

Best Regards

Andrew

[A.Wendy]

Originally Posted by ADGlassby

Hi Andy,

Did you manage to download my model zip file? Have you any thoughts yet?

Best Regards

Andrew

Hi Andrew,

I am on a training until friday. I Will have a look then. but on the first view it was a little confusing structure^^

Andy

[ADGlassby]

Hi Andy,

I was wondering if you had managed to decipher my structure enough to comment on why I'm not seeing the right motion?

Regards

Andrew

[ADGlassby]

I've been trying to understand topoSet and cyclicFaces (and cyclicAMI) and I'm wondering , in my situation with a rotating zone, where should the "upwind" cells be located, inside the rotating cylinder (ie moving) or outside the rotating cylinder (stationary)? This might be the reason for my all moving mesh!! I've been working through the TJunctionFan example and here it defines the slave cells in the upwind location. My mesh wont have an upwind position since, ultimately the flow will cross, radially, the rotating mesh.

Thanks in advance

Andrew

[A.Wendy]

Originally Posted by ADGlassby

I've been trying to understand topoSet and cyclicFaces (and cyclicAMI) and I'm wondering , in my situation with a rotating zone, where should the "upwind" cells be located, inside the rotating cylinder (ie moving) or outside the rotating cylinder (stationary)? This might be the reason for my all moving mesh!! I've been working through the TJunctionFan example and here it defines the slave cells in the upwind location. My mesh wont have an upwind position since, ultimately the flow will cross, radially, the rotating mesh.

Thanks in advance

Andrew

hi andrew,

i haven't had to time to take a closer look yet. maybe today evening sorry.

[ADGlassby]

OK. The latest steps in this are:
I've looked into using setSet which seems to make sense to me..... I've merged the two meshes which gives two patches at the interface between the static zone and the moving / rotating zone.

Using these two patches and setSet I have created two cellZones and two faceZones one each for the static and moving zones. Ive checked the mesh using foamToVTK and looking in ParaFOAM. This SEEMS to look like other AMI interface models. I've checked constant/polyMesh to see what is in faceZones and cellZones and it looks like I have correct "looking" entries there.

BUT.... when I run the model the whole domain STILL rotates and not the inner moving zone, which I have check in the dynamicMeshDict to see that I have called the correct zone!

Complete loss now. My understanding was that mergeMeshes only brought the two meshes together whereas stitchMesh literally glues them together requiring a split again. I also thought I understood that identifying the faceZones either side of the AMI interface would effect a distinction between the moving and static parts of the mesh. As long as I identify the correct faceZone in dynamicMeshDict then that part alone should move (rotate in my case).

Surely working in 2D can't be the problem? Working in 2D should only be like working in 3D but with only 1 cell depth in the Z direction??

I have attached a link to my latest workings

https://dl.dropboxusercontent.com/u/...estAMI%202.zip

Any suggestions or pointers would be gratefully received.

Andrew

[ADGlassby]

Yay.... a minor success. I managed to get the zone rotating!

I followed the new annularThermalMixer tutorial released into the 2.2.x github. So the model is currently rotating in 3D fashion. I built the model without flattening and extruding between the castellatedMesh and Snap stages so its a little rough at the moment. The next step is to extrude the model to see if I can get it to 2D state.

It looks like the secret here is to allow snappyHexMesh to create the master/slave patches and the rotating zone.... this seems to sort out the couple between the face and cell zones etc...

Not too sure what extruding is going to do to this happy position though ??

Anyway I'll keep updating when I make successful steps (and failures I suppose)

Andrew

[giovanidiniz]

Hi, Andrew,

I read your post and I'm facing exactly the same situation.

I'm simulating a propeller and the whole mesh is moving.

Can you share exactly what you did to solve that?

Thanks!

[ADGlassby]

Giovani,

Sorry it's taken so long for me to get back to you.....

If you have a look at my entries in the discussion below (mine are towards the end) I think this should help you.

http://www.cfd-online.com/Forums/ope...lowing-up.html

Basically at that point I was merging two meshes, a central rotating mesh and an outer static mesh, and trying to get the central mesh to rotate. Linneman came to my rescue and suggested the splitMeshRegions which solved my 2D problem.

Best of luck!

Andrew