|
block geometry inside fluid domain
i am working on extending SIMPLE to simulate the solid block within fluid domain. now, SIMPLE maps a rectangular domain and uses domain extension method to treat the solid domain. i am trying to a bakward-facing step problem, but don't wanna use domain extension method. So the i-, j-, k-, cannot be numberred simply from 1 to max. anyone can provide some advice or reference on this? Thanks a lot
|
Re: block geometry inside fluid domain
Very fun solition
add one more array - logical and one else array - integral then all points which is inside let 99 then found numerals which is wont repeated for border points it will took other values then your back ward facing step will look like (2d) 71 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 33 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 9999 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 59 32 32 32 32 11 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 00 00 00 00 00 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 00 00 00 00 00 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 00 00 00 00 00 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 00 00 00 00 00 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 00 00 00 00 00 59 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 55 main disadvantage - you will have idle points, but if your solver is non commercial but just for study - I found it rather usefull and it will be need to add into the solver logical switches which will control fluxes for border points (you cwn use one solver for all variables) i.e. internal points 99 which won't be in use 00 e border points - 91 w border points - 66 n border points - 77 s border points - 32 wn corners - 71 (external) ws corners - 59 (external) es corners - 55 (external) en corners - 33 (external) and so on for 3D case before you will generate grid - make such array but look through classic work - by Kim - he had rectangular domain |
Re: block geometry inside fluid domain
thanks a lot, Mike.
I am modeling the turbulence flow and I need special treatments for the solid walls. this is why i don't wanna follow the domain extension any more. In my previous code, the finite volume equations are solved using TDMA+ADI. My question is "can they still work if I add the array as you advise?". I am thinking between two options: a) using two zones of grids to map the upstream and the downstream sections, respectively. Something is like the multi-block method. In this way, the solver (ADI+TDMA) can still be used because the compuational domain is rectangular in either zone. b) changing the coefficients of the finite volume equations. Only one zone of grid will be used, but the regular TDMA+ADI algorithm cannot be used directly (not from 1 to maximum). By the way, could you provide more information about the classic paper by Kim? Paper title, journal, vol. and issue numbers? Thank you very much. |
Re: block geometry inside fluid domain
Sure it will work
Unfortunately I've lost my code and can't send it to you I should add that you will apply this procedure and for TDMA ADI all nodes with "99" will be treated as internal points (P and Q computation) in I direction - nodes which marked as "66" will be treated as "1st" point, - nodes which marked as "91" will be treated as "max" point, in J direction - nodes which marked as "32" will be treated as "1st" point, - nodes which marked as "77" will be treated as max point, flow over cylinder 71 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 33 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 9999 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 66 99 99 99 99 99 99 32 32 32 32 32 32 32 32 32 32 99 99 99 99 99 91 66 99 99 99 99 99 99 91 00 00 00 00 00 00 00 00 66 99 99 99 99 99 91 66 99 99 99 99 99 99 91 00 00 00 00 00 00 00 00 66 99 99 99 99 99 91 66 99 99 99 99 99 99 91 00 00 00 00 00 00 00 00 66 99 99 99 99 99 91 66 99 99 99 99 99 99 91 00 00 00 00 00 00 00 00 66 99 99 99 99 99 91 66 99 99 99 99 99 99 91 77 77 77 77 77 77 77 77 66 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 66 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 91 59 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 55 what is concerned Kim's work, I also had it but lost. so may be yoy will find it at Kim's web (look through CFD guru's list at CFD on line) |
Re: block geometry inside fluid domain
as for treatment of solid walls I used additional domain for boundary conditions above mentioned array only describe computational domain, and I also added an array wich described solid walls, inlet and outlet conditions, I had a very complex geometry and a lot of holes with fuel sprays
|
Re: block geometry inside fluid domain
configuration in this case may vary as only you want to and you will only need to build universal solver, and
all work will be in preparation for computations when you build a grid and compute values of alfa beta gamma. This work will be done separately |
Re: block geometry inside fluid domain
you will apply the procedure to the whole domain (e.g. 300 x 300 x 300) and your solver will decide all itself where it will solve, and where it won't.
it does not matter, what will be in it and what geometry will be - you all describe earlier, when you build a grid and this additional array. |
Re: block geometry inside fluid domain
look at this line
and I hope you will understand idea i >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> max 66 99 99 99 99 99 99 91 00 00 00 00 00 00 00 00 66 99 99 99 99 99 91 It doesn't matter for your TDMA ADI solver. It solves the whole domain. and P and Q arrays have the same dimensions P(300) Q(300) Just in "00" it won't work at all points marked as "66" will treated as "1st" points marked as "91" will treated as "max" --------------------------------------------------- the same thing and with Aw, Ae, As, An, At, Ab coefficients for example you add in your solver addition that for point "77" convective flux at "N" face equal zero |
Re: block geometry inside fluid domain
May be it won't be zero in common case, it depends from boudary conditions, but I hope you understand me rather well.
When I used HLPA and other TVD schemes, it was important to describes such points, cause HLPA scheme uses (e.g. E face) ee + e + P values, and it's important to point, where it own't be used. Also it's important when you use Rhie and Chow monotonizator for colocated grid arrangement |
Re: block geometry inside fluid domain
Corner points I described separately
so you have to describe all cases edge faces "E" "W" "N" "S" "T" "B" corners "es" "en" "ws" "wn" "ts" "tb" corners such as "est" all that was for non orthogonal complex geometry, TVD schemes for convective fluxes, and standard k-eps model and colocated arrangement It took three years for me to build such sover from complete zero (Patankar's book) and a lot of disturbances |
Re: block geometry inside fluid domain
The same and with wall functions (in K-eps model) and with Sp terms
I made all using fluxes' treatment and logical switches for boundary's nodes |
Re: block geometry inside fluid domain
I remember how I implemented boundary values
It's very plain First node I put at the boundary volume's face e.g. W-boundary control volume !----------------------------------------------------------------------------! !................................................. .................................................. .................! !................................................. .................................................. .................! !................................................. .................................................. .................! "1st" i-node ................................. 2nd i-node .................................! (u,v,w,p,k,e)..................................(u, v,w,p,k,e).......................................! !................................................. .................................................. .................! !................................................. .................................................. .................! !................................................. .................................................. .................! !--------------------------------------------------------------------------------! then you set all necessary boundary variables from these values, and they change only if it will be outlet boundary conditions and sure I used colocated arrangement it took a lot of time to decide all this, cause I worked alone by trials and errors method here - it's essential of my results why I put "1st" - in " " ? because it can be both 60th and 200th just it's important that before it - "00" or it's really the 1st node I mean it's an edge point where we set a fixed values of variables the same and with "max" nodes and other directions |
Re: block geometry inside fluid domain
In previous case
1st will be "66" 2nd will be "99" |
Re: block geometry inside fluid domain
wow, thank you very much for your help, Mike.
I think all your posts clarify my questions. I will change the modules of coefficient generation and solver. Now the ist, jst and kst will not be a constant and might be one value, depending on how many solid "blocks" there are within the fluid demain. So will the iend, jend, and kend. I was using staggered grid distribution. But I can switch to collocated one, if necessary. Again, I appreciate your help very much. Happy Easter. |
Re: block geometry inside fluid domain
By the way, the corners should be okay, since they are not solved in the code. There are no algebraic equations for the corners. Actually, the wall B.C.s are not solved either in my code. Thanks
|
Re: block geometry inside fluid domain
no Jeff.
I rejected the whole idea to use ist, jst, kst indexes I used cycle do i=1,Nmax (where N max e,g, = 300) for whole domain and switches decide what point they have to solve and what point is out of consideration. I thought about universaal solver, which used only the ready prepared arrays of geometry (X,Y,Z coordinates) and this additional describing array where is indicated, what point have to be treated (which I showed) Also array describing B.C. And array of initial values of dependent variables such as U,V,W,k,eps, P, T |
Re: block geometry inside fluid domain
There are NOT any ist jst kst values in solver
only array with "99", "00", or "32" which indicated what point is boundary and what point is inside flow only consideration of how to treat every node, depending upon is this "99", "00", or "32" point and I also made simplifyer, cause logical operataion with boolean variable is less expensive (CPU time) then with integral ones |
Re: block geometry inside fluid domain
I guess you didn't understand me properly
"99" "00" "32" - only signs, it even could be boolean variables, they only changed words - "internal point" means 99 "W border point" means 66 "E border point" means 91 "S border point" means 32 "N border point" means 77 "out of flow" means 00 and so on I used numbers cause it uas connected with how I generated and controlled this array |
Re: block geometry inside fluid domain
I get your idea. Thanks a lot, Mike.
|
| All times are GMT -4. The time now is 14:43. |