Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

problems with XLF/64 bit


Hi newsgroup!

I have encountered some problems when trying to port my code to a 64-
(powerpc) machine using XLF. In short: When compiling with ifc on a
32-bit machine it works fine, giving reasonable results, but it wouldn't
work anymore on a 64-bit (cluster) machine, i.e. the results are
nonsense. FYI: the code is a numerical MHD solver (zeus-mp).

I invoke the compiler via the mpif90 wrapper script using

xlf90_r -q32 -O0 ...

-q32 because I thought the problems might be due to 64-bit stuff,
doesn't look like it, though.

What happens is that it introduces NAN into the calculations. I tried to
track the source of these NaN down, and while doing so, I stumbled
across some interesting (=weird) behaviour.

I have code like:

          do 350 j=jbeg,jend
            do 340 i=ibeg,iend
              w1(i,j,k) = u1(i,j,k) + q1 * st1(i,j,k) / srd1(i,j,k)**2
              w2(i,j,k) = u2(i,j,k) + q1 * st2(i,j,k) / srd2(i,j,k)**2
              w3(i,j,k) = u3(i,j,k) + q1 * st3(i,j,k) / srd3(i,j,k)**2
340        continue
350      continue
360    continue

c       write (*,*) '=='
c       write (*,*) u2(42,:,ks)
c       write (*,*) '--'
c       write (*,*) st2(42, :, ks)
c       write (*,*) '++'
c       write (*,*) srd2(42, :, ks)

return
end

I know that after the code returned from this subroutine, there is a
couple of NaNs in w2 (I know that by just writing the array to stdout).
However, if I uncomment the write statements at the end, the NaNs go
away! The results of the code still don't make sense, but at least they
are numbers, so I guess you could consider that as a progress :-)

Obviously, there shouldn't be a difference when I just print out the
arrays.... I suspect some compiler optimization that takes place when
the write commands aren't there and doesn't if they are.

Do you have any ideas? I'd also be really grateful for any comments
about how to get xlf to be compatible to ifc code. There is the
possibility that this is some library/architecture problem, but I
strongly suspect the compiler at the moment.

Thanks heaps!

Cheers,

Matthias

--
http://astro.ph.unimelb.edu.au/~mvigeliu/

A likely one is array bound violation. The write statements add some
memory space for constants and character strings, so when they are
active, those values are overwritten innocuously instead of the
important numbers.

Another possibility is an "unsaved" variable that happens, by chance,
to retain its value when the writes are there.

Hi Michel,

Michel Olagnon wrote:
>> I know that after the code returned from this subroutine, there is a
>> couple of NaNs in w2 (I know that by just writing the array to
>> stdout). However, if I uncomment the write statements at the end, the
>> NaNs go away! The results of the code still don't make sense, but at
>> least they are numbers, so I guess you could consider that as a
>> progress :-)

> A likely one is array bound violation. The write statements add some
> memory space for constants and character strings, so when they are
> active, those values are overwritten innocuously instead of the
> important numbers.

ok, that sounds interesting. Any ideas how that can occur with xlf while
it doesn't occur with ifc? Probably some side-effects in the storage
handling of arrays... I'm trying to work through the thousand compiler
options of xlf but haven't found any interesting yet.

> Another possibility is an "unsaved" variable that happens, by chance,
> to retain its value when the writes are there.

i thought about this, as well. Indeed, it sometimes helps to add -qsave
but not in all cases - seems there's some multiple errors here.

thanks heaps!

Cheers,

Matthisa


--
http://astro.ph.unimelb.edu.au/~mvigeliu/

If a program has array bounds errors, then it will typically produce
different behavior with different compilers.  There is no reason to
suspect anything special with respect to those two compilers, other than
the fact that they happen to use different memory layouts.

If you have any other compilers available, it may be instructive to try
the program with them.  Something may pop up that sheds light on the
problem.

--
Dave Seaman
Oral Arguments in Mumia Abu-Jamal Case to be heard May 17
U.S. Court of Appeals, Third Circuit
<http://mumia2000.org/>

On Fri, 13 Apr 2007 18:00:29 +1000,
 Matthias Vigelius <mvige@physics.unimelb.edu.au>
 wrote in <evndb0$i8@news.albasani.net>:

> Michel Olagnon wrote:
>>> I know that after the code returned from this subroutine, there is a
>>> couple of NaNs in w2 (I know that by just writing the array to
>>> stdout). However, if I uncomment the write statements at the end, the
>>> NaNs go away! The results of the code still don't make sense, but at
>>> least they are numbers, so I guess you could consider that as a
>>> progress :-)
>> A likely one is array bound violation. The write statements add some
>> memory space for constants and character strings, so when they are
>> active, those values are overwritten innocuously instead of the
>> important numbers.
> ok, that sounds interesting. Any ideas how that can occur with xlf while
> it doesn't occur with ifc? Probably some side-effects in the storage
> handling of arrays... I'm trying to work through the thousand compiler
> options of xlf but haven't found any interesting yet.

        Have you found the one to turn on bounds-checking?  That's the
first thing I'd try.  (Others mentioned bounds errors, but not turning on
checking, as far as I've seen so far.)  Hmm, a quick google suggests -C
(or -qcheck).  Maybe -qextchk and -qflttrp would be useful, too.

>> Another possibility is an "unsaved" variable that happens, by chance,
>> to retain its value when the writes are there.
> i thought about this, as well. Indeed, it sometimes helps to add -qsave
> but not in all cases - seems there's some multiple errors here.

--
Ivan Reid, School of Engineering & Design, _____________  CMS Collaboration,
Brunel University.    Ivan.Reid@[brunel.ac.uk|cern.ch]    Room 40-1-B12, CERN
        KotPT -- "for stupidity above and beyond the call of duty".
Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc