Prev: Some matlab -> fortran translation
Next: minor typo in The Fortran 2003 Handbook?
From: Tim Prince on 27 Dec 2009 09:29
Terence wrote:
> On Dec 27, 10:18 am, News user <ara...(a)gmail.com> wrote:
>
>> I realized that I forgot to mentioned some details on my code:
>>
>> I use f77 fortran and I have double-checked my code with ftnchek;
>> and yes I always write very carefully using double precision constants
>> (e.g. 3.5d0) and all my real variables are defined to be real*8.
>> (The code is quite complicated and long to be included in a message.)
>>
>> Note that on machine (c) g77 works ok - it is the
>> intel ifort em64t compiler which produces the low 4 s.d. agreement.
>
> I wonder if you are specifying a single-precision square root function
> in an environement where there are reserved names for the various
> levels of desired precision?
This can be a valuable hint where g77 appeared to work better than other
compilers. All function return values in g77 on x87 are extended
double, even if declared default single precision. Likewise, as Terence
points out, intrinsics such as sqrt would in effect return at least
double precision, even though the argument is single precision.
From: robin on 27 Dec 2009 18:34
"News user" <arapis(a)gmail.com> wrote in message
news:cfc2b911-5c1f-4513-be40-fd71c45b47ee(a)j24g2000yqa.googlegroups.com...

| Machines (a) and (b) produce results identical to 9 significant digits
| (s.d.) but machine (c)
| produce results with only 4 s.d. Note that my code uses double-
| precision and the systems
| are well-conditioned, and thus I expect very limited round-off error,
| and in particular,
| agreement close to 14 s.d.

Problems such as you describe are likely to be caused by
real constants having default precision instead of double precision.

If you expect double precision results, constants need to be written
with D0 or Dsomething (except possibly integral constants such as 1. and 2. etc
(but even then, care may be required).

You may also have mis-matched arguments with corresponding dummy arguments.


From: robin on 27 Dec 2009 18:34
"News user" <arapis(a)gmail.com> wrote in message
news:66633bf9-1240-4186-9283-d7f85e15e225(a)m26g2000yqb.googlegroups.com...
|
| > Please post and provide more details in our user forum (link below). In
| > particular, please tell us which compiler options you are using. If you
| > can provide a test case, that would be best as otherwise all we can do
| > is speculate.
| Many thanks for your answers.
|
| Using ifort I compiled my code using:
| ifort -O2 program.f -o program
| or via MKL with:
| ifort [-openmp] -O2 program.f -L$MKLPATH \
| -Wl,--start-group $MKLPATH/libmkl_intel_lp64.a $MKLPATH/
| libmkl_intel_thread.a \
| $MKLPATH/libmkl_core.a -Wl,--end-group -liomp5 -
| lpthread \
| -o program

Still no code.

This is like "My car won't start. What's wrong with it".

Withourt code, this will go nowhere.


From: Ronald Benedik on 28 Dec 2009 11:12


"News user" <arapis(a)gmail.com> schrieb im Newsbeitrag
news:cfc2b911-5c1f-4513-be40-fd71c45b47ee(a)j24g2000yqa.googlegroups.com...
> Hi there:
>
> I have a rather long experience with scientific fortran programming
> the last 20 years.
> Recently I noticed the following problem with intel fortran em64t
> compilers:
>
> I have access to 3 differtent types of intel-CPU linux computers
> running either intel ifort
> (versions 9, 10 and 11) or g77:
> (a) Pentimum 4 using intel 32-bit compilers
> (b) Dual core Itanium 2 (linux ia64) using intel 64 compilers
> (c) Intel Xeon 5300 quad core Processor (linux x86_64) using intel
> em64t compilers
>
> My fortran code solves over-determined systems using LAPACK DGELS
> Least-Squares solver
> while mainly I compile my code with ifort and MKL.

Once I wrote a least square program using QR decomposition
in C. I dropped the idea of doing it in Fortran because there's
better control of data types and subsequently
rounding behavior in C.

> Machines (a) and (b) produce results identical to 9 significant digits
> (s.d.) but machine (c)
> produce results with only 4 s.d. Note that my code uses double-
> precision and the systems
> are well-conditioned, and thus I expect very limited round-off error,
> and in particular,
> agreement close to 14 s.d.

> So, has anyone seen this issue/problem? Origin of problem? Any
> possible solution?

I can't help on that.

> --------------------------------------------------------------------------------------------------------------------------------------------
> I do have an additional question:
>
> Since my code uses double-precision and the systems are well-
> conditioned,
> I expect agreement close to 14 s.d - not the 9 s.d I get at the very
> best.

That depends on the number of calulations for example
the system size: the relative rounding error grows
exponential with the number of consecutive calculations.

> In the past, on other types of processors (e.g AIX and SGI
> workstations)
> I was able to get 14 s.d. but not on current INTEL-based computers.

With the same system size or pretty well done examples?

64 bit processors may include the fused multiply add
instruction not found on the x86 or x86-64 platform.

From: Steve Lionel on 28 Dec 2009 11:46
On 12/27/2009 12:01 AM, News user wrote:

> As Steve suggested, transfering the executable from machine (a) to
> machine (c)
> I got identical results to the 14 s.d. I print out.

Ok, this is a big clue. Machine (a) is 32-bit and machine (c) is
64-bit. The function return and argument passing conventions are
different enough so that type mismatches which may go undetected in
32-bit mode will cause strange problems in 64-bit mode. You ran the
32-bit program on machine (c) and it worked as you wanted.

Try adding the option "-warn interface" to your ifort build and see if
it reports any problems. (If not using version 11.1, add
"-gen_interface" as well.) I'm guessing that you have mismatched types
in arguments or function return values.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Some matlab -> fortran translation
Next: minor typo in The Fortran 2003 Handbook?