# 39th Workflow Meetup (2021-04-12 Mon)
================================

[20210412 · workflow\-meetup\-jp/workflow\-meetup Wiki](https://github.com/workflow-meetup-jp/workflow-meetup/wiki/20210412)

2021-04-12(Mon)
13:00 - 19:00 まで。

完全リモートのため、全世界どこからでも参加可能。

# 事前計画

## 全体

- 池田さんより、CWL定義ファイルに stderr や stdoutのキャプチャをする設定をしておいた場合、意図せず
- cwltoolの内側で失敗したときに、うまくキャプチャできない。ログが吸い込まれてしまう。
- ジョブスケジューラと連携も考える。
- SGE系だと、STDERRに出力すると、exit status が O でも、エラー。
- 標準出力に出した
- https://www.gisaid.org/
- https://www.gisaid.org/hcov19-variants/

## 石井

- 次回日程を決める
- 5月10日を希望したいです。12日か

## 西田

- Rcwl(https://www.bioconductor.org/packages/release/bioc/html/Rcwl.html) と RcwlPipelines(https://bioconductor.org/packages/release/bioc/html/RcwlPipelines.html) を使ってみる

## 丹生
- ep3 いじり

## 坊農

- pitagora-cwlを一部使わせていただいて論文出しました。ありがとうございました。
- Meta-Analysis of Oxidative Transcriptomes in Insects. https://doi.org/10.3390/antiox10030345
- Systematic Analysis for Quantification of Expression (SAQE) https://github.com/bonohu/SAQE
- 今後、非CWLの部分のCWL化を進めたい
- salmonなど新しいバージョンのcommand line toolを使ったワークフローをSAQEのrepoにアップしていくでよい？
- `「良い」` とおもいます（一同）
- sra-tools の prefetchをつかっているから、CWL+singularity環境の場合問題がおこる可能性あるかも（おおたさん）

## 池田

# こうなりました

## 全体

- 次回2021年5月12日水曜日
- [20210512 · workflow\-meetup\-jp/workflow\-meetup Wiki](https://github.com/workflow-meetup-jp/workflow-meetup/wiki/20210512)

2021-05-12(Wed)
13:00 - 19:00 まで。
ただし、西田さんが１７時までなので、第１回ラップアップを、１６時半から行う。

完全リモートのため、全世界どこからでも参加可能。

### sapporoとCWLの話

この部分の記述を読む前に、おおたさんの本日の作業記録を書いてあることを読んだほうがよいです。
こちらは石井が会話を全部かきとめたかんじなので。

- かくざきさんの画面を見ながら以下の作業
- 知らない人は、ドキュメントをみながら作業ができるのか
- ドキュメントの修正
- [ ] Getting Startedのスペルミスおよび登場箇所の修正
- [ ] `jq` のインストールについての記述
- [ ] docker-compose に`-d` がない理由の説明が必要
- [ ] 別窓をひらいてcurlを実行しましょうの記述追加
- [ ] WESについて読む必要がある
- [ ] 最初に実行できるワークフローがあることの記述
- [ ] 別ブランチからマージしてももんだいないことの確認（おおた）
- [ ] WFの準備の仕方として `git clone`の必要がないことの記述
- [ ] 準備する必要があるファイルと、準備する必要がないファイルの記述
- [ ] `cat` の記述がわかりにくい
- [ ] 準備する必要があるファイルとして以下の２つ
- [ ] `workflow_params.json`
- [ ] `workflow_engine_params.json` こちらはjsonでからだけど必要。echoで、作成する方法を記述
- [ ] WFはURLを教えてあげると、sapporoがとりにいってくれることを記述
- [ ] ダウンロードしてしまうと、相対パスが解決できないので、リモートURLの指定が必須
- [ ] curlでserviceにポストすることは何かを書く。
- [ ] curlでserviceにポストする部分で、tags.jsonが必須でないので、直前までの説明で、tags.jsonを省いた場合は、curlでポストの例でも、はぶいておく
- [ ] 実行結果は、sapporo-service以下のrunの中にできる。確認したいなら、別のディレクトリに移動する
- [ ] WESについての深い話は、sapporo-serviceのREADMEのしたにある。（ほかにもあるかもしれない）、Getting Startedの先頭の方にかいてあってもよいかもしれない
- [ ] runidの説明について
- [ ] 実行するたびに違うidがふられるUUIDであることは書いておいたほうが良いだろう。UUIDのバージョンは 4?5?とかは、さらっとあるとうれしい人もいるかもしれないが、Getting Startedレベルかは不明
- [ ] swagger APIについて、リンクがあるか確認する
- [ ] sapporo-webは、chromeだと動くことはかいてあるが、ほかのではうごかないかもしれないので、ほかので動かないときは、chromeを推奨するように書く
- [ ] jq `.outputs` の部分を `.run_log.stdout` にするなどの例もかく。このとき指定できるのは、swagger API の　Modelで確認できる
- [ ] 簡単にかけるなら、cwltoolの出力としての改行も正しく取り扱えるコマンドをのせておく
- [ ] sapporo webで登録できるAPIサーバーは、ローカルだけでなく、遺伝研上
- [ ] sapporo webで投げたくなるドキュメントを書く
- [ ] Register Serviceをしたときの次くらい？に書く
- [ ] 登録してあるものを動かすの次が、githubにあるもの（さっきのcurlのやつ）を実行する
- [ ] コピペするべき、WFのrawのURLを、コピペしやすい位置に書いておく
- [ ] serverの名前と、WFの名前は、別にしておいたほうがよいことを書いておく。
- [ ] WFの名前は、それっぽいタスクなどの名前にする
- [ ] 入力ファイルを渡す方法の記述（Getting Startedではないかもしれないけど）
- [ ] Register Workflowの手順を記述する
- [ ] WFの指定
- [ ] WFエンジンの指定
- [ ] WFエンジンパラメータと、tagsは空でよい
- [ ] attachement に、URLだけでなく、ローカルからアタッチする方法もあること、そのやりかたの記述
- [ ] YAMLで記述する方法を紹介したほうが良いだろう。JSONで書くのは、人類の大部分の人にはむずかしいため。
- [ ] sapporo web の "Workflow Attachment as File" にファイルをアタッチする方法を書く
- [ ] アップロードするファイルの制限は、どこで行われているか。
- [ ] nginxとかにも制限がある可能性がある。数十GBあるようなファイルを扱いたいとき
- [ ] S3におけば、S3からおとすという方法がある。
- [ ] 数十GBあるようなファイルはWESの仕様としては、アタッチするしかないのだが、sapporo web としては、現実として使えるようにどこかにあげたものをURLで指定できるようにしたということの記述
- [ ] アップロードしたものは、runディレクトリの中にあることの記述もしておいた方が良いだろう
- [x] かくざきさん
- [x] special thanksてきなところに名前を載せても大丈夫か？
- 問題ないです！（角崎）
- [ ] Workflow Meetup
- [ ] special thanksてきなところに名前を載せても大丈夫か？
- [ ] かくざきさんより
- [ ] Getting Startedにいきつかなかった
- [ ] `curl` をどのターミナルの窓に打つか
- [ ] `jq` は普通はいっていない。
- [ ] prepare to run a workflow
- [ ] ファイルのリンクがあったらダウンロードしちゃうよね
- [ ] フォルダの構造があるとうれしい
- [ ] APIがいまいちなにをしているかわからない。（何かがサーバー側でうごいていることは感じれたので、よいといえばよい）
- [ ] サーバーに詳しい人が前提だろうという印象
- [ ] WES Servicesには走らせたいWFがある
- [ ] Runsには、実行結果
- [ ] おおたさんより
- [ ] sapporo serviceとsapporo webの連携などを図示したほうがよいのではないか。
- [ ] WFやサービスの名前のつけかたの指針がドキュメントにあったほうがよいだろう。同じ名前はよくない。わかりづらいので。
- [ ] おおたさん、すえたけさんより
- [ ] 実行したWFのインポート機能をつけてもよいのではないか。
- [ ] ドキュメントengine parameterとtagsは、隠しておいてもよいかもしれない
- [ ] 現状、すえたけさん、いしい以外はほとんど使う人はいないので、大きな面積を確保しておかず展開できるようにしておいてもよいかもしれない
- [ ] singularity対応について
- [ ] 現状の推奨
- [ ] dockerであることは間違いない
- [ ] ローカルインストール可能
- [ ] run.shをいじる。
- [ ] HPC向けにsingularityで実行する方法があってもよい。
- [ ] singularityの辛さ
- [ ] singularityはデフォルト、HOMEディレクトリをマウントしてくれるし、仮想ファイルシステム的なところにかくわけではない
- [ ] 特定のbioinformaticsのツールとsingularityのコンビネーションが悪い可能性がある。
- [ ] sapporoを強制することで、SSHとかしちゃだめだみたいなことができるかもしれない。
- [ ] データだけ指定してもらって、特定のWFを回すことも可能だろう。
- [ ] 全データがS3にあれば
- [ ] Galaxyとの違いについて
- [ ] Galaxyは実績もあるが、sapporoを使う理由。
- [ ] stderrのダウンロードの方法をかいたほうがよいだろう `download_logs` について

### CWL の stderrやstdoutは、どこでキャプチャするのがよいか？

異常終了時のエラーのメッセージをみたい。

- ツールがエラーを起こすと、cwltoolが落ちるとstderrが回収できない
- stderrがエラー以外のものを出力しているという現実がある
- WORKAROUND
- CWL定義内でstderrをファイルに記述する部分をコメントアウトする
- 結局これがいまのところ
- cwltoolとしての出力も極力減らしておく、 `--quiet` をつけるとか、 `--verbose` を切っておくなどと併用。
- 地道にログをみる
- cwltoolの前提
- 出力オブジェクトのみが、stdoutに出力され、それ以外がstderrに出力される
- cwltoolでのみ起こるのだから、toilで確認しても、それは違うものになってしまう可能性が高い
- 結局cwltoolで実行したほうがよい。
- エンジン開発的な観点からすると
- エラーログが小さいという前提なら可能な処理も、エラーログが３GBとかあるとか、さらにそれが、言語のオブジェクトになっているとさらにファイルサイズが大きい。

通常の場合

- エンジン側が正しい挙動するならば、CWL定義内に書いておいてよい
- パスが同じになるように自分でかいているとか、そういうのはないとする。
- 各ステップの標準出力、標準エラーは、内部表現の話になるので、ユーザーからは直接見えない
- なので、エンジン側が適当な名前でつくってもよい
- エンジンとして最終的に整合性がとれていればよい考えることができる。

池田さん含め一般的な感想

- cwltoolでだいたい動くことがわかっているツールは、 cwltoolを使うと便利
- よくおこる失敗は、パラメータで渡すファイルを間違える。
- formatについて
- 書いてあっても、現状はつかわれていない
- make templateしても出力されないので、自分でもう１度書く必要がある
- 仕様上は、formatのバリデートの必要がかかれていない
- 実装によっては適当なものを書いてもとおってしまうだろうし、きちんとチェックしているものもあるだろう
- cwltoolがチェックしているのは、cwltool固有の実装であって、仕様ではない
- 未確認だが、例えば、SAMとBAMであれば共通の概念を指定することが可能
- [EDAM \- Bioscientific data analysis ontology \- Alignment format \- Classes \| NCBO BioPortal](https://bioportal.bioontology.org/ontologies/EDAM/?p=classes&conceptid=http%3A%2F%2Fedamontology.org%2Fformat_1921)
- そもそも、ファイルを指定してそのファイルの形式が正しいかをチェックするようなツールがない
- bio\* 系だと、読めるまで読む。
- GFFはvalidatorがある。
- bioinformaticsらしいといえばらしいケース
- fastaをgzipされたものの扱いとか。
- Galaxyは、そのあたりもよしなにやってくれる。
- ツール単独の時間の計測などにはむいていないこともある。
- 前処理、後処理で対応しているようだが、ログには出力されない？ログ

### singluarity

CWL+NCBItools+Singularityだと起こる問題で
NCBItools+Singularityではおきないし
CWL+NCBItools+dockerではおきない

- 環境変数でいろいろわたさせるのだが、HOMEのオーバーライドして指定ができない。
- ツールの前提として、HOME以下に書き出すので困ることがある。
- cwltoolとしては、隔離された環境を作ることができない

[2\.10\.3 brings vdb\-config \-\-interactive nightmare · Issue \#291 · ncbi/sra\-tools](https://github.com/ncbi/sra-tools/issues/291)

インタラクティブが強制発動する＞これを回避する方法が提案された＞rootでないと動かない方法だった

## 石井

- 次回日程を決めた
- その次は6月2日を希望したいです。
- ２０２１年度は、月の第一週の水曜日１３時スタートの方向。ただし、月曜日など他の日になるかもしれないです。
- 既存のツールを組み合わせただけのワークフローで、ジョブファイルを書き換えたら別の研究ができたという事例が紹介された
- もう１回あれやるのやだなぁ、という系統の作業をコードゼロで解析できた。
- 得られたTIPS
- 変更が予想されるパラメータをそとにだしておく必要があるかもしれない
- サブワークフローにしてパラメータをふって、全通り対応させるのも楽だった

## 西田
- RcwlとRcwlPipelinesのvignetteに加え https://liubuntu.github.io/Bioc2020RCWL/articles/Bioc2020RCWL.html もやってみて下記の問題に確信を抱いた


> atls <- cwlUpdate()  ## sync the tools/pipelines
Update scripts...
trying URL 'https://github.com/hubentu/RcwlRecipes/archive/master.zip'
downloaded 316 KB

Error in cwlProcess(baseCommand = "table_annovar.pl", requirements = list(req1,  : 
  could not find function "cwlProcess"

- 確信を抱いたので https://community-bioc.slack.com/ の rcwl チャンネルで報告した。(GitHubでissueを作るのがめんどいと思う人はこれがいいかも。)

### Rcwlのshinyアプリ

e1 <- InputParam(id = "flag", type = "boolean",
                 prefix = "-f", doc = "boolean flag")
e2 <- InputParam(id = "string", type = "string", prefix = "-s")
e3 <- InputParam(id = "option", type = "string", prefix = "-o")
e4 <- InputParam(id = "int", type = "int", prefix = "-i", default = 123)
e5 <- InputParam(id = "file", type = "File",
                 prefix = "--file=", separate = FALSE)
e6 <- InputParam(id = "array", type = "string[]", prefix = "-A",
                 doc = "separated by comma")
mulEcho <- cwlParam(baseCommand = "echo", id = "mulEcho",
                 label = "Test parameter types",
                 inputs = InputParamList(e1, e2, e3, e4, e5, e6),
                 stdout = "output.txt")
mulEcho

inputList <- list(option = c("option1", "option2"))
app <- cwlShiny(mulEcho, inputList, upload = TRUE)
runApp(app)

こんなコードで下記のようなshinyアプリが立ち上がる。

これを使うと、パラメーターだけを変更してそのcwlをrunするだけの環境をユーザーに提供することが可能となるようだ。

## 丹生
- 就職できました。
- 4月から遺伝研勤務になります。
- NII にも籍はある
- ep3 のデバッグ
- ep3 内で動かしている medal が何故か終了しない
- ログを見ると、medal の処理自体が途中で止まっているように見える
- medal 単体で同一コマンドを動かすと正しく終了してくれる
- 何が原因か？
- ビルドオプションの違い？
- release, debug 両方で再現
- musl libc と static link してるのが原因？
- これから検証

## 角崎
- SapporoのGetting Startedのハンズオンをやった
- https://github.com/ddbj/sapporo/blob/master/docs/GettingStarted.md
- 初心者用のQiita記事を書きたい
- Special thanks問題ないです！
- protein系のツールのCWL化をちょっと書いた

(石井記述：すえたけさんよりghcrがよい。[Packages · Bioinformation and DDBJ Center](https://github.com/orgs/ddbj/packages)。Github Actionを書くだけで良い。わからなかったら、docker channel で質問してもらえると、このあたりどこがよいかをみんなさぐっている)
(丹生追記: ghcr.io の公式のドキュメントは[こちら](https://docs.github.com/en/packages/guides/container-guides-for-github-packages)。似たものに package registries がありますが、こちらは沼にハマることになるので触らないほうがいいです)

## 大田

- Sapporo: Getting started の dogfooding w/ たろうさん
- docker-compose を -d しない理由, 別窓で開く必要性
- jq へのリンクとインストール方法を書いておくべき
- post で投げるときに準備が必要なファイルとそうでないファイルがわかりにくい
- `cat` の例がわかりにくい（これを実行するものだと思ってしまう）
- フォルダ内の構造があるといいかも
- `tags.json` はいらないんじゃね疑惑
- `uuid` を変更する必要ありです
- `run_id` に対する説明がない
- `POST to run a workflow` でわかるのか (もっといい見出しがあるかも)
- RESTful API の routing についての簡単な説明があってもいいのか
- 'workflow を register する' という概念について
- 'preregistered' という概念について
- GUI には複数の service を登録できるよという説明
- GUIのデモに使うワークフローのURLを文字列としてコピーできるようにしておく
- `workflow_engine_parameters` と `workflow_params` がわかりにくすぎる問題
- 試しにやるときに "こういう名前をつけましょう" とするのがよい
- singularity 対応？
- vs Galaxy?
- 「Galaxyの二番煎じじゃん」と言われたらどうディフェンスするのか
- そもそも Galaxy がヘボいと思って作ったものではない、Galaxy は最高
- Sapporo の
- [目的] 色々の言語で書かれたワークフローを再利用したい
- 言語の実行方式等々を勉強したくない、ワークフロー指定してパラメータ入れたら走ってほしい
- [解決策] 異なるワークフロー言語間の「実行形式」の標準化
- [実装] GA4GH WES API に準拠してランナーを縛らない実装を作った = Sapporo
- めも：FSにバックアップを任せられるのが最高
- CWL成功事例
- 某研究プロジェクトで「あのパラメータで試してなかった」「このパラメータ全通りやる」がめちゃくちゃスムーズでした、自分の書いたスクリプトだったらコードまで読みに行かないとパラメータをどう変更すればいいかわからなかったりとかがよくある、スペックがある安心感……
- NCBI sratools 地獄の話
- https://github.com/ncbi/sra-tools/issues/291
- 混ぜるな危険
- `$HOME/.ncbi` に勝手にかつインタラクティブに config を作らせる NCBI sratools
- 予め config を作っておく方法でインタラクティブ強制は回避可能だが `$HOME` 以下しか許さないという縛り
- ホストのFSから切り離された環境で実行したい CWL
- `$HOME` をホストの環境そのままで実行したい singularity
- こういう問題が起きる https://github.com/pitagora-network/pitagora-cwl/issues/38#issuecomment-803378567
- ENTRYPOINT 使って $HOME 以下に config を作る workaround を実装することで docker ユーザ権限実行はいけるようになった
- https://github.com/inutano/docker-sra-toolkit/blob/fcafeb0ef1e240062acf60e1ba6c57ebeeb6be86/sra-tools/Dockerfile#L7

# 末竹

- taro-san を読んで、sapporo を触ってもらった
- WES を知らない人に説明することの大変さ
- なんなら bioinfo がわからない人に説明することも多いため、いつも辛さを感じている
- 書類仕事とか、細々とした何かしらをやっていた

# 池田

- Sapporoのハンズオンがとても興味深いものだった
- cwlについていろいろ話を聞くことができて良かった

# 後藤

- Singularityについて調べたり
- BioConductorのslackを見たり
- 計算機システムの仕様書などの書類

# 前回のミートアップから今回のミートアップまでにSlackなどにあったリンクメモ

- [GigaScienceさんはTwitterを使っています 「Great to see @NCBI using @CommonWL\. Transcriptome annotation in the cloud: complexity, best practices, and cost https://t\.co/j7Jef4uSJ0 https://t\.co/nkQTI0xYQm」 / Twitter](https://twitter.com/GigaScience/status/1367141591123640323)
- [Transcriptome annotation in the cloud: complexity, best practices, and cost \| GigaScience \| Oxford Academic](https://academic.oup.com/gigascience/article/10/2/giaa163/6123656)
- [S3のAPIと互換性を持ったオブジェクトストレージの運用についてお話します \- ペパボテックブログ](https://tech.pepabo.com/2021/03/04/about-bayt/)
- [ブラウザ自動化ツール カオスマップ風 \- STAC2018 LT](https://www.slideshare.net/hnisiji/stac2018-lt-125349647)
- [軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 \- inductor's blog](https://blog.inductor.me/entry/alpine-not-recommended)
- パフォーマンス関連の話もあり
- [performance \- Why is the Alpine Docker image over 50% slower than the Ubuntu image? \- Super User](https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image)
- コレ自体は２０１８年のもののようですが、パフォーマンスに関連するポイントはでているもよう
- [GoogleContainerTools/distroless: 🥑 Language focused docker images, minus the operating system\.](https://github.com/GoogleContainerTools/distroless)
- Alpineとは違う、軽量ベースコンテナ
- [slack workspace に emoji を一括で追加する \- bcdeeiloprru](https://scrapbox.io/bcdeeiloprru/slack_workspace_%E3%81%AB_emoji_%E3%82%92%E4%B8%80%E6%8B%AC%E3%81%A7%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B)
- Slackに絵文字を一気に追加
- [仏OVHcloudのデータセンターで火災　4棟中1棟が全焼 \- ITmedia NEWS](https://www.itmedia.co.jp/news/articles/2103/11/news074.html)
- データセンター火災で消失
- こういうこともあるので、「クラウドにバックアップ」をとるだけでなく、「クラウドのバックアップ」をとることを考えることも大切
- [There are no descriptions about optional types · Issue \#605 · common\-workflow\-language/common\-workflow\-language](https://github.com/common-workflow-language/common-workflow-language/issues/605#issuecomment-444425511)
- [Common Workflow Language \(CWL\) Command Line Tool Description, v1\.0\.2](https://www.commonwl.org/v1.0/CommandLineTool.html#CWLType)
- [Expressions in default field · Issue \#377 · common\-workflow\-language/common\-workflow\-language](https://github.com/common-workflow-language/common-workflow-language/issues/377)
- [vm\.max\_map\_count in docker\-desktop distro for WSL2 · Issue \#5202 · docker/for\-win](https://github.com/docker/for-win/issues/5202)
- [Dockerfileのベストプラクティス Top 20 \| Sysdig](https://sysdig.jp/blog/dockerfile-best-practices/)
- 2021年らしい感じのアドバイスなどもあり、過去に似たようなものを読んだか方も新しい発見があるかと。
- .dockerignore
- distroless
- [仕事でPythonコンテナをデプロイする人向けのDockerfile \(2\): distroless編 \| フューチャー技術ブログ](https://future-architect.github.io/articles/20200514/)
- コンパイルしたpipをbuilderから持ち込む
- > COPY --from=builder /usr/local/lib/python3.7/site-packages /root/.local/lib/python3.7/site-packages
- [\.dockerignore アンチパターン \- Qiita](https://qiita.com/munisystem/items/b0f08b28e8cc26132212)
- [Linux Foundation、無料のソフトウェア署名サービス「sigstore」を発表 \| スラド オープンソース](https://opensource.srad.jp/story/21/03/11/165237/)