創作においてメインの記述言語と異なる言語が出てきた際の違和感について

どうみても異世界な作品があったとする。ごく一部の例外を除いて、その世界の描写や登場人物のセリフはふつうは英語とか日本語とかで記述される。

以下、作品は小説でも漫画でもアニメでもたぶんいいと思うが、中間を取って漫画くらいに思っておくといいかもしれない。

日本語話者をメインターゲットとした作品なら基本的には日本語で描写されるだろう。しかし、もちろん異世界なので、お店の看板に本当に日本語で「冒険者ギルド」と書いてあったり、「へい、マスター」と言ったり、「今日の依頼は？」とか言ったりはしていない。何らかの現地語があって、それを作者が超能力で日本語へと翻訳している、ようなものだろう。現地語があっても全て現地語で書いてしまうと（たとえ地の文は日本語にしてセリフだけを現地語にしても）、煩雑だし、そもそも読者に創作の言語を強要するのはあまりに敷居が高すぎる。ここまでは、普通は陽にこのルールが書かれていないけれど「お約束」であって、特に問題はない。

問題はここに日本語以外の言語が登場したときだ。これにはいくつかのパターンがあると思う。

まず、現地語のカタカナ表記の場合は特に問題はないと感じる。なるほど現地ではこういう音の単語で、日本語でいうとこのような意味なんだな、という説明もふつうはある。現地の人名や地名などのカタカナ表記も、特に問題はないだろう。

一方で、自分が気になるのは、非日本語だが地球にある言語が出てきた場合だ。要するに英語であることが多い。これはさらに数パタンに分けられるように思う。まず、外来語のようにも見えるが日本語として使われないこともないような単語の場合は、まぁ、日本語ということでいいだろう。「ファイヤーボール」とか「ヒール」とか、もうこういうのは、英語というわけでもなく、日本語だと思っていいだろう。ただしこれらが敢えてアルファベットで fireball! とか heal! と書かれていると…違和感が出てくる。

しかし、作者が本当に何かを意図している場合ということがありえる。要するに、「作中の世界においても、その国で一般的な言語ではないことを示したい場合」だ。これはこれでよい。このケースであれば、アルファベット表記に我々読者が違和感を感じるのはむしろ作者の意図通りということにもなりえる。

もう一つ、これが困るわけだが、作者が特に何も考えておらず、「なんとなく英語を使っちゃった」場合もあるのではないかと思う。「異世界なので現地語を話しているのだがそれを作者が日本語に翻訳している」ということを作者が明確に意識していない、ということだ。ただ、話はたぶん単純ではなく、そうであっても無意識には「外国語感・外来語感」を出したかったのだ、ということもありそうだ。

最悪なパタンとしては、出典をすぐ出せない（忘れた）が、「英語のアルファベットについて、登場人物が言及してしまう（たとえばアナグラムとか）」というやつがある。これも、好意的に解釈すれば、等価あるいは近い内容の現象を作者が（なぜか英語に）翻訳しているのだ、というふうにもとれるかもしれないが、苦しいと思う。

そういうわけで、自分という読者・視聴者は、異世界を描いた作品においてメインの記述言語（日本語）以外の言語が出てくると、これらのうちのどれだと思えばよいのかがわからないことが多くて、結局、メインストーリへの没入が削がれて、違和感を覚えたり、不機嫌になったりすることが多い…ということを言いたかった。「そんなの、作者が深く考えてないだけのことが多いだろう」というツッコミはありえて、確かにそうだろうなとも思うのだが…ただ、「異世界と思ったけど実は未来の地球でした」パタンは自分はけっこう好きなので、実はそういった設定の伏線なのではないか、とか考えるのも好きなわけですよ。それなのに結局単なる「なんも考えてないだけ」だとがっかりというか…まぁでもそれがほとんどなのだろうけど、だとしたらそれも結局ロークオリティということでがっかりなわけで…

ついでにいうと、本筋ではないが、こういうときに英語の文法やスペルあるいはパンクチュエーションが間違っていると、余計にイライラする。単なるミスなのか（おそらくこれが多いのだろうが）、それとも、そこにも実は意味（意図）があるのか、がわからない。

論文読み: Range of motion in the avian wing is strongly associated with flight behavior and body mass

基本情報

Baliga, V. B., Szabo, I. and Altshuler, D. L. (2019). Range of motion in the avian wing is strongly associated with flight behavior and body mass. Science Advances 5, eaaw6670. https://doi.org/10.1126/sciadv.aaw6670

結果

Fig. 1

翼平面形とRoMの基本的な整理

• Fig. 1F: これは要するに軽い種のほうが関節の可動域が広く、重い種では狭く…というかより正確には「ひじと手首を独立して動かしづらい」ということかな。
• Fig. 1G: まじで何を言ってるか全くわからない…

Fig. 2

ひじ関節を（人が）可動させたとき、手首関節が自動的に動く。それに関するおはなし。基本的に A 以外はあまり違いがないなぁという結果ぽい。

• Fig. 2C (right), 2D: 可動にともなって AR も当然変わるので、その変動パタンを調べている。

Fig. 3

平面でなく3次元的なRoMについて。具体的には背腹方向（bending と呼称）と長軸周りの回転（twisting と呼称）。これらの呼称はあまり良くないと思うが、素晴らしい代替案があるかっていうと…。

なおこれについては平面的なRoMと大きな違いがあり、 1. 調べたのは手首関節についてのみ。まぁひじ関節はほぼ1自由度回転なんじゃないのという気がするからこれは妥当に思える。 1. 調べたのは61種ではなく約半分の30種のみ。こっちの方が気になる。疲れちゃったんだろうか…

• Fig. 3上: 本文によると、ザックリ言って、右上に行くほど（＝翼を伸ばすほど）3次元的な運動は抑制される（色としては暗くなる）という傾向があるようだ。まぁそうかなって気がする。
  • ただ、レンジが80度・150度とかなり大きく、個別に種を見ると相当な variation があるよねぇこれ…。たとえば、
    • bending で高い値の Cal ann は Calypte anna (Anna's hummingbird), Ral lim は Rallus limicola (Virginia rail).
    • twisting で高い値の Asi fla は Asio flammeus (short-eared owl), Tae gut は Taeniopygia guttata (Sunda zebra finch).
• Fig. 3A, C: というのをもっとわかりやすく示してるのがこれら。更に、色が暗いほど体重が重く、それらは下の方に位置している＝3次元的な可動性が低い。まぁなんか直感的にもそうかなという気はする。
• Fig. 3B, D: 飛行タイプによる違いはあるかどうか。黒 (gliding & soaring) とオレンジ (flapping & bounding) を比べるとありそうだけど、全体的にはこの差は弱いようだ。

Fig. 4

生体の運動計測との比較というか validation 的なもの。

• A--C: A, B は zebra finch, pigeon の羽ばたき。C は gull の滑空。破線は Fig. 2 でやった「ひじを人が動かしたときの手首の動き」というカップリングの線。AとCはまぁいい。Bはカップリングの線が全然被ってないじゃんっていう。
• D--F: 3次元的な可動の方について。ただし gull は3次元RoMとってないので（なんでや？？？まぁ前の研究でも出せてないのかもだが）、ここに示してるのは zebra finch と pigeon の bending と、pigeon の twisting. N=4と多めの zebra finch の twisting を示さないのは謎すぎ。サプリにあるかとは思うが…⇒なかった。えー？本文になんか言い訳あるかな…

Fig. 5

進化のお話。

論文読み: Birds can transition between stable and unstable states via wing morphing

基本情報

• Article: Harvey, C., Baliga, V. B., Wong, J. C. M., Altshuler, D. L. and Inman, D. J. (2022). Birds can transition between stable and unstable states via wing morphing. Nature 1–6. https://doi.org/10.1038/s41586-022-04477-8 (open access)
• News & Views: Wissa, A. (2022). Trade-offs between stability and manoeuvrability in bird flight. Nature. https://doi.org/10.1038/d41586-022-00638-x

背景

• 飛行の機動性や安定性に効くのは aerodynamics と inertia があって、これまでの研究は主に aero にフォーカスされていたけど、今回は inertial properties にフォーカスした。これまではいくつかの種について散発的に調べられていただけだったが、今回は広い分類群にわたって 22種（36サンプル個体）について、博物館標本を用いて計測した。
• 質量については鳥の体を多くの基本要素に分割し、それぞれの要素について質量を計測・慣性モーメントを計算。たとえば風切羽は1本1本をさらに羽軸などに分割している（質量計測は1枚の羽根単位だが慣性モーメント計算の際は羽軸や羽弁まで考慮）。一方、ひじ関節と手首関節の可動範囲を計測（マーカをつけて OptiTrack というモーションキャプチャで撮影）。こうして、可動に伴う全体の重心（質量中心）位置の変化・慣性モーメントの変化というのをまず基本情報として出す。
• さらにこの重心位置変化と、別に計算した neutral point という空気力学的な代表点との位置関係から、ピッチについて機動性 (agility) と静安定の両方を計算している。最後に進化的な影響（淘汰圧を受けてきたか）を調べた。

結果

きれいに各 figure とサブセクションが対応していて、読みやすい。このような書き方は共同研究者もやっていて参考になった。

概要的な話

• Fig. 1 参照。
• 1a で力のつりあいや重心（質量中心）位置、慣性モーメントなどを説明
• 1c-1g にあるように、考慮しているのは基本的にひじ関節と手首関節の可動。肩関節は一応ザックリとだけ考慮（実測はしてない）
• 例として2つの翼可動状態が示されている。1c&d は手首を最大に開いた状態（150度くらい）、1e&f は手首をそこそこ閉じた状態（90度くらい）。いずれもひじは80-100度程度と中間的。

重心（質量中心）位置の変化は小さい

• Fig. 2 にまとまってる
• Fig. 2b（側面図）と 2c（上面図）の見方は Fig. 2 右上にある。つまり 2b で点みたいに見えるのが実は RoM で、複数あるのは個体差。
• 2b で点のように見えるってことは、前後・背腹方向への重心の変動は小さいということ
• 手首関節を開くと CG は前に移動する傾向。ひじもだが種による。
• 両関節とも、開くと CG は背側に移動する傾向。
• 2b で半透明の四角は「肩関節が仮に前後・上下に90度動いた場合」という保守的な仮定に基づく計算

慣性モーメントの変化は、ピッチは小さいがロールとヨーは大きい

• Fig. 3 にまとまってる
• ロール軸まわり () とヨー軸まわり () の慣性モーメントは大きく変化
  • 主にひじ関節による
  • Fig. 3b-3f は、「ひじと手首関節を最大に開いたとき、3軸回りの慣性モーメントに、体のどの部位がどれだけ寄与しているか」を種ごとに示している。
    • たとえば Lady Amherst's phesant（ギンケイ）のピッチ軸 () ヨー軸 () まわりの慣性モーメントは、尾羽が7割くらいを占めている。たしかにこいつは尾羽がメチャ長く、en.wp によると体長100-120 cmのうち尾羽が80 cmもあるとか。
    • 一方でロール軸まわり () は翼の寄与が当然大きく、とくに青の風切羽が（質量の割には）かなり重要なことがわかる。当然ヨーにも翼は効く。
• ピッチ軸まわりの慣性モーメント () の変化は小さい。ただし、肩関節による sweep は全く考慮していないことには注意。実際には sweep によって多少の変動はあるはずだ。

ピッチの agility 変化と、静安定性

• Fig. 4 にまとまっている。
• pitching agility の指標として、「迎え角が1度変わったときに角加速度が何 1/(s²) 変わるか」というものを提唱し、計算している。Method でのこれの計算は比例関係で終わっていて意味がわからない。イコールにするためには係数が必要だと思うのだが、それが1だとも書いてないし、比例記号はイコールの書き間違いだろうか？
• 22種中17種において、静安定の正負が翼（ひじと手首関節）の可動のみによって逆転しうると判明した。
  • 逆に言うと、5種 (23%) ではひじと手首関節の可動のみでは静安定性の正負を逆転できない。

静安定に対する淘汰圧

これは Extended Data Fig. 2-4 が対応しているようだ。おそらくセクションタイトル通り、静安定に淘汰圧がかかっている（きた？）かどうかということを知りたいようで、モデル選択みたいなことをしているようなのだが、自分にはなじみがなさすぎて、解説も全く無いため、ロジックは全然理解できなかった。

Ornstein Uhlenbeck model というのが Brownian motion よりも適合するとか言われてもそれが何なのか知らんしだからどうなの？？となった。

In evolutionary biology

The Ornstein–Uhlenbeck process has been proposed as an improvement over a Brownian motion model for modeling the change in organismal phenotypes over time.[13] A Brownian motion model implies that the phenotype can move without limit, whereas for most phenotypes natural selection imposes a cost for moving too far in either direction. A meta-analysis of 250 fossil phenotype time-series showed that an Ornstein-Uhlenbeck model was the best fit for 115 (46%) of the examined time series, supporting stasis as a common evolutionary pattern.[14] Ornstein–Uhlenbeck process - Wikipedia

なるほど。つまり「ランダムではなく自然選択の結果でありそうだ」ってことか。

用語の整理

• agility アジリティ…敏捷性？
  • axial agility: 並進加速度に関連
  • torsional agility: 角加速度に関連
    • 実際にはこの論文では「ピッチ角加速度を迎え角で微分したもの」もっと平易に言うと「迎え角が1度変わったときに角加速度が何 1/(s²) 変わるか」を pitch agility metric としている。
• manoeuvrability 機動性
• mobility
• static stability 静安定
  • 擾乱を受けた瞬間に、つりあい状態へ戻ろうとする（正）か、しない（負）か
  • static margin > 0 (when neutral point is behind the CoM) then stability is positive (= stable)
  • 正の静安定が強いとき、それに打ち勝つだけの空気力・トルクを出さないと姿勢変更ができないので、機動性は一般に低下する。
• dynamic stability 動安定
  • 擾乱を受けてから時間が経ったときに、つりあい状態へ戻る（正）か、発散してしまう（負）か
• partial eta-squared って何？？ refs 23, 24 を見よ、らしい。どうやら統計関係の論文のようだ。

手法関係の補足

Nature とはいえ article なので Methods もそれなりに書いてある。が、やはり supplementary information の方にかなりの分量があり、詳細はそちらを見ないと不明。

• 博物館標本（死体）のうち程度のよいもののみを使って、elbow（ひじ）関節と wrist（手首）関節の可動範囲 range of motion (ROM) を調べた
  • 回転は平面的な1自由度のみ？
• shoulder（肩）関節の可動は計測していない。また尾羽も furled（閉じてる）と想定。ただし Cheney et al., 2021 を cite してここも大事だとは気づいているよと付記。
  • 自分の論文もそうなので人のこと言えないのだが、マヌーバの話するのに尾羽考慮しないってのはけっこう辛さがある…と思ったらさすがに supplemental method 2 で粗いとはいえ尾羽の影響を見積もっていた。さすがにそうなるか。
• 慣性モーメントの変動に関しては R でプログラムを作成し、AvInertia と命名。過去の文献値と比較して validation している (Fig. 1h) 。
• neutral point (= aerodynamic centre) を求める際には空気力学の情報が必要になる。そこは別の論文 ( https://doi.org/10.1098/rsif.2021.0132 ) で開発されたプログラム MachUpX を使っているようだ。それは lifting-line theory の改良版のようで、low AoA (<= 5 deg) でないとあまり良くない模様。また、これは gull のみに関して使えるものであり、他の21種の結果は全て gull の結果から外挿している。個人的にはこの部分がこの論文のロジックで一番弱い点だと思う。当然著者たちもわかっていて、sensitivity analysis をして結論は変わらないだろうという主張をしている。それはたぶん妥当なのかなという気はする（きちんと追えてはいない）。

How to install & use VTKFortran (2022-03)

まえがき

リンク

• https://github.com/szaghi/VTKFortran ←これがVTKFortran
• VTKFortranをWindowsでビルドする - Qiita ← 時間経過でファイル名などが微妙に変わってるけど非常に参考になる

環境

• Ubuntu 20.04 LTS on WSL2 (Windows 10 Pro 21H2)
• Intel Fortran Compiler 2021.5.0（今回メインで使いたい）
• gfortran 9.3.0（今回はほぼ使わず）

モチベーション

Fortran で VTK を保存したい。Legacy は計算工学会の連載（ https://www.jsces.org/activity/journal/web_vol26no1_tutorial.pdf など）を参考に自分で書いたけど、これでは結局マルチブロックオーバーセットのための vtm.series を使えないことに気づいて絶望…。XML VTK を吐き出すには結局ライブラリ（公式でもサードでも）使うべきということで探したらこれがあった。

なお、計算工学会の方では其の五で公式ライブラリを C++ でコンパイルしてそこにアクセスしろみたいな感じのことが書いてたけど試してない。もしかしたらそっちの方がいいかも。公式だし…。

ところで python で動くので良ければ他にあるのは知ってて pyevtk を使っての Plot3D から XML VTK の変換は普通にできていた。でも「Fortran の CFD が吐き出したメッシュと流れ場（自分の場合 Plot3D）を python で XML VTK に変換」ってすると python の変換部分が死ぬほど遅くて嫌になった*1。計算中に直接VTK出した方がいいじゃんと。

Download

VTKFortran のドキュメント https://github.com/szaghi/VTKFortran/wiki/Download を信じてそのとおりに、

git clone https://github.com/szaghi/Lib_VTK_IO

とやると、./src/thrid_party/ 以下の submodules がインストールされない。git (github?) のこの仕組みをよくわかってないけど同じ作者の他のレポジトリを参照してるようだ。…という話はフォーラムを見ないとわからない→ https://github.com/szaghi/VTKFortran/issues/26#issuecomment-797308540

んで結局のところ、

git clone --recurse-submodules -j8 git://github.com/szaghi/Lib_VTK_IO

でよい（How to "git clone" including submodules? - Stack Overflow を参考にした）。

Installation

FoBiS.py のインストール

まず先に同じ作者が作った依存関係ソルバ？みたいな FoBiS.py というのを入れておくのがいいらしい → GitHub - szaghi/FoBiS: FoBiS.py, Fortran projects Building System for poor people

面倒なので自分は PyPI Installation, the Python Package Index · szaghi/FoBiS Wiki · GitHub にあるように pip で

cd ~
pip install FoBiS.py

と入れた。

さて、この直後に https://github.com/szaghi/VTKFortran/wiki/Compile にあるとおりに動作確認として

FoBiS.py build -lmodes

と打ち込むと、ドキュメントにあるような

The fobos file defines the following modes:
  - "shared"
  - "static"
  - "test-driver"
  - "shared-debug"
  - "static-debug"
  - "test-driver-debug"

ではなく、

The fobos file defines the following modes:
  - "shared-gnu"
  - "static-gnu"
  - "tests-gnu"
  - "shared-gnu-debug"
  - "static-gnu-debug"
  - "tests-gnu-debug"
  - "shared-intel"
  - "static-intel"
  - "tests-intel"
  - "shared-intel-debug"
  - "static-intel-debug"
  - "tests-intel-debug"

が表示される。ここもドキュメントの記述が古い…。

VTKFortran のインストール (compile)

というわけで、

cd Lib_VTK_IO 

はいいとして、ドキュメントどおりに

FoBiS.py build -mode static

とかやってもそんなオプションはない、と言われて終わる。ひどい。

FoBiS.py build -mode static-intel

とかやるのが正解。なんだが、Global name too long とか出てるな…大丈夫なのかこれ…

Test

prep.

インストール後のテストは VTKFortranをWindowsでビルドする - Qiita にだいたい書いてあるけど、この記事時点と微妙に変わってるようなので一応書いておく。

まずそもそもの親ディレクトリ名がデフォルトだと VTKFortran ではなく Lib_VTK_IO となっていた。それはいいとして、上記記事のとおりに

Lib_VTK_IO
├── src
│   └── main.f90
├── include
│   └── *.mod
└── lib
    └── libvtkfortran.a

と配置する。

また、テストファイルも /src/main.f90 というものはなく、以下のようになっている：

maz@mazSCAN:~/Lib_VTK_IO$ ll ./src/tests/
total 52
drwxr-xr-x 2 maz maz 4096 Mar  1 14:12 ./
drwxr-xr-x 5 maz maz 4096 Mar  1 14:12 ../
-rw-r--r-- 1 maz maz  507 Mar  1 14:12 vtk_fortran_use_module_basic.f90
-rw-r--r-- 1 maz maz 5205 Mar  1 14:12 vtk_fortran_write_pvts.f90
-rw-r--r-- 1 maz maz 8710 Mar  1 14:12 vtk_fortran_write_volatile.f90
-rw-r--r-- 1 maz maz 3654 Mar  1 14:12 vtk_fortran_write_vtm.f90
-rw-r--r-- 1 maz maz 3652 Mar  1 14:12 vtk_fortran_write_vtr.f90
-rw-r--r-- 1 maz maz 3033 Mar  1 14:12 vtk_fortran_write_vts.f90
-rw-r--r-- 1 maz maz 4150 Mar  1 14:12 vtk_fortran_write_vtu.f90

vts (structured grid)

vts（構造格子）用のテストは vtk_fortran_write_vts.f90 だ。自分の場合は ifort を使いたいので、

$ ifort ./src/tests/vtk_fortran_write_vts.f90 -Iinclude -Llib -lvtkfortran
$ ./a.out

とすると、XML_STRG-raw.vts および XML_STRG-binary.vts が出てきた。どっちかを ParaView にドロップすると開ける。 Qiita と同じような表示をするには、Contour を出してから Isosurfaces を一旦 Remove して（赤いバツマーク）、Add a range of values（メモリみたいなアイコン）を Generate するとよい。

vtm (multiblock)

同様に、マルチブロック用のテストは vtk_fortran_write_vtm.f90 なので、

$ ifort ./src/tests/vtk_fortran_write_vtm.f90 -Iinclude -Llib -lvtkfortran
$ ./a.out

とする。すると、XML_STRG.vtm および XML_STRG-01.vts ... XML_STRG-04.vts が出てくる。XML_STRG.vtm を ParaView にドロップすると開ける。

visualisation of a vtm test in VTKFortran (as of 2022-03-01)

利用

（かきかけ）

概要

基本的にサンプルコードを改変すればうまくいく。

VTK xml 用のモジュールには以下の4つを作った：

  private :: write_data !! サンプルコードを改変
  public :: write_vts_xml_multi !! サンプルコードを改変
  public :: write_vtm !! 自作
  public :: write_vtm_series !! 自作
  public :: write_vtm_series_finalise !! 自作

要は vts だけ VTKFortran で書き出して、vtm や vtm.series は自分で書いてみた。 vtm も VTKFortran が提供してるっぽかったけど覚えるのが面倒で…

コンパイルと実行

実際にはちょっと違うけど、概ね、

$ ifort ./src/main.f90 -xHost -qopenmp -Iinclude -Llib -lvtkfortran
$ export OMP_NUM_THREADS=6
$ time nohup ./a.out > log.txt 2>&1 &

のような感じで。

ところで XML VTK "ASCII" でよくね？

研究室の計算機が古くて、ライブラリのインストールができなさそうだった。そこでふと、ASCII ならライブラリとかいらなくね？と思っていつものVTK公式PDFと PENGUINITIS - VTK ファイルフォーマット を横目に見ながら書いてみたらアッサリできてしまった。Frotran だけで。容量や速度的にバイナリより悪いだろうけど、とりあえずこれでいいかも…

*1:もちろん自分の python スキルが足りないのだろうが、そこは置いておく。

GH: convert a Referenced Surface to a Surface

I encountered an issue related to the Referenced object (surface) in the following situation:

1. Launch a Rhino instance, place a surface.
2. Launch a GH instance, place a Surface and choose the surface in the Rhino. If you check this with a Panel, it'll be shown as a Referenced Surface.
3. Export the surface to a GHdata file via Data Output component.
4. Open another Rhino instance, and open another GH instance.
5. Import the saved surface via Data Input component from the GHdata file.
6. In this 2nd GH file, the Referenced Surface is recognised (you can check with a Panel) but the preview won't actually show up in the 2nd Rhino window. Oops...?

I'm not 100% sure why this is happening but I suspect that for a "referenced" geometry to work, the corresponding object must be available in THE Rhino file that corresponds to the current GH file. The easiest solution came up to my mind is to convert the Referenced Surface in the 1st GH file into something else (before Data Output)... an "actual" surface. There may be many ways for this and perhaps the right way is to use GH_Convert.ObjRefToGeometry Method (GH_Convert.ObjRefToGeometry Method) but I just wanted to be simpler... and tried something else.

1. Pass the Referenced Surface to Deconstruct Brep component. The "Faces" output shows the corresponding surface (Untrimmed Surface in my case). Happy.
2. Somehow the Deconstruct Brep messes up the tree structure, so use the Path Mapper if you want, and choose Create Trim Mapping by right-clicking ((Trim Tree doesn't work here, as it's the innermost branches not the outermost branches that are added by the Deconstruct Brep.)).

I haven't tried the similar method for other object types such as Brep or Line or Points, but hoping something similar might work (or, I should probably actually use the GH API Method above... I know...).

Hope this helps to somebody having hard time in treating Referenced object with Data Output/Data Input...

2020 以前の ANSYS student のライセンス更新方法（2021-08時点）

まえがき

家では student バージョンで軽いテストをすることがあるけど、自分はまだ 2019 R3 を使っている（大学で使ってるバージョンとの兼ね合い）。しかし student はライセンスが1年しかもたないので更新が必要。最近になって注意が必要な変更があったのでメモ。

要は

How to Renew Ansys Student Product License — Ansys Learning Forum を見ると良い。

もう少し詳しく

ライセンスの更新は以前から「新しい ANSYS student のパッケージをダウンロードして、中にあるライセンスファイルを取り出し、古いライセンスファイルをこれで置き換える」という方法だった*1。この手順自体は変わっていないが、「新しい ANSYS student」として以前ならその時点の最新版で良かったのが、2021 R1 で変更が入ってライセンスファイルが隠蔽されてしまったため、敢えて一つ古い 2020 R2 をダウンロードしろ、ということになった。

手順

ぜんぶ上のフォーラムに書いてあるが、

1. Download Ansys Student | Workbench-based Simulation Tools の Prior Releases から DOWNLOAD ANSYS STUDENT 2020 R2 を選ぶ。
2. 解凍し、student フォルダの WINX64.7z を解凍する。shared files > Licensing にある student.lic が新しいライセンスファイル。
3. 古いライセンスファイルは C:\Program Files\ANSYS Inc\ANSYS Student\Shared Files\Licensing にあるので、新しいもので置き換える。

UPDATE 2022-02-16

残念ながら、ライセンスファイルを取り出す方法はもう全く使えなくなってしまったようだ： https://forum.ansys.com/discussion/comment/129094/#Comment_129094

*1:たった数キロバイトのライセンスファイルのために何GBものファイルをダウンロードすることの無駄さ、という話もフォーラムで出ているが、ここでは関係ない

ANSYS Meshing で multibody part のとき「ボディ1つだけ選択」と「複数ボディを選択」ではメッシュが変わる

マニュアルには書いてあるのかもしれないが、気づかなかった。かなり衝撃的…。

左：bodyを1つだけ選択してメッシングした時。右：2つ選択してメッシングしたとき。右の body のメッシュがぜんぜん違う。

接触している場合に順番に依存する（すでにあるメッシュに適合するように次のメッシュが作られる）のは直感的にもわかっていたが、まさか「直接は接触していない body 同士」でも「body を1つ選択してメッシングする」のと「body 2つを同時に選択してメッシングする」ので結果が変わるとは思っていなかった。想像の埒外だった。

なお DesignModeler に戻って Multibody part をやめてみたら、この挙動はなくなった。つまり multibody part に伴う現象のようだ。他の設定は色々といじってもこの挙動には影響しなかった。