Scott: I can now get a 1.7GHz P4 with 512Mb of Rambus for $1560 or two for a little less than $3120. I don't see the advantage of the dual cpu board. Am I missing something?

Scott, when you say that you do not recommend the 1.3GHz machine are you talking about the AMD with the PC133 or DDR memory?

Steve,

Sometimes the choice comes down to non-technical things. If your boss likes the P4, and you'd have to talk him into an Athalon, it would clearly be easier just to get a P4. Hey, it's his money you're spending, make him happy and spend it the way he wants you to

Regards, Alton

Alton, you may be right. If the P4 performance is not up to advertising, I won't get the blame But I like to get the best possible since I'm doing the calcs.

(1). Well, in this case, you are on your own. (2). If you have time, you can rent the machines and run the test based on your problem.(3). Or you can can buy one and rent one. (4). Still, it will depend on the code and your problem. It is hard to generalize.

When I mentioned that the 1.3 GHz was a poor performer, I was talking about the 1.3 GHz P4 you mentioned in your initial post (the third machine). Originally you didn't mention the code you would be running so I assumed it is multiprocessor capable. If it is capable you should see a dual 1.7 GHz Xeon running 30%-110% faster than a single 1.7 GHz P4 (depending on how well the code distributes the work). I have no experience with WIND.

I do feel that the extra bandwidth that your boss likes probably will be wasted. Compare Jonas Larsson's benchmarks: the double bandwidth DDR machine was only 5% faster that the PC133 machine. Increasing the bandwidth even further from DDR to RDRAM will also show little improvement yet add dramatically to the price of the computer.

Scott: Thanks for the clarification.

(1). It seems to me that if one is using someone's free codes, then he is likely to spend most of his time worrying about the speed of a computer. And since the speed of a computer is not designed for CFD analysis, then the consequence is one is really at the control fo the someone's codes and someone's computer. (2). As you see, even if one put together a large cluster of computers based on the off-shelf PC, he is nothing but a person trying to get the code running at certain speed, which is arbitrary! or perhaps it is controlled by the boss or the project schedule. (3). And the source of this is the creation of the code as equivalent to CFD. (4). If one can not look at the problem, the equations, the formulations, the mesh independent solutions, then even if one has free access to the super-computer, the work is still NOT CFD. (it is still important, if your survival depends on it) (5). What's happening here reflect the general environment and practice as part of CFD. It is rather hopeless, because the speed of a computer has no impact on the solution accuracy in CFD. My suggestion to the governmnet is: stop wasting the tax payer's money inventing the so-called CFD codes, especially if it is going to be free.

I would contend that the speed of a code is NOT arbitrary (the 'C' is just as important as the 'FD'). Reducing the time it takes to arrive at a solution is the only way we can move CFD away from analysis (reactive) and towards design (proactive). The faster it runs, the more powerful it becomes. Larger and more complex problems can be accomodated in acceptable time frames.

I have a rotor and a stator. Previously I would analyse each one separately, making assumptions about boundary conditions etc etc, a full unsteady stage calculation would be unviable - it would take weeks and weeks to arrive at a solution. Now I can mesh the whole stage, send it to my beowulf cluster and have an answer the next day. That answer is BETTER than anything I had before because is tells me all about the unsteady interaction of the two components (which is critical). The code has not changed (apart from being parallelized) but now my results are many times more useful.

(1). I think, I agree with you 100%. (2). The issue here is the other way around. That is trying to find a faster PC to do the work of a Cray computer. (3). A network is a practical way to solve more complex problem. It is a totally different approach. (4). Your approach is "parallel computing". (5). Stage calculation is a complex issue, and Multi-stage is even more complicated. Whether such transient calculation can simulate the real flow field, is itself a research issue. (6). And if you have to simulate 360 degree of flow field including all the blades, then suddenly it becomes impossible task. The inlet flow to axial turbine is always non-uniform. And in the radial flow turbomachinery, the flow through each blade passage is different, because of the volute or scroll. (7). So, there is a huge room for improvement. In both the hardware and the software.

Badger, does the beowulf networking work only in a Linux environment or can it work with Win2000?

Incorporated into all programs designed to run on Beowulf clusters is the 'Message Passing Interface' (MPI) this is a set of libraries that allow each node in the cluster to communicate with one another, remain synchronised, etc etc. If you go to the MPI homepage www-unix.mcs.anl.gov/mpi/index.html you will see that there are Win NT/2000 implementations of the libraries available. So although by far the most popular OS for Beowulf is Linux, *in theory* a Win2000 cluster could be built (never heard of one though)

Bagder, thanks for the response re Beowulf and the website.