- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have set up Ifort on Linux Ubuntu 9.04 32Bits.
I worked with F77 and all was good. Now with ifort , compilation : OK, calculation : OK but NaN in results files.
Which are the the changes I have to do?
Thanks in advance,
Sony
I have set up Ifort on Linux Ubuntu 9.04 32Bits.
I worked with F77 and all was good. Now with ifort , compilation : OK, calculation : OK but NaN in results files.
Which are the the changes I have to do?
Thanks in advance,
Sony
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - sony97onegmail.com
Hello,
I have set up Ifort on Linux Ubuntu 9.04 32Bits.
I worked with F77 and all was good. Now with ifort , compilation : OK, calculation : OK but NaN in results files.
Which are the the changes I have to do?
Thanks in advance,
Sony
I have set up Ifort on Linux Ubuntu 9.04 32Bits.
I worked with F77 and all was good. Now with ifort , compilation : OK, calculation : OK but NaN in results files.
Which are the the changes I have to do?
Thanks in advance,
Sony
I would try to isolate the cause of the fault. Compile with:
-g -traceback -fp-stack-check -check all -fpe0 -warn all
and run.
This will trap on floating point exceptions, look for array boundary problems, check for illegal calling sequences, and a whole lot of other checks.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your help,
I have this warning message :
warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.
I have another program in explicit (with no "implicit none") and it work and it is very fast with Intel Compiler ;)!
I can give you the code if it's possible...
Thanks again
Sony
Quoting - Ronald Green (Intel)
I have this warning message :
warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.
I have another program in explicit (with no "implicit none") and it work and it is very fast with Intel Compiler ;)!
I can give you the code if it's possible...
Thanks again
Sony
Quoting - Ronald Green (Intel)
I would try to isolate the cause of the fault. Compile with:
-g -traceback -fp-stack-check -check all -fpe0 -warn all
and run.
This will trap on floating point exceptions, look for array boundary problems, check for illegal calling sequences, and a whole lot of other checks.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The -warn all has caught something:
warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.
you have truncated the actual message: it should look something like this:
testit.f(3): warning #5194: Source line truncated.
This is because you have a fixed-format file (.f for example, or .f77) and you've exceeded column 72. Note that the "testif.f(3)" tells me this warning is in file "testit.f" and the line number is 3 "(3)". Go to that line and find the problem.
OR you can use -extend-source 80 to make the compiler accept source out to column 80 (132 is also an option if you need it)
Now the message: "name has not been given an explicit type" Is this on the same line as the 'truncated' message? If so, the extend-source will fix it. If not, you have an undeclared variable. Go to the line indicated in "(#)" to find it and fix it.
Then once that is done, you can remove -warn all and continue with the other compiler options given.
warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.
you have truncated the actual message: it should look something like this:
testit.f(3): warning #5194: Source line truncated.
This is because you have a fixed-format file (.f for example, or .f77) and you've exceeded column 72. Note that the "testif.f(3)" tells me this warning is in file "testit.f" and the line number is 3 "(3)". Go to that line and find the problem.
OR you can use -extend-source 80 to make the compiler accept source out to column 80 (132 is also an option if you need it)
Now the message: "name has not been given an explicit type" Is this on the same line as the 'truncated' message? If so, the extend-source will fix it. If not, you have an undeclared variable. Go to the line indicated in "(#)" to find it and fix it.
Then once that is done, you can remove -warn all and continue with the other compiler options given.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok,
When I extended I have these messages :
/tmp/ifortDb0QBC.o: In function `lblirt':
/home/sony/Bureau/LBLIRT/lblod.f:188: undefined reference to `sgeisac_'
BIB/bib.a(CONTINUUM-NEW.o): In function `cont_o3':
/home/sony/Bureau/LBLIRT/BIB/CONTINUUM-NEW.f:285: undefined reference to `o3chapw_'
BIB/bib.a(CONTINUUM-NEW.o): In function `continuumnew':
/home/sony/Bureau/LBLIRT/BIB/CONTINUUM-NEW.f:45: undefined reference to `o3chapw_'
BIB/bib.a(CONTNM.o): In function `abscnt':
/home/sony/Bureau/LBLIRT/BIB/CONTNM.f:30: undefined reference to `o3chapw_'
sony@sony-desktop:~/Bureau/LBLIRT$
Previously:
SURFAC.f(49): warning #6717: This name has not been given an explicit type. [MI]
REAL BDR( MI,0:* ), BEM(*), CMU(*), CWT(*), EMU(*),
--------------------^
SURFAC.f(50): warning #6717: This name has not been given an explicit type. [MXUMU]
$ HLPR(0:*), RMU( MXUMU,0:* ), UMU(*),
-------------------------------^
But MI and MXUMU are define in the main code lblod.f
In /home/sony/Bureau/LBLIRT/BIB/ I have put my subroutines
I compile :
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -c -O3 *.f
rm D1MACH.o
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -c D1MACH.f
ar r bib.a *.o
rm *.o
In in /home/sony/Bureau/LBLIRT/ I compile :
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -O3 $1.f -o $1 BIB/bib.a
All lines are less 72 characters and it run with f77.
I really want to use Intel Compiler because I saw that it's faster in other program... ;)
Thanks
Sony
Quoting - Ronald Green (Intel)
When I extended I have these messages :
/tmp/ifortDb0QBC.o: In function `lblirt':
/home/sony/Bureau/LBLIRT/lblod.f:188: undefined reference to `sgeisac_'
BIB/bib.a(CONTINUUM-NEW.o): In function `cont_o3':
/home/sony/Bureau/LBLIRT/BIB/CONTINUUM-NEW.f:285: undefined reference to `o3chapw_'
BIB/bib.a(CONTINUUM-NEW.o): In function `continuumnew':
/home/sony/Bureau/LBLIRT/BIB/CONTINUUM-NEW.f:45: undefined reference to `o3chapw_'
BIB/bib.a(CONTNM.o): In function `abscnt':
/home/sony/Bureau/LBLIRT/BIB/CONTNM.f:30: undefined reference to `o3chapw_'
sony@sony-desktop:~/Bureau/LBLIRT$
Previously:
SURFAC.f(49): warning #6717: This name has not been given an explicit type. [MI]
REAL BDR( MI,0:* ), BEM(*), CMU(*), CWT(*), EMU(*),
--------------------^
SURFAC.f(50): warning #6717: This name has not been given an explicit type. [MXUMU]
$ HLPR(0:*), RMU( MXUMU,0:* ), UMU(*),
-------------------------------^
But MI and MXUMU are define in the main code lblod.f
In /home/sony/Bureau/LBLIRT/BIB/ I have put my subroutines
I compile :
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -c -O3 *.f
rm D1MACH.o
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -c D1MACH.f
ar r bib.a *.o
rm *.o
In in /home/sony/Bureau/LBLIRT/ I compile :
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -O3 $1.f -o $1 BIB/bib.a
All lines are less 72 characters and it run with f77.
I really want to use Intel Compiler because I saw that it's faster in other program... ;)
Thanks
Sony
Quoting - Ronald Green (Intel)
The -warn all has caught something:
warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.
you have truncated the actual message: it should look something like this:
testit.f(3): warning #5194: Source line truncated.
This is because you have a fixed-format file (.f for example, or .f77) and you've exceeded column 72. Note that the "testif.f(3)" tells me this warning is in file "testit.f" and the line number is 3 "(3)". Go to that line and find the problem.
OR you can use -extend-source 80 to make the compiler accept source out to column 80 (132 is also an option if you need it)
Now the message: "name has not been given an explicit type" Is this on the same line as the 'truncated' message? If so, the extend-source will fix it. If not, you have an undeclared variable. Go to the line indicated in "(#)" to find it and fix it.
Then once that is done, you can remove -warn all and continue with the other compiler options given.
warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.
you have truncated the actual message: it should look something like this:
testit.f(3): warning #5194: Source line truncated.
This is because you have a fixed-format file (.f for example, or .f77) and you've exceeded column 72. Note that the "testif.f(3)" tells me this warning is in file "testit.f" and the line number is 3 "(3)". Go to that line and find the problem.
OR you can use -extend-source 80 to make the compiler accept source out to column 80 (132 is also an option if you need it)
Now the message: "name has not been given an explicit type" Is this on the same line as the 'truncated' message? If so, the extend-source will fix it. If not, you have an undeclared variable. Go to the line indicated in "(#)" to find it and fix it.
Then once that is done, you can remove -warn all and continue with the other compiler options given.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sony,
On my signature is a link that describes how to upload files to this forum. Would you like to tar up the whole directory and upload? Do a 'clean' first before the tar.
ron
On my signature is a link that describes how to upload files to this forum. Would you like to tar up the whole directory and upload? Do a 'clean' first before the tar.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
In attachement you will find the whole 'clean' directory ;)!
I put 2 versions :
1 with f77 and the results files in RES
1 with ifort and the results files in RES with NaN
You have to remove "bib.a" in BIB directory then
First run "./job" in BIB directory (to create bib.a) then "./compil lblod" in the parent directory then "./lblod" to run the program.
Thanks
Sony
Quoting - Ronald Green (Intel)
In attachement you will find the whole 'clean' directory ;)!
I put 2 versions :
1 with f77 and the results files in RES
1 with ifort and the results files in RES with NaN
You have to remove "bib.a" in BIB directory then
First run "./job" in BIB directory (to create bib.a) then "./compil lblod" in the parent directory then "./lblod" to run the program.
Thanks
Sony
Quoting - Ronald Green (Intel)
Sony,
On my signature is a link that describes how to upload files to this forum. Would you like to tar up the whole directory and upload? Do a 'clean' first before the tar.
ron
On my signature is a link that describes how to upload files to this forum. Would you like to tar up the whole directory and upload? Do a 'clean' first before the tar.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you watch the screen echo when you compiled? You have constants which underflow to zero at compile time, as if your application depended on a platform which automatically extends range beyond the range of IEEE default real. Did you try setting -r8?
You have code which depends on your use of -g to turn off optimizations. As has been discussed many times on these forums, it is better to update your source code to use intrinsics such as EPSILON and TINY, rather than depending on platform dependent code last updated 25 years ago.
The source code appears to be intentionally obfuscated, which is not a good sign.
Nevertheless, it does run (painfully slowly) with your compile scripts and a recent ifort version.
You have code which depends on your use of -g to turn off optimizations. As has been discussed many times on these forums, it is better to update your source code to use intrinsics such as EPSILON and TINY, rather than depending on platform dependent code last updated 25 years ago.
The source code appears to be intentionally obfuscated, which is not a good sign.
Nevertheless, it does run (painfully slowly) with your compile scripts and a recent ifort version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sony,
As Tim said, there is some really old and bad code that needs to be addressed. BIB/GEISHA.f
line 207, 259, and 349 have hardcoded some small numbers that do not properly fit into 32bits. You were lucky that f77 extended these to denormalized values and that f77 does not flush denormals to zero. As you noticed, ifort will not do this: other compilers may or may not. So it is best to correct the bad code
line 207: SMAX=TINY(SMAX)
line 259: SMAX=TINY(SMAX)
line 349: AMAX=TINY(AMAX)
It is hard to say if there are more bugs in there. This code does look quite old.
ron
As Tim said, there is some really old and bad code that needs to be addressed. BIB/GEISHA.f
line 207, 259, and 349 have hardcoded some small numbers that do not properly fit into 32bits. You were lucky that f77 extended these to denormalized values and that f77 does not flush denormals to zero. As you noticed, ifort will not do this: other compilers may or may not. So it is best to correct the bad code
line 207: SMAX=TINY(SMAX)
line 259: SMAX=TINY(SMAX)
line 349: AMAX=TINY(AMAX)
It is hard to say if there are more bugs in there. This code does look quite old.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sony,
As Tim said, there is some really old and bad code that needs to be addressed. BIB/GEISHA.f
line 207, 259, and 349 have hardcoded some small numbers that do not properly fit into 32bits. You were lucky that f77 extended these to denormalized values and that f77 does not flush denormals to zero. As you noticed, ifort will not do this: other compilers may or may not. So it is best to correct the bad code
line 207: SMAX=TINY(SMAX)
line 259: SMAX=TINY(SMAX)
line 349: AMAX=TINY(AMAX)
It is hard to say if there are more bugs in there. This code does look quite old.
ron
As Tim said, there is some really old and bad code that needs to be addressed. BIB/GEISHA.f
line 207, 259, and 349 have hardcoded some small numbers that do not properly fit into 32bits. You were lucky that f77 extended these to denormalized values and that f77 does not flush denormals to zero. As you noticed, ifort will not do this: other compilers may or may not. So it is best to correct the bad code
line 207: SMAX=TINY(SMAX)
line 259: SMAX=TINY(SMAX)
line 349: AMAX=TINY(AMAX)
It is hard to say if there are more bugs in there. This code does look quite old.
ron
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page