物理量は 数字ｘ単位 であるので、
L=1 m でないといけない。
ところが、歴史的な理由からか日本の教科書には角括弧でM=1[kg]などと書くことがある。理解しづらい。M=1000[g]とどう違うのか？という議論になってしまう。
角括弧の意味を正当化しようとして、ルールを決めようとするんだけど、どうにもローカルルールになってしまう。本質的な妥当性がないのでいたしかたない。あちこちで不具合が出る。ローカルルールの通用する個々の業界では困らないだろうけども。
深刻なのは教育的問題だろう
でたらめな角括弧ルールのせいで単位が理解できていない。組み立て単位がわからない。違う物理量を結びつけるのが物理定数ということがわからない。「ものを比べる」ということの意味がわからない。
例えば、物理的な次元を明瞭にしたいだけなら（多くの場合そういうことだと思える）、
長さL (次元 m)
とでも書き、L (次元 km)と書いても同じ意味である、とすべき。いくらかくどくてもきちんと書かないと混乱が起きる。わかってればどっちでもいい、ということではない。
MobilityReportHomework
https://colab.research.google.com/drive/1GzSjUvEivOgN0CGMFlGT7KKVRrMbNg1j?usp=sharing
M-x compile
ctrl+x `
でエラー行にジャンプ
https://flex.phys.tohoku.ac.jp/texi/emacs-jp/emacs-jp_158.html
gfortran,以下のように -O2と-gが両立するようだ。コンパイラのトレースバック機能がだいぶと良くなってきた。
mpif90 -O2 -g -fimplicit-none -ffixed-line-length-132 -DMPIK -JOBJ.gfortran -IOBJ.gfortran -c ../wanniergw/htbplot.F -o OBJ.gfortran/htbplot.o
f90の形状引き継ぎfoobar(:,:)はとてもよいが、モジュールに入れたサブルーチンをuseしないと引き継ぎが保証されないようだ。呼び出し側と呼び出される側を同じファイルに入れてもコンパイラは形状一致をチェックするので、いささかの混乱がある。
どうしてもf77のライブラリを利用することになるがトップダウンでf90化していく必要はある。subroutineの引数でデータを渡すのは避けるべき。指示（入力のみ）を書くべき。module変数のprotectで出力する。use,olnyとprotectの併用でデータフローのしっかり読めるコードになる。f77コードをトップダウンで（上位レベルから）モジュール化していくのがよい。依存関係やI/Oが明瞭になる。
ある種の単純化された「数値計算向けオブジェクト指向」というものがある。
f77ルーチンにsize(foobar)でサイズを取りたいが、このときfoobar(:)でいかないといけない。ただし、(:)だとシェープチェックも入ってくるので次元合わせまで要求されてしまう。
