Compiler Error
in [Fortran]
|
From: Steve Lionel on 11 Jun 2010 09:50 On 6/11/2010 1:43 AM, rfengineer55 wrote: > No, the error is not happening with print statements. Here is the line > in te code where the Intel compiler zeros in on - > > WRITE ( UNFDAT,IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > IREC is the variavle that the compiler says is not assigned to a > label. I agree with those who suggest that this was originally UNFDAT'IREC. Change it to: WRITE (UNFDAT, REC=IREC) and it will probably be happier. In the syntax you have, with the comma, IREC needs to be a label for a FORMAT statement. In older dialects of Fortran, one could ASSIGN a label to an integer variable and then use the variable in place of a label. That is no longer in the current standard but is still supported by Intel Fortran. This is why the compiler complains, because it sees IREC used in a context that requires a label but notices that IREC has not been named in an ASSIGN statement. That the variable containing the unit number is named UNFDAT supports this theory, since it is probably opened for unformatted access where a format label would be invalid. -- 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
From: rfengineer55 on 11 Jun 2010 10:43 On Jun 11, 8:23 am, dpb <n...(a)non.net> wrote: > e p chandler wrote: > > "rfengineer55" <rfenginee...(a)aol.com> wrote in message > >news:251de982-07fc-4df0-8a32-2c7b8ff5f1d3(a)q12g2000yqj.googlegroups.com.... > > On Jun 10, 11:47 pm, "e p chandler" <e...(a)juno.com> wrote: > >> "rfengineer55" <rfenginee...(a)aol.com> wrote in message > >>news:f73f40db-1dde-4d45-8673-e807071e68cd(a)q12g2000yqj.googlegroups.com.... > > ... > > ... > > > No, the error is not happening with print statements. Here is the line > > in te code where the Intel compiler zeros in on - > > > WRITE ( UNFDAT,IREC ) FREQ, SIG(II), > > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > > IREC is the variavle that the compiler says is not assigned to a > > label. > > > ----> OK. Look at the WRITE statement IREC is a format specifier. The > > format specifier can be a number of things. > > Yes, most specifically, a label to a FORMAT string. > > ... > > > Look at this console window session (Win32): > > ... > > C:\Users\epc\temp>type foo.f90 > > i=998 > > write(*,i) 'hello' > > assign 999 to i > > write(*,i) 'world' > > 998 format(1x,a,' 998') > > 999 format(1x,a,' 999') > > end > > ... > > Or more to the point, the following programette generates the error in > CVF... > > program nolabel > integer:: irec > real:: anyvar > > irec = 1 > anyvar = 3.14 > > open(11, file='anyfilename') > write(11,i) anyvar > end > > As noted elsewhere, the program used ISAM which is built into VAX OS and > FORTRANM knew how to handle it. AFAIK, CVF and Intel Fortran > extensions don't include ISAM files as part of the VAX/DEC-compatible > extensions. > > You've got (again as somebody else already noted) convert from an ISAM > file to another format such as sequential but to do so you'll have to > figure out how to read the right data at the right time into the right > variables. > > I'll reiterate my previous (and that of at least one other poster) > advice to chill, slow down and think this through in a logical and > ordered manner instead of just flailing around and throwing a tantrum > when it doesn't "just work". Consider the task for what it really > instead of what you wish it were; you've tackled moving an old > OS-specific piece of code using a compiler that took advantage of the > unique features of the machine and OS, some of which features were > utilized by the authors of the code you're attempting to use. To move > that to another OS which doesn't support some of those specific features > (ISAM in this case, specifically) and a compiler which, while it has > some syntax extensions to Standard Fortran that were also present in the > DEC/VAX compiler, doesn't completely emulate that former compiler on a > system that doesn't have all the facilities by which to do so will > require working around that lack. > > Doing that successfully won't happen just by throwing the code at the > compiler and futzing around w/ a few options switches; it'll require > actually understanding what the file structure of the input file is and > modifying the code to handle it. > > -- My past challenges are old stale news and I'm ready to move on and I suggest you do the same. If you don't want to contribute meaningful programming suggetions as many others have here, and do so without editorializing, don't contribute to my thread at all then. This is nothing personal. This is about solving a programming problem, so let's keep it that way. Everything you've said about flailing, tantrums how I think it should be, etc., is all your interpretation, and you are responsible for that. That's how you choose to see the situation, and I'm not at all interested in hearing about it. So airing your interpretation is going to do nothing but waste bandwidth. Jeff RF ENGINEER55
From: rfengineer55 on 11 Jun 2010 10:45 On Jun 11, 8:50 am, Steve Lionel <steve.lio...(a)intel.invalid> wrote: > On 6/11/2010 1:43 AM, rfengineer55 wrote: > > > No, the error is not happening with print statements. Here is the line > > in te code where the Intel compiler zeros in on - > > > WRITE ( UNFDAT,IREC ) FREQ, SIG(II), > > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > > IREC is the variavle that the compiler says is not assigned to a > > label. > > I agree with those who suggest that this was originally UNFDAT'IREC. > Change it to: > WRITE (UNFDAT, REC=IREC) > > and it will probably be happier. In the syntax you have, with the > comma, IREC needs to be a label for a FORMAT statement. In older > dialects of Fortran, one could ASSIGN a label to an integer variable and > then use the variable in place of a label. That is no longer in the > current standard but is still supported by Intel Fortran. This is why > the compiler complains, because it sees IREC used in a context that > requires a label but notices that IREC has not been named in an ASSIGN > statement. > > That the variable containing the unit number is named UNFDAT supports > this theory, since it is probably opened for unformatted access where a > format label would be invalid. > > -- > 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 Steve, Thank you very much for that suggestion. I'll give that a whirl and see whhat happens. I appreciate your taking the time to respond. Jeff RF ENGINEER55
From: Luka Djigas on 11 Jun 2010 11:14 On Fri, 11 Jun 2010 06:38:08 -0700 (PDT), rfengineer55 <rfengineer55(a)aol.com> wrote: >IT department here is quite specialied, and they do very little >programming. The Comp Sci departmentis pretty good, but they have a >very full plate given the state funding situation. I've writen an >instructor a few times with things that Ijust don't know how to solve, >and he's learned that if he gives me a few days, I figure it out for >myself :-) There is both a good and bad side to be highly motivated :- >D > >The IT department did suggest that I need to find a good newsgroup on >the net, so here I am :-) > >Jeff I find it rather suprising that they did not suggest a good newsreader to go along, for I would've expected that of any serious IT department staff member who knows what Google groups are like, and yet has been in the job long enough to familiarize itself with Usenet culture and its ways (from the time before Google groups). -- Luka
From: Alois Steindl on 11 Jun 2010 12:04
rfengineer55 <rfengineer55(a)aol.com> writes: > > If you don't want to contribute meaningful programming suggetions as > many others have here, and do so without editorializing, don't > contribute to my thread at all then. This is nothing personal. This is > about solving a programming problem, so let's keep it that way. > > Everything you've said about flailing, tantrums how I think it should > be, etc., is all your interpretation, and you are responsible for > that. That's how you choose to see the situation, and I'm not at all > interested in hearing about it. So airing your interpretation is going > to do nothing but waste bandwidth. > > > > Jeff > RF ENGINEER55 Hello, besides learning to use your programming environment, the syntax of Fortran and the handling of your newsreader, you will also have to learn about usenet: Everybody may contribute to any thread he wants to, you have no right or possibility to restrict that. As you already may have noted, there are many helpful experts in this group, dpd being one of them. His posting contained no offense against you, but had remarks about a broader view of the underlying dilemma: How to use and modify old code, which is floating around. You might not yet understand what he was speaking about, but just calling his contribution waste of bandwidth is a strong offense. Is this your normal way of behaving: If you encounter any problem, shout at all those people you think are responsible for it? Alois |