[atul1018]

Hello Foamers

I want to simulate a turbulent flow in a symmetrical step case (see attched image). Both the inlet channel and oulet channel have exact same height and width, i.e. one to one mapping is possible, thus geometry is periodic. However, there is a symetrical step between inlet and outlet channel, where flow seperation and reattachment may occure. I am not sure but i think in this case, the flow at the outlet can not be cycled to inlet as they seem to be non-periodic in flow.

I tried to use cyclic bc at inlet and oulet and used fvOption to provide the mean flow velocity. But, somehow simulations gets killed. I tried to use different fvSchemes an fvsolutions methods but no access. Each time, the simulation gets killed either due to floating point exception error or convergence problem even after 1000 iterations. I think, this happens, because I am trying to use cyclic bc where physically it it not periodic. Am i right?

Best Regards
Atul

[JulioPieri]

Cyclic BC will only copy what happens at one BC to the other. It does not do any physical check; I don't believe you are diverging because of that.

To understand periodic (i.e. cyclic) BC, imagine that you have inifinite instances of your domain, attached inlet<->outlet. So what happens in the outlet must be exactly what happens in the inlet.

Is that what you want? Cyclic BCs are not that easy to make stable. Try running your case with regular inlet/outlet bcs to get the flow resolved, then map that as initial condition to a new case with cyclic bc

[atul1018]

Hello Julio

Thanks for your valuable comments.

Cyclic BC will only copy what happens at one BC to the other. It does not do any physical check; I don't believe you are diverging because of that.


To understand periodic (i.e. cyclic) BC, imagine that you have inifinite instances of your domain, attached inlet<->outlet. So what happens in the outlet must be exactly what happens in the inlet.

Yes, I know the cyclic bc copy flow fields exactly from one boundaty to another. In m,y understanding, this is physically possible only of the flow doesn't change in between those two boundaries, example channel flow. In my case, there is step in between those two boundaries. I wonder, if in this case also, flow at the oulet and inlet be same? Somehow, I am not convinced about it.

Is that what you want? Cyclic BCs are not that easy to make stable. Try running your case with regular inlet/outlet bcs to get the flow resolved, then map that as initial condition to a new case with cyclic bc

I followed the channel395 to set up my case. Interestingly I get stability problem only for my geometry but channel395 works as expected. Is it because cyclic bc can only be used where geometry and flow must have some periodicity. On channel395 both these conditions are satisfied but for my geometry, i think there is chance that flow is non-periodic in nature. I know, I can use mappedPatch bc, where i match flow fileds from a certain offset from inlet and this should result fully developed turbulent flow. But I wanyted to try cyclic bc and be sure if that can not be used in my geometry.


Thanks and Best Regards
Atul Jaiswal

[JulioPieri]

Hi! Well you are right about the cyclic BC only being possible when the flow doesn't change from outlet to inlet, but it can change in the middle. When you apply the BC you're telling the solver "give me the condition that satisfies that", so it will find a solution that guarantee inlet=outlet. Even if for that the profile is funky and weird.

Have you tried running it in transient and see how the solver is evolving? Physically, I imagine that the velocity profile will be intense near the top wall and possibly back-flowing near the bottom of the patch. That could make a phisically demandind setup to converge, but it should find a solution.

Share your case, as simple as it can be, and I'll have a look and try to help.

[atul1018]

Dear Julio

Actually, i managed to run the case without fatar error/covergence problem. But the profiles I am getting change a bit in the flow direction (reduction in peak). As far I understand, the flow profile should remain same as you move in longitudenal direction, then only it is fully developed flow.

Actually, the original case is multiphase case, which i am simulating by coupling openfoam and liggghts. Here, I am attaching only the CFD part (openfoam), so that you dont have to give extra effort and donot need extra coupling code. It has some extra files that you can simply ignore. While attaching the zipped file the portal shows invalid file. In case it is not uploaded, you can give me your email in private chat, i will mail you the setup.

Thanks and best Regards
Atul

[JulioPieri]

So, I got your case, thanks! I have some things to suggest.

1) Your snappyHexed mesh does not have surfaceFeatures on, that's why you're getting these chamfered corners. If this is your final mesh, it's pretty simple and faster to run when created in blockMesh. I can help you with that if you need.

2) The best way to create cyclic BC is by running createPatch after the mesh is done. From the files you shared, it seems you have manually edited /constant/boundary file, right? Try using createPatch -overwrite instead. Also, remember that you shouldn't create cyclic BCs from blockMesh nor snappyHex.

3) I ran the case until 0.01s and the results didn't seem to change - it converged. The profile is quite as I'd expect. You flow will change in longitudinal (flow) direction as you have the cavity (bottom part of your domain). The profile will then reshape itself to match the inlet-cycled condition. Remember, with cyclic you are simulating an infinite number of cavities like these, as if there were several connected "T"s.
Like [...]->TTTTTTTTTTTTT->[...] entering from top line of the letter "T". A fully developed flow will not change in time, i.e. every cross-section of your domain will have the same velocity profile at every time, but not necessarily will have the same profile between them.

4) I also noticed that your top BC is allowing slip for some reason. You have U_X velocity on it. Check if this is really happening, and if you want it to do so.

5) Lastly, not sure how DEM coupling works, but this case could be run in steady-state, and you could guarantee the convergence more precisely using OF's residuals and monitors. In DEM, you first have to have a fully developed profile for LIGGGHTS to take over? Or it runs together with transient timesteps?

Hope this helps!

[atul1018]

Hello Julio

Thank you so much for arranging time and looking into the case.

1) Your snappyHexed mesh does not have surfaceFeatures on, that's why you're getting these chamfered corners. If this is your final mesh, it's pretty simple and faster to run when created in blockMesh. I can help you with that if you need.

Yes, the corners of the created mesh looks not so good. I thought it was visualization problem. I didn't know about the surfaceFeatures option. it would be great if you could help me in getting perfect corners. I have no clue, how to use that option. Can you modify my case and send it to me so that I understand how it works.

2) The best way to create cyclic BC is by running createPatch after the mesh is done. From the files you shared, it seems you have manually edited /constant/boundary file, right? Try using createPatch -overwrite instead. Also, remember that you shouldn't create cyclic BCs from blockMesh nor snappyHex.

Yes, I have manually edited the boundary file on order to assign cyclic bc to patches. After the blockMesh and snappyHexMesh execution, all the boundary patches are patch or wall type. When I want to change something, I just change it in the boundary and that should be okay (I thought). One question: if I want symmetry bc in z-dir (front and back), I just edit the patchType in boundary file. can someone use createPatch to generate symmetry patches also or it is suitable for cyclic bc only?

3) I ran the case until 0.01s and the results didn't seem to change - it converged. The profile is quite as I'd expect. You flow will change in longitudinal (flow) direction as you have the cavity (bottom part of your domain). The profile will then reshape itself to match the inlet-cycled condition. Remember, with cyclic you are simulating an infinite number of cavities like these, as if there were several connected "T"s.
Like [...]->TTTTTTTTTTTTT->[...] entering from top line of the letter "T". A fully developed flow will not change in time, i.e. every cross-section of your domain will have the same velocity profile at every time, but not necessarily will have the same profile between them.

From this explainantion, I think, I should not go for cyclic bc. I want to simulate a flume experiment, where fine sediment gets infiltrated in already prepared bed (in that cavity area, I fill particles before cfd calculation). These infinte number of cavities will have diffrent flow process compared to what is observed in the flume experiment. I am saying this beacuse looking into the results of cyclic bc, I see half part of the cavity (outlet side) was competely eroded and half part of the cavity (inlet side) remain stable. which is realistically not possible. i think, i should go for mapped bc. I just map the flow fields from a certain distance from inlet back to inlet. In this scenario, more physically realistic flow and sediment transportation/infiltration may be observed.

about the fully developed flow: thanks for clearing my doubt regarding fully developed flow. Does fully develped flow should also not chnage in spanwise direction (z-dir, front and back). I am asking this question because applying different bc at front and back boundary will result different flow solutions. for example using symmentry and zero gradient in z-direction will have different flow solutions and which one is neat to fully dveloped flow?

4) I also noticed that your top BC is allowing slip for some reason. You have U_X velocity on it. Check if this is really happening, and if you want it to do so.

I am striclty applying noSlip bc at top boundary (see U file) in the case files i sent to you and slip is commented. however, as I am modellling a flume, whcih is open channel flow, i.e. no wall at the top surface. slip bc would have be more appropiate option. How, did you find out that some slip at top boundary? Am I missing something?

5) Lastly, not sure how DEM coupling works, but this case could be run in steady-state, and you could guarantee the convergence more precisely using OF's residuals and monitors. In DEM, you first have to have a fully developed profile for LIGGGHTS to take over? Or it runs together with transient timesteps?

OpenFOAM and Liggghts run one by one and transfer data at some time intervals. for example, DEM part runs for 0.001 sec, then particle data are transferred to CFD part, then CFD runs for decribed time steps and then transfers back the data to DEM. May be, You are right, as at the biginning, flow at inlet is not fully develped (particle are also injected from inlet). I should run cfd for some time steps and once I have got fully dveloped flow at inlet, I inject particles from the inlet. Also, may turning of ddt scheme and solving in steady state could be better option but I am not sure if that is a good idea as the flow is turbulent and I am suing RANS to model it.

I wrote quite a much but I thought its worth to discuss it with you.

Thanks and Best Regards
Atul Jaiswal

[JulioPieri]

Hi! So,

1) check blockMesh user guide, it will help you creating the mesh. You must create a 4-block mesh: bottom part of the "T", each side of the upper part, and the middle part where the previous three connect. Each block must have one of its side fully connecting to another's block side, that's why you need 4 blocks insted of 2.

It's better to create that way, but if you want to use snappy, search the tutorials (using linux command, google it as I don't have it memorized) for snappy usage and you will see this surfaceFeatureExtractDict thing. It extracts the edges of your .stl surface por explicit snap to them. Check out wolfdynamics tutorial for snappyHexMesh. It explains eveything very well.

2) you want to have 2D symmetry in z-dir? that would make your case very fast to run, and possibly good results. Por particle tracking, though, I'm not sure if you need to resolve their movement in z-dir, and I don't know the LIGGGTHS limitations on 2D geometry.

To make 2D, you need to have a 1-cell thickness in z-dir and make both patches as "empty" type (you can create straight from blockMesh). This will mean that your "slice" is sufficiently far away from the walls to neglect its influence.

The cyclic bc (which works in 2d as well) can be done this way you did, but it's better to use createPatch

3) I don't think you need mapping at all, not cyclic, specially if run 2D (which is very fast). just make a far-enough inlet BC so the profile can develop. There are typical numbers on that, I don't remember exactly, but was something like 5 times the hydraulic diameter.
Also, is your flume experiment simulating water? If so, isn't your top boundary opened to air? If that's the case, you might need to use interFoam to get this free surface. If not, check the influence of the top wall on your experiment and be careful with that. Maybe you could make it far enough from the main flow to isolate its contribution.

About the fully developed, that only concerns about time evolution: the same cross-section at any future timestep will have the exact same 3D profile, that is, same points will have the same properties. If your setup demands you to account for the presence of the front and back wall, then you need to consider it. If, on the other hand, you're just interested in the middle section of your experiment setup, or and infinitely thick (z-wise) setup, you can consider the 2D "symmetry".

4) I wrote the previous comment about the open channel before seeing this. So, if you want an open channel, for best results I'd go with interFoam. Then you should definitely aim for 2D symmetry as it's a heavier solver. If you cannot couple this with DEM, stick with the slip condition but remember that slip still a wall bc, i.e, you don't have flow through it. It would be worth checking if a suficiently far top wall will impact the solution. You could run two test cases: interFoam vs pisoFoam-with far top bc and compare the fields.

5) Are you saying RANS or RAS? I think your RANS model will find a steady solution, as it is time-averaged. You will get the mean quantities. If your settings do change in time (inheritely transient) the solver will simply not converge as each iteration, as the flow will try to be somewhere else.

Hope it helps!

[atul1018]

Hello Julio

1) check blockMesh user guide, it will help you creating the mesh. You must create a 4-block mesh: bottom part of the "T", each side of the upper part, and the middle part where the previous three connect. Each block must have one of its side fully connecting to another's block side, that's why you need 4 blocks insted of 2.

It's better to create that way, but if you want to use snappy, search the tutorials (using linux command, google it as I don't have it memorized) for snappy usage and you will see this surfaceFeatureExtractDict thing. It extracts the edges of your .stl surface por explicit snap to them. Check out wolfdynamics tutorial for snappyHexMesh. It explains eveything very well.

-Thanks for suggestion. I managed to learn how it works. I did it using snappyHexMesh.

2) you want to have 2D symmetry in z-dir? that would make your case very fast to run, and possibly good results. Por particle tracking, though, I'm not sure if you need to resolve their movement in z-dir, and I don't know the LIGGGTHS limitations on 2D geometry.

To make 2D, you need to have a 1-cell thickness in z-dir and make both patches as "empty" type (you can create straight from blockMesh). This will mean that your "slice" is sufficiently far away from the walls to neglect its influence.

-No, I dont want to simulate in 2-D, thats why empty bc at front and back is not what I want. LIGGGHTS simulations are always 3-D and flow should be resolved in all direction. As the flume was really big and with particles it is not possible to simulate it in CFD-DEM framework even in HPCs. Therefore, I use smaller width. As the width is reduced, I think symmetry bc should be used. Am I right?

3) I don't think you need mapping at all, not cyclic, specially if run 2D (which is very fast). just make a far-enough inlet BC so the profile can develop. There are typical numbers on that, I don't remember exactly, but was something like 5 times the hydraulic diameter.
Also, is your flume experiment simulating water? If so, isn't your top boundary opened to air? If that's the case, you might need to use interFoam to get this free surface. If not, check the influence of the top wall on your experiment and be careful with that. Maybe you could make it far enough from the main flow to isolate its contribution.

-As i want the flow resolution in 3D, I need some mapping to get fully developed flow at inlet. I cant extend my inlet channel length exessively as CDE-DEM simulations are super super expansive.
-opensource CFD-DEM code only couples the pisoFoam and Liggghts thats why I must set up my case only in two-phase. To reduce the effect of top wall on infiltration phenomena, slip bc seems to be suitable. As I have certain water depth in flume and top wall is located at the elevation. I cant make the top wall very far, in this case the water depth will be increased and
flow velocity will decrease and flow conditions will no longer be same as in the experiment.

4) I wrote the previous comment about the open channel before seeing this. So, if you want an open channel, for best results I'd go with interFoam. Then you should definitely aim for 2D symmetry as it's a heavier solver. If you cannot couple this with DEM, stick with the slip condition but remember that slip still a wall bc, i.e, you don't have flow through it. It would be worth checking if a suficiently far top wall will impact the solution. You could run two test cases: interFoam vs pisoFoam-with far top bc and compare the fields.

yes, this was my querry. As i have definite water depth and velocity (as per discharge), the top wall should be at water surface elevation. If I increase the top wall distance it will no longer be the same water depth as in experiment. I am not sure, keeping top wall far enough yet maintaining same water height and flow velocity.

5) Are you saying RANS or RAS? I think your RANS model will find a steady solution, as it is time-averaged. You will get the mean quantities. If your settings do change in time (inheritely transient) the solver will simply not converge as each iteration, as the flow will try to be somewhere else.

I want to resolve turbulent flow by RANS, which seems to be the best compromise between accuracy and computational demand. The average flow quanties that I get from RANS should be able to give physical realistic particle infiltration.

I am really learning alot of things from our discussion. Thanks!

-Atul

[JulioPieri]

2) Yes, you can use half symmetry in the z-dir (perpendicular to the flow direction, right?). There you could also use cyclic, though I'm not sure how LIGGGHTS will behave. Have you considered using just MPPICFoam instead of DEM? It is much less demanding.

3) Yes, you could first run a simulation with just the inlet/outlet cross section (same coordinates as yours) and run to convergence. Then map this inlet profile back to your case with the cavity.

4) Since you have a heavy case, stick with the slip BC for now. It should give fair results, you are right. But keep in mind that this is not the same as solving for open channel!

Glad that I'm helping!

[atul1018]

Hello Julio

I was quite busy last week, now I am back.

2) Yes, you can use half symmetry in the z-dir (perpendicular to the flow direction, right?). There you could also use cyclic, though I'm not sure how LIGGGHTS will behave. Have you considered using just MPPICFoam instead of DEM? It is much less demanding.

Yes, perpendicualr to flow (in front and back walls; along the width). Cyclic and symmetry bc in front and back plane should results similar results. I had used MPPICFoam and DPMFoam before for other case but they are not suitable for my current case as I am planning to model the 3D packing and infirltration phenomena and particle-tracking solvers in openfoam are point particle based solvers. Also, Liggghts provides a lot more options to model granular system and their mechanism.


Best Regards
Atul