As the title says, I want to know whether its possible to track the fluid phase.
As far as I know, this is not supported. (Please correct me if anyone knows differently!). It might be a good feature to add in the future.
MFiX will not allow you to define massless particles (d_p0 = 0) but there is no lower limit to the density or size of particles, I was able to create very tiny, almost massless particles:
Would that suffice for your purposes?
Yes. But two more question may arises, The collision between solid 2 can be ignored. However, will the code calculate the collision between solid 1 and solid 2? In that condition, the DEM iteration step and the collision search algorithm consume many resources and the accuracy of solid2 in the performance of the tracing fluid phase will also have a big discount.
Good point - the collisions could become a problem. Perhaps someone else has a better suggestion.
Thank you very much. I will try and see whether it works.
Yuanhe, could you explain why you want to seed tracer particles in the flow? What information are you looking to gain?
If you just want to see the streamlines, you should be able to do this in Paraview using their Stream Tracer function - this basically creates instantaneous tube glyphs that align with your flow. You can also seed your flow with small, neutrally buoyant particles. If you space them out sufficiently, they shouldn’t collide with one another (depending on how chaotic your flow is) but you would most likely have to hard code an override to the DEM time step calculation if you want the code to run faster. In general, as long as your Stokes number is <<1, any particles you add should follow the streamlines.
As an aside, the term massless can be a bit of a misnomer when talking about tracer particles. I know the Fluent documentation uses this term when they really mean massless and diameterless particles, because a truly massless particle would have a net upward buoyant force (similar to the behavior of an air bubble in a water channel). As long as you pick a small diameter with the same density as your fluid, you should get decent results!
1 Like
Hi Julia, I am trying to apply the recurrence CFD concept to MFIX platform. In breif， the fluid field movement are recorded by the tracer particles movement. In some system，the fluid field shows similarity. Thus, we can store the fluid quantities to the tracer particles and extent the time based on the fluid tracer movement pattern.
In the RCFD-DEM work, I need to track the fluid tracers and solid phase simutanesouly.
As you said, I can forcely set the DEM step. Will the fluid tracer particles enter the inside of DEM particle and cause error.
Interesting, I’ve never heard of recurrence CFD before so I probably won’t be of much help. I imagine this method would require a lot of tracer particles so solids 1/solids 2 “collisions” are almost unavoidable. I don’t believe there are any keywords to disable collision calculations for one phase in MFIX at the moment.
I doubt this is supported, but you could try setting the DEM collision parameters for the tracer particles (spring constant/damping coefficient) to 0. This would, or should, give a value of 0 for the collision force, so that your tracer particles do not influence your “true” solids particles. Then your tracer particles would be able to interpenetrate your solids particles without causing them to move. But be careful with this - you will certainly need to make some source code modifications, values like the DEM time step are calculated based on the spring constant of your particles. You also have to watch out for places in the code where this would cause division by 0.
Alternatively, you could try adjusting the neighbor search algorithm so that it excludes tracer particles (i.e. ignore all particles in phase 2), but that might be fairly challenging.
2 Likes
Thank you very much. Your suggestion is very specific and helpful.
Hi Julia,
I need around 16 tracers particles in each cell so the caculation burdon is unaffordable if the tracer particles takes part in the DEM solver procedure.
I read the fluent documents, and it says that the massless tracer has no physical quantities but share the fluid velocity and temprature.
Therefore i am thinking using UDF to record the fluid velocity and other property on the tracers by intInterpolation.
There are two problems in this route.
The first thing is that the fluid tracers particles may go through the wall during update, and how i can prevent this.
The second problem is that how to dynamically changes the tracers number as there are new tracers coming into and out of the domain.
Regards
Yuanhe
Hopefully I am understanding correctly, so just to clarify, in my below responses I assumed you are using a Lagrangian approach (array data associated with your tracer particles, where # entries corresponds to your # of tracer particles) even if you are not using the DEM solver for collision calculations.
I would study the mass inlet (i.e. mass_inflow_dem) and pressure outlet subroutines in MFIX to determine how they update the particle arrays as particles enter/leave the domain. Dynamically updating an array size is challenging imo but seems doable based on the mass_inflow_dem subroutine.
If you want to avoid using the DEM collision subroutine and you have simple geometry describing your domain (i.e. a box), you can add some collision calculation “hacks” in your UDFs. For example, after tracer positions are updated, loop through your tracer particles and if x>n, x<nn, y>m, y<mm etc. where n/nn/m/mm are your domain limits, have it go through a UDF subroutine that does wall calculations. If this is too slow, you could skip any particles that are not in a cell that contacts a neighboring wall. But I have not done this and am not confident it would be any faster or less computationally expensive than using the DEM solver’s collision subroutines. You would have to try it and see what happens.
1 Like
Thanks for your guidance.