i wanna speed up my solver!
hi.
my MAC based incompressible fluid solver is finished, but... it is not very fast. at the moment im searching any methodts to speed up them. i read an paper by fostern (metatax or something like that)  he wrote than is easy way to speed up computations  just replace viscosity by viscosity(dt) function. that function will return minimal, but >= real viscosity for local fluid velocities (U[i][j]  U[i1][j]). Is that good way to optimize code? Anybody have done these function? Is that means never halve dt, only make viscosity large? /// maq 
Re: i wanna speed up my solver!
Hi Maciej,
One way to speed up a code is to eliminate coding that slows things down. This assumes that the basic scheme remains the same. The ways to speed up the convergence of your chosen scheme include preconditioning, multigrid etc. which are not what I am talking about here. It is not clear what exactly you are referring to. The first step in speeding up your code (keeping the scheme the same) is to perform a profiling of your program to identify the cpu intensive subroutines. In most cases there are only a few (56) routines that end up doing 7080% of the computation. This allows one to focus on the routines whose speedup gives the maximum returns. From this point, the optimization procedure is dependent on the language, machine type (scalar, vector) etc. Normally scalar optimization gives a speedup of around a factor of 2 (this is assuming that one coded up the program without too much attention to performance). You will find information on scalar optimization in usual Fortran books and elsewhere in the internet. Most highperformance installations have information in their websites. regards, chidu... 
Re: i wanna speed up my solver!
(1). The other way to speed up the code is to use a faster computer. (2). So, put your program on a faster computer and run it. If your code runs faster on the faster computer, then you are in good shape. It is much harder to speed up the code by software approach.

Re: i wanna speed up my solver!
I beg to differ. It is hard to speed up a code beyond a certain limit. In any case, it is a good idea to identify the heavyduty routines. Profiling a code is simple to perform is surely not a waste of time.
chidu... 
Re: i wanna speed up my solver!
John does not always give the answer that is wanted. A practical and simple solution to a complex question is not always acceptable. It was a god laugh reading the answer, but it is also true Most new releases of, at least commercial codes, gives a speed up of the solution, probably due to better solving, removal of bugs in the code etc., this software speedup it totally lacking behind the current increase in CPU speed. An example – I changed from CFX4.2 to CFX4.3 and on a certain benchmark case I use, I found an increase in speed on 16%. This is an impressive increase, but still small compared with the approximately 100% increase in CPU speed over 1 year, and the software speed up frequency is probably larger than 1 year. I do believe that is important with the software speed up, at least so I feel I get value for money, but John's comment is still very true Run it on a faster computer!

Re: i wanna speed up my solver!
And of course, the problems WE WANT to solve scale faster in time than any speedups achievable from better coding or faster computers! It doesn't matter how fast the computer  its still going to be too slow!
Greg 
Re: i wanna speed up my solver!
(1). Well, there is no question about using the faster computer to speed up the calculations. That's why vectorprocessors and parallelprocessors were developed to speed up the calculations. If the timing is important, then faster computer is essential. (2). But there are many tricks involve in software speed up. I have studied this subject for a long time, but I am not ready to discuss it here. The simplest way to improve the performance of the code, like Chidu mentioned, is to improve the programming technique and the subroutines first. (this requires the identification of the subroutines in the first place.) (3). There is a small book, strongly recommended here to reduce the computing time, written by Charles B. Kreitzberg and Ben Shneiderman, entitled "the elements of FORTRAN style: techniques for effective programming", published by Harcourt Brace Jovanovich,Inc.,1972 ISBN:01552215666. IN the book, the Chapter 2 deals with Reducing Program Compute Time. (4). Let me just write down the section titles of the Chapter2: Eliminating Redundant Expressions, Eliminating Unnecessary Subprogram calls, Effective Subscripting, Loop Optimization, Efficient Initialization, Efficient Subroutine Linkage, Efficient I/O Operations, Unformatted I/O. The Chapter3 covers the reduction of storage requirement. (5). Read the book, rewrite the code, and you should see the performance improvement in the code. ( I bought this 121 pages book 27 years ago. This is a good book for everyone writing Fortran programs. This is a preF77 book, but the ideas present are still useful.)

Re: i wanna speed up my solver!
hi!
thanx for a lot of answers but.. point of my question is not, how to optimize program in general. im c programmer, and my program is full c written, something about 6 years i have coded in M68030 (motorolla 680EC30) assembler and i know lot of tricks to optimize code (CODE). anyway my question is how to optimize algorithm of my solver. it is very fast to compute one step time, but when i halve, halve, halve my computing time to do stability criteria ( MY STABILITY CRITERIA: dt < (2 * viscosity)/ ( max(dx,dy) * max(U[i][j][U[i1][j]) its going to be slow  compute like 1023 steptimes for one second of animation (one frame per one second). anybody tried to change local viscosity by function of velocity? Maybe problem is than resolution is too less in my calculations, and dt is going to be very very small? Im calculating 320x200 screen with 32x20 cells or 640x400 with 64x40 cells, with start dt=0.2 (halved when stability fail, else doubled for every timestep). in ine cell i have 5 x 5 particles with distance between two particles = 1 pixel. here dx = width/nx = 10. its ok? maybe here is any problem? ahh! im using GY = 0.98 and vis = 0.01 maybe i must change viscosity, when GY isnt 9.8??? hmm??? help! /// maq 
Re: i wanna speed up my solver!
(1). Sorry, I guess you are an expert in programming. But in CFD, that is only part of it. (2). The other part is the numerical solution algorithm. Since we don't know what you are doing with this MAC method, I can only give you some general direction. (3). If you are using explicit time marching method, then, for stability reason, the time step is limited by the stability criteria. (4). This is the reason why the implicit methods were used to relax the stability limitation. In the implicit methods, iterative methods have to be used in the internal loop. And it takes more time to do one implicit step. (5). In addition to this time step limitation, there is also the cell Reynolds number limit when the central difference scheme is used for the convection terms. The cell Reynolds number is defined as U(i,j)*DX(i,j)/nu(i,j), or V(i,j)*DY(i,j)/nu(i,j), where nu(i,j) is the kinematic viscosity of the fluid. (6). So, in order to improve the stability of the calculation and speed up the simulation, you can try to use upwind scheme for the convection terms, and the implicit method for the transient equation. The explict time, central difference for convection terms, will force you to use small time step for stability reason. (7). Since I am not using the MAC method, you can only get the suggestions from other experts with MAC experience. (8). In addition to the stability limitation of the algorithm, the boundary conditions used also will have impact on the stability. And the boundary conditions are related to the problem which you are trying to solve, but which is unknown to us. (8). By the way, if you modify the viscosity, then you are changing the property of the fluid, am I right? (The flow would be more stable in low Reynolds number range. If that is what you are trying to do.)

All times are GMT 4. The time now is 17:00. 