I am considering building a PC using the new AMD Athlon 1000Mhz cpu combined with the Asus A7V motherboard and Matrox G450 32Mb AGP video card. I will be using this PC for CFD number crunching (NPARC and WIND) and grid generation using CAD software (ICEM CFD). I can get the Athlon for $217 and the Asus for $162; I will be using 3 256Mb modules for RAM.

Is this combination suitable for my purposes?

(1). No one knows, because we don't know what's in the hardware and the software. (2). Ask the vendors of the software for the opinion first. Or you can simply go ahead and try it, and let us know your results here.

Hi,

I work for ICEM CFD and have just built the same system!

The CPU I used was 1.2Ghz with 64meg GFX. The system is very fast, about over 100% faster at meshing that a R10000 SGI. I am happpy with the system but there was one big problem that took me a week to solve. You may find that the GFX and cpu are too fast the bus on the asus mother board. This will cause the graphics to freeze. If this happes then update the BIOS. This can be downloaded from the asus web site.

Other wise from a pre processing point of view it is a good system.

Cheers

David

Hi Dave. Surprised to see you on this site! What is the GFX? Is it a video card? Can you please give more details (manufacturer, source of purchase, etc)? Which BIOS did you motherboard have?

I was going to call you on Friday (2/16) to ask your opinion on this system for ICEM-CFD use. My main concern is with a video card that can handle shaded surfaces and the rotation of shaded surface in DDN, HEXA and Mesher. The WinNT version of ICEM-CFD did not allow rotation of shaded surfaces in DDN. Has this been fixed.

I'm working with Win2000 and have now both NICs working!

Hi,

The GFX (graphics) card in my system is based on the Gforce II ultra chip set. It`s currently one of the fasted but will set you back about 400GBP. Another good card is the Gforce II GTS which is around the 200GBP mark.

The BIOS was 1004b which I upgraded to 1005D.

The above cards will handle solid shading of models with ease in ICEM CFD and with verison 4.1.1 the shading is naturally faster. DDN doesn`t support dynamic shading as on NT in is running is X11 rather than OPEN GL as MED and TETRA / HEXA. Alot of DDN users have now switched to direct interfaces (CATIA / PROE / UG etc).

Let me now if you need more info etc.

Cheers

David - ICEM CFD UK

Dave, thanks for the info. Who makes the Gforce card?

I wish we could go to a direct interface but we can't afford any worthwhle CAD package. Does ICEM-CFD support Solidworks?

Hi,

My card is by a company called Hercules, but Creative labs and Asus make one with the same chip set.

Yes, you can use solidworks with ICEM CFD. Solidworks is the latest CAD system to get a DIRECT CAD INTERFACE to ICEM CFD meshing. There is some infomation on:

http://www.icemcfd.co.uk and http://www.icemcfd.com

Cheers

David

David, I bought my system on Sat. and got the Hecurles 3D Prophet II GTS PRO with 64MB and the Gforce chipset. Got the 1.1Ghz Athlon since it was about $40 more. I am now using 2 generic PC100 128MB RAM cards until I get some Crucial PC133 256MB SDRAM. I was surprised that I could run a 3million-grid points CFD job on so few RAM with Win2000; I could never do this on Win98 and therefore made incorrect conclusion on the RAM needed to run CFD.

BTW, I must apologize since I mistook you for another David M (Marshall) who works for ICEM-CFD near Detroit, Michigan. This may explain some of my seemingly cryptic remarks.

Hi,

I am glad you like the system!

I wasn't sure I knew you either but I didn't like to be rude and say so!

Since I made this system I haven't used my SGI octane!

Cheers

David

One, clue about your location, that should I should have taken, is the price of your GFX card, 400 pounds which is a bunch of dollars

I bought this system recently and am now trying a CFD case as a test. So far then results are very discouraging. The solution keeps diverging despite reducing the time step and increasing pressure relaxation. But this same case will run successfully on my Gateway with has a 450Mz Pentium III with 3 128Mb sticks of PC 100 RAM. I also have 3 128Mb sticks of PC 100 RAM with the AMD Athlon (the ASUS manual states that the PC 100 RAM is acceptable). I beginning to wonder whether PC133 RAM is needed?

What I'm reading from your note does not indicate to me, at all, that you have a memory problem. Divergence of a problem, especially if it runs well on another (but similar) system, has nothing to do with memory.

Potential problems: (1) Bug in the CPU (remember intel a few years back?), (2) Bug in the compiler, (3) CPU speed incompatibility with the compiler - so maybe some memory conflicts occur (?), (4) double precision vs. single precision run. (5) others I can't think of right now

Either way, this is a very important/interesting finding! Please let us know what the problem is when you find it.

Note: I've heard lots of pro off-the-shelf PC computing arguments on this list - based on CPU speed alone. What I have not read (enough) by the listers is the software side of the problem. For example, as far as the reliability of and the advance in compilers, operating systems and other scientific computing support software are concerned I wonder if the PC's can compete with generations of development at SGI and/or SUN. Any comments?

Adrin Gharakhani

Andrin, Thanks for your quick reply.

I'll comment on your comments: 1)You mention a past bug in the Intel some time back. What bug was it? 2)Did not compile the code on the new computer; I copied the executable from the older machine. Is this a problem? 3)I have ordered the PC 133 RAM (I'm using the PC 100 RAM as a temporary substitute). 4)All calcs are done in single precision on both machines 5)need more excuses

(1). I have used PC to develop CFD codes since early 80's. (2). I have used Radio Shack Model III, Amiga/1000, PC/286, PC/486, PC/Pentium, PC/AMD, with BASIC, FORTRAN, and had no problem with convergence with my own codes. I am in the process to write CFD code using VC++. (3). What you need to do is: run the same code for just a few iterations to see whether you can get the "identical" results from both computers, if the old one is still available. Make sure that the codes, including the input files are identical.(make sure that you don't use old versions of the code by accident. (4). You also should check whether the old code has "undefined variables" or not. (or un-initialized variables) (5). I think, the problem is likely in the software. The hardware part is easy to fix. (so far, I had none in the last 30 years with PC)

John, I used the same input for both cases and started with the same solution and grid with the same executable. I copied the files from the old computer unto a CD and read it into the new computer.

I'm not sure what you mean by 'undefined variables'; the code would give an error or abort if the input is incorrect. I've basically used the same input file for the past year so its reliability seems to be very good.

(1). I noticed that you said you did not re-compile the code. (2). If you are using two different CPU's, you may want to recompile the same code on the new computer and find out whether both versions will give the same answer. Remember that sometimes small difference in different versions of code can have big effect on the operation. (3). Make sure that you are using the same version of the operating system. (4). If you still have the old computer system, you can easily check out the new one by writing a short program and run it on the new system. Upgrading to the new operating system is not always a good idea. Try to keep the system "identical" will keep you trouble free.

About reliability - we've run the majority of all our CFD simulations over the last 2 years on a large cluster of Linux PC's (Dell OptiPlex GX1 PIII 500 MHz). We run both in-house codes (compiled with Absoft Fortran) and commercial codes (mainly Fluent). Reliability and performance has been fantastic - the cluster is much more stable than all our other high-end Unix machines (we have a bunch of SGI workstations, dual-CPU HPs and a 12-CPU HP compute server). We are just now upgrading our cluster. We are not even concidering buying anything but PCs with Linux - the price/performance ratio is at least 5 times better than any Unix alternative. Stability is also better. The downside is that to get the best price you still have to build the cluster yourself. This means that you have to do your own home-work to assure that everything works together and you have to install Linux yourself.

For pre- and post-processing the memory limitations of the 32-bit PC architecture (max 4 GB in theory, often 1 GB in practise) still often forces you to use expensive 64-bit Unix workstations.

This sounds strange and worrying. I have not heard of any known bugs in the Athlon that could cause this. You should be able to transfer the executable and the case/data file and run and get the same results. The FP bug in the Pentium mentioned by andy is an old problem that was fixed a long time ago. The Asus A7V is well known for excellent stabilty and many people have used it succefully for number-crunching.

Does your system run everything else well? Any stability problems or lock-ups? If everything except your CFD code runs well then my guess is that you somehow made a misstake transfering the code/case-data (try to load the stuff from the CD onto the Pentium machine and see if it runs there when you "install" it the same way as you do on the Athlon). If your machine is stable and runs everything else well it is most likely not a memory problem.

I assume that you have the same operating system on the two machines - if you don't then that is a likely cause of the problem.

If you have access to source code you could always try to trace the cause of the divergence - often tough work though.

Pleas let us know if you find the bug - we're also considering testing a few Athlons (with the new DDR memory).

I agree with John that in order to find where the problem is you need to minimize the number of variables. So, if at all possible, keep operating system, compiler, source code, etc, etc. identically the same and see if there is a problem. I doubt there is a bug in the AMD CPU or we would probably have found out about it by now. (I mentioned it so that listers realize that we can't take the "surest of" things for granted)

The intel problem was with the floating point operations, which did not produce correct results. There are tons of scientific papers on this subject, believe it or not - check the internet for A. Edelman, prof. of math at MIT, for starters (I hope he still has the material available on-line)

Now back to your problem. I'd recommend, likewise, that you compile the code on the new machine. That is probably where your problem lies.

John's issue with initialization of the code is quite on target as well. Most fortran programmers (including myself for a long time in the past) are not in the habbit of initializing every variable, so the compiler assigns a value to them, if you don't. Most often the variables are initialized to zero, but sometimes they are assigned random garbage numbers and if you use such a code based on the implicit assumption that the uninitialized variables are set to zero, then you'll get "wrong" answers.

My last comment: if you get _vastly_ different results just because you changed the CPU or the compiler or the operating system (and if the solution does not depend on random number generators), then I guarantee you that there is a (nasty) bug in the code. Count your blessing that you found such a difference, because it allows you now to find where it is. But the operative word is vastly, such as convergence vs. divergence and not differences in the last digit of the computation. I'm not yet suggesting that you have a bug in the code - not until you compile the code on the new system )

Adrin Gharakhani

Jonas,I have not done much else with the Athlon except use Wordpad to edit and browse files and some use of Tecplot which I use to plot the CFD solution.

I had early problems with the display freezing, so I reduced the screen resolution and, in the BIOS, I reduced value for the AGP slot from 64MB to 32MB. I'm not sure if this is a real problem.

Your idea of retransferring the data back to the other machine and rerun this case is a great idea! Ooops, just remembered that I'll need to hook up a CD RW so I can transfer the files.

I have Win2000 on the AMD machine and WinNT on the old machine but I don't think that this is the problem since I'm running the same CFD code and model on a third machine that has Win2000. I'm considering recompiling the code on the AMD machine.