Hello everyone,
First of al
Hello everyone,
First of all, these should be quick questions for a few of you. 1. I'm trying to import a mesh file created in gambit, exported to .msh format and imported into OF1.4.1dev using the fluentMeshToFoam utility. Once imported there are a few boundaries with the "_shadow" attached to the end of them. How do I handle them in OF? Right now I have a cyclic boundary called "cyclic" and a shadow bc called "cyclic_shadow". I have them both defined as cyclic base types...is this correct? Does a cyclic BC need a defined value (Uniform/nonuniform?)? 2. I would like to run a case using interFoam with periodic BC's. In order to properly handle pressure do i need to do something similar to channelOodles with creategradP and writeGradP? Will the (VOF method) interfoam solver handle this? Thanks for your help in advance. Dan 
Just thought I would respond t
Just thought I would respond to my own post with the solution.
1. If you are using Gambit and want periodic boundaries, just link the two sides (its in the manual), mesh the object, and then define a single bc as those two faces (3d)/edges (2d) as a type "wall". After you import the mesh then go to your constant/polyMesh/boundary file and change the boundary type of your cyclic boundary to type "cyclic". If you define your initial bc's correctly it should work. 2. The short answer to this is yes, you will need to use create and writeGradP, but I am currently having problems passing gamma to the other side of my cyclic boundary. Just thougth this might help someone trying to use gambit and make a domain with cyclic boundaries. Dan 
Interfoam across cyclic boundary
Quote:
I messed with this last year in OF solely because I was told I would spend my life trying to get Fluent to do this properly (thankfully for that comment my advisor has switched completely to OF since). I was able to get cyclic boundaries to work with interFoam and rasInterFoam. I remember that the problem was with the fact that gravity was lumped into the pressure term and when the liquid drop fell through the bottom and was supposed to come back through the top...the liquid drop just stopped and hung in mid air with small pieces showing at the top of the domain. it was actually pretty funny to see. The solution was to add rho*g to the rhs of the momentum equation (pd = P  rho g z. i.e. the reduced pressure is not periodic, but the absolute pressure. interFoam solves pd, not P) (in addition to all the changes to make it similar to channelOodles). The main bit of code that was really a simple change in UEqn.H was: Code:
fvVectorMatrix UEqn Lastly, one thing that i noticed was that as I dropped a liquid drop and it traveled through the domain boundaries and appeared again on the top...it kept speeding up. I am pretty sure this was because there was no drag term in the momentum equation...something that I know for the case of the rising bubble has been studied for a while. There are numerous threads on that topic. Anyway, long answer for a simple question...yes its possible to do this in OF. 
Thanks for pointing me to this post and also for keeping it up to date. I have an implementation in Fluent for channel where I correct momentum, pressure and phase fraction. This implementation doesn't work, when I turn on gravity. I guess it's due to the reasons you outlined above, but with Fluent I have little chance of investigating the origin of the problem. Your post sounds very encouraging so I'll try to rewrite it to interFoam.

Cyclic boundary in interFoam
hello chegdan,
I'm arriving 2 years after the discussion but I hope somebody is still watching ! As many others, I'm trying to modify the interfoam solver to an InterCyclicOpenChannelFoam one. I model flow over bedform when water depth scale with bedform heigth. It is happenning on steep slopes in mountains river. Here, the gravity component in xdirection is the only energy source in the system. My idea to begin the simulation was to start with an initial volume of water at rest, that will move forward with the action of gravity and come to a steady (water depth/velocity/pressure) when the turbulent dissipation will compensate the gravity source. (see image below at the initial condition) https://lh4.googleusercontent.com/j...44/alphat0.png I made the modification you suggested to deal with cyclic conditions for relative and absolute pressure adding the rho*g term. I didn't made the change to keep the flow rate constant (like channelOodle) as it is not constant in my case but going from zero (initial water at rest) to the limit discharge. However, it seems I still have a problem at the cyclic patch, water seems not to go freely back to the input... Look at the images below : Alpha : https://lh4.googleusercontent.com/b...44/alphat1.png Pressure : https://lh3.googleusercontent.com/v...144/prght1.png Velocity: https://lh6.googleusercontent.com/_...E/s144/Ut1.png Where do you think it is coming from ? Should I try to implement also the constant flow rate ? I guess the bubble case is a bit the same than mine for the transcient behavior ... Maybe I missed something when you said : "separate gravity from pd and add it back into the momentum equation" ... How can I separate the gravity from pd ? in which file ? Also "you need to read in the g field and value of rho" is not clear for me. simply adding rho*g in Ueqn.h is not enough ? Thanks very much ! Joris 
Solution...
Ok, I guess I found the solution...
In addition to add rho*g in the RHS of UEqn.h , I deleted the line: Quote:
Is it correct ? It seems to work at first look. Cheers, Jors 
Joris,
I haven't been in this solver for a little while and its changed a little bit from 1.4.1dev when I did some fiddling with interfoam. I did notice that they changed the algorithm a bit and now it uses the PIMPLE method (it seemed a little bit simpler a few versions of OF ago). So, with this...I am going to just say be careful when you make quick adhoc changes and I cannot confirm if what you did was correct. When you do find an answer, post back that it worked for others to see. 
hehe yeah maybe it is a bit violent what I did, but as I'm not really familliar with the FOAM coding...
Also I forgot to say that I changed your proposition Code:
fvVectorMatrix UEqn ( fvm::ddt(rho, U) + fvm::div(rhoPhi, U)  fvm::laplacian(muf, U)  (fvc::grad(U) & fvc::grad(muf)) // fvc::div(muf*(fvc::interpolate(dev(fvc::grad(U))) & mesh.Sf())) == rho*g //added to pull gravity out of pressure term + flowDirection*gradP //added for channel flow ); UEqn.relax(); Code:
fvVectorMatrix UEqn ( fvm::ddt(rho, U) + fvm::div(rhoPhi, U)  fvm::laplacian(muf, U)  (fvc::grad(U) & fvc::grad(muf)) // fvc::div(muf*(fvc::interpolate(dev(fvc::grad(U))) & mesh.Sf()))  rho*g //added to pull gravity out of pressure term + flowDirection*gradP //added for channel flow ); UEqn.relax(); I definitely not converge to a finite velocity, and after 10 sec waves developed on the free surface cause the celocity (and the froud number) becomes too high... This is maybe because I used a relatively coarse mesh and I should better use RANS or LES than laminar to model small scales dissipation... The problem with the flow I try to model is that in reality there is a strong dissipation due to the wall friction (the wall roughness is in the same order of magnitude as the flow depth) and it seems a bit strange to model it with a "flat" curved wall. I know that there exists some wall functions in OpenFOAM, I migth have to use it... Again, thanks for advices ! Joris 
Ok, here I post the results I got with what I did above. It seems nice.
Water: http://www.youtube.com/watch?v=wEjsM...B1BLS8joo24x_y Velocity: http://www.youtube.com/watch?v=Rr6aQkXUlh8&context=C3f6e459ADOEgsToPDskJj rSjp4uB1BLS8joo24x_y Thanks for helping joris 
All times are GMT 4. The time now is 01:59. 