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
これは 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. 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.
Ornstein–Uhlenbeck process - Wikipedia
maz@mazSCAN:~/Lib_VTK_IO$ ll ./src/tests/
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
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...