
[Sponsors] 
January 19, 2000, 19:03 
Time spent on FV scheme

#1 
Guest
Posts: n/a

1. I changed my finite difference scheme code into finite volume method version, and I found the latter code became quite time consuming. Roughly 2 times more per iteration compared with FD version. And I found the majority of computation time increase happens at the flux calculation part(I use van leer FVS). Could someone give me ideas on this change? By the way, how does the arrangement of ifendif block and doloop affect the computation time? 2. I appreciate some detailed explaination about the physical wall boundary condition treatment with finite volume scheme. (e.g. Do I need to evaluate the convective flux at wall with FVS or just specify it as zero? )
Thanks. 

January 20, 2000, 12:39 
Re: Time spent on FV scheme

#2 
Guest
Posts: n/a

(1). There are many questions in your message. I can only give you some general information. (2). Fortran is very fast in doloop, and it was designed to do so. And the vectorsupercomputer also takes advantage of this property. (3). If statement requires the logic check and then branch out to other statements. It is slow, and you also don't like to put a lot of Ifstatement in a doloop. (4). I am not sure whether you can find a Fortran compiler which will give you the statistics of the computer time spent in a subroutine. This would be easier to sort out the locations where the computer spends most of it time. But, you can always insert a statement to print the time. (5). In general, a finitedifference code is very fast, a finitevolume code is slower, and a finiteelement code is even slower. But, any code can be restructured to optimize for minimum memory or maximum speed. It is likely that a finitevolume code has more geometry related stuff to compute. And a finiteelement code has a very large matrix to solve. (6). A factor of two is not bad, so, you can try to store some temporary variables ahead of the time at the begining of the code. In this way, you don't have to recompute it a second time. For 2D flow, this is a good approach, because you normally do not have the memory limit. For 3D problems, this approach can push the code memory to a very large number.(commercial codes are normally in this category, with huge memory requirement) Then, it is not possible to use a large mesh size, and the solution accuracy will suffer. (7). For the boundary cells, you can first apply the regular formula to it, then apply the wall condition. In this area, you really have to draw the boundary cell first. Sometimes, the cell will be on one side of the wall with the cell surface attached to the wall, sometimes, the cell will enclose the wall, and only the inner side of the cell will be effective. And sometimes, an image cell is created on the wall side(inside the wall). So, it depends on your definition of the finite volume mesh. It will become more confusing when applying the law of the wall treatment. (8). Anyway, if you find it difficult, then you should try to deal with the 1D problem first, such as the fullydeveloped channel flow. Then you can try out different formulations of the boundary condition. In this case, the CPU time will not present any problem to you.


Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
TimeVaryingMappedFixedValue  irishdave  OpenFOAM Running, Solving & CFD  28  May 28, 2015 13:37 
Hydrostatic Pressure and Gravity  miliante  OpenFOAM Running, Solving & CFD  132  October 7, 2012 22:50 
Floating point exception error  Alan  OpenFOAM Running, Solving & CFD  10  April 6, 2012 14:02 
Differences between serial and parallel runs  carsten  OpenFOAM Bugs  11  September 12, 2008 11:16 
Time Spent  Faraz  Main CFD Forum  13  December 10, 1999 12:38 