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 Advances5, eaaw6670. https://doi.org/10.1126/sciadv.aaw6670
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)
これは 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
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
とする。すると、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)
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.
Export the surface to a GHdata file via Data Output component.
Open another Rhino instance, and open another GH instance.
Import the saved surface via Data Input component from the GHdata file.
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.
Pass the Referenced Surface to Deconstruct Brep component. The "Faces" output shows the corresponding surface (Untrimmed Surface in my case). Happy.
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...
左:bodyを1つだけ選択してメッシングした時。右:2つ選択してメッシングしたとき。右の body のメッシュがぜんぜん違う。
接触している場合に順番に依存する(すでにあるメッシュに適合するように次のメッシュが作られる)のは直感的にもわかっていたが、まさか「直接は接触していない body 同士」でも「body を1つ選択してメッシングする」のと「body 2つを同時に選択してメッシングする」ので結果が変わるとは思っていなかった。想像の埒外だった。
なお DesignModeler に戻って Multibody part をやめてみたら、この挙動はなくなった。つまり multibody part に伴う現象のようだ。他の設定は色々といじってもこの挙動には影響しなかった。