Hi, I wanted to test the flow code some more (as was said in the other thread, difficult to write a good test for the code in viscous limit), and not having dolphyn, I decided to see how fipy stacks up for the lid driven cavity, Re=1000, which is a well known example with many literature comparisons.
The example file and figures are in Ticket URL: < http://matforge.org/fipy/ticket/306> The literature comparison for a 123x123 grid is not bad, but not stellar either: http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvx.png http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvy.png I think it would be good to add this example to the flow examples so as to clearly show fipy users what fipy can do for flow simulations. For my own use I only need an approximated flow field to do mass flow, so it seems sufficient for my needs. Perhaps to add in the example is that one can obtain better matching values with literature for refined parameters, at a heavy computational cost. Eg, for N=243 pressureRelaxation = 0.8 velocityRelaxation = 0.6 sweeps = 3000 I obtain: http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvx_N243_sweep3000.png http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvy_N243_sweep3000.png As a comparison, it is interesting to look at http://www.cfd-online.com/Wiki/Sample_code_for_solving_Lid-Driven_cavity_test_%28Re%3D1000%29_-_Fortran_90where a 120 grid is used to obtan the results. For a 123 grid, fipy still has visible discrepancy, however that code uses a higher order derivative for the convective term (HLPA it is called there), perhaps that explains it. Obviously, having such a convective term would be great if it makes such a difference :-) Also a result of fluent here: http://www.cfd-online.com/Wiki/Lid-driven_cavity_problem on a 32x32 grid, but it is not written what order or method is used or how long the computation took. My guess would be one can obtain better results if one can put the velocity implicitly in the velocity equation, now the velocity facevariable is used, which is fixed and updated once in every sweep. I tried that in the code, but it is commented out, because the results where bad. Perhaps I do something wrong ... >>> #xVelocityEq = 2.* xVelocity * PowerLawConvectionTerm(coeff=(1.,0.)) \ .. # + yVelocity * PowerLawConvectionTerm(coeff=(0.,1.)) \ .. # + yVelocity.getGrad().dot([0.,1.])*xVelocity \ .. # - DiffusionTerm(coeff=viscosity) + pressure.getGrad().dot([1.,0.]) >>> #yVelocityEq = 2.* yVelocity * PowerLawConvectionTerm(coeff=(0.,1.)) \ .. # + xVelocity * PowerLawConvectionTerm(coeff=(1.,0.)) \ .. # + xVelocity.getGrad().dot([1.,0.])*yVelocity \ .. # - DiffusionTerm(coeff=viscosity) + pressure.getGrad().dot([0.,1.]) Would be nice if sombody can tweak it to have matching results with the literature, but anyway, this test has shown me fipy is adequate for my purposes. Obviously I wonder if the fully coupled matrix equation Daniel talks about would not also solve the problem better, however, that fortran code I refer to works apparently great without such a coupled solver. Benny
