Learning Forum

[Diego Fernando Garcia Gonzalez]

Hello everyone,

I have had a particle sedimentation problem for some time that I have not been able to solve.

I want to run a transient simulation of freely falling single particle in 2D as well as in 3D, in a Viscous Stagnant Fluid. To do this, I use overset mesh method and SixDOF solver to solve compute external forces and moments resulting from the interaction of the body with the fluid.

For this, I also have used a UDF in which I defined the properties of the SixDOF Solver ( mass and moments of inertia) and which was also adapted to track the components of the velocity of the CG during the fall.

I have already tested it and it is functional, however when I define very small mass units for the solver (1e-3 kg, 1e-4 kg...) divergence is detected in AMG solver with a floating point exception.

I have tried many options and I have not been able to solve it, I have changed the mesh, with quality monitoring, trying different meshing methods, turbulence models, CFL number, different time step size, using dynamic meshes instead of the Overset mesh method , different solution methods, pressure-velocity coupling, One DOF analysis but nothing has worked.

If anyone has experience on this topic, please suggest me something helpful. I can share the case files and images. I am using Ansys Fluent 19.3, 22R1 or 23R2. Thanks 

[Rob]

If you set a very small mass, what does that equate to re the particle density? How does the particle size look relative to the domain cell size? If we cheat, is there a reason for moving the particle, or can you move the fluid? 

[Diego Fernando Garcia Gonzalez]

I appreciate your quick response,

To be a little more specific, I am interested in tracking the sedimentation of particles, which are not even that small 500-2500 µm (2.5 mm), the density ratio can range between 1.1 to 2.5. Regarding the particle size relative to the domain cell size, I'll show u two images of 2D circular and elliptical cylinder.

 

   

 

I would be interested in other points of view, and the option of being able to move the fluid instead of the particle could be considered. However, I don't know if this is the right way to solve the problem, since I would like to be able to not only obtain the fluid dynamic forces (drag, lift and torque) during settling, but also track the particle's trajectory and velocity.

[Rob]

The above should work, can you check for orphan (I think that's the one) cells when you switch on overset? If you have too many of those things tend to go wrong. Then, if you work out the terminal velocity of the particle, how many time steps will it take to cross one cell of your domain? Ie are you resolving time correctly? 

The 6DOF example in Fluent's Help ought to cover what you're doing very nicely. But I suspect it's all laminar flow. Just check the domain scale to make sure you've not set something as (near enough) zero mass. 

Moving the fluid will allow forces to be calculated, and you can run transient to see the shedding effects. Torque will be an interesting one, and I'm not sure how large a domain you'll need to allow the solution to develop to see if you get a tumbling effect: sphere/circles are notoriously hard to model. 

[Diego Fernando Garcia Gonzalez]

 

Hi Rob.

 

I have experience using the Overset Mesh Method and I’ve always tried, if possible, to have a ratio of 1:2 or even 1:4 between the background cell size and the overset zone cells. I also execute different treatments for the overset mesh through TUI, so I always seek to avoid the appearance of orphan cells. The only time I expect orphan cells to appear is when the particle is near the bottom of the tank. Regarding resolving time correctly, I hope that the particle can reach a terminal velocity of 5 cm/s… from this I can determine the must time steps to cross a cell in my domain (background). I am using a time step of 1e-4 even less, so if the particle reaches terminal velocity, it takes 21 time steps to cross a domain cell. trust me, I have already I’ve tried many things, from modifying the mesh, the time steps to the solution methods and many other things… but nothing has worked when I define small mass values in the properties of the SixDOF solver .

 

I’ve tried the examples in the ANSYS FLUENT tutorials, and there is nothing different from anything I’ve configured before. I understand that SDOF_properties works with the SI units, for which I customize only the mass and moments of inertia. With all this, I still don’t understand how to define a mass value of eg. 4.3e-4 kg, it can cause problems for me.

 

The case remains as a laminar flow, If you need more information don't hesitate to ask me.

 

If u have a different methodology to solve it, I'll gladly try it.

Thanks!!.

 

[Rob]

That should behave. Remember in 2d you're solving a 1m thick cylinder, rather than a sphere - that may need accounting for?

[Diego Fernando Garcia Gonzalez]

Yes Rob, I take this consideration into account.

 

In the case of the elliptical cylinder (major axis a=0.1cm; Minor axis b=0.05cm and ρ=1.1g/cm3) the resulting mass is 0.000432 kg, the calculation runs normally until reaching a point where stabilization problems are generated and the case diverges.

 

When I carry out the case of oblate ellipsoids (3D), it has the same incidence, in this case the densities are similar to those described in 2D, but the mass values are much smaller, and this is where I present the greatest divergence problems. If I define mass values of the order of 0.1 to 1 g, these problems do not arise.

[Rob]

Does it behave if you scale the fluid density too? I'm wondering if the eddy shedding returns daft torque values given the scale? How does the flow look just before divergence?

[Diego Fernando Garcia Gonzalez]

 

Hello rob,

 

The way I understand it, density is an intrinsic property , it isn’t clear to me when you’re referring “to scale fluid density”. Could you explain it to me?. 

 

By the way, Initially I’m not monitoring the torque, I am mainly interested in being able to know the particle position and velocity during the fall. When I haven’t problems with the methodology, Imma estimate the Drag, Lift and Torque.

 

The divergence occurs from one moment to the next, I attach two images of the SixDOF solver history report where it’s possible to see reasonable results of the position of the Particle and after a while daft results until divergence.

 

       

 

BONUS: report oblate cylinder fall:

 

Regards.

 

[Rob]

OK, and the flow field at that point? The table shows it's gone wrong, I'm hoping the contours in the few time steps leading up to that will show why. 

Density for the particle falling is relative - ie it's based on the density difference with the carrier fluid. If the problem is linked to precision then 1g particle in 2500kg/m3 liquid (same density difference) may avoid the issue. 

[Diego Fernando Garcia Gonzalez]

 

Hello Rob

 

I don’t have info of the flow field, I’m gonna run the case again and monitor the flow field just before the divergence and I’ll tell you.

 

Regarding the scale particle density, I think I understand you, correct me if I am wrong. What you mean is that the dynamics of the free falling particle is governed by the difference in the densities of the body and the carrier fluid, This is clear to me, now you tell me that I can scale the densities maintaining the difference between both, in order to avoid divergence when I define smaller values of the mass, this without scale the fluid domain. Imma try it.

 

…..Another point of interest in my analysis is to compare numerical soltion with an analytical solution of the Basset–Boussinesq–Oseen equation.

 

Rob, I would like to know if in this same thread, you could give me some suggestion to stop the calculation when the particle reaches the bottom of the domain.

 

[Rob]

The density comment is correct. Let's see if increasing the mass to reduce potential precision issues fixes this. 

Stopping the particle is more difficult as there isn't (yet) a IF something happens STOP command. In theory the convergence checks can be triggered by setting scalars when things happen but in practice it's usually easier to just keep an eye on the model. 

[Diego Fernando Garcia Gonzalez]

Thank u Rob, When I get results I'll let you know.

 

I was researching this topic and I know that a command called cx-interrupt “exists” in the SCHEME language. From the Exacute Commands Panel I could interrupt the calculation by imposing an IF conditional. Do you have knowledge about it? Because the information about this is limited and I didnt find anything similar in the Ansys Fluent Manuals.

[Rob]

We don't document (m)any Scheme commands so I'm unable to comment in the Community. Please use any Scheme commands with caution, and always keep a "safe" copy of the case & data as they can cause case corruption. 

[Diego Fernando Garcia Gonzalez]

Hi Rob, I bring new updates to the thread, show you the suggestions you recommended to me.

 

Below I show you a comparative image of the results obtained by increasing the mass of the particle while maintaining the density difference between the rigid body and the fluid. There's no significant difference, which gives me more options for analyzing a 3D model.

 

I've been able to carry out validations with the sedimentation of the circle, and I have had good results.

 

Answering your question about the flow field before divergence for the case of elliptical cylinder sedimentation, I show you the following images:

 

These are the results of the velocity field for different times, very close to each other before the divergence. I also include the report of the residuals, I'd like to know if u perceive what may be happening?

 

Thanks Rob.

[Rob]

A velocity scale would help, but the odd graphic effect in 1) about half way between the elipse & wall suggests something mesh related. Check the contact/transfer/overset cells, and in 3) & 4) see if they tie up with the anomally in the flow it's mesh related. That could just be the time step is too big: run a model with a fixed mesh and move the fluid to see if anything unexpected is happening. 

[Diego Fernando Garcia Gonzalez]

Hi Robert, I have two questions.

 

1. What do you mean the velocity scale would help?

2. Idk how to apply the option you gave me of Contact/transfer/overset cells, I was searching in the TUI commands but I can't find anything like that. If you can guide me I would appreciate it.

 

By the way, I ran the model with the fixed mesh and move the fluid, I present it the result of the velocity contour for a flow of 15 cm/s from the bottom of the domain, nothing unexpected happens.

 

[Rob]

The images you previous posted for the flow field don't have a scale so I have no idea what speed the colours represent. 

The image from today has a acceleration, but thats in part due to the domain restriction, and as a result looks sensible. 

There's an option (I think contour) for displaying orphan cells, check what else there is. What you're checked is where data is passed from the background to overset mesh. If there's a problem, or poor data convergence it could explain the odd contours. 

[Diego Fernando Garcia Gonzalez]

Hey Rob!

 

I got you, but I consider that the velocity scale in the image I showed you, it is not relevant. Instead, I find odd the sudden changes of the velocity contour in so few time steps.

 

The results of the fixed mesh and the movement of the fluid around the ellipse looks sensible to me as well and confirm that the mesh can be suitable for the analysis.

 

As for the contours, when I use Overset meshes I always verify that there are no orphan or dead cells. I attach as an example this image:

 

 

Rob,  In the post-processing, the contours generated by FLUENT usually show discontinuity in the areas where the "Overset interface" is located. However, it seems to me that it is only a graphical inconsistency of FLUENT because in other cases using CFD-POST that doesn't happen. Has it happened to you too?

[Rob]

That looks a little odd. Can you replot with node values off? The cell size isn't a great match between the background and overset so that may explain the problems. How far does the block move relative to the donor/receptor cell size in one timestep? 

[Diego Fernando Garcia Gonzalez]

Hey Rob!

 

I attach a new image with the node values off....

Before the calculation I always define options to the overset interface, for example the donor priority method to boundary distance based 

 

Also, I have tried different cell sizes between the background and the overset - ie 1:1, 1:2 and even 1:4 and I still have the problem. I've even tried dynamic meshes and the problem persists

 

Regarding, the displacamente of the block relative to the cell size. For this analysis I am assigning maximum time steps of 4e-4 s, if I consider that the expected terminal velocity of the ellipse is about 2 cm/s it would take 18 TS to overtake the receptor cell size (consider the receptor cell because it is smaller to the donor cells).

[Rob]

Odd that there are two layers of donor cells. 

[Diego Fernando Garcia Gonzalez]

I agree

 

What can I do in that case? I consider that I have the Overset mesh set correctly.

 

I also usually activate options for the interaction between the background and overset. Such as the donor priority method that I told you about, render receptor cells, verbosity, and intersect-all.

 

I could share the .msh files with you, is there no problem with that?

[Rob]

Staff are not permitted to download anything, other community members aren't restricted in this way. I've asked a colleague, but not heard back as yet. 

[Diego Fernando Garcia Gonzalez]

I Got u.

I’ll be pending your response, to review the overset setup and know what happens.

Could you give me another suggestion? … I just thought of something. Could I track the position and terminal velocity of a single particle using DEM? -ie, obtain a report file similar to the one shown by the 6DoF solver.

[Rob]

If you don't need to see any wake effects then DEM will work. For wake try semi-resolved particles in Rocky, coupled to Fluent. I'm not quite sure how good the resolution is, it's a relatively new feature. 

[Diego Fernando Garcia Gonzalez]

Rob...

I greatly appreciate if you can share tutorials or links to run semi-resolved particles in Rocky-DEM and couple to Fluent. I have actually never used Rocky and I would like to learn. I have it as an alternative.

[Rob]

There are some courses in Learning, and if you click on Help then navigate up the system you'll find some tutorials in Rocky's Help. Semi-resolved is very new, so I'm not sure about tutorials at the moment. They're also application based as opposed to feature so you may need to check each one. 

[Rob]

I've heard back. There's a tolerance option that I can't share (I'll see if I can make it public so I can) for UDF motion definitions; however he's not convinced that's a problem here. Also a TUI option to change the way Fluent works out the solve/donor distance, I can share that.

/define/overset-interfaces/options dpm

Available methods:    [0]: cell volume based     [1]: boundary distance based

That may help. Note, use the 1:1 mesh as the method tends to be more reliable when the cell size matches. It's marginally less critical for stationary meshes as they're easier to check, for moving mesh you'd need to confirm the update was good every few time steps.