Prev: call c lib from fortran in ms visual studio 2005
Next: What exactly does the SAVE statement do ?
From: eric948470 on 23 May 2010 01:51
Hi,

Below is a program I wrote. In addition to storing the values of the
arrays 'f' and 'tau' in files named 'f_vs_tauxxxxxx.txt', (where
xxxxxx is the number of times the conditional loop labeled 4 has been
iterated), it is also supposed to display the following data on screen
for each iteration. (x's denote numbers)

iteration x
adfmax= x.xxxxxxxxExxx
Data written to f_vs_tauxxxxxx.txt

But the above are displayed on screen for only 6 iterations. Then the
output to the screen stops. But the calculation seems to go on until
'f' converges to the required tolerance (I know because there are a
total of 206 txt files written, not 6). It does what I want it to do.
But I don't what's happening to the screen output. Can anybody help?

And btw, there's also an unwanted file named 'fort.6' that is made by
the program.

Thanks.

PS: I checked the contents of 'fort.6' just now, and the rest of the
output I wanted to be written to screen has been written to that file.

Program follows.

PROGRAM hmwrk6

INTEGER i,j,NSTEPS,n
PARAMETER (NSTEPS=10000)
DOUBLE PRECISION tau(NSTEPS+1),mu(10),f(NSTEPS+1),b(NSTEPS
+1),a(NS
$TEPS+1,10),c(NSTEPS+1,10),d(NSTEPS+1,10),beta(2:NSTEPS
+2,10),e(NST
$EPS+1,10),alpha(2:NSTEPS+2,10),u(NSTEPS+1,10),uprime(NSTEPS
+1,10),
$delta,w(10),fold(NSTEPS+1),adf(NSTEPS+1),adfmax
CHARACTER fname*64

delta=10.0D0/NSTEPS
do 1 i=1,(NSTEPS+1)
tau(i)=(dble(i-1)*10.0D0)/dble(NSTEPS)
f(i)=1.0D0
b(i)=0.75D0*f(i)*(tau(i)+(2.0D0/3.0D0))
1 continue

mu(1)=-0.97390653D0
mu(2)=-0.86506337D0
mu(3)=-0.67940957D0
mu(4)=-0.43339539D0
mu(5)=-0.14887434D0
mu(6)=-mu(5)
mu(7)=-mu(4)
mu(8)=-mu(3)
mu(9)=-mu(2)
mu(10)=-mu(1)

w(1)=0.06667134D0
w(2)=0.14945135D0
w(3)=0.21908636D0
w(4)=0.26926672D0
w(5)=0.29552422D0
w(6)=w(5)
w(7)=w(4)
w(8)=w(3)
w(9)=w(2)
w(10)=w(1)

do 2 j=1,10
a(1,j)=0.0D0
d(1,j)=1.0D0+(mu(j)/delta)+(delta/(2.0D0*mu(j)))
c(1,j)=mu(j)/delta
beta(2,j)=c(1,j)/d(1,j)
do 3 i=2,NSTEPS
a(i,j)=((mu(j)**2.0D0)/(delta**2.0D0))
d(i,j)=1.0D0+(2.0D0*((mu(j)**2.0D0)/(delta**2.0D0)))
c(i,j)=(mu(j)**2.0D0)/(delta**2.0D0)
beta(i+1,j)=c(i,j)/(d(i,j)-(beta(i,j)*a(i,j)))
3 continue
a(NSTEPS+1,j)=(mu(j)/delta)-0.5D0
d(NSTEPS+1,j)=0.5D0+(mu(j)/delta)
c(NSTEPS+1,j)=0.0D0
beta(NSTEPS+2,j)=c(NSTEPS+1,j)/(d(NSTEPS+1,j)-(beta(NSTEPS
+1,j)
$*a(NSTEPS+1,j)))
2 continue

adfmax=1.0D0
n=0
4 if(adfmax.ge.1.0D-6)then
n=n+1
write(*,*)'iteration',n
do 5 j=1,10
e(1,j)=(b(1)*delta)/(2.0D0*mu(j))
alpha(2,j)=e(1,j)/d(1,j)
do 6 i=2,NSTEPS
e(i,j)=b(i)
alpha(i+1,j)=(e(i,j)+(alpha(i,j)*a(i,j)))/(d(i,j)-
(beta(i
$,j)*a(i,j)))
6 continue
e(NSTEPS+1,j)=(b(NSTEPS+1)*(0.5D0+(mu(j)/delta)))+
(b(NSTEPS)
$*(0.5D0-(mu(j)/delta)))
alpha(NSTEPS+2,j)=(e(NSTEPS+1,j)+(alpha(NSTEPS
+1,j)*a(NSTEPS
$+1,j)))/(d(NSTEPS+1,j)-(beta(NSTEPS+1,j)*a(NSTEPS+1,j)))

u(NSTEPS+1,j)=alpha(NSTEPS+2,j)
do 7 i=NSTEPS,1,-1
u(i,j)=alpha(i+1,j)+(beta(i+1,j)*u(i+1,j))
7 continue

uprime(1,j)=((4.0D0*u(2,j))-(3.0D0*u(1,j))-u(3,j))/
(2.0D0*de
$lta)
do 8 i=2,NSTEPS
uprime(i,j)=(u(i+1,j)-u(i-1,j))/(2.0D0*delta)
8 continue
uprime(NSTEPS+1,j)=((3.0D0*u(NSTEPS+1,j))+u(NSTEPS-1,j)-
$(4.0D0*u(NSTEPS,j)))/(2.0D0*delta)
5 continue
do 9 i=1,(NSTEPS+1)
b(i)=0.0D0
fold(i)=f(i)
f(i)=0.0D0
9 continue
do 10 j=6,10
do 11 i=1,(NSTEPS+1)
b(i)=b(i)+(w(j)*u(i,j))
f(i)=f(i)+(4.0D0*w(j)*(mu(j)**2.0D0)*uprime(i,j))
11 continue
10 continue
adfmax=0.0D0
do 12 i=1,(NSTEPS+1)
adf(i)=dabs(f(i)-fold(i))
if(adf(i).gt.adfmax)adfmax=adf(i)
12 continue
write(*,*)'adfmax=',adfmax
write(fname,fmt='(A,I6.6,A)')'f_vs_tau',n,'.txt'
open(unit=n,file=fname)
do 13 i=1,(NSTEPS+1)
write(unit=n,fmt='(1X,E16.8E3,TR2,E16.8E3)')tau(i),f(i)
13 continue
close(n)
write(*,*)'Data written to ',fname

goto 4
endif

END
From: Richard Maine on 23 May 2010 02:14
eric948470 <eric948470(a)gmail.com> wrote:
....
> But the above are displayed on screen for only 6 iterations. Then the
> output to the screen stops. But the calculation seems to go on until
> 'f' converges to the required tolerance (I know because there are a
> total of 206 txt files written, not 6). It does what I want it to do.
> But I don't what's happening to the screen output. Can anybody help?
>
> And btw, there's also an unwanted file named 'fort.6' that is made by
> the program.
....
>
> PS: I checked the contents of 'fort.6' just now, and the rest of the
> output I wanted to be written to screen has been written to that file.

You should normally avoid unit numbers in the single digits. They are
often used for special purposes. In particular, unit 6 is very commonly
used for the screen output (aka unit *). By opening unit 6 with a file
name, you have messed with the screen output. The exact details of what
will result from opening and closing unit 6 are likely to vary from
compiler to compiler. What happened to your code sounds plausible. After
you closed unit 6, subsequent output to unit * reopened it with the
fort.6 file name (but no longer to the screen). But you don't really
care about those details. Just know to avoid such unit numbers.

You really don't need multiple unit numbers at all. Although you are
writing multiple files, you are doing so one at a time, opening one
file, writing to it, and then closing it before opening the next one.
After you have closed the file, it is perfectly fine and normal to reuse
the unit number for the next file. I would recommend you use just a
single unit number, independent of the iteration number..... and make
that unit number something with 2 digits.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: robert.corbett on 23 May 2010 02:15
On May 22, 10:51 pm, eric948470 <eric948...(a)gmail.com> wrote:
> Hi,
>
> Below is a program I wrote. In addition to storing the values of the
> arrays 'f' and 'tau' in files named 'f_vs_tauxxxxxx.txt', (where
> xxxxxx is the number of times the conditional loop labeled 4 has been
> iterated), it is also supposed to display the following data on screen
> for each iteration. (x's denote numbers)
>
> iteration x
> adfmax= x.xxxxxxxxExxx
> Data written to f_vs_tauxxxxxx.txt
>
> But the above are displayed on screen for only 6 iterations. Then the
> output to the screen stops. But the calculation seems to go on until
> 'f' converges to the required tolerance (I know because there are a
> total of 206 txt files written, not 6). It does what I want it to do.
> But I don't what's happening to the screen output. Can anybody help?
>
> And btw, there's also an unwanted file named 'fort.6' that is made by
> the program.

Most Fortran implementations preconnect standard output to unit 6.
When your program opens unit 6, it replaces the connection to unit 6
with
a connection to the file named by the FILE= specifier. After unit 6
is
closed, the following writes to unit *, which is equivalent to unit 6
in
the implementation you are using, write to the implicitly opened file
fort.6. You should find your missing output in that file.

The usual solution to this problem is to not use unit numbers less
than
10 for files you open yourself. In your program, there is no need to
use more than one unit number. Because the files you create are
opened,
written and closed before the next file is accessed, you could use the
unit number for all of the files.

Bob Corbett
From: eric948470 on 23 May 2010 10:09
On May 23, 2:14 am, nos...(a)see.signature (Richard Maine) wrote:
> You should normally avoid unit numbers in the single digits. They are
> often used for special purposes. In particular, unit 6 is very commonly
> used for the screen output (aka unit *). By opening unit 6 with a file
> name, you have messed with the screen output. The exact details of what
> will result from opening and closing unit 6 are likely to vary from
> compiler to compiler. What happened to your code sounds plausible. After
> you closed unit 6, subsequent output to unit * reopened it with the
> fort.6 file name (but no longer to the screen). But you don't really
> care about those details. Just know to avoid such unit numbers.
>
> You really don't need multiple unit numbers at all. Although you are
> writing multiple files, you are doing so one at a time, opening one
> file, writing to it, and then closing it before opening the next one.
> After you have closed the file, it is perfectly fine and normal to reuse
> the unit number for the next file. I would recommend you use just a
> single unit number, independent of the iteration number..... and make
> that unit number something with 2 digits.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

I did what you suggested and the program works perfectly now. Thanks!
From: e p chandler on 23 May 2010 17:28
"eric948470" wrote:
> (Richard Maine) wrote:
> You should normally avoid unit numbers in the single digits.
> They are often used for special purposes.

On additional suggestion. Your original program contained

a(i,j)=((mu(j)**2.0D0)/(delta**2.0D0))
d(i,j)=1.0D0+(2.0D0*((mu(j)**2.0D0)/(delta**2.0D0)))
c(i,j)=(mu(j)**2.0D0)/(delta**2.0D0)

While one change probably will not save you much run time, it's far better
when raising a real number to an integer power to use an integer as an
exponent.

so you would have **2 instead of **2.0D0.

There are a number of other suggestions I would make in terms of style, etc.
but I'll save those in case the OP returns.

--- e



 |  Next  |  Last
Pages: 1 2 3
Prev: call c lib from fortran in ms visual studio 2005
Next: What exactly does the SAVE statement do ?