NonAdvancing output ?

[Flavio_Almeida]

I have Intel Fortran 10.1 Professional and also the MS Fortran Powerstation Professional.

Sometimes I use Powerstation and I would not like to retire it but apparently the compiler has the bug explained below. I would like to know if someoneknow a bug in this compiler, concerning writing ADVANCE="NO" records to files?

I think this should have been tested properly, as this bug is so simple but I am not able to find a solution. Ah, if I compile it usingIntel Fortran 10.1 this problem does not occur!)

-----------------

I used implied DO for writing arrays in thisconsole application.

If I do not use the ADVANCE modifier the program works properly but would generate a file different from what I want. (I know, I can recode it using string concatenation but I would not like to do so as the language says we can use nonadvancing output.)

The problem is:

The do loop (that controls this writing) mysteriously stops after 10 records (from more than 1000) records

with no error message.

If if I use the screen instead of an UNIT connected to a file, i.e., (UNIT=6) the program works perfectly.

Recoding (as I said I would not like to do this) the "writes" as below (commented version) and the software was able to write all the records, but using the originalversion the software stops after record 10.

In this case the generated file (associated with UNIT=OUT) has size=0.

This is so simple that I am afraid to ask: Is this a MS Powerstation compiler bug?

...

!original code:

write(UNIT=OUT,FMT=280,ADVANCE= "NO") (memb_func(j),j=1,nent+nsai)

write(UNIT=OUT,FMT=282, ADVANCE= "NO") grau

write(UNIT=OUT,FMT=281) (perts(j),j=1,nent+nsai)

!rocoded code

!write(UNIT=arg1,FMT=280) (memb_func(j),j=1,nent+nsai)

!write(UNIT=arg2,FMT=282) grau

!write(UNIT=arg3,FMT=281) (perts(j),j=1,nent+nsai)

!write(UNIT=OUT,FMT='(A)') TRIM(arg1)//" "//TRIM(arg2)//" "//TRIM(arg3)

end do

280 FORMAT (50(I3))

281 FORMAT (50(F6.2))

282 FORMAT (F9.5)

[Steven_L_Intel1]

Powerstation has a reputation as having many bugs, and it has not been developed for 13 years. Why don't you want to retire it?

[Flavio_Almeida]

Steve, thank you for your response.

In fact I didnt know this reputation and I was not using MS Powerstation.

Anyway I found on google that there exists a service pack (that I do not have).

Several years ago a scientist that was developing a sophisticated linear programming interior point method with several f77 modules could not believe that my MS Powerstation code (Release version) was faster than his Watcom Code.

Probably it is a good f77 compiler.Perhaps the problem is with F90 specific constructions.

This episode caused a good impression on me about a Microsoft product.

Other reason: it is lighter than Intel Fortran and generate a more compact code.

Even using the small code (/O option) Intel generated a .exe with 561152K.(release). Powerstation generates 171520k.

As I like small and fast codes... I would not like to retire it.

But after your observation, I am thinking about retiring it.

Flavio

[Steven_L_Intel1]

That extra code size is run-time library code that does a lot more than what PowerStation could do. Your own executable code is likely to be no larger. To test this, build with the /MD option (in Intel Visual Fortran with Visual Studio, this is Runtime Library> Multithreaded DLL. The Intel code will almost certainly be faster.

[Flavio_Almeida]

32k (with this option)

[Flavio_Almeida]

After your test I am getting the message: Error 1 fatal error LNK2023: bad DLL or entry point 'msobj80.dll' LINK

even after returning the Project Configuration to what I think was the default. Do you know what I forgot?

[Flavio_Almeida]

I have just solved the problem: Reboot. Windows probably reloaded the dll.

[Flavio_Almeida]

Just to be clear: I have not solved the MS Powerstation bug (the subject of this post). I only solved a temporary compilation problem with Visual Studio - Intel Fortran.

Interestingly, another post dealing with file input problems, this time with Intel Fortran appeared today with the title "Strange Errors with stream I/O".

I hope someday Software vendors do what Knuth did: (Source Wikipedia)

Knuth has kept a very detailed log of all the bugs he has corrected and changes he has made in the program since 1982; as of 2008, the list contains 427 entries, not including the version modification that should be done after his death as the final change in TeX.^[24][25] Donald Knuth offersmonetary awards to people who find and report abug in TeX. The award per bug started at $2.56 (one "hexadecimal dollar"^[26]) and doubled every year until it was frozen at its current value of $327.68. Knuth, however, has lost relatively little money as there have been very few bugs claimed. In addition, recipients have been known to frame their check as proof that they found a bug in TeX rather than cashing it.^[

[Steven_L_Intel1]

I believe that Knuth had to discontinue the practice of paying for TeX bugs.

Are you still having a problem with Intel Visual Fortran? If so, please (re)explain.

[Flavio_Almeida]

Here I was talking about MS Powerstation.

[Flavio_Almeida]

Hi Steve

ah, concerning the other post" strange errors on io stream", can we conclude that text file reading problem is a bug of intel fortran?

[Steven_L_Intel1]

It may have been, and it was fixed a long time ago. The oldest 11.0 release I have on my system is 11.0.074 and it runs correctly with that.

[Flavio_Almeida]

Steve

After this suggestion to find the size of my program (without the library) , I was not able to reset the compiler on the normal condition.

I thought I had solved the problem because after a reboot the compiler stopped complaining about missing dll.

(so that I posted I had solved the problem).

I am not so familiarized with this IDE andI forgot to test the "Start Debugging" (F5) to execute the program.

Now the compiler is complaining about a missing libifcoremd.dll and suggesting a reinstallation.

Will I need to reinstall the compiler?

Flavio

[Steven_L_Intel1]

Flavio,

Are you getting this error when you try to use "Start Debugging" from within Visual Studio? The compiler install should have added the path to the compiler's LIB folder to the PATH environment variable. It is possible that you disabled this during a custom install. Look for PATH to have something like this:

%IFORT_COMPILER11%lib\ia32

if it doesn't, add this.

You can also go back to the Fortran > Libraries property page and change "Runtime Library" to "Multithreaded".

[Flavio_Almeida]

Yes, the error is with Start Debugging from Visual Studio.

But my path does not contain this folder (only systems variables that are related to intel fortran)

[Steven_L_Intel1]

PATH should contain that - or the explicit path with 11.0\xxx\Fortran, etc. If it is not there, add it.