I wrote the following two lines in fortran
C23456789
REAL H3 = 0
H3=H*H*H
and I received the following errors from gdb :
ljmd.f:186.5:
REAL H3 = 0
1
Error: Non-numeric character in statement label at (1)
ljmd.f:187.5:
H3=H*H*H
1
Error: Non-numeric character in statement label at (1)
ljmd.f:187.6:
H3=H*H*H
1
What is the proper way to create and use new variables in the middle of someone else's fortran program? C23456789 is my label of the current column used in the program.
This is in any random Fortran tutorial. I expect you have the fixed source form. Then any statement must start at column 7 or farther.
Also,
REAL H3 = 0
isn't legal in free form source Fortran and does a completely different thing in fixed form (see #francesalus' comment). And in your case there is no reason to initialize the variable at all. You can just do
REAL H3
H3 = H**3
If you happen to need the initialization somewhere else, you either must use
real :: a = 0
(requires Fotran 90), or
REAL A
DATA A/0/
(in Fortran77). Beware, both version make the variable SAVE which you may know as static from other languages.
The last point, you cannot introduce variables anywhere "in the middle of program", the declaration of variables have their place at the beginning of each compilation unit (program, function, subroutine,...).
Related
I found this one old fortran 77 program printed in one old book, and i typed in the program but it isnt running. When I give the dimensions of variables, appear the next:
DIMENSION XN(20),YN(20),W(20),NUMAJ(20),NUMAAJ(20),SSW(20)
1,NEJI(5,20),QX(20,20),QY(20,20),IACTE(20),N1(20),N2(20),X(20)
2,Y(20),DD(20),TT(20),NUMAJA(20)
And the error code:
Error: Non-numeric character in statement label at (1)
Error: Unclassifiable statement at (1)
Thanks a lot,
Comparing the original and edited version shows still incorrect indenting: fixed format reserves columns 1-5 for labels, 6 for the continuation character and starting from 7 for the statements. If column 6 is not a space the line continues the previous line.
In the 3 line example above the characters "1" and "2" are the continuation characters of line 2 and 3, so they have to be exactly in column 6. The first line has no label or continuation character so it must start in column 7. The comment from #melpomene was incomplete regarding continuation character and based on the old version where one space less was used (the edited version has one space too much).
As shown in the following code that I use to practice fixed-form Fortran (because the code I am trying to learn is fixed form Fortran), the 4th format statement and the reading from file 1 are newly added. The code worked as expected prior to adding these statements, but now the intel ifort compiler with no additional flags will not compile the 4th format statement and returns the following error:
fortPractice.for(18): error #5082: Syntax error, found FORMAT_ELEMENT 'format' when expecting one of: <END-OF-STATEMENT> ;
4 format(i6,2x)
--------------^
fortPractice.for(26): error #6052: This label has not been defined as a FORMAT label.
write(2,3)
----------------------------------^
The code is:
c This is a script for practicing Fortran codes
program fortPractice
implicit none
integer :: x(0:5),y(2:7)
integer :: nph(1:6)
real :: z(4:9)
integer :: i
OPEN(unit=1,file='test.txt',status='old')
read(1,*) nph
close(unit=1)
open(unit = 2, file = 'output.txt')
2 format(i3,2x,i3,2x,2e11.2)
3 format(1x,78('*'))
4 format(i6,2x)
do i = 0,5
x(i) = i;
y(i+2) = i+2;
z(i+4) = x(i)**2 + y(i+2)**2
z(i+4) = sqrt(z(i+4)) + 10000
write(2,2) x(i),y(i+2),z(i+4)
write(2,3)
enddo
write(2,*) nph
close(unit = 2)
endprogram fortPractice
Output is a file created by the program. test.txt contains just a row of numbers: 1 2 3 4 5 6
When I comment or remove the 4th format statement then the code compiles and runs as expected. As I am just learning how fixed form Fortran works, I am just interested in why the 4th format statement won't compile.
Edit:
I have replaced all the tabs with spaces, and the program with some more modification shown below can now compile, but the program does not produce the output file, likely encountered some run-time error:
Edit 2:
Nevermind, I forgot to change the file identifiers.
Thanks everyone!
Now we have enough information to solve the problem. In the troublesome source line, the label 4 is preceded by a tab. Tabs in Fortran source are not standard, but Intel Fortran (and many other compilers) support something called "tab source form". The way it works in ifort is as follows:
If the line starts with a tab and then a nonzero digit, the digit is treated as if it were in column 6
If the line starts with a tab and then some other character, then the character is treated as if it were in column 7
If the line starts with a numeric statement label and then a tab, the next character is treated as if it were in column 7
Otherwise, a tab is treated as a blank (this last varies among compilers)
In your case, a tab preceded the 4 so it was taken to be a continuation of the previous line, resulting in an error. Either don't use tabs, or understand how the compiler treats them. Editors that automatically insert tabs will just give you trouble.
300 do i=1,counter
open(1,file='Pcow_pd.txt')
write(1,*),Sw_pd(i), Pcow_pd(i)
open(2,file='Krw_pd.txt')
write(2,*),Sw_pd(i), Krw_pd(i)
open(3,file='Kro_pd.txt')
write(3,*),Sw_pd(i), Kro_pd(i)
print*, counter
end do
print *,"filled =",filled
When I compile the code I get an error message at write lines which I cannot fix
Compile error: error 573 - Missing expression
As has been commented, there should be no comma before the list of items for output. You should simply have
write(1,*) Sw_pd(i), Pcow_pd(i)
and so on.
The later line
print*, counter
where the comma before counter is absolutely necessary, may add a little confusion on writing. This is perhaps increased by how read is used: there are two forms:
read *, x
read (*,*) y
The first example without an explicit statement of unit implies the same unit as the * in the second and it requires a comma. The second must not have a comma.
A simple way to remember whether the output list has a comma first: if the format comes in isolation use the comma; if the unit is specified, don't.
i'm totally new to Fortran, and i want to write a test program using a real*8 function called NeQuick, so i've written the following program :
program test
implicit real*8 (a-h,o-z)
aNe=NeQuick(400.0D0,45.0D0,15.0D0,10,1.929D2,15.0D0)
write(6,'(A,E12.5,A)')
& ' NeQuick electron density =',aNE,' m^-3'
call sleep(10)
end program
At the end when i compile it I have the following errors in each line of the little program : -Non-numeric character in statement label at 1 or
-Unclassifiable statement at 1
Can you guys please explain me what's wrong with my program ?
The way this code is written tells me that it was intended to be fixed-form source. This requires that all of the code start in column 7, except for the & in the second line of the WRITE statement which should be in column 6. Often when such code is pasted into an editor, the leading blanks are removed. If you do this, though, you will have to rename the source file to have a .f or .for file type so that the compiler knows it is fixed-form.
Another, perhaps easier solution is to put an & at the end of the first line of the WRITE - this will then make the source as you have it valid free-form.
For some perspective on this, please read Source Form Just Wants to be Free.
I came across a little puzzle with Stata's locals, display, and quotes..
Consider this example:
generate var1 = 54321 in 1
local test: di %10.0gc var1[1]
Why is the call:
di "`test'"
returning
54,321
Whereas the call:
di `test'
shows
54 321
What is causing such behaviour?
Complete the sequence with
(1)
. di 54,321
54 321
(2)
. di "54,231"
54,321
display interprets (1) as an instruction to display two arguments, one by one. You get the same result with your last line as (first) the local macro test was evaluated and (second) display saw the result of the evaluation.
The difference when quotation marks are supplied is that thereby you insist that the argument is a literal string. You get the same result with your first display command for the same reasons as just given.
In short, the use of local macros here is quite incidental to the differences in results. display never sees the local macro as such; it just sees its contents after evaluation. So, what you are seeing pivots entirely on nuances in what is presented to display.
Note further that while you can use a display format in defining the contents of a local macro, that ends that story. A local does not have an attached format that sticks with it. It's just a string (which naturally may mean a string with numeric characters).