# 54th Workflow Meetup (2022-07-06 Wed, 07 Thu)
================================

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

2022-07-06(Wed)
2022-07-07(Wed)　pitagora meetup と共催
13:00 - 19:00 まで。

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

# 事前計画

## 全体

## 石井

- 次回8月17日水曜日,18日木曜日を予定
- 2021年度は、月の第一週の水曜日13時スタートの方向。ただし、月曜日など他の日になるかもしれないです。
- 8月18日木曜日は、おそらくpitagora meetup と共催

# こうなりました

## 全体

### JupyterLabのgithubサイトを作る

## 石井

toil + cwltool 石井がいつも試す組み合わせ

- [jga-analysis](https://github.com/biosciencedbc/jga-analysis)は動きます。
- [human-reseq](https://github.com/ddbj/human-reseq)は動いたと思います。

ほかも大抵動くと思います（cwl1.2最先端の仕様をのぞく）

git+https://github.com/DataBiosphere/toil.git@aa50bbfdef66bd9a861fb889325e476405fe25b6
cwltool==3.1.20210816212154
galaxy-tool-util==21.9.2

[1330](https://github.com/common-workflow-language/cwltool/issues/1330)について丹生さんと議論する。

- やりたいことは、ResourceRequirementsを適切に親のワークフローから、子供のコマンドラインツールに渡したい
- 丹生さんとしては、WorkflowのStepのRequirements
- 親のワークフローから子供のワークフローに、inputsを引き回したいわけではない

[CWLの中のJavaScriptがどのように、nodeに渡されているかの例、inputsの前はvarが書いてある。](https://github.com/common-workflow-language/cwltool/pull/1566#issuecomment-1170944941)

`self`については、[ParameterReferenceの仕様](https://www.commonwl.org/v1.2/CommandLineTool.html#Parameter_references)にのっている。

'"use strict";
var inputs = {
    "in": "hello inp1"
};
var self = null;
var runtime = {
    "cores": 1,
    "ram": 1024,
    "tmpdirSize": 1024,
    "outdirSize": 1024,
    "tmpdir": null,
    "outdir": null
};
(function(){ 
  return {"out": inputs.in +" "+inputs.in2};
})()'

もともとやりたかったのは、こんなかんじの[cwlを書いて、親のワークフローでいろいろ渡したかった](https://github.com/biosciencedbc/jga-analysis/blob/cf77df252ff187bdcf718d29f1fb4834c0626ed1/per-sample/Tools/gatk4-HaplotypeCaller.cwl)
現状は、このコマンドの上には、ワークフローが２段（以上？）あり、全部の段階で、inputsを明示的に上から指定してきて解決したきがする。
最初やりたかったのは、親のワークフローにだけ書いて、サブワークフローを何段経たあとに存在するCommandLineToolは、そのinputパラメータがあればその値を使い、なければ、defaultを使うなどをしたかった。

- 1330について
- これだけを解決する場合、eagerにすればよい
- ep3は、eagerで作っていて、conformance testとおっているところからして、現状のconformance testにはlazyのみ通るケースはないと思われる。
- 現状では、eagerでもlazyでも通るケースのみが登録されている。
- まずは、以下の流れがよさそうなのではないかという話になった。
- lazyのissueをたてる
- 入力ファイルサイズによって、決まるようなケース
- 1330解決のPRをする
- lazyのissueを解決する
- ExpressionToolに関するものも自然に解決するだろう
- [unconnected ExpressionTool](https://github.com/common-workflow-language/cwl-v1.2/pull/156)
- EagerとLazyどちらをデフォルトにするかの問題
- デフォルトeagerがよいのではないか？というのを1330で合意をとれればよい
- [Clarify evaluation policy of Workflow level requirements · Issue \#157 · common\-workflow\-language/cwl\-v1\.2](https://github.com/common-workflow-language/cwl-v1.2/issues/157)
- これもまた解決されるだろう。
- EagerもLazyも対応して、デフォルトどちらを使うかも決めれば、どの実装でも動きがきまるはずである。
- 丹生さんのところにある、`cwl:requirements`の議論もまた、1330とは別である。
- 今も、今後も、親が４で子が８となっている場合、８で動くべきである。
- 親が４で子が８なのに、子が４で動くのは、言語仕様違反
- 親と子が別のエンジンで動く場合、子に適切に requirements を渡す方法がない！
- `cwl:requirements` だと子も 4 にされてしまう
- さらに別のissueとしてoverride_requirements的なもの。
- cwltool は処理系拡張として[提供している](https://github.com/common-workflow-language/cwltool#overriding-workflow-requirements-at-load-time)
- ほとんど全部を、プロセス数１でうごかすために、親のResourceRequirementsのcoreMaxは１、しかし、子供のうち１つだけは、コア１６で動かしたいときに対応する言語仕様がない。
- ワークフロー実行エンジンと、コマンドラインツール実行エンジンが異なるときなどのために、明示的に必要。

- 新海さんと少しおはなしできたのは、別の仕事の解決にむかいそうです。ありがとうございます。

## 西田

## 丹生

石井補足：（どこか適切な場所に移動していただいて大丈夫です）
はまりガチポイント：
コンテナ内から、slurmに投げるのは、ちょっとおすすめしにくいかもしれない。munge.keyなどをシェアする必要があるだろう。
SGEだったとしても、submit許可されているホスト名の問題とかあったかも。`dockedr --net=host`こういうのもいるかもいｓれない。
技術的には可能だが、大抵は（石井しか理解できない、したくない）黒魔術になってしまうだろうという感じもあります。
白魔術まってます。すごい知りたい。
せっていできる環境変数はこんな感じです。(バージョンふるいかもだけど、だいたいおなじ　TOIL_SLURM_ARGS大事)
https://toil.readthedocs.io/en/3.15.0/appendices/environment_vars.html

コンテナ外のtoilからは、slurmに投げるのはいつもおこなっており、数カ所で試してきちんと動いてます。
(pipで必要ためしたものは、石井のセクションに書いてあります。←石井はこれで石井の動かしたいワークフロー動かしました)
テストするだけなら

toil-cwl-runner --batchSystem Slurm /tmp/example.cwl /tmp/example-job.yaml

か、jobStoreの設定は必須かも。しれません。

toil-cwl-runner --batchSystem Slurm --jobStore /home/manabu/work/slurmdocker/docker/jobStore3 /home/manabu/work/slurmdocker/docker/example.cwl /home/manabu/work/slurmdocker/docker/example-job.yaml

- [書きかけですが、今このブランチで開発中](https://github.com/biosciencedbc/jga-analysis/tree/add-readme-for-persample/per-sample)
- これを書く必要があるので、なにかわからない。

ここまで石井

- RDM+ワークフローエンジン連携に関するミーティング
- [GakuNin RDM](https://rdm.nii.ac.jp/) とワークフローエンジンを連携させたい
- デモに使ったリポジトリ: https://github.com/tom-tan/sapporo-demo
- RDM 的には、バックエンドのエンジンとジョブスケジューラー連携もやりたい
- 長期的には遺伝研スパコンのノードと連携するみたいなのもできたらうれしい
- 石井さんから toil とジョブスケジューラー連携のアドバイスをもらった
- エンジンはホストに入れたほうがいい
- コンテナからジョブを投入できない
- バージョンの組み合わせの相性があるかも
- そのうち解析している人からのフィードバックが欲しい
- 募集中
- [cwltool#1330](https://github.com/common-workflow-language/cwltool/issues/1330) に関する議論
- 本質的には `requirements` 中の expression を eager に評価すべきか lazy に評価すべきか
- cwltool は lazy, ep3 は eager
- 長期的には以下がいいのでは？
- [`cwl:requirements`](https://www.commonwl.org/v1.2/CommandLineTool.html#Requirements_and_hints) を継承された requirements 用に拡張 -> エンジンが別の場合
- 継承された requirements と `cwl:requirements` では優先順位が異なるため両方必要
- [WorkflowStep#requirements](https://www.commonwl.org/v1.2/Workflow.html#WorkflowStep) からステップの入力オブジェクトを参照する方法
- 現在の仕様では `inputs` でワークフロー全体の入力オブジェクトしか参照できない
- そのうち [ep3](https://github.com/tom-tan/ep3) と [shaft](https://github.com/tom-tan/shaft) でも同じ問題に引っかかる
- デフォルト lazy だと CommandLineTool 専門のエンジンの実装がめんどくさくなる
- shaft は path mapping 周りの設計で難航中

## 新海

- 論文向けの調査開発等
- Rも勉強します…

石井追加

- SNAP, FlatPak, AppImage
- [Linux Mint Tips : SNAP、FLATPAK、APPIMAGE 違い比較 \| 221B Baker Street](http://baker-street.jugem.jp/?eid=25)

石井ここまで

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

- ここから書く