Hi,

I've a 2D FVM fractional step CFD solver. I need to solve 2 linear equations - momentum and poisson. I was hoping to reduce the runtime since mine is an unsteady problem which requires many steps to reach a periodic state and it takes many hours to reach it.

My grid is typically around 200X80

I'm thinking of parallelizing the code with a parallel solver such as PETSc. However, I was told that my problem is not big enough. There are simply too little points. Is that so? Is it true that in general, for a problem size similar to mine, it is not worth parallelizing at all?

Thanks!

you will not gain much with parallelizing such small codes.Instead try to optimize your code for the particular machine and you can speed it up.

Based on which reference did you develop the solver ? .I have been thinking of doing fractional step for some of my work.

There are quite a lot of reference. The one I used is from JCP 162, 411â€"428 (2000) by Haecheon Choi. Thanks

>... it is not worth parallelizing at all?

i am agree with considering ur problem size.

in clear:

1. u want to parallelize linear solver, it needs communication per cycle (usually), when u breake problem to parts, solution work per node is decreased (but ur total work is small) but network latency is fixed, that can anihilate your effort (or has reverse effect)

2. u have additional work due to parallelizm and communication.

3. u select PETSc, so i guess, u construct system on master then distribute it and use PETSc, then collect solution, it is the worst method and is acceptable only for very large problem (better cure is using distributed data).

4. finally note that scale of ur problem is large but in temporal direction, i don't knowe why is it? but try to reduce it. You can think about space-time (or only time) multigrid methods (convergence acceleration in temporal direction).

I hope this help.

Just looking at the size of the grid might not be a sufficient indicator to if a code will benefit from being executed in parallel.

I've done some benchmarking using a commercial code with up to 6 nodes. The test case was about 15k cells and to my surprise I didn't reach the threshold where the network communication was the limiting factor.

The tests were not "scientific" in any way but it showed me that there is no general magic number where the amount of cells is too few.

---

If you do decide to parallelize the code you should calculate the time lost in doing so before you start.

You might also be able to use a dual- or quad-core if you want a small boost, and not have to worry about network communication.

Best Regards

F.P.

Ok, your __grid size__ is surely small for parallelism (not necessarily your code) but if you decide to make your code parallel you could explore grid sizes much greater (even DNS scaled grids).

An easier way of implementing parallelism in your code would be using a shared memory approach like OpenMP. Do you know how OpenMP works? If so, you could parallelize your code in less than a day and gain some performance (only for shared memory machines -- several CPU's using the same memory system).

Regarding PETSc: I'm not a PETSc user but it seems that in PETSc you can build the system in a master node, as RT said, or you can do it in a distributed manner (better approach).

Finally, if your code is "simple" it would be a nice opportunity to start understanding and implementing parallelism for more complex future codes. I guess it's a good starting point.

Cheers

Renato.

Aside from the problem of small domains...

you probably have heard this before, because anyone who knows something about computational efficiency will first tell you this: Optimize your serial code to the maximum possible performance, before even thinking about parallelization.

Putting 2 and 2 together (with some information from your other posts) I think you are performing 2D computations on periodically moving airfoils. I will further assume that you are using your fractional step method as a time-marching algorithm to drive your flow from some initial condition to a periodic state. If this is the case, there is a large potential for improving your efficiency by choosing a "slightly" different approach: The harmonic balance method. I say "slightly" because the transition from a time-marching method to the harmonic balance method can be surprisingly simple in implementation (under certain conditions), far simpler than creating an efficient parallel code. (that's despite the fact that the concept is quite different from the time-marching approach). If you haven't heard of it, the harmonic balance method attempts to obtain the periodic solution directly, rather than resolving irrelevant and lengthy temporal transitions. It's usually quoted as 5-10 times more efficient than time-marching for periodic flows. Anyway, I think it's worth considering, because your type of application is ideal for this method... and afterwards think about parallelization.

you can do it using OPENMP or HPF. it is very easy to do and you don't need to change your code a lot.