Memo - dennou Diff

{{toc}}

= dcl による作画
== 疑問
* wsn=2 で ps に出力する場合、iwidth と iheight を指定しても用紙は landscape に固定？
  * 図を tex などに張る場合、ps ファイルは用紙サイズ・形状とは無関係の方が楽。
    * landscape 固定だと無駄な空白領域が出来うる。
  * dclpsrmcm, dclpsmargin を通しても効いてないみたい。
    * annotate があるから？
    * psファイルの diff を取れば分かる。だけど、ps言語が分からない。
  * 用紙の向きは？ dcl.ps を gv で見る限りはlandscape に見えるが、tex で取り込んだら図が90度回転し、縦長になっていた。
    * はじめから用紙の向きを portrait に出来たら良い。
  * cygwin の eps2eps (Ghostscript 8.63)がよさげ。vine の eps2eps (gs 7.07)よりも margin を削除してくれている。

== 円柱座標系のデータの作画 (2009.09.12)
itr = 5 を使うのが真っ当なやり方だと思われるが、何かと復習・理解しないといけないことが多そうなので、g2pk01.rb のやり方を真似て、itr=51 で円柱座標系上の全グリッド点を cartesian 座標上での点に対応させて作画（((<itr=51について|URL:http://www.gfd-dennou.org/library/dcl/dcl-5.3.3/README_itr51>))）。頑張ってスマートに(こちら側で陽に座標変換の作業をしなくてよいように)しようと itr=5 にこだわなくても、itr=51 でやったほうが実際に行われている作業が見通しやすい。itr=5 (6も?) の使い易さは微妙（昔は頑張って使ったのだが）。

= ggraph
== 疑問
* tone で細かい刻みで塗った後に、contour lines を描くのはどうする？
* 以下のような繰り返しの場合、contour なら問題ないが tone だとエラーになる：

...
ncfiles.each{ |file|
    gphys = GPhys::IO.open(file,"de")
    DCL.gropn(1)                # 2 でも同様
    GGraph.tone( gphys, true )  # contour なら問題ない
    DCL.grcls
}

* annotate の場所を変えたい
  * 基本的に文字は横書きなので、左右のマージンではなく上下のマージンに書きたい。
  * ggraph.rb の def annotate を参照。

=== 解決済み
* GGraph.tone などの第2引数の true false は何？
  * => newframe


== 利点
* gphys オブジェクトのまま直接作画してしまえる（配列に戻す必要がない）
  * そのため、極力 ggraph で済ましてしまいたいのだが、挙動がよく理解できないため、結局 DCL べた書きしたほうが早い。
    * ggraph が内部で何をしているのかが分からない（ggraph.rb を読み込めばそのうち分かるようになるのだろうけど）。
    * DCL のレベルでもきちんと理解していないことも結構ある。
  * 自分の理解度からすると、欲しい図をかくなら結局 DCLべた書きをして、ggraph は gpview, gpvect の次のレベルのクイックルックとして使うべきか。。。

= gpview, gpvect
== 疑問
* データに log10 などの数学関数を演算させるには、gpview や gpvect だけからは直接は無理？
  * log10 だけでも処理できたらかなり守備範囲が広がるのだが。
    * => 自前で解決


= gphys
== 組み込みたいこと
=== gphys オブジェクト演算時の履歴の記録
* gphys オブジェクトに演算処理を施して新たな gphys オブジェクトを生成させたとき、変数名にその演算が反映されるようにしたい。とりあえずは、単項演算子（例えば数学関数）から。
  * gphys.rb の 707 行目からの for 文の中を少し手を加えればよさそう。

for f in VArray::Math_funcs
   eval <<-EOS, nil, __FILE__, __LINE__+1
   def #{f}(*arg)
     GPhys.new( self.grid, self.data.#{f}(*arg) )
   end
   EOS
end

現状では、以下で動作している

for f in VArray::Math_funcs
   eval <<-EOS, nil, __FILE__, __LINE__+1
   def #{f}(*arg)
     gp = GPhys.new( self.grid, self.data.#{f}(*arg) )
     gp.name=(self.name+".#{f}")
     gp.long_name=("#{f}("+self.long_name+")")
     gp
   end
   EOS
end

* memo
  * 設計上の選択肢として、変数名 name を直に書き換えるべきか、別の属性を設けてそこに演算のヒストリーを記録するのがよいか。
    * 直に書き換える場合、制御文字・特殊文字に影響をあたえないように、規則は要考察。
  * 本来なら単位も変えるべし。だが、自分が必要に駆られていないのでパス。
  * 2項演算も処理するためには？
  * すべての演算を追うのは不可能。どこかで諦めるか、全くやらないか。全くやらないにしても、変更が加えられていることは最低でも見えてほしい。

=== 内挿


== 疑問
* gphys オブジェクトから座標値（の配列）の取り出し方は？
x = gphys.axis("x").flatten[0].val
とりあえずこうすれば x が 1 次元の NArray として取得できるが、これが最適な取り出し方法?方法かは不明。
* protect？
  * GPhys オブジェクトを生成した時点ではまだ実体はなくファイルを示すポインタ的なものしかないから書き換えられない、ということ？
  * インスタンスメソッド grid は参照すらできない。data は参照できるのに。
  * 既にある GPhys オブジェクトに演算を施した新しい GPhys オブジェクトも同様？

* grid.rb
  * l.393 "incuded" は typo?
  * l.416 "monotonic" はどういう意味？

* axis.rb
  * _minloc_ は、monotonic を仮定しているように見えるが、コメントでは違うと書いてある。

== gphys.cut の構造（cut_rank_conservingも構造は同じなので割愛）
GPhys::cut()
|- Grid::cut()
|   |- Grid::_cut_()
|   |   |- Axis::cut()
|   |   |   |- Axis::_cut_()

== GPhys オブジェクトの座標値の取得の仕方
* とりあえず、以下のようにすれば、x,y,z がそれぞれ 1 次元の NArray となり取得できるが、最適な方法なのかは疑問。
gphys = GPhys::IO.open("test.nc","de")
x = gphys.grid.axis(0).pos.val
y = gphys.grid.axis(1).pos.val
z = gphys.grid.axis(2).pos.val