Are moving mesh capabilities on the MFIX horizon? Or has anyone tried this that can provide tips about what subroutines need be modified?
The mesh I want to move is very simple (rectangular prism made of cubic mesh cells) and just vibrates along a predefined trajectory. It seems like it should be possible to create a library with timestamped mesh files that the solver can reference for this.
There is a basic moving STL geoemtry capability for DEM granular flow. Please take a look at the mixer_3d and conveyor_3d examples.
This only works for pure DEM, correct? Unfortunately the gas-solid coupling here is non-negligible.
I have used the moving cylinder with a fluid too, here with water
Looks nice! Have you gotten decent experimental agreement with this approach?
My system has a porous wall that moves in two dimensions, so I either need a mesh that moves with it or some kind of algorithm that deletes/adds mesh cells as the wall moves. I’ve tried a fluctuating gravity condition too, but that seems to effectively force the fluid and particles to move together more than they really would, and thus underestimates drag. I’ll cross my fingers that we can figure something out!
Hi,
can I use a moving stl to simulate a stir in fluid？
Kind regards
Yuanhe
have you tried this yet? Having a cylinder and a stir in middle, and rotate the cylinder?
have you managed to get that working?
Eric,
So I looked into this, and unfortunately for my system this is a MUCH more complicated endeavor than I initially thought. Because the moving geometry of interest is porous and inside my simulation domain (gas flows through it), I would need a moving STL with a porous jump condition and remeshing as the STL moves through the simulation domain. Alternatively, I looked into using a rigid body moving mesh instead, which is usually done by implementing a relative velocity formulation for the gas phase (you can read the ANSYS Fluent documentation on moving meshes if you’re interested), but this also creates issues. This formulation is enough for Eulerian-Eulerian multiphase flows but not Eulerian-Lagrangian, where the moving mesh actually changes the particle-wall overlap on each time step. You could get this to work but it would be a very significant coding endeavor.
I’ve found a workaround where I kinematically prescribe velocities to a series of moving “wall particles” that approximate my vibrating porous media, and this seems to work alright. It’s an approximation to the real-life situation, but until someone comes out with a moving mesh package & porous media formulation that is CFD-DEM compatible, I think that is the best we can do. EDEM might be able to do this but unfortunately I don’t have access to EDEM 
Hi Julia,
Thanks for the explanation. Seems very complex indeed. So you have a porous plate of DEM particles that moves up and down? Is that in air?
Eric,
Yes that’s correct; I use a layer of DEM particles to approximate the porous plate, and this vibrates in two dimensions (up and to the right, down and to the left). We typically run inert gases through the system (i.e. nitrogen) with trace amounts of reactive gases, but for some of my multiphase flow studies I have used air as the carrier gas. It simplifies the imaging setup if we don’t have to worry about reactions fouling up the viewing window 
when I run “mixer_3D” it doesn’t work from the start when I run the mesh. Precisely because of the presence of internal surfaces. For the “conveyor_3D”, it works because the Keyframe function is used.