スパム対策の為、SAD BBSを下記プログラムに移行致します。
(生出施設長、鎌田先生 確認済)

★acc-physics.kek.jp/cgi-bin/SAD2/wforum.cgi
(★=http://)

本日よりこちらのBBSへの記事投稿は出来なくなりましたのでご注意くださいませ。
これまでの投稿ログは残し、閲覧可能な状態に致します。
ホームページからのリンク等、一両日中に変更作業を行います。

お手数ですが、ブックマーク等のご変更をどうぞ宜しくお願い致します。

Dear Users,

1. The definition syntax of Class is changed to avoid a crash when something like C=Class[{},{},] is declared by mistake. This change should not affect anything for a properly written program.

Dear Users,

1. (k64 only) A bug was found when the second argument of Partition is non-positive.

2. ListContourPlot now takes an option ColorFunctionScaling. If it is False, the value of the list is directly pased to the color function. The default is True.

thank you for immediate and exhaustive answer (:

> How can I use FIT procedure with interconnected elements? For example, i want to variate doublet of quads with opposite polarity (or just different aperture or different coils) but with single power supply. I didn't found in help and examples possibility to FREE elements with correlation preserved.
>
Solution:
A. Define correlation among elements
A-1. COUPLE command
ex). COUP Q1 Q2 -1;
A-2. ElementValues global variable
ex). ElementValues := {"K1"["Q2"]:>="K1"["Q1"], ...}
B. Define correlation as binding condition
B-1. FitFunction global variable
ex). FitFunction := {Element["K1", "Q1"] + Element["K1", "Q2"], ...}

How can I use FIT procedure with interconnected elements? For example, i want to variate doublet of quads with opposite polarity (or just different aperture or different coils) but with single power supply. I didn't found in help and examples possibility to FREE elements with correlation preserved.

・Xcode6.1をApple store経由でインストールする。その後、Developersよりサインインして、command lineをインストールする。
・Yosemiteにアップデートした後に、Xquartzをインストールしなおす。アップデートするときに消されてしまうので。

・gmp のソースファイルを展開する
$ bzip2 -dc ../archive/gmp-6.0.0.tar.bz2 | tar xvf -

・mpfr のソースファイルを展開する
$ bzip2 -dc ../archive/mpfr-3.1.2.tar.bz2 | tar xvf -

・mpcのソースファイルを展開する。
$ tar xvf ../archive/mpc-1.0.2.tar

・gcc のソースファイルを展開し、パッチを当てる。
$ bzip2 -dc ../archive/gcc-4.9.1.tar.bz2 | tar xvf -
$ wget -q -O - ‘https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180’ | patch -p1

・gmp
$ cd gmp-6.0.0/
$ ./configure --enable-cxx
$ make
$ make check
$ sudo make install

・mpfr
$ cd ../mpfr-3.1.2/
$ ./configure
$ make
$ make check
$ sudo make install

・mpc
$ cd ../mpc-1.0.2
$ ./configure
$ make
$ sudo make install

・compile ディレクトリーに移動しオブジェクトディレクトリーを作り、そこに入る
$ mkdir obj_gcc-4.9.1
$ cd obj_gcc-4.9.1

・gcc のコンパイル。次のシェルスクリプトを実行する。
$ sysctl -a | less
または
$ uname -v
でカーネル情報を確認。

・次のようなスクリプトファイルを用意する。

#!/bin/tcsh
set var = $<
echo gcc-${var}

../gcc-${var}/configure \
--enable-languages=c,c++,fortran \
--disable-nls \
--with-system-zlib \
--program-suffix=-${var} \
--infodir=/usr/local/share/info/gcc-${var} \
--mandir=/usr/local/share/man \
--libdir=/usr/local/lib/gcc-${var} \
--with-gxx-include-dir=/usr/local/include/c++/${var} \
--build=x86_64-apple-darwin14.0.0 \
CC=gcc CXX=g++

$ chmod 755 make-gcc.sh
$ make-gcc.sh
4.9.1 <return>

・gcc のビルド
$ make bootstrap

・gcc のインストール
$ sudo make install
$ sudo chown -R root:wheel /usr/local/lib/gcc-4.9.1

・compileディレクトリーに入る。
$ cd /Users/foo/src/compile

・SADをcvsを用いてダウンロードする。（初回のみ。次回からはoldsasd内で$ cvs updateとすると、ソースが最新バージョンにアップデートされる。）
$ cvs -z3 -d :pserver:anoncvs@www-acc-theory.kek.jp:/Users/cvs/SAD checkout -P oldsad

・SADのコンパイル
$ cd oldsad

・sad.confを適当に編集。
（Xftを使う場合、/usr/X11R6/bin/xft-configを旧いマックからコピーしておく。）

$ make exe

・SADのテスト
$ cd script
$ /Users/foo/src/compile/oldsad/bin/gs bench2.sad

以上

> > > > 広島大学の清宮です。
> > > >
> > > > 1本の加速管を3つに切って、切った加速管同士をフリンジ無しで以下のように直接繋げたのですが（つもり）、
> > > > 加速管1本をそのままTrackParticlesしたものと3つに切って繋げた場合のTrackParticlesで
> > > > 結果が少々違うようです。
> > > > 私には何か間違っているのか、仕様なのか、バグなのか判断ができませんでしたので、連絡させていただきました。
> > > >
> > > 物理的に異なる加速器モデル(TES1 vs TES2)を比較して結果が変わらなかったら、それこそがバグだと思います
> >
> > フリンジを切れば物理的に同じモデルになると思っていました。
> > 1本の加速管の一部にQを巻く場合、CAVI2種とMULT1種を合わせてシミュレーションできるかと考えていたのですが、
> > TES3ではそういったシミュレーションはできていないということになりますよね。
> > どのようにすれば1本の加速管の一部にQを巻くシミュレーションができるのでしょうか。
> >
> なりません
>
> あなたは、加速管COPを 三種の加速管 COP1,2,3に分解する段階で、物理的に異なるモデルを構成しています
> (これは、フリンジモデリングなどの摂動レベルの差異ではありません)
>
> COP/COP1〜3のフリンジをすべて取り去り、通過させる粒子の6元座標を(0, 0, 0, 0, 0, 0)にとれば、
> よりはっきりと問題が明かになると思います

ありがとうございます。
一致しない原因は、粒子の速度が光速より遅いことで生じる位相の変化を、下流のRFで考えていなかったためと思います。
切った加速管を切る前と同じように繋げるには、切り口からちょうど粒子が出るときのRF位相を知る必要があると思うのですが、
このような値を取得できる関数はあるでしょうか。
(無い場合は、δφ= 2πf ∫ (1-v(z)/c)/v(z) dzを積分する？）

よろしくお願い致します。

> > > 広島大学の清宮です。
> > >
> > > 1本の加速管を3つに切って、切った加速管同士をフリンジ無しで以下のように直接繋げたのですが（つもり）、
> > > 加速管1本をそのままTrackParticlesしたものと3つに切って繋げた場合のTrackParticlesで
> > > 結果が少々違うようです。
> > > 私には何か間違っているのか、仕様なのか、バグなのか判断ができませんでしたので、連絡させていただきました。
> > >
> > 物理的に異なる加速器モデル(TES1 vs TES2)を比較して結果が変わらなかったら、それこそがバグだと思います
>
> フリンジを切れば物理的に同じモデルになると思っていました。
> 1本の加速管の一部にQを巻く場合、CAVI2種とMULT1種を合わせてシミュレーションできるかと考えていたのですが、
> TES3ではそういったシミュレーションはできていないということになりますよね。
> どのようにすれば1本の加速管の一部にQを巻くシミュレーションができるのでしょうか。
>
なりません

あなたは、加速管COPを 三種の加速管 COP1,2,3に分解する段階で、物理的に異なるモデルを構成しています
(これは、フリンジモデリングなどの摂動レベルの差異ではありません)

COP/COP1〜3のフリンジをすべて取り去り、通過させる粒子の6元座標を(0, 0, 0, 0, 0, 0)にとれば、
よりはっきりと問題が明かになると思います

> > 広島大学の清宮です。
> >
> > 1本の加速管を3つに切って、切った加速管同士をフリンジ無しで以下のように直接繋げたのですが（つもり）、
> > 加速管1本をそのままTrackParticlesしたものと3つに切って繋げた場合のTrackParticlesで
> > 結果が少々違うようです。
> > 私には何か間違っているのか、仕様なのか、バグなのか判断ができませんでしたので、連絡させていただきました。
> >
> 物理的に異なる加速器モデル(TES1 vs TES2)を比較して結果が変わらなかったら、それこそがバグだと思います

フリンジを切れば物理的に同じモデルになると思っていました。
1本の加速管の一部にQを巻く場合、CAVI2種とMULT1種を合わせてシミュレーションできるかと考えていたのですが、
TES3ではそういったシミュレーションはできていないということになりますよね。
どのようにすれば1本の加速管の一部にQを巻くシミュレーションができるのでしょうか。

よろしくお願い致します。

> 広島大学の清宮です。
>
> 1本の加速管を3つに切って、切った加速管同士をフリンジ無しで以下のように直接繋げたのですが（つもり）、
> 加速管1本をそのままTrackParticlesしたものと3つに切って繋げた場合のTrackParticlesで
> 結果が少々違うようです。
> 私には何か間違っているのか、仕様なのか、バグなのか判断ができませんでしたので、連絡させていただきました。
>
物理的に異なる加速器モデル(TES1 vs TES2)を比較して結果が変わらなかったら、それこそがバグだと思います

広島大学の清宮です。

1本の加速管を3つに切って、切った加速管同士をフリンジ無しで以下のように直接繋げたのですが（つもり）、
加速管1本をそのままTrackParticlesしたものと3つに切って繋げた場合のTrackParticlesで
結果が少々違うようです。
私には何か間違っているのか、仕様なのか、バグなのか判断ができませんでしたので、連絡させていただきました。

よろしくお願い致します。

!--------------------------
MARK
P00=(EMITX=2.84762926e-05 AX=0.0 BX=0.65
EMITY=2.84762926e-05 AY=0.0 BY=0.65)
P01=()
;

CAVI
CCP=(L=2.0 FREQ=1.3e9 VOLT=40e6 PHI=-90 DEG)
CCP1=(L=0.9 FREQ=1.3e9 VOLT=40e6 PHI=-90 DEG FRINGE=1)
CCP2=(L=0.9 FREQ=1.3e9 VOLT=40e6 PHI=-90 DEG FRINGE=2)
CCP3=(L=0.2 FREQ=1.3e9 VOLT=40e6 PHI=-90 DEG DISFRIN=1)
;

MULT
CCPQ=(L=0.2 FREQ=1.3e9 VOLT=40e6 PHI=-90 DEG K1=0 DISFRIN=1 FRINGE=0)
;

LINE TES1=(P00 CCP P01);
LINE TES2=(P00 CCP1 CCPQ CCP2 P01);
LINE TES3=(P00 CCP1 CCP3 CCP2 P01);

FFS;
NPARA=1;
TRPT;
beam={1,{{1e-3},{1e-3},{1e-3},{1e-3},{1e-3},{1e-3},{1}}};

FFS["USE TES1"];
Design orbit length = 2.0000000000000000
POS=LINE["POSITION","P01"];
TrackParticles[beam,POS]
Out[3]:= {3,
{{.002996010266232957},{.0009993326457982824},{.002996010266232957},{.0009993326457982824},{.000998007971811252},{.00099817325467\
94604},
{1}}}

FFS["USE TES2"];
Design orbit length = 2.0000000000000000
POS=LINE["POSITION","P01"];
TrackParticles[beam,POS]
Out[5]:= {5,
{{.0029925489404048094},{.0009974854714060555},{.0029925489404048094},{.0009974854714060555},{.0009980148715060793},{.00099453584\
79871674},
{1}}}

FFS["USE TES3"];
Design orbit length = 2.0000000000000000
POS=LINE["POSITION","P01"];
TrackParticles[beam,POS]
Out[7]:= {5,
{{.0029925489404048094},{.0009974854714060555},{.0029925489404048094},{.0009974854714060555},{.0009980148715060793},{.00099453584\
79871674},
{1}}}

> > 広島大学の清宮です。
> >
> > RF空洞の周りに４極磁石をかぶせたい場合、ラティスファイル内のLINEの書き方を
> > 教えていただけないでしょうか。
> > 例えば、3m加速管にQをかぶせる場合、
> >
> > MARK
> > P00=();
> >
> > DRIFT
> > L01=(L=-0.1);
> >
> > CAVI
> > C01=(L=1.5 FREQ=1.3e9 VOLT=40e6 FRINGE=1)
> > C02=(L=1.5 FREQ=1.3e9 VOLT=40e6 FRINGE=2);
> >
> > QUAD
> > Q01=(L=0.2 K1=+1.00);
> >
> > LINE TES=(P00 C01 L01 Q01 L01 C02);
> >
> > でよいのでしょうか。
> > よろしくお願い致します。
>
> つ MULT

MULTは多極磁石だけでなく加速も使えたのですね。
ありがとうございます。

> 広島大学の清宮です。
>
> RF空洞の周りに４極磁石をかぶせたい場合、ラティスファイル内のLINEの書き方を
> 教えていただけないでしょうか。
> 例えば、3m加速管にQをかぶせる場合、
>
> MARK
> P00=();
>
> DRIFT
> L01=(L=-0.1);
>
> CAVI
> C01=(L=1.5 FREQ=1.3e9 VOLT=40e6 FRINGE=1)
> C02=(L=1.5 FREQ=1.3e9 VOLT=40e6 FRINGE=2);
>
> QUAD
> Q01=(L=0.2 K1=+1.00);
>
> LINE TES=(P00 C01 L01 Q01 L01 C02);
>
> でよいのでしょうか。
> よろしくお願い致します。

つ MULT

広島大学の清宮です。

RF空洞の周りに４極磁石をかぶせたい場合、ラティスファイル内のLINEの書き方を
教えていただけないでしょうか。
例えば、3m加速管にQをかぶせる場合、

MARK
P00=();

DRIFT
L01=(L=-0.1);

CAVI
C01=(L=1.5 FREQ=1.3e9 VOLT=40e6 FRINGE=1)
C02=(L=1.5 FREQ=1.3e9 VOLT=40e6 FRINGE=2);

QUAD
Q01=(L=0.2 K1=+1.00);

LINE TES=(P00 C01 L01 Q01 L01 C02);

でよいのでしょうか。
よろしくお願い致します。

> ところがいくつか問題があります
> 以前に書いたいくつかのコードでセグメンテーションフォルトをおこしてコアダンプします
>
> バックトレースを見ると
> Backtrace for this error:
> #0 0x41F365E7
> #1 0x41F36B84
> #2 0x4408D235
> #3 0x4408D4A6
> #4 0x7FFFFFFFF002
> セグメンテーション違反: 11 (コアダンプ)
>
> と同じ表示になってます
>
> これはまだkern.maxdsizの減らし方が不十分と言うことなのでしょうか？
> １Gに減らしてみたりしたのですが症状は変わりませんでした
>
> 実はこのセグメンテーションエラーは
> freeBSDが入っている端末では正しく動いているコードを
> Xウィンドウエミュレータ上で動かすと発生するんです
>
> どうやらOpticsPlotを実行すると起こっているみたいなのですが。。。
> 動かないコードもPlotを実行するところでエラーを起こしているみたいです
> ただターミナル上でPlotを使って簡単な関数を書いてみても問題なく動作するのでなぜエラーを吐くのかよくわからないんです
> 例えばプロットする関数をリストに書き下してListPlotするときちんとプロットできるので
> Plotに入れている関数が不当というわけではないと思います
>
> もしなにかお気づきの点がございましたら教えていただけるとありがたいです
>
状況から考えて、X Serverの実装依存の問題です
SAD側のBacktraceの解析(Tk及びX11を含む)とX Protocolの通信ログの解析などが有効と思われます

> > > > Ubuntu14.04.1.amd64なども試してみたのですがコンパイルは通ったのですが
> > > > うまく動作しなかったんですよね。。。。
> > > >
> > > > intel系のPCにインストールして成功した組み合わせ（OS+SADブランチ）というのはないんですかね？
> > > >
> > > KEKのSAD計算機は、FreeBSD/amd64 9-STABLE + lang/gcc(4.7.4) + MAIN trunk/k64-1-6 branchの組み合わせで稼働中
> > > ただし、MAIN trunkの動作を保証するためてにカーネルパラメターを調整しています
> >
> > MAIN TRUNKの動作を保証するカーネルパラメータは具体的にどこのパラメータを変更すればできるのでしょうか？
> >
> > 挑戦してみたいので教えていただけると幸いです
> >
> mmap(2)が割り当てる仮想アドレスが、16GiB境界の下に降りてくるまで、kern.maxdsizを減らしています
> (この調整は、単一プロセスで多量のメモリーを必要とする計算環境と両立しません)
>
> 技術的な根拠は、以下の通り
> MAIN trunkでは内部アドレス表現として、8-octet境界の配列インデックスを符号付き32bit整数で表現し、
> 非正の値を無効な値として扱うため、基準となる配列 rlistの先頭から 16GiBの範囲に全ての動的メモリを
> 割り当てる必要があります

返信が遅れて申し訳ありませんでした
kern.maxdsiz="2G"としたところエラーなくexampleが動きインストールできました
ありがとうございました

ところがいくつか問題があります
以前に書いたいくつかのコードでセグメンテーションフォルトをおこしてコアダンプします

バックトレースを見ると
Backtrace for this error:
#0 0x41F365E7
#1 0x41F36B84
#2 0x4408D235
#3 0x4408D4A6
#4 0x7FFFFFFFF002
セグメンテーション違反: 11 (コアダンプ)

と同じ表示になってます

これはまだkern.maxdsizの減らし方が不十分と言うことなのでしょうか？
１Gに減らしてみたりしたのですが症状は変わりませんでした

実はこのセグメンテーションエラーは
freeBSDが入っている端末では正しく動いているコードを
Xウィンドウエミュレータ上で動かすと発生するんです

どうやらOpticsPlotを実行すると起こっているみたいなのですが。。。
動かないコードもPlotを実行するところでエラーを起こしているみたいです
ただターミナル上でPlotを使って簡単な関数を書いてみても問題なく動作するのでなぜエラーを吐くのかよくわからないんです
例えばプロットする関数をリストに書き下してListPlotするときちんとプロットできるので
Plotに入れている関数が不当というわけではないと思います

もしなにかお気づきの点がございましたら教えていただけるとありがたいです

> > > Ubuntu14.04.1.amd64なども試してみたのですがコンパイルは通ったのですが
> > > うまく動作しなかったんですよね。。。。
> > >
> > > intel系のPCにインストールして成功した組み合わせ（OS+SADブランチ）というのはないんですかね？
> > >
> > KEKのSAD計算機は、FreeBSD/amd64 9-STABLE + lang/gcc(4.7.4) + MAIN trunk/k64-1-6 branchの組み合わせで稼働中
> > ただし、MAIN trunkの動作を保証するためてにカーネルパラメターを調整しています
>
> MAIN TRUNKの動作を保証するカーネルパラメータは具体的にどこのパラメータを変更すればできるのでしょうか？
>
> 挑戦してみたいので教えていただけると幸いです
>
mmap(2)が割り当てる仮想アドレスが、16GiB境界の下に降りてくるまで、kern.maxdsizを減らしています
(この調整は、単一プロセスで多量のメモリーを必要とする計算環境と両立しません)

技術的な根拠は、以下の通り
MAIN trunkでは内部アドレス表現として、8-octet境界の配列インデックスを符号付き32bit整数で表現し、
非正の値を無効な値として扱うため、基準となる配列 rlistの先頭から 16GiBの範囲に全ての動的メモリを
割り当てる必要があります

> > Ubuntu14.04.1.amd64なども試してみたのですがコンパイルは通ったのですが
> > うまく動作しなかったんですよね。。。。
> >
> > intel系のPCにインストールして成功した組み合わせ（OS+SADブランチ）というのはないんですかね？
> >
> KEKのSAD計算機は、FreeBSD/amd64 9-STABLE + lang/gcc(4.7.4) + MAIN trunk/k64-1-6 branchの組み合わせで稼働中
> ただし、MAIN trunkの動作を保証するためてにカーネルパラメターを調整しています

MAIN TRUNKの動作を保証するカーネルパラメータは具体的にどこのパラメータを変更すればできるのでしょうか？

挑戦してみたいので教えていただけると幸いです

それともやはりハード環境によって調整すべきパラメータが変わるんでしょうか？

> Ubuntu14.04.1.amd64なども試してみたのですがコンパイルは通ったのですが
> うまく動作しなかったんですよね。。。。
>
> intel系のPCにインストールして成功した組み合わせ（OS+SADブランチ）というのはないんですかね？
>
KEKのSAD計算機は、FreeBSD/amd64 9-STABLE + lang/gcc(4.7.4) + MAIN trunk/k64-1-6 branchの組み合わせで稼働中
ただし、MAIN trunkの動作を保証するためてにカーネルパラメターを調整しています

> > ktrace(1)/kdump(1)の結果です
> > 落ちている近傍の物だけですがもっと上から追わないとわからないんでしょうか？
> > 読み方もちょっとわからないのでどこを切り出せば情報になるのかわかりません
> > 本当に申し訳ないです
> >
> > 84154 sad1.exe RET write 43/0x2b
> > 84154 sad1.exe CALL madvise(0x8050c1000,0x41000,MADV_FREE)
> > 84154 sad1.exe RET madvise 0
> > 84154 sad1.exe CALL write(0x2,0x7fffffffdbc0,0x34)
> > 84154 sad1.exe GIO fd 2 wrote 52 bytes
> > "lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> > "
> > 84154 sad1.exe RET write 52/0x34
> > 84154 sad1.exe CALL mmap(0x800000000,0x400000000,0x3<PROT_READ|PROT_WRITE>,0x1012<MAP_PRIVATE|MAP_FIXED|MAP_ANON>,0xffffffff,0)
> > 84154 sad1.exe RET mmap 34359738368/0x800000000
> > 84154 sad1.exe PSIG SIGSEGV caught handler=0x80330e3c0 mask=0x0 code=0x2
> > 84154 sad1.exe PSIG SIGSEGV SIG_DFL code=0x2
> > 84154 sad1.exe NAMI "sad1.exe.core"
> >
> > inimem_()内でklistを使っているcall lminitはコメントアウトされているようですが
> > 他のところでcallされているんでしょうか？
> > どのあたりのコードを修正すればいいのか。。。
> >
> grepで追いかけると、初期化のコードフローは、以下の通り
> main routine @ MAIN.f
> - inimem @ pfalloc.f
> -- talocinit @ tfstk.f
> --- tfcbkinit @ tfstk.f
> ---- lminit_ @ sim/unix_memory_.c
> --- mapallocfixed_ @ sim/unix_memory_.c
>
> kernel traceからは、mmap(2)は成功しており、mmapで貼った仮想メモリに触って SEGVしてるように見えます
> ここから先の動作解析には、kernelの動作やプロセスの仮想メモリマップの知識が必要な気がします

そうですか。。。
それは完全に私の能力からははみ出てますね。。。

お忙しいなか相談に乗っていただきありがとうございました

Ubuntu14.04.1.amd64なども試してみたのですがコンパイルは通ったのですが
うまく動作しなかったんですよね。。。。

intel系のPCにインストールして成功した組み合わせ（OS+SADブランチ）というのはないんですかね？

> > ktrace(1)/kdump(1)の結果です
> > 落ちている近傍の物だけですがもっと上から追わないとわからないんでしょうか？
> > 読み方もちょっとわからないのでどこを切り出せば情報になるのかわかりません
> > 本当に申し訳ないです
> >
> > 84154 sad1.exe RET write 43/0x2b
> > 84154 sad1.exe CALL madvise(0x8050c1000,0x41000,MADV_FREE)
> > 84154 sad1.exe RET madvise 0
> > 84154 sad1.exe CALL write(0x2,0x7fffffffdbc0,0x34)
> > 84154 sad1.exe GIO fd 2 wrote 52 bytes
> > "lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> > "
> > 84154 sad1.exe RET write 52/0x34
> > 84154 sad1.exe CALL mmap(0x800000000,0x400000000,0x3<PROT_READ|PROT_WRITE>,0x1012<MAP_PRIVATE|MAP_FIXED|MAP_ANON>,0xffffffff,0)
> > 84154 sad1.exe RET mmap 34359738368/0x800000000
> > 84154 sad1.exe PSIG SIGSEGV caught handler=0x80330e3c0 mask=0x0 code=0x2
> > 84154 sad1.exe PSIG SIGSEGV SIG_DFL code=0x2
> > 84154 sad1.exe NAMI "sad1.exe.core"
> >
> > inimem_()内でklistを使っているcall lminitはコメントアウトされているようですが
> > 他のところでcallされているんでしょうか？
> > どのあたりのコードを修正すればいいのか。。。
> >
> grepで追いかけると、初期化のコードフローは、以下の通り
> main routine @ MAIN.f
> - inimem @ pfalloc.f
> -- talocinit @ tfstk.f
> --- tfcbkinit @ tfstk.f
> ---- lminit_ @ sim/unix_memory_.c
> --- mapallocfixed_ @ sim/unix_memory_.c
>
> kernel traceからは、mmap(2)は成功しており、mmapで貼った仮想メモリに触って SEGVしてるように見えます
> ここから先の動作解析には、kernelの動作やプロセスの仮想メモリマップの知識が必要な気がします
>
動作比較としては、KEK内のSAD計算機(FreeBSD/amd64 9.3-STABLE r269298)環境では、
(ka .ge. kcpthre)が .false.となり elseブロック側にフローが流れるので、mapallocfixed8は呼び出されません

> ktrace(1)/kdump(1)の結果です
> 落ちている近傍の物だけですがもっと上から追わないとわからないんでしょうか？
> 読み方もちょっとわからないのでどこを切り出せば情報になるのかわかりません
> 本当に申し訳ないです
>
> 84154 sad1.exe RET write 43/0x2b
> 84154 sad1.exe CALL madvise(0x8050c1000,0x41000,MADV_FREE)
> 84154 sad1.exe RET madvise 0
> 84154 sad1.exe CALL write(0x2,0x7fffffffdbc0,0x34)
> 84154 sad1.exe GIO fd 2 wrote 52 bytes
> "lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> "
> 84154 sad1.exe RET write 52/0x34
> 84154 sad1.exe CALL mmap(0x800000000,0x400000000,0x3<PROT_READ|PROT_WRITE>,0x1012<MAP_PRIVATE|MAP_FIXED|MAP_ANON>,0xffffffff,0)
> 84154 sad1.exe RET mmap 34359738368/0x800000000
> 84154 sad1.exe PSIG SIGSEGV caught handler=0x80330e3c0 mask=0x0 code=0x2
> 84154 sad1.exe PSIG SIGSEGV SIG_DFL code=0x2
> 84154 sad1.exe NAMI "sad1.exe.core"
>
> inimem_()内でklistを使っているcall lminitはコメントアウトされているようですが
> 他のところでcallされているんでしょうか？
> どのあたりのコードを修正すればいいのか。。。
>
grepで追いかけると、初期化のコードフローは、以下の通り
main routine @ MAIN.f
- inimem @ pfalloc.f
-- talocinit @ tfstk.f
--- tfcbkinit @ tfstk.f
---- lminit_ @ sim/unix_memory_.c
--- mapallocfixed_ @ sim/unix_memory_.c

kernel traceからは、mmap(2)は成功しており、mmapで貼った仮想メモリに触って SEGVしてるように見えます
ここから先の動作解析には、kernelの動作やプロセスの仮想メモリマップの知識が必要な気がします

> > > > > 東北大の武藤です
> > > > >
> > > > > intel corei5のマシンにFreeBSD/amd64　9.3を導入してSADをインストールを試みたのですが
> > > > >
> > > > > コンパイルは通ったようなのですがexampleの実行でこけていることがわかりました
> > > > >
> > > > > oldsad/bin/gsは生成されているので単体で実行したところ
> > > > > $ ./gs
> > > > > *** Welcome to SAD Ver.1.0.10.6.13.2k64 built at 2014-07-31 02:39:25 +0900 ***
> > > > > *** Today: 02:40:44 Thursday 07/31/2014 ***
> > > > > Segmentation fault
> > > > > のように単体で実行してもセグメンテーションフォルトですぐに落ちてしまいます
> > > > >
> > > > > まったく情報が足りないと思いますが何かお気づきの点があれば教えていただきたいです
> > > > >
> > > > 何が起こっているかを把握するために、-g -O1辺りでコンパイルして、SEGVで生成された core fileから
> > > > バックトレースを取るべきです
> > > >
> > > > また、COPTへ -DDEBUG_MEMORY=3を付けてコンパイルするとSADの内部allocatorからデバックメッセージが取り出せます
> > >
> > > コメントありがとうございます
> > > 試してみました。結果は以下のようになりました
> > >
> > > -DDEBUG_MEMORY=3を付けて実行
> > > > bin/gs
> > > *** Welcome to SAD Ver.1.0.10.6.13.2k64 built at 2014-08-04 01:31:35 +0900 ***
> > > *** Today: 01:54:28 Monday 08/04/2014 ***
> > > lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> > > Segmentation fault (core dumped)
> > >
> > > コアファイルをみてみると
> > > > gdb771 obj/AMD64-FreeBSD9/sad1.exe sad1.exe.core
> > > GNU gdb (GDB) 7.7.1 [GDB v7.7.1 for FreeBSD]
> > > Copyright (C) 2014 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-portbld-freebsd9.3".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > <http://www.gnu.org/software/gdb/bugs/>.
> > > Find the GDB manual and other documentation resources online at:
> > > <http://www.gnu.org/software/gdb/documentation/>.
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from obj/AMD64-FreeBSD9/sad1.exe...done.
> > > [New process 100114]
> > > Cannot access memory at address 0x800aa9808
> > > Cannot access memory at address 0x800aa9800
> > > (gdb) where
> > > #0 0x000000080330e3c0 in ?? ()
> > > #1 0x00007ffffffff003 in ?? ()
> > > #2 0x000000080330e3c0 in ?? ()
> > > #3 0x0000000000000000 in ?? ()
> > > (gdb)
> > >
> > > 別途gdb上でrunしてみると
> > > (gdb) run
> > > Starting program: /usr/home/tmuto/oldsad/obj/AMD64-FreeBSD9/sad1.exe
> > > [New LWP 100251]
> > > [New Thread 80501f400 (LWP 100251)]
> > > *** Welcome to SAD Ver.1.0.10.6.13.2k64 built at 2014-08-04 01:31:35 +0900 ***
> > > *** Today: 02:42:21 Monday 08/04/2014 ***
> > > lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> > > [New LWP 100251]
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to LWP 100251]
> > > 0x000000080303207c in ?? () from /lib/libc.so.7
> > > (gdb) where
> > > #0 0x000000080303207c in ?? () from /lib/libc.so.7
> > > #1 0x0000000000423a1d in mapallocfixed8_ (base=0x800000000,
> > > usize=usize@entry=0x7fffffffe448, unit=unit@entry=0x649a3c,
> > > irtc=irtc@entry=0x7fffffffe45c)
> > > at /usr/home/tmuto/oldsad/src/sim/unix_memory_.c:412
> > > #2 0x00000000004adad3 in tfstk::talocinit ()
> > > at /usr/home/tmuto/oldsad/src/tfstk.f:348
> > > #3 0x000000000043c1a1 in inimem () at /usr/home/tmuto/oldsad/src/pfalloc.f:24
> > > #4 0x0000000000422b36 in MAIN__ () at /usr/home/tmuto/oldsad/src/MAIN.f:27
> > > (gdb)
> > >
> > > のような結果を得ましたがこれでなにか情報は得られるでしょうか？
> > > 正直なところ当方浅学のためよくわかりません
> > >
> > src/sim/unix_memory_.c(正確には、unix_memory8_.c)にある mapallocfixed_()にて、mmap(2)の呼び出しで失敗しているようです
> > mmap(2)の呼び出しの確認前後の状況は、ktrace(1)/kdump(1)で確認できるかと思われます
> >
> > inimem_()から始まる一連のSAD内部のheap管理構造の初期化に失敗しているので、
> > その辺のコードを修正すれば良いと思います
> >
> つらつらと眺めた限り、src/tfstk.fで定義されている maccbk module内の integer(8), pointer: klist(:)が未初期化のまま
> call lminitにてdereferenceされてるのが原因かなぁ・・・
>
> 多分、未定義動作になるので、SEGVしても Fortran的には正しい実装動作です

返事が遅れて申し訳ありません

ktrace(1)/kdump(1)の結果です
落ちている近傍の物だけですがもっと上から追わないとわからないんでしょうか？
読み方もちょっとわからないのでどこを切り出せば情報になるのかわかりません
本当に申し訳ないです

84154 sad1.exe RET write 43/0x2b
84154 sad1.exe CALL madvise(0x8050c1000,0x41000,MADV_FREE)
84154 sad1.exe RET madvise 0
84154 sad1.exe CALL write(0x2,0x7fffffffdbc0,0x34)
84154 sad1.exe GIO fd 2 wrote 52 bytes
"lminit: rlist0=0x800000000 align=8 bits=61 offset=0
"
84154 sad1.exe RET write 52/0x34
84154 sad1.exe CALL mmap(0x800000000,0x400000000,0x3<PROT_READ|PROT_WRITE>,0x1012<MAP_PRIVATE|MAP_FIXED|MAP_ANON>,0xffffffff,0)
84154 sad1.exe RET mmap 34359738368/0x800000000
84154 sad1.exe PSIG SIGSEGV caught handler=0x80330e3c0 mask=0x0 code=0x2
84154 sad1.exe PSIG SIGSEGV SIG_DFL code=0x2
84154 sad1.exe NAMI "sad1.exe.core"

inimem_()内でklistを使っているcall lminitはコメントアウトされているようですが
他のところでcallされているんでしょうか？
どのあたりのコードを修正すればいいのか。。。

> > > > 東北大の武藤です
> > > >
> > > > intel corei5のマシンにFreeBSD/amd64　9.3を導入してSADをインストールを試みたのですが
> > > >
> > > > コンパイルは通ったようなのですがexampleの実行でこけていることがわかりました
> > > >
> > > > oldsad/bin/gsは生成されているので単体で実行したところ
> > > > $ ./gs
> > > > *** Welcome to SAD Ver.1.0.10.6.13.2k64 built at 2014-07-31 02:39:25 +0900 ***
> > > > *** Today: 02:40:44 Thursday 07/31/2014 ***
> > > > Segmentation fault
> > > > のように単体で実行してもセグメンテーションフォルトですぐに落ちてしまいます
> > > >
> > > > まったく情報が足りないと思いますが何かお気づきの点があれば教えていただきたいです
> > > >
> > > 何が起こっているかを把握するために、-g -O1辺りでコンパイルして、SEGVで生成された core fileから
> > > バックトレースを取るべきです
> > >
> > > また、COPTへ -DDEBUG_MEMORY=3を付けてコンパイルするとSADの内部allocatorからデバックメッセージが取り出せます
> >
> > コメントありがとうございます
> > 試してみました。結果は以下のようになりました
> >
> > -DDEBUG_MEMORY=3を付けて実行
> > > bin/gs
> > *** Welcome to SAD Ver.1.0.10.6.13.2k64 built at 2014-08-04 01:31:35 +0900 ***
> > *** Today: 01:54:28 Monday 08/04/2014 ***
> > lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> > Segmentation fault (core dumped)
> >
> > コアファイルをみてみると
> > > gdb771 obj/AMD64-FreeBSD9/sad1.exe sad1.exe.core
> > GNU gdb (GDB) 7.7.1 [GDB v7.7.1 for FreeBSD]
> > Copyright (C) 2014 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-portbld-freebsd9.3".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>.
> > Find the GDB manual and other documentation resources online at:
> > <http://www.gnu.org/software/gdb/documentation/>.
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from obj/AMD64-FreeBSD9/sad1.exe...done.
> > [New process 100114]
> > Cannot access memory at address 0x800aa9808
> > Cannot access memory at address 0x800aa9800
> > (gdb) where
> > #0 0x000000080330e3c0 in ?? ()
> > #1 0x00007ffffffff003 in ?? ()
> > #2 0x000000080330e3c0 in ?? ()
> > #3 0x0000000000000000 in ?? ()
> > (gdb)
> >
> > 別途gdb上でrunしてみると
> > (gdb) run
> > Starting program: /usr/home/tmuto/oldsad/obj/AMD64-FreeBSD9/sad1.exe
> > [New LWP 100251]
> > [New Thread 80501f400 (LWP 100251)]
> > *** Welcome to SAD Ver.1.0.10.6.13.2k64 built at 2014-08-04 01:31:35 +0900 ***
> > *** Today: 02:42:21 Monday 08/04/2014 ***
> > lminit: rlist0=0x800000000 align=8 bits=61 offset=0
> > [New LWP 100251]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to LWP 100251]
> > 0x000000080303207c in ?? () from /lib/libc.so.7
> > (gdb) where
> > #0 0x000000080303207c in ?? () from /lib/libc.so.7
> > #1 0x0000000000423a1d in mapallocfixed8_ (base=0x800000000,
> > usize=usize@entry=0x7fffffffe448, unit=unit@entry=0x649a3c,
> > irtc=irtc@entry=0x7fffffffe45c)
> > at /usr/home/tmuto/oldsad/src/sim/unix_memory_.c:412
> > #2 0x00000000004adad3 in tfstk::talocinit ()
> > at /usr/home/tmuto/oldsad/src/tfstk.f:348
> > #3 0x000000000043c1a1 in inimem () at /usr/home/tmuto/oldsad/src/pfalloc.f:24
> > #4 0x0000000000422b36 in MAIN__ () at /usr/home/tmuto/oldsad/src/MAIN.f:27
> > (gdb)
> >
> > のような結果を得ましたがこれでなにか情報は得られるでしょうか？
> > 正直なところ当方浅学のためよくわかりません
> >
> src/sim/unix_memory_.c(正確には、unix_memory8_.c)にある mapallocfixed_()にて、mmap(2)の呼び出しで失敗しているようです
> mmap(2)の呼び出しの確認前後の状況は、ktrace(1)/kdump(1)で確認できるかと思われます
>
> inimem_()から始まる一連のSAD内部のheap管理構造の初期化に失敗しているので、
> その辺のコードを修正すれば良いと思います
>
つらつらと眺めた限り、src/tfstk.fで定義されている maccbk module内の integer(8), pointer: klist(:)が未初期化のまま
call lminitにてdereferenceされてるのが原因かなぁ・・・

多分、未定義動作になるので、SEGVしても Fortran的には正しい実装動作です