s2e-core
s2e-core copied to clipboard
Create data/external dir & move GeoPotential files
Related issues
- #611
Description
ExtLibraries/GeoPotential
is not library. Just a data.
So, it should be move to data
dir.
- Create
data/external
dir - Move
ExtLibraries/GeoPotential
todata/external/geo_potential
- Merge
scripts/Common/download_EGM96coefficients.sh
intodata/external/geo_potential
- Add
EXT_DAYA_DIR_FROM_EXE
virtual environment value for config files- So, S2E read
data/external
files directory - No longer need to "build" and "install" step
- So, S2E read
Test results
Provide the test results and a link to the detailed results log.
Impact
Users should be migrate ExtLibraries/GeoPotential
path reference to EXT_DIR_FROM_EXE/geo_potential
修正提案ありがとうございます。
今の状況ですが、
-
ExtLibraries/cspice
の中にもde430.bsp
など、天体に関するデータは含まれている -
ExtLibraries/nrlmsise00
の中にもSpaceWeather-v1.2.txt
などの天体に関するデータは含まれている -
ExtLibraries/LunarGravityField
も同様に存在する -
data
の中に外部から落としてきたデータを入れる場合は、initialize_files/gnssのような場所に入れようとしている
という感じです。なので、Geopotential
だけ動かすのはそれはそれで整合性が取れなくなるかなと思います。
今の分類の方針としては、
-
ExtLibraries
には、- 外部からソースダウンロードしているライブラリに関連したデータを保存している
- cspice, nrlmsise00
- ほとんど更新が必要にならない(ユーザー毎にファイルが変わらない)データを保存している
- cspice, geopotential, lunar gravity
- nrlmsise00は更新しなくてもよい使い方も考えられるが、場合によっては1日毎に変更できるファイルもあるので、少し微妙
- 外部からソースダウンロードしているライブラリに関連したデータを保存している
-
data/initialize_file
には、- 必須ではないし、シミュレーション条件によって頻繁に変わるデータが保存される(data内はユーザー毎に自由度高く編集される想定)
- gnss、thermal、コンポーネントの詳細データなど
- しかも、iniファイル内でどのファイルを参照するかを決めている
- 必須ではないし、シミュレーション条件によって頻繁に変わるデータが保存される(data内はユーザー毎に自由度高く編集される想定)
という感じになっていると思います。
方針を変更して整理する場合、次のような特性を考慮して分け方を考えた方が良いのかなと思います。
- 必須データかどうか
- cspiceは必須
- 他はiniの設定によってなくても動きはする
- ユーザー毎に変わるものか、高頻度に変わるものか
- cspice, geopotential, lunar gravityはそんなに高頻度で変わらない
- gnssはユーザーのシミュレーション対象時期によって高頻度に変わる
- nrlmsise00は両者の中間で、高頻度で変わらない平均値的なファイルもあり得るし、1日毎に変わるファイルもあり得る
この特性を踏まえて、data
ディレクトリ配下に置くべきなのかなどを議論するのが良いかなと思います。
また、ここに出てきておらず、みてみぬふりをしているものとして、src/library/external/igrf/igrf11.coef
などもあります。次のような特性を持っていますが、これを機に別に移動させても良い気もします。
- これは性質としてはgeopotentialとかに近い
- 5年に一回更新されるので、geopotentialなどよりは高頻度
- 参考にしているigrfコードに紐づいているので、伝統的にこの場所に保管されている
はい.これはその通りで,あくまで最初のミニマルな改善提案だというのと,単にレビューコストを下げるためにパッチを分割していただけです > Geopotentialだけ動かすのはそれはそれで整合性が取れなくなる
必須データかどうか,によって分け方を考えた方がよい,というのはあんまりわかっていないです. これはディレクトリの分割方針というよりかは,ドキュメントやスクリプトの責務な気がしています. 例えば,「標準的なファイルだけまとめてダウンロードする」みたいなスクリプトはあってよいと思いますが,ディレクトリとは別の話かなと.
データのライフサイクルという観点だと,今重要なのは「ビルド前に(操作が)必要か(ビルド時に必要なライブラリのダウンロード)」「ビルド時に必要か(リンクする)」「実行時に必要か(初期化時に読み込む)」という区別が重要だと考えていて,この PR は実行時に必要なモノをすべて data
に移動したい,というアイデアです.
あー,なるほど.S2E user ごとに管理するべきものと,各シミュレーションケース(ex: data/sample
)毎に管理すべきデータがあるのではないか,という話か.理解しました. > 頻度
ということであれば,data
ディレクトリに置くべきかどうかの議論,というよりは,data
ディレクトリのどこに置くべきか,という議論をするのが建設的な気がしますね.そうなるとここでも external
はちょっと一般的すぎて微妙な命名かもしれません.
とりあえず Issue 立てました: #613
データ関連ファイルは次のような分類になると思います。
- どのs2e-userでも共通のもの
- geopotential, lunar gravity field, igrf.coef, de430.bspなど滅多に変わらないもの
- s2e-user毎に変わるもの
- gnss, 宇宙天気, thermal, コンポの特性CSVファイルなど、衛星が変わると変わるもの
- satellite.ini、structure.iniなどはこちらに入るかもしれない
- ユーザー一人一人がその時々に変える可能性があるもの
- シミュレーション開始時間、log取得頻度、ノイズ・外乱の大きさなどいわゆるiniファイル
これまで、s2e-coreをsubmoduleとして取り込まない場合も想定しており、ExtLibraries
は複数のs2e-userで共有される可能性があったので、どのs2e-userでも共通のもの = ExtLibraries
となっていました。
今はs2e-user内でsubmoduleでs2e-coreを取り込み、それぞれでExtLibrariesを生成することを推奨しているので、どのs2e-userでも共通のもの
という分け方にこだわる必要もないのかもしれません
data ディレクトリのどこに置くべきか,という議論をするのが建設的な気がしますね.
そうですね。基本的にはそれに賛成です。
ただ、唯一気になっているのはExtLibraries/cspice
とcspice/de430.bspなど
が同じcspiceでまとまっている方がわかりやすいかもしれないという点です。de430.bsp
などは中身を見てもよくわからないspice専用データで、これがExtLibraries/cspice
と近くに配置されてることはある程度見やすさの観点でありかなと思ったりもします。この辺りは広く意見を聞きたいです。
これを気にせずにdataに集約するなら、次のような分類分けが今の構成を自然に拡張できるかなと思っています。
- data
- logs
- initialize_files
- simulation_base
- environment
- gnss.ini
- gravity_field
- geopotential, lunar gravity field
- magnetic_field
- igrf.coef
- space_weather
- SpaceWheather.txt
- cspice
- de430.bspなど
- gnss
- sp3ファイルなど
- hoge_satellite
- satellite.ini
- structure.ini
- local_environment.ini
- disturbance.ini
- thermal_csv_files
- components
- いろんなiniファイル
- コンポーネントによってはCSVファイル
- fuga_satellite
- hoge_ground_station
- ground_station.ini
- components
- antenna.ini
- antenna_pattern.csv
@sksat こちら、上の提案でよければ私の方で全て整理しますがいかがでしょうか?
なるほど,これは特に考えていなかったです & s2e-core を取り込む想定でよいと思います > s2e-coreをsubmoduleとして取り込まない場合も想定
これには明確に反対の立場です.出自とカテゴリが似通っているというだけで,ビルド時に使うモノとランタイムに使うモノはデータのライフサイクルが異なるからです.これらのデータの場所を固定することによって ini ファイル内で s2e-core のディレクトリ構造や実行時のパスからの s2e-core へのパスなどを考慮しないといけなくなってしまうのはユーザ体験が非常に悪いと感じています. > ExtLibraries/cspice
とcspice/de430.bsp
などが同じcspiceでまとまっている方がわかりやすいかもしれない.
initialize_files
ディレクトリは不要な気がしますが,基本的にはそのような分類を行うことに賛成です. > 次のような分類分け
「初期化のためのファイル」みたいな分類をディレクトリ単位でする必要はそんなにないのでは,とは思っています.入力・出力にそれぞれたくさんのファイル・ディレクトリがあるのであればまだしも,出力ファイルは logs
に出ることが明らかですし.
「初期化のためのファイル」みたいな分類をディレクトリ単位でする必要はそんなにない
逆にinitialize_files
ディレクトリがあるデメリットや、なくなった時のメリットなどを教えてください。
ちなみに私としては、シミュレーション設定のためのファイルが一つのディレクトリにまとまっている方が各種説明を行う時に楽ですし、設定のコピペなどもまとまっている方が楽など、ディレクトリ分けした方がメリットがあると思っています。