Re: problem with variables

okale1 · ‎01-01-2009

Ihave study on acode related to myMs. Thesis. In the program,there are lots ofsubroutines. I studided with Fortran Developer Studio 97 in the past. Now, I start with Visual Fortran 11.066 version. I have faced with some problems after using 11.066 compiler. A small part of my code is below:

__________________________________________________________

...

subroutine nwmrk ()

...

call hystr2 (ll,ss,dd,ds,ff,fs,md)

go to 100

!
return
end

...

subroutine hystr2 (ll,ss,dd,ds,ff,fs,md)

implicit real*8 (a-h)
implicit integer (i-n)
implicit real*8 (o-z)

common /stff/dc,dy,fc,fy,sc,sy,su,b0,b1

go to (1,2,3,4),ll
! initial elastic stage.
1 if (dy-abs(dd)) 110,110,100
100 ff=sy*dd
go to 1000
110 dmx=dy
if (dd) 300,200,200
! post-yielding stage in positive direction.
2 if (dd-ds) 220,220,210
200 ll=2
ss=su
210 ff= fy+(dd-dy)*su
go to 1000
220 if (dmx.lt.abs(ds)) dmx=abs(ds)
es=sy*(dy/dmx)**b0
du=ds (problem here!)
dl=(fs+fy-dy*su-du*es)/(su-es)
fl=-fy+(dl+dy)*su
if (dd-dl) 300,300,400
! post-yielding stage in negative direction.
3 if (dd-ds) 310,320,320
300 ll=3
ss=su
310 ff=-fy+(dd+dy)*su
go to 1000
320 if (dmx.lt.abs(ds)) dmx=abs(ds)
es=sy*(dy/dmx)**b0
dl=ds (problem here!)
fl=-fy+(dl+dy)*su
du=(fy-fl+dl*es-dy*su)/(es-su)
if (dd-du) 400,200,200
! post-yielding elastic stage.
4 if (dd-du) 420,200,200
400 ll=4
ss=es
410 ff=fl+(dd-dl)*es
go to 1000
420 if (dd-dl) 300,300,410
!
1000 return
end

________________________________________________________

I compile the program in theFortran 11.066, thevariables du and ds(which are written bold in the upper code)take the value ofapproximately zero at the out of the subroutine. Hovewer, these values did not take the zero value when compiling the older Fortran versions. du and ds take the same value in the subroutine and out of the subroutine.

There is another problem is that sometimes program gives the error of "A non-optional actual argument must be present when invoking a procedure with an explicit interface". I readsome explanation on the link http://software.intel.com/en-us/forums/showthread.php?t=39831 but I could not understand USE DFLIB comment.

I will be gladof your answers.

gib · ‎01-01-2009

Quoting - ozkankale81

Ihave study on acode related to myMs. Thesis. In the program,there are lots ofsubroutines. I studided with Fortran Developer Studio 97 in the past. Now, I start with Visual Fortran 11.066 version. I have faced with some problems after using 11.066 compiler. A small part of my code is below:

__________________________________________________________

...

subroutine nwmrk ()

...

call hystr2 (ll,ss,dd,ds,ff,fs,md)

go to 100

!
return
end

...

subroutine hystr2 (ll,ss,dd,ds,ff,fs,md)

implicit real*8 (a-h)
implicit integer (i-n)
implicit real*8 (o-z)

...

You must make sure that the same variable declarations, that is in your case the implicit statements, are used in nwmrk() as in hystr2(). The subroutine arguments in the calling and called subroutines must be of the same type, and the same applies to the way the common variables are declared in both places.

I prefer to use 'implicit none' in every subroutine/function, then explicitly declare each variable used. This makes it much less likely to get a type mismatch.

You probably don't want to make major modifications to your code, but once you try using modules you will never want to see a common block again.

Gib

TimP · ‎01-01-2009

Quoting - gib

You probably don't want to make major modifications to your code, but once you try using modules you will never want to see a common block again.

OP doesn't want anything as recent as f66 (with the exception of f77 comments and implicit), and you're recommending modules? Where did he use COMMON?

TimP · ‎01-01-2009

I've never seen anyone go to such lengths with spaghetti code. Would you care to show us your expectation, in saner code, of how you expect this to be interpreted?

Upon removal of the comments which look somewhat like C code, one of the more popular compilers says this:

In function hystr2:
nmwrk.f90:26: warning: dmx may be used uninitialized in this function
nmwrk.f90:29: warning: du may be used uninitialized in this function
nmwrk.f90:42: warning: fl may be used uninitialized in this function
nmwrk.f90:42: warning: dl may be used uninitialized in this function
nmwrk.f90:27: warning: es may be used uninitialized in this function

In fact, it's clear that certain of these are never initialized before use, and others aren't initialized for certain values of ll (although, if that is what you mean, you could declare them as SAVE variables, depending on the values of ll which do initialize them being executed first).

It's hard to believe that you have followed one of the important principles, which would be to write code that you yourself can understand. For a thesis, the standard is higher; any competent reader should be able to understand what you are doing. Intentional obfuscation to the point that you don't know what you are doing is totally unacceptable. If, as it appears, you are returning ll values to be used on the next call to the subroutine, this is so inscrutable as likely to be outside the experience of any reviewer.

If you are depending on some non-standard initialization of these variables, you should not be surprised to encounter difficulties with the use of their values.

Here is a literal translation, using a little more f77, of what you have posted:

[cpp]      subroutine hystr2(ll,ss,dd,ds,ff,fs,md)
      implicitreal *8(a-h)
      implicitinteger (i-n)
      implicitreal *8(o-z)
      common/stff/dc,dy,fc,fy,sc,sy,su,b0,b1
      goto(10,20,30,50),ll
C initial elastic stage.
10      if(dy >  abs(dd))then
            ff= sy*dd
            return
          else
              dmx= dy
              if(dd >= 0)then
                goto90
                endif
              goto70
          endif
20      if(dd >  ds)then
          goto100
          endif
      if(dmx <  abs(ds))then
        dmx= abs(ds)
        endif
      es= sy*(dy/dmx)**b0
C/du=ds (problem here
C)/*
      dl= (fs+fy-dy*su-du*es)/(su-es)
      fl= -fy+(dl+dy)*su
      if(dd <= dl)then
        goto70
        endif
      goto40
C post-yielding stage in negative direction.
30      if(dd <  ds)then
          goto80
          endif
      if(dmx <  abs(ds))then
        dmx= abs(ds)
        endif
      es= sy*(dy/dmx)**b0
C/dl=ds (problem here
C)
C*fl=-fy+(dl+dy)*su
      du= (fy-fl+dl*es-dy*su)/(es-su)
      if(dd >= du)then
        goto90
        endif
40      ll= 4
      ss= es
         goto60
C post-yielding elastic stage.
50      if(dd >= du)then
          goto90
          endif
      if(dd <= dl)then
        goto70
        endif
60      ff= fl+(dd-dl)*es
      return
70      ll= 3
      ss= su
80      ff= -fy+(dd+dy)*su
      return
90      ll= 2
      ss= su
100     ff= fy+(dd-dy)*su
      return
      end
[/cpp]

gib · ‎01-01-2009

Quoting - tim18

OP doesn't want anything as recent as f66 (with the exception of f77 comments and implicit), and you're recommending modules? Where did he use COMMON?

common /stff/dc,dy,fc,fy,sc,sy,su,b0,b1

I could have said a lot more about his code, but decided that it would take too long, and he probably didn't want to hear it. In any case, if code like that he showed was to be upgraded, I'd recommend skipping F77 and going straight to F90. Opinions might differ.

TimP · ‎01-01-2009

Quoting - ozkankale81

"A non-optional actual argument must be present when invoking a procedure with an explicit interface". I could not understand USE DFLIB comment.

Apparently, you used a function which has an interface in DFLIB, so the compiler checks whether the arguments you used agree with the interface. As it says, you can't omit arguments unless they are explicitly shown as optional.

okale1 · ‎01-02-2009

Thank you all,

firstly, I would like torespond some of your recommendations. "common variables" and "implicit statements" are placed on the related subroutines and main code. I think the problem is not associated with this fact. Another one is that if sub hystr2() is written in the different format (like tim18's answer (Thank you for your suggestion) ), writing other sub hystrxx()will bevery very difficult. The format I use is the most appropriate way of writing related to my works.

I want to explainmy problem in a different way. When I compile the program without adding write(139,*)dd,ff line, program gives exact result in the subroutine. If I add the write(139,*)dd,ff line, program gives corrupted values. For example dl value could be odd (dl=1.697657925370483E-313). I try to understand what can beappliedto the code to cope with the problem.

!---------------------------------------------------------

subroutine newmrk(md,dt)

implicit real*8 (a-h)
implicit integer (i-n)
implicit real*8 (o-z)
common /rspn/d2,d6,ds,vl,ac,gr,wt,bm,bk,fs,lv
common /rspn2/ sd,g,err,adn,avn,aan
common /stff/dc,dy,fc,fy,sc,sy,su,b0,b1
common /rsps/sdd,dss
common /irsps/lvv
common /stfs/du,fu
...
go to (11,12,13,14,15,16,17,18,19,20), md
11 call hystr1 (ll,ss,dd,ds,ff,fs,md)
go to 100
12 call hystr2 (ll,ss,dd,ds,ff,fs,md)
write(139,*)dd,ff
go to 100
13 call hystr3 (ll,ss,dd,ds,ff,fs,md)
go to 100
14 call hystr4 (ll,ss,dd,ds,ff,fs,md)
...
return
end

!---------------------------------------------------------

Thank you for your suggestions.

Ozkan

TimP · ‎01-02-2009

Quoting - ozkankale81

If I add the write(139,*)dd,ff line, program gives corrupted values. For example dl value could be odd (dl=1.697657925370483E-313).

This is a typical consequence of uninitialized variables. If you meant to initialize dl to a specific value, it is extremely important to write that in your code, the more so as you may be called upon to defend your thesis.

When you have syntax which a compiler is able to tell you is wrong, you have to expect the unexpected.

If your thesis is on the possibilities for writing bad code by misuse of archaic syntax, it is still important to understand the implications of what you write. I couldn't begin to follow your errors without the automatic translation; my point is not to suggest this as the best way, but to suggest that you must make it feasible for yourself and others to understand.

okale1 · ‎01-02-2009

Hi all,

I have fix the problem by using the "write()" statements out of the subroutines. I used the "write()" commands in main part of the code. If I use any "write()" commands in the subroutines, the program gives irrelevant results. Is there anybody whoknows why the "write()" statements make problem out of the main code?

Thanks,

Ozkan.

gib · ‎01-02-2009

Quoting - ozkankale81

Hi all,

I have fix the problem by using the "write()" statements out of the subroutines. I used the "write()" commands in main part of the code. If I use any "write()" commands in the subroutines, the program gives irrelevant results. Is there anybody whoknows why the "write()" statements make problem out of the main code?

Thanks,

Ozkan.

Errors that are affected by adding or removing write statements are often the result of some sort of memory corruption. Have you tried compiling with runtime error checking turned on?

Project > Properties > Fortran > Run-time > Runtime Error Checking (select All)

okale1 · ‎01-03-2009

Quoting - gib

Errors that are affected by adding or removing write statements are often the result of some sort of memory corruption. Have you tried compiling with runtime error checking turned on?

Project > Properties > Fortran > Run-time > Runtime Error Checking (select All)

I have compiled the program as you said and then the program gives an error while debugging. I have search the problem in this way.

Thank you.