CSVファイルをインポートすると，どこかでこのファイルに書き込みを実行している．通常系図ファイルはDLL側でオープンされるが，CSVファイルの場合は，VB側でオープンされ，VBで読み取ったレコードがDLL側に送られるようになっている．CSVファイルを読み取り専用に設定して開いた場合には書き込みは行われない．ただし，エラーも発生しない．⇒テストはリリース版で実行しているが，リリース版のコードにテスト用のコードが残っていて，書き込みを実施しているのではないか？リリース版では少なくもテスト用のエクスポートは止めておかなくてはならない．これではテストにならないので，もう一度リリース版を作り直してみよう．⇒Version 2.2.0.025 Release 2021-02-09を所内解放した．
TribeRelocationのステージ【４】重婚同類グラフ検定でBuildSameGeneMarriageGraphを実行して生成された「重婚クラスタグラフ」をインポートして表示すると下図を得る．
節点数27，枝数34の非循環的有向グラフだ．これからGetHasseDiagramでハッセ図を生成して得られる図面が重婚クラスタ図だが，どうもうまくいっていない．節点数は変化していないが，すべての枝を失ってしまっている．
どこで失敗しているのだろう？かなりおかしい．多重クラスタグラフがいつの間にか軸線図グラフにすり替わっている．いや，勘違いだ．GetHasseDiagramは血統軸線図検定の中でも呼び出されている．⇒SIMPLEGRAPH::ExportGraphが動作していない．TOPOLOGY：SaveClusterGraphなら保存できる．
ExportGraphは不要なフィールドを省いてコラム数を11まで削減したものだが，少なくとも軸線図ではこれで動いている．⇒SIMPLEGRAPH：ExportGraphの共通ブロックにCARDLINKを使っているところがあった．場合分けしなくはならない．⇒多重クラスタグラフが取れた．多重クラスタ図も作れる．下図左はGetHasseDiagramで出力した重婚クラスタ図，右は既存ハッセ図検定の出力．
節点数は27で同じ，枝数は30に減少している．世代数は10で既存ハッセ図検定の出力と同じだ．比較してみよう．2つの図面の基本的な違いは，推移枝をカットする位置と思われる．重婚クラスタ図では下流でカットし，既存ハッセ図では上流でカットするようになっている．しかし，この違いは必ずしクラスタ検定と既存ハッセ図検定の差という訳ではない．GetHasseDiagram（新設した関数）で引数のseed（起点）を変えてやると下図のような図式が出力される．
ただし，GetHasseDiagramの中で実施している上流検定と下流検定の順序も入れ替えている．つまり，出力結果の図式は手順によって変わるということが言える．現行では推移枝を無差別に削除しているが，その枝が端点ノードの唯一の枝の場合は削除しないように変えてみよう．
大分それらしくなってきたので，この方向でもう少し作業を進めることにしよう．TestInevitableMultiZeroとVerticallyTightenHasseDiagramを廃止して，GetHasseDiagramに置き換えた．出力を見てみよう．左が現在，右が従来方式だ．
3段目のundosysは本来4人兄弟なのだが，従来方式ではそのうちの2人が抜けて下の方に移動してしまっている．これは，少なくともこの図面の制作意図には反しているように思われる．このサンプルの原図であるZTモジュール構成図は，モジュール構造を可視化することを目的とするものであるからだ．どちらの図面も軸線が複線になってしまっている．世代関係を維持しながら，この軸線を通すためには，どうしてもnoduleを3世代分垂直シフトする必要がある．垂直シフトを許すとフロート婚が発生する可能性があるために現行では禁止されているのだが，それを解除するとどうなるかを見てみよう．⇒まだエラーは出ているが通った．
これでよいのではないかと思う．すべてのノードが重婚クラスタ検定で割り当てた絶対世代番号の位置に配置されている．これができれば，問題はほぼ解決したも同然だ．どんな大風が吹いてもびくともしない構造物が作れそうだ．
▲STAGE6.ZELを#6 undosysで開いて，MARGBOX::setgoodsonのエラーが出る．(PHASE > CLEARTABLE && GoodSon && (!goodson || !goodson->GoodBox) && !IsExtractDummy() && !OnSetGoodSon && !OnRestoreExtractBox && !OnBuildShaftLine && IsVital() && !OnsetGoodSibling && !OnCancelBetweenTwo) という理由だ．つまり，「GoodSonを訳もなく空にしてはならない」という意味だ．
コメントには「対象ノードがgoodsonである場合はgoodson解除する＠2018-03-30」とある．これはカードシフトされたカードはgoodsonにはなれないという意味だが，今の場合軸線なのでgoodsonを解除することはできない．⇒「GoodSonをシフトしたときはgoodson解除しない＠20210209」としておこう．今度は，makeGoodSonで停止した．
(!head->IsaSibling() && head->GoodSon->getmyhome() != head)という理由だ．「単体枠でGoodSonを持っているがGoodSonのボックスはこの結婚枠でない」というコメントが付いている．この結婚枠が設定しているGoodSonは#266nodule(0)で抽出されたノードだ．結婚枠に入っているのはnodule(4)でnodule(4)→nodule(0)のように接続されている．noduleの仮ノードは(1)が欠番で，(0)から(12)までの12個表示されている．undosysとnodule(0)をつなぐ抽出枠チェーンは(4)→(5)→(6)→(0)のように繋がっている．(4)→(5)→(6)はダミーなので(0)がGoodSonとなるのは妥当だろう．
軸線がシフトすることを認めるとしたのだから，ここでは停止しないというのでよいのではないだろうか？ないし，条件に「EXTRACTBOXでない」を付け加えてもよい．⇒今度はNAMEBOX：MakeTooYoungWifeで停止した．「カードシフトによる抽出ダミー枠のチェーンをTYWの長い尻尾に転換」しようとしている．これはまずいのではないか？
NAMEBOX::CardShiftDirectではGoodBoxをTYWに転換することは禁止している．従って，このノードは軸線ではない．MakeTooYoungWifeではNAMEBOXではなく，CARDLINKがjikusenであるかどうかをチェックしているが，NAMEBOXが軸線でなければ許可してよいと思う．これでエラーはすべて解消した．ダミーノードにはjikusenのマークは付与されないので，可視ノード数とjikusenの個数が一致しない場合がある．couplingでソートすると下図のようになる．
ここまでやるか！？という感じもあるが，まぁ，やるっきゃないね…
▲STAGE6.ZELの#30 MDBで「軸線が通っていない」エラーが出た．出力では一応通っているように見えるのだが…
水平座標の比較の基準としてTREEVIEW::baseboxを使っているのだが，これ以外のすべての軸線ノードとの間で不一致が生じている．それも-56 <> 108という大きな差が出ている．軸線上のノードはMDB(2)だ．baseboxはMDB(0)で不可視の消去された仮ノードだ．baseboxの選定が悪いということになる．baseboxはSETRELATIVEフェーズで設定されている（その前にも仮設定されていはいるが…）．
条件は始系列に属する可視ノードだ．⇒軸線が決定したときに見直すか？ないし，baseboxが不可視になったときに取り直しをするかのどちらかが必要だ．⇒TREEVIEW::SelectBaseBoxという関数を新設し，baseboxが不可視になったときにはこの関数を実行するようにした．
▲上記サンプルを#43 graph1でソートして，SIMPLEGRAPH：GetLongestChainで無限ループしている．重複パスの単線化に失敗している．完全木テストで連続実行している場合にのみ起こる．#43 graph1で起動した場合には発生しない．いや，#43ではなく次の#61で起きているようだ．