2018 Leicester helicopter crash の報告書 AAIB Bulletin S2/2018 を読んだ

まえがき

ja.wp の AW169 の事故（あったことを知らなかった…）の記事がよくわからなかったので事故調査の報告書読んでた。本来回転すべきではないコントロールシャフト内軸が回転してしまったためにすっぽ抜けてアクチュエータが効かなくなり、テールロータピッチ変えられなくなってヨー制御不能…怖すぎる…

— maz (@dynamicsoar) 2018年12月26日

の続き。

ja.wp の記事 の記述では、コッターピンが外れてから溶着とあるが、順番が逆だと思う。

ヨー操舵入力の流れ

まずヨーの操舵入力がどのようにテールロータのピッチ変更を行うか。正直、図を見ないと（見ても）わかりにくいのだが、おそらく以下のようになっている：

操舵入力（ペダル） → 操舵ケーブルの前後運動 (push or pull) → ヘリコプタ尾部のベルクランク → レバー → レバー端のピン（？） → ピンキャリア → コントロールシャフト（レバー側）→（シャフトが押し/引きされる）→ シャフト後端のベアリング → ピッチ変更機構（詳細略）

いくつかポイント

• 重要なのは「シャフト後端のベアリングのインナーレース」までは、シャフトは長軸周りの回転をせず、前後の押し引きのみが起こるべきである、ということ。
• 実際にはレバー中央がアクチュエータのソレノイドバルブにつながっていて、フィードバック制御が入るようだが、そこは省略。
• それから、「レバー端のピン（？）」「ピンキャリア」の部分は大事なんだけど、残念ながら情報が不足しているので、想像が入っている。要するにレバーの回転をシャフトの前後運動に変換するところ。おそらく次のようになっている
  • シャフト端部にはネジが切ってあり、その途中にコッターピン用の穴もある。
  • まずシャフトにピンキャリアという部品を入れる。写真が不鮮明だが、これは要はレバー側とシャフト側の2つの円柱用の穴が空いた部材だろう。両側とも回転はすべりだけで、接合はされないと思われる。シャフト前後方向への並進自由度の制約としては、後ろ側へはおそらくシャフト径で制約していると思われる。前側は入れるために細くないといけないので、キャッスルナット (castlated nut) という特殊なナットをシャフト端部のネジ切り部にはめることで位置を制限している（これは確定）。このように、ピンキャリアとキャッスルナットはお互いに接触はするかもしれないが一体となって回転するものではなく、むしろ独立しているべきである。
  • キャッスルナットというのは、王冠のように縁に凹凸のあるナットで、この凹部とシャフトの穴にコッターピンを通すことで、ナットとシャフトの回転（緩み）を防ぐもの。

事象シーケンス

以上を前提として、事象シーケンスは以下のようになると考えられる（だいたい報告書に書いてあるが一部は推測）：

1. コントロールシャフト後端部のベアリング内外レースが（グリス不良かなにかで）正常に回転しなくなった（数度しか動かない状態）。
2. 本来はベアリングのおかげで回転しないはずのコントロールシャフトが（テールロータと一緒に）回転し始めた。
3. シャフト前端部（レバーやアクチュエータの側）では、シャフトと一緒にキャッスルナットも回転し始めた。コッターピンも当然一緒に回転するので、この自転ではせん断破壊しないと思われる。
4. キャッスルナットと接触していたピンキャリアは、レバーと同じ座標系にいるため非回転。したがって、この2者の接触面が摩擦接合されてしまった。シャフト＝キャッスルナットが回転していない通常状態であれば、ピンキャリアは単に前後方向に押されるだけなので、接触しても接合などするはずはなかった（なので間に接合防止部材なども入っていなかったのだろう…というかそんな想像もしなかったかもしれない）。
5. キャッスルナットがレバー座標系＝静止側に固定されてしまい、シャフトと一体回転できなくなったことで、両者をつなぐコッターピンに過剰なせん断応力が生じた。これによりコッターピンの頭部と尾部（端部？）が吹き飛んだ。
6. シャフトがキャッスルナットおよびピンキャリアから抜け、レバーシステムとの接続が失われた。
7. 操舵入力がテールロータに伝わらなくなり、ヨー制御が不能となって墜落に至った。

感想

この状況では「コッターピンがせん断破壊されなければ…」という想定は無理がありそう。防ぐべきは第一に後部ベアリングの回転不良だろう。また、キャッスルナットとピンキャリアの間になにか接合を防ぐような部材があれば少しはよかったかもしれないが、長時間の高速回転に耐えられるものだろうか…。

文献

• AAIB Bulletin S2/2018 (PDF)
• 2018 Leicester helicopter crash - Wikipedia
• レスター・ヘリコプター墜落事故 - Wikipedia

Fluent: write-settings & read-settings are extremely useful

I'm pretty sure you're tired of repeating the same (or similar) settings for loads of computation cases. At some point you noticed that you can use "Duplicate" the Fluent module in workbench. Yes it's useful. But there's an even better way: settings.

After setting up the Fluent and just before you run the computation, go to TUI window and type

file/write-settings

then you'll be prompted for a file name. Type a name such as "my_settings.ini" then it'll be saved in your working directory (such as D:\my_project_files\dp0\FLU-1\Fluent\ ).

Now you can close the Fluent without saving. Open it again, and go to TUI window, and type in

file/read-settings

and when asked type "my_settings.ini" Voilà! All the settings such as turbulence model, boundary conditions, etc. are recovered.

This is not only useful in the desktop mode but also for the computations on the HPCs with journal file. Within the journal file, you can now simply read the mesh file, read the settings, initialise the flow field, setup the Data File Quantities and Run. For example you can try many different meshes, or you can easily change the inlet velocity in the journal file, etc. Alternatively you can directly edit the setting file (which is a text file with Scheme syntax).

run Fluent, export .cas and .dat, and compress them after computation (on Linux)

I could not find the way to specify the auto-save .cas & .dat files in the format of .cas.gz & .dat.gz, and I gave up to compress them using the journal file. Instead, I decided to compress them in the script file after the computation, if there's any remaining wallclock time. For this I used a simple shell script utilising pigz (parallel version of gzip). If your HPC does not have pigz you can use normal gzip instead but won't get the benefit of parallel compression.

Sample script for pigz

The script will be something like this:

#!/bin/bash
#$ OTHER PARAMETERS REQUIRED BY HPC SYSTEM

export INPUT='my_journal.jou'
N_cores=28

. /etc/profile.d/modules.sh
module load ansys
module load mpi-intel

fluent 3ddp -mpi=intel -g -i ${INPUT} > log.txt 2>&1

wait

for file in $(find . -type f -name '*.dat' -o -name '*.cas'); do
    pigz -p ${N_cores} "$file"
done

Sample script for gzip

Or, if you are using normal gzip, simply:

#!/bin/bash
#$ OTHER PARAMETERS REQUIRED BY HPC SYSTEM

export INPUT='my_journal.jou'

. /etc/profile.d/modules.sh
module load ansys
module load mpi-intel

fluent 3ddp -mpi=intel -g -i ${INPUT} > log.txt 2>&1

wait

for file in $(find . -type f -name '*.dat' -o -name '*.cas'); do
    gzip "$file"
done

micro CT settings memo

I'm using SkyScan 1172. According to one of the Bruker's manual named "SkyScan 1172 How to set up a scan?", for 4K camera mode with No Filter,

• Voltage = 40--50 kV: but it turned out this resulted in some star-like ray noises. As per the suggestion from the technician, I raised it to 70 kV and it got better.
• rotation step <= 0.3 deg: "Preferably lower the rotation step (instead of increasing frame averaging) for low dense samples when the signal to noise ratio is too low."
• frame averaging 4--8 frames: "Preferably increase the frame averaging (instead of decreasing the rotation step) for high dense samples when the signal to noise ratio is too low."

Considering my sample is of very low density material (which does not allow me to use even a thin filter), it is likely that I should decrease rotation step a lot and use moderate number of frames for averaging. However, there's yet another potential consideration that I am suspecting: motion blur. My sample is quite susceptible to the vibration, I can see the blur when I press the "Grab" button immediately after rotation or translation. Therefore, I am suspecting that during the actual scan the first image frame for each position can be slightly blurry. If this is true, increasing frame averaging can be quite important to reduce the noise due to blur. I usually take 0.1--0.15 deg rotation step and 3-5 frame averaging but maybe I should try increasing the frame averaging a bit more.

ANSYS FE Modeler was "undocumented" (removed) in version 19.1

I've been looking for the FE Modeler in version 19.1 and never found it. Uninstalling & reinstalling a few time --> no success. Then, I found that in their release note, it says:

1.8. FE Modeler As we previously announced, FE Modeler has now been undocumented at Release 19.1 because newer ANSYS technologies, such as External Model, have made the FE Modeler application obsolete

Oh... so the External Model should have the similar function... I'll try.

Well, I have never expected a drastic change such as removing a module ("Toolbox") can happen between the 0.1 version difference, which I regarded as minor version up... but for ANSYS it's normal. We should be careful...

---

日本語： FE Modeler は version 19.1 から消えている。インストールのミスとかではなくて公式が削除した模様。代わりに External Model というのを使えといっている。

To use "Body of Influence" in ANSYS Meshing (at least in version 19), Physics Preference must be changed to CFD from Mechanical

The title says it all... we wasted more than an hour for this...

ANSYS Mechanical で "core" 数が変えられないとき→メニューとツリーの2箇所変える必要がある（場合がある）

これに気づかなくて最近はずーっとデフォルトらしき2コア（論理コア）でしか並列計算ができてなかった。前はできたこともあったのでバージョン違いのせいか忘れたかのどっちか（あるいは両方）。

とにかくタイトルの通りで、メニューの Tools > Solve Process Settings... からの設定と、左のツリービューアの Solution からの "Number of Cores to Use (beta)" の設定と、2箇所ある。少なくとも version 19.0 ではそうだった。両方をたとえば 16 とかにすれば問題なく 16 論理コアで動く。そんだけ…

と思ったが、全く同じ V19.0 なのにもう一台のマシンだとツリービューの Solution に "Number of Cores to Use (beta)" という項目自体がない！？なんなんだこれ…（頭を抱える）。しかも悪いことにどっちもCPUマザボが同じスペックのPCで、しかも同じタイミングで（つい昨日？）ANSYS をインストールしたんだよね。なにこれ…。唯一の違いとしては片方には先に V19.1 が入っていた、ということ。たぶんここなんだろうな。もうホントやだ…