Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

upgrading


Hello all,

I have sizeable numerical code that was originaly written to the f77
standard, It has been rewritten in parts to f90 standard. I have a
mild interest in bringing the code up to f95 standard.

I have a couple of  questions

Is this actually worth the bother ?

If one were to decide to rewrite to f95 standard are there any
programing tools freely available to aid in such a task ? (I use the
emacs editor)

All advice is welcome.

Zakl

On 11 apr, 12:33, "Zak" <b.zaryc@googlemail.com> wrote:

It depends:
- Unless your programs are really old, they should still be
  valid Fortran 90 or 95. So the easy way out is to leave
  them as they are.
- Most people (*) prefer free-form over fixed-form source.
  There are all manner of tools to assist with that
- Most people do not like hunting down all the jumps that
  seem to populate FORTRAN 77 programs, especially the
  ones intended for heavy-duty numerical work.
  Again: there are tools that assist in replacing the
  GOTOs and labels to more modern equivalents.
- You may want to use array assignments instead of
  simple loops - I find them clearer, at least in
  simple cases. That is a somewhat involved aspect of the
  language and I am not sure if there are really
  reliable tools available.

Places to visit for such tools:
http://www.fortran.com
http://www.dmoz.org/Computers/Programming/Languages/Fortran/Tools/

(among others, many of which can be found in various postings
in this newsgroup)

Regards,

Arjen

(*) I know one or two people who object to free-form source and
    occasionally there will be another battle fought in this
    newsgroup about the pros and cons. Suffice it to say that
    while I have no actual figures to corroborate the statement
    nor any intention to start yet another such battle, my
    distinct impression is that a fairly large majority
    prefers free-form.

On Apr 11, 6:33 am, "Zak" <b.zaryc@googlemail.com> wrote:

> Hello all,

> I have sizeable numerical code that was originaly written to the f77
> standard, It has been rewritten in parts to f90 standard. I have a
> mild interest in bringing the code up to f95 standard.

> I have a couple of  questions

> Is this actually worth the bother ?

That depends on the programmer and the code. The question of whether
to use Fortran 77 or later versions of Fortran has been discussed many
times here. Let me tackle the narrower question of whether to use
Fortran 90 or 95.

Most compilers that are actively developed and supported are Fortran
95 compilers, so a lack of compilers is not reason to avoid F95.

The FORALL construct of F95 can be convenient, but it certainly not
essential, and some messages here indicate that ir is rarely used in
production code.

I have not found the ability to declare functions and subroutines PURE
in F95 to be very helpful. It's like programming in a straitjacket,
since one cannot print error messages or terminate the program within
the procedure, if an error occurs.

I *do* find user-defined ELEMENTAL subroutines and especially
functions to be useful. To get the same effect in F90 -- the ability
of a single function to handle arguments of varying ranks -- one would
need to write an INTERFACE with MODULE PROCEDURES and write some
duplicative code within the MODULE PROCEDURES. ELEMENTAL functions are
also PURE, but they have advantages to offset their constraints.

There are some convenient enhancements to the edit descriptors in F95.

CPU_TIME is convenient.

By using strict F95 you will be forced to change DO loops with non-
integer loop variables, which is probably a good thing.

The expanded functionality of ALLOCATABLE arrays in an update to F95
(present in F2003 also) is useful.

To sum up, I'd say use F95 over F90 in new code, but if a code uses
the modern features of F90 and works, I don't think the upside to
adding F95 features is that great. An exception may be replacing
POINTERs with ALLOCATABLE arrays where allowed by extended F95.

> If one were to decide to rewrite to f95 standard are there any
> programing tools freely available to aid in such a task ? (I use the
> emacs editor)

I don't know if a tool is necessary. Just compile with more than one
F95 compiler (gfortran and g95 are free) in strict F95
mode -- for those compilers the option is std=f95.
On Apr 11, 9:26 am, "Arjen Markus" <arjen.mar@wldelft.nl> wrote:

> On 11 apr, 12:33, "Zak" <b.zaryc@googlemail.com> wrote:

<snip>

> - You may want to use array assignments instead of
>   simple loops - I find them clearer, at least in
>   simple cases. That is a somewhat involved aspect of the
>   language and I am not sure if there are really
>   reliable tools available.

There is VAST/77to90 http://www.crescentbaysoftware.com/vast_77to90.html
but since the full version costs $16000, I have not tried it.
Hi Zak,

Just one thing to be aware of:  the SIGN function changed between F90 and F95.  
It had a significant effect on my GFD codes, so keep that in mind if you do the
upgrade.  I wouldn't really recommend it unless there is a good reason to, F95
compilers should always be backwards compatible (ie, we can still compile F77
!)

Re SIGN:
http://developers.sun.com/sunstudio/articles/sign.html

F90_Man

In article <1176287620.711326.292@w1g2000hsg.googlegroups.com>,
b.zaryc@googlemail.com says...

On Apr 11, 6:33 am, "Zak" <b.zaryc@googlemail.com> wrote:

Let me share an example recently posted in an old thread where "thogy"
wrote:

-- begin quote --

I am a FORTRAN n00b and am trying to get a piece of code running.
The
complier I am using is g95.  I did not write the FORTRAN code and I
believe that it is FORTRAN 77 or something but not sure.

If someone has a second, would you mind running the code and seeing
if
you get similar errors?

code:
http://rjaengineering.googlepages.com/ex3_8b.f

screen shot of some of the errors I got:
http://rjaengineering.googlepages.com/erros.jpg

-- end quote --

Looking at the code, which was Fortran 77 plus extensions in fixed-
format, it was clear that the problem was mis-alignment of code.
statements were shifted left into the continuation column,
continuation markers where shifted right into the code area, one
comment was misplaced. One formula was in error. (Perhaps OCR errors?)
[forgive sentence fragments :-)]

It was easy to fix these problems and get the program to run as fixed
format code, but I wondered "How does this code work and what does it
do?" Converting to Fortran 95, including free-format, let me "clean
up" enough to help me understand some of what was going on.

In this case, the features of Fortran 95+ I liked were

1. Free format source made it easier to indent code showing its block
structure.
2. Flow control constructs such as DO (no statement label) .. ENDDO
for better control (versus a common CONTINUE statement ending several
loops, for example.)
3a. Array assignments got rid of some DO loops.
3b. An array assignment pre-initialized to the most common value.
Assigning the alternate value was left to a single IF ... THEN which
executed only a small part of the time.
4. Dimensioning a group of arrays with a common size and shape was
easy via e.g. real,dimension(...) :: name1,name2,name3
5. Replacing DATA statements with initialization expressions, e.g.
real,dimension(...) :: name1 = (/..../), etc. cleaned up the code and
converted some constants assigned values into parameters.
6. Replacing some IF ... THEN .. ELSE with var1=max(var1,var2) [This
may be F77.]
7. Nicer relational operators (> versus .gt.) cleaned up a bit.

So for me, the effort was worth it. This left me with code that I
(assuming I understood the problem domain, which I do not) could
maintain.

8. Some of the comments were overly long and not very informative.
Writing pithy comments pointed out use of a cyclic list to handle a
recurrence relation.

Of course there are many other desirable features of Fortran 95 versus
older standards. I wanted to highlight some which came up while re-
writing an old program in order to understand its workings.

-- elliot

Zak <b.zaryc@googlemail.com> wrote:
> I have sizeable numerical code that was originaly written to the f77
> standard, It has been rewritten in parts to f90 standard. I have a
> mild interest in bringing the code up to f95 standard.

> I have a couple of  questions

> Is this actually worth the bother ?

> If one were to decide to rewrite to f95 standard are there any
> programing tools freely available to aid in such a task ? (I use the
> emacs editor)

I think you need to clarify what you actualy mean. If the code is, as
you mention, written to the f77 or f90 standard, then it already is also
written to the f95 standard, with very minor exceptions that are
unlikely to be of significance (first because you probably won't run
into them, and second because they are easy to handle). In almost all
cases, code that is alleged to be f77 code, but has problems with f95,
is either

1. Not actually standard-conforming f77 code in the first place, but
instead f77 plus extensions

or

2. Technically standard-conforming f77, but depending on
processor-dependent features so that it wasn't portable f77 code. One
example of this is the dependence on the behavior of the sign intrinsic
for signed zeros mentioned in another posting here. That's not a
particularly common problem, I might add; I mention it just because it
was already brought up.

So if you have accurately stated your goal as being to "bring the code
up to the f95 standard", then there is likely little or nothing to do.
If your goal instead is to take advantage of some of the features new to
f90 or f95, then that's a different matter.

Whether it is worth the bother varies widely. Both "yes" and "no" are
ludicrous answers to that question. The only reasonable answer is "it
depends", with variations of what it depends on, and what the
conclusions are. I'd start with asking what you would expect to achieve
from such a thing: improved code clarity, maintainability, flexibility,
performance? My listing of those doesn't mean you can necessarily expect
to achieve them. For example, converting to f95 isn't likely to
automatically improve performance. I'm just trying to prompt you to
think about what it is that you expect to achieve. That's a necessary
step for evaluating pretty much any "is it worth it?" kind of question;
you need to know what the measure of worth in question is.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

>I have sizeable numerical code that was originaly written to the f77
>standard, It has been rewritten in parts to f90 standard. I have a
>mild interest in bringing the code up to f95 standard.

>I have a couple of  questions

>Is this actually worth the bother ?

Bottom line, answer the question "is it broke" by some standard?

If it ain't broke, don't fix it.

SO fundamentally what does "broke" mean to you with regards to
this set of code?   What justifies the investment of effort
and the potential of introducing new bugs and exacerbating old,
possibly hidden, bugs.  If it just for fancy, it ain't worth it.
If there are real reasons, what are they?

MHOO - YMMV

P.S., free advice is often worth what you paid for it.

On Apr 11, 8:26 am, "Arjen Markus" <arjen.mar@wldelft.nl> wrote:

<flame on> Anybody with any sense... <flame off>
On Apr 11, 11:05 am, "Kevin G. Rhoads" <kgrho@alum.mit.edu> wrote:

Fortran code is compiled to machine code run by a computer, but it is
also read by humans trying to understand algorithms. Features of
Fortran 90 such as free source form and array operations make it
superior to F77 in expressing algorithms IMO.

I recently purchased from Amazon a used copy of Daniel McCracken's "A
Guide to Algol Programming" (1962) to get a taste of the Algol 60
language. (One can compare it with his "Guide to Fortran Programming"
of 1961.) Reading that book, I think that in some respects Fortran did
not reach the expressiveness of Algol 60 until the 1990 standard.
Algol was used to express algorithms in scientific publications for
many years, even if the actual calculations were done by Fortran
programs translated from Algol.

"Exacerbating old, possibly hidden, bugs" can be a good thing if that
means they get fixed, depending on whether the "notification" is a run-
time error on one's PC or an industrial accident.

>I recently purchased from Amazon a used copy of Daniel McCracken's "A
>Guide to Algol Programming" (1962

I have McCracken's Fortran and COBOL books from when I was learning
programming back in the late 60's. I liked his exposition style.

I was not trying to discourage OP from working on the code.  I was
trying to get OP to think about what he was trying to do and was it
worth the effort.  I agree that

>"Exacerbating old, possibly hidden, bugs" can be a good thing if that
>means they get fixed,

but if the expected reward does not justify the effort, one should not
start the project.  I failed to see any consideration of this matter
in OP's post.  Doesn't mean OP didn't consider it, but it did seem to
make raising the question worthwhile.

And, yes, I liked Algol 60 and Algol 68 a lot.  But it seemed evident
to me back then they weren't getting significant mindshare and would
be backwatered.  Unfortunately my intuition proved correct.

"e p chandler" <e@juno.com> wrote in message
news:1176304873.220410.161490@p77g2000hsh.googlegroups.com...

 - This line should not start with '&' as it is not a continuation of the
previous line
 - Unpaired right bracket(s)
 - Illegal character combination, '-' followed by '-'
 - Variable ONTINUE follows another operand (possible unexpected space?)
! end f95 compiler's complaints, begin source snippet, then column numbering
      DO 4 J=0,JMAX+1
      EY1(J)=0
      EZ1(J)=0
4    CONTINUE
1234567
Almost all the errors I see in this source are due to misattention to fixed
form.  An example is the above snippet, where 4 is in the first column, and
the "C" in the CONTINUE is in the sixth.  The compiler is then looking for
something called ONTINUE.
--
WW

"e p chandler" <e@juno.com> wrote in message
news:1176304873.220410.161490@p77g2000hsh.googlegroups.com...

> On Apr 11, 6:33 am, "Zak" <b.zaryc@googlemail.com> wrote:
> Looking at the code, which was Fortran 77 plus extensions in fixed-
> format, it was clear that the problem was mis-alignment of code.
> statements were shifted left into the continuation column,
> continuation markers where shifted right into the code area, one
> comment was misplaced. One formula was in error. (Perhaps OCR errors?)
> [forgive sentence fragments :-)]

> It was easy to fix these problems and get the program to run as fixed
> format code, but I wondered "How does this code work and what does it
> do?" Converting to Fortran 95, including free-format, let me "clean
> up" enough to help me understand some of what was going on.

C-----d. EX  generation:
        IF((J.NE.0).AND.(J.NE.JMAX).AND.(K.NE.0)) THEN
        M = IXMED( I, J, K )
        EX(I,J,K,NCUR) = CA(M)*EX(I,J,K,NPR1) + CBMRB(M)*
     &  (HZ(I,J,K,NCUR)-HZ(I,J-1,K,NCUR)+HY(I,J,K-1,NCUR)
     &                 -HY(I,J,K,NCUR))
        ENDIF
C-----e. EY  generation:
        IF(K.NE.0) THEN
        M = IYMED( I, J, K )
        EY(I,J,K,NCUR)=CA(M)*EY(I,J,K,NPR1) + CBMRB(M)*
      &  HX(I,J,K,NCUR)-HX(I,J,K-1,NCUR)+HZ(I-1,J,K,NCUR)
      &                -HZ(I,J,K,NCUR))
        ENDIF
!end source snippet
EY generation looks the same to me as EX generation, yet no matter what I
do, I can't make my compiler get through EY.  I think the culprit is one of
the things you mention above, but how to fix it?  The first error objects to
it being a valid continuation.
--
WW

Line up the "&" character in the section of code for EY generation to
match those in the EX generation.  As others have told you, your
sourcecode is in a form that requires certain parts of the code line to
be in very specific columns.  Your continuation characters (the &) must
be in column 6.

"baf" <w@nowhere.com> wrote in message

news:McxTh.32$G4.13527@okeanos.csu.net...

C-----d. EX  generation:
        IF((J.NE.0).AND.(J.NE.JMAX).AND.(K.NE.0)) THEN
        M = IXMED( I, J, K )
        EX(I,J,K,NCUR) = CA(M)*EX(I,J,K,NPR1) + CBMRB(M)*
     &  (HZ(I,J,K,NCUR)-HZ(I,J-1,K,NCUR)+HY(I,J,K-1,NCUR)
     &                 -HY(I,J,K,NCUR))
        ENDIF
C-----e. EY  generation:
        IF(K.NE.0) THEN
        M = IYMED( I, J, K )
        EY(I,J,K,NCUR)=CA(M)*EY(I,J,K,NPR1) + CBMRB(M)*
     &   (HX(I,J,K,NCUR)-HX(I,J,K-1,NCUR)+HZ(I-1,J,K,NCUR)
     &     -HZ(I,J,K,NCUR))
                        ! was unpaired right brace^^
        ENDIF

Gotcha.  You can't judge it with your eye.  I had to scoot the ampersand to
the right until it compiled.  I also added a left brace, instead of chopping
off the unpaired right one.  If EX generation is coded correctly, then one
would want CBMRB(M) to multiply the last four terms in the analogous EY
code, from group theory.
--
WW

On Apr 12, 5:23 pm, "Wade Ward" <inva@invalid.net> wrote:

1. That's why I use an old DOS text editor. It lets me scoot the
cursor down vertically in column 6 or 7 even if some lines are shorter
than 6 or 7 columns. That way I can nudge the line left or right as
needed to meet the requirements of fixed source format.

2. Similarity of code suggested to me where to add the missing left
parenthesis as you also discovered.

3. Yet anoher reason why I keep a Fortran 77 (+ extensions) compiler
(g77) on my system. Getting old code _to_compile_ as fixed format
makes it easier to use tools like Metcalf's "convert" to go to free
source form as "convert" expects standard conforming code.

4. Please look at the substantive changes I discussed after I took
care of the fixed-source to free-format conversion manually. If you
would like a copy of the program after conversion feel free to e-mail
me.

-- e-mail: epc8 at juno dot com
-- elliot

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc