Strange random crashes on Athlon/Linux platform

[Tatiana Korona]

Hi,

I had the same error messages for some my Molpro jobs (each time in the
other place for the same job), and in my case it was the faulty mainboard.
I just got my computer from the service with the new mainboard and now all
seems to be O.K., but I need to make more tests. Did you try the
combination your CPU+other mainboard? You can establish this way whether
your CPU is O.K. or not. Besides, I heard that >1Gz Athlons need a good
heat sink, and overheating can also result in a random generation of
errors (this is the experience of my brother who's hobby is overclocking
CPU's).

Best wishes,

Tatiana Korona

On Fri, 27 Apr 2001, Dave Moore wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear MOLPRO Users,
>
> 	I just posted a bug report on this item (text included below), but I
> was wondering if anyone else out there has had any problem similar to
> the one described below.  Any and all help is welcome.  Cheers!
>
> Dave Moore
>
> I am running MOLPRO 2000.1 (properly patched) on a 1GHz Athlon under
> Linux (kernel 2.2.16).  The program was built using gcc 2.95.3
> (CONFIG file included at end).  The command "make test" ran with no
> error messages, and the program seems to run fine for most short
> jobs.  However, on long jobs (CCSD[T] potential energy surface scans
> with many points), the program crashes in a seemingly random and
> unreproducible fashion.  In other words, if I run the same exact
> input file several times, MOLPRO will crash in a different place each
> time.  Typically it crashes during the CCSD(T) calculation with an
> "UNREASONABLE NORM, CALCULATION STOPPED" message, but it has also
> crashed during the SCF ("UNREASONABLY HIGH ENERGY") and INT ( just
> general "ERROR EXIT") routines.  I have included an example input
> file that seems to produce this behavior.  When I run it, it
> typically finishes the calculations for 3-12 points on the PES, and
> then the next point will generate the error .. so I don't think it
> can possibly be the input file, since a particular geometry will run
> correctly one time, and then die the next.
> At first I thought this behavior might be due to a faulty CPU in my
> machine, so I swapped CPU's with another, identical machine ... but
> the problem came right back, although it got through >30 steps before
> crashing this time.  I also tried other CCSD(T) PES scans that have
> run successfully on another platform, and these also were subject to
> the same random crashes.
>