● ftnchek で間違いを見付けよう。

そろそろプログラムも長くなってきたので、 間違いを見付ける(「バグをとる」)のが大変になってきましたね。 間違いを見付ける「古典的な」方法は知っておいた方が良いでしょう。

• コンパイル出来ない場合には、f90 からのエラーメッセージを もとに間違いを探す。

• コンパイル出来るが動かない場合には、最初の方に間違いがあるので 最初の数行を徹底的に確認する。分からない場合には 最初の部分だけを取りだした小さなプログラムを作って動かしてみる。

• 動くが途中で止まる、あるいは変な答えになる場合には、 おかしい付近を想定して、いろいろな変数の値を画面に書き出させる (abc の値がおかしいようなら write(*,*) abc, などを プログラムのあちこちにいれる)。

• プログラムが動いている間におかしい部分を見付けてくれる コマンド (dbx など) を使う。(説明しません。)

• ftnchek はセンターの標準コマンドではありませんので、 最初に使う場合には 環境設定についての Homepage (エイリアスとコマンドパスについての解説)、 演習で行った 「Unix の環境を整備しよう」のページ を参照して、
  
  /home1/s-0007/bin
  をコマンドパスにつけ加えて下さい。

  具体的には、各自の Home Directory にある環境設定ファイル .cshrc の 次に、set path=... の部分に /home1/s-0007/bin を追加してください。
  

  set path=(./ /usr/local/bin /usr/gnu/bin /usr/bin/X11 $path )
  --> set path=(./ /home1/s-0007/bin /usr/local/bin /usr/gnu/bin /usr/bin/X11 $path )

  (前回の環境整備で現在の directory ./ を付け加えていない人は今回ついでに付け加えましょう。 path= の最初に "./ " (ドット スラッシュ スペース) を加えて下さい。

  編集が終ったら環境を更新します。
  

  source .cshrc

  これで ftnchek コマンドが使えます。

  プログラムの間違いを探すには
  

  ftnchek progXX.f
  のようにコマンドの後に Fortran プログラムファイル名をいれます。

  例1: 例えば次のようなプログラムだと

  
        program progXX
        implicit real*8(a-h,o-z)
        x=1.0d0
        y=1.5d0
        z=x+y
        write(*,*) w
        end
  

  次のように怒られます。

  ap1 71: ftnchek progXX.f
  FTNCHEK Version 2.11 July 1999
  
  File progXX.f:
  Warning in module PROGXX file progXX.f:
     Variables set but never used:
           Z         
     Variables used before set:
           W         
   0 syntax errors detected in file progXX.f
   2 warnings issued in file progXX.f
  ap1 72:
  

  used before set は値を与える前に変数を使っている、ということです。 x, y, z は与えていますが、w は与えていませんね。

  例 2: あと、見付けにくい間違いとして subroutine の引数の数や型が 違うことがあります。 Lesson06 の prog06.f で次のような例がありました。

  
        program prog06
        implicit real*8 (a-h,o-z)
        ....
           call onestep(x,y,vx,vy,t,dt)
        ....
        end
  c **********************************************************************
        subroutine onestep(x,y,vx,vy,dt)
  c **********************************************************************
  c Force at x,y
        call force(x,y,fx,fy)
        ....
        end
        ...
  

  このプログラムはコンパイルで「エラーはありません」と出るのに 走らせると「Bus error (core dumped)」という訳の分からないメッセージを 出して止まります。ftnchek で調べてみましょう。

  
  ap1 87: ftnchek prog06.f
  
  FTNCHEK Version 2.11 July 1999
  
  File prog06.f:
   0 syntax errors detected in file prog06.f
  Subprogram ONESTEP: varying number of arguments:
      Defined with 5 arguments in module ONESTEP line 40 file prog06.f
      Invoked with 6 arguments in module PROG06 line 31 file prog06.f
  Subprogram ONESTEP:  argument data type mismatch
    at position 1:
      Dummy arg X is type real  in module ONESTEP line 40 file prog06.f
      Actual arg X is type real*8  in module PROG06 line 31 file prog06.f
      ....
  

  0 syntax errors detected... と出ているので、確かにそれぞれの部分(メインプログラム、副プログラム) でのエラーはありません。しかしつなぐと間違いになるエラーがあるのです。

  varying number of arguments は「引数の数が合っていないよ」というメッセージです。 良く見ると onestep を call するときには 6 つの引数を与え、 subroutine の部分では引数が 5 つになっています。 メインプログラムと subroutine は「引数の順番」で情報をやりとり しているので、上の例ではメインプログラムの t をsubroutine 内では dt として扱ってしまうのです。

  argument data type mismatch は「変数の型が合っていないよ」というメッセージです。 良く見ると subroutine onestep で implicit 宣言をして いなかったため、呼ぶ側では倍精度実数と思っているのに、 呼ばれる側では単精度実数扱いしているのでした。

  メッセージが長すぎる場合はファイルに出力して見てみましょう。
  

  ap1 87: ftnchek progXX.f > abc
  

  ap1 88: mule abc &

  私が注意するメッセージは次の言葉を含むものです。

  • "used before", "used but": ...する前に使用されている、 使用されているが...である。
  • "mismatch": 変数の型などが合っていない。ミスマッチがある。
  • "varying number of argument": 引数の数が合わない。

  私もしばしばまちがったプログラムを書きます。 「間違いを見付ける」方法をいくつも持っているかどうかによって、 正しいプログラムを速く書けるかどうかが決まります。 古典的な方法と合わせて利用してみて下さい。