|
[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 if-endif block and do-loop 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 do-loop, and it was designed to do so. And the vector-super-computer 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 If-statement in a do-loop. (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 finite-difference code is very fast, a finite-volume code is slower, and a finite-element code is even slower. But, any code can be restructured to optimize for minimum memory or maximum speed. It is likely that a finite-volume code has more geometry related stuff to compute. And a finite-element 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 re-compute it a second time. For 2-D flow, this is a good approach, because you normally do not have the memory limit. For 3-D 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 1-D problem first, such as the fully-developed 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.
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Floating point exception error | Alan | OpenFOAM Running, Solving & CFD | 11 | July 1, 2021 22:51 |
TimeVaryingMappedFixedValue | irishdave | OpenFOAM Running, Solving & CFD | 32 | June 16, 2021 07:55 |
Hydrostatic Pressure and Gravity | miliante | OpenFOAM Running, Solving & CFD | 132 | October 7, 2012 23:50 |
Differences between serial and parallel runs | carsten | OpenFOAM Bugs | 11 | September 12, 2008 12:16 |
Time Spent | Faraz | Main CFD Forum | 13 | December 10, 1999 12:38 |