ログインと初期設定
ログインまで
Wisteria/BDECへのログインは公開鍵方式です． 公開鍵の作成方法の詳細はこちら をご覧ください．
- 最初の公開鍵は 利用支援ポータル からアップロードします．
- ログインのための接続先は
wisteria.cc.u-tokyo.ac.jpです．
ひとたび最初の1台のマシンからログインできるようになれば，他のマシンの公開鍵（id_rsa.pub）をログインノードの .ssh/authorized_keys に追加することで，そのマシンからもログインできるようになります．
ディレクトリ構成
アカウントは，申請に応じてグループに紐づいています．以下ではそれを ${group} 変数で表します．また，${user} が個人ユーザーIDを表すとします．
ディレクトリは
- ホーム
/home/${user} - ワーク
/work/${group}/${user} - 共有
/work/${group}/${share}
です．ホームディレクトリ・ワークディレクトリの基本パーミッションは700で，他の人は読み書きできません．グループ内で共有するファイルは共有ディレクトリをご利用ください．
自分のグループ番号がわからない場合は，id コマンドで調べることができます．
id
uid=49177(k64002) gid=20802(gk64) groups=20802(gk64),21639(gv49),21640(gv50),21949(gz06)gid のあとの括弧内がグループ番号です．東京大学情報基盤センターでは，複数のルート（予算）で申し込みをすると，同じアカウントで複数のグループに所属することがあります．その場合は，groups の中に複数のグループ番号が表示されます．
ホームディレクトリは容量が小さく，また ホームディレクトリではジョブの実行ができません． コードの開発や管理はホームディレクトリで，計算はワークディレクトリでやることを推奨します．
コンパイラとクロスコンパイラ
コンパイラやそれに付随するライブラリは，module コマンドを用いてロードし，実行します． Wisteria/BDECではジョブを実行するシステム（実行ノード）のCPUとログインノードのCPUが根本的に違う，という顕著な特徴があります． ログインノードは普通のIntel系のLinuxマシンですが，実行ノードはFujitsuのSPARC64系のCPUが使われています． そのため，ログインノードで動作する実行バイナリは，実行ノードではそのままでは動きません．
そこで，計算ノードで実行できるバイナリを生成するクロスコンパイラが用意されています． ログインノードにおいて，クロスコンパイラでコンパイルしたバイナリは実行ノードで動作します．しかし，当然ですがログインノードでは動きません．
このような特徴のため，計算ジョブとして実行するプログラムのコンパイラと，ログインノードで実行するプリポスト処理などのコンパイラを使い分ける必要があります．
クロスコンパイルのための環境は
module load fjあるいは
module load odysseyです．これらのあとに
module availコマンドを実行すると，その環境でロード可能なライブラリの一覧が表示されます．
クロスコンパイル環境でのFortranコンパイラは frtpx，MPIは mpifrtpx です．Cはそれぞれ fccpx と mpifccpx です． コンパイルオプションの体系は，gfortranやintel fortranとはまったく異なりますので，詳しくはマニュアル等を参照してください．
JupyterHub
BDECの特徴のひとつに，ブラウザからJupyter Notebookを介してスパコンにアクセスできるというものがあります．
https://wisteria08.cc.u-tokyo.ac.jp:8000 からログイン（パスワードは利用支援ポータルのログインパスワード）すると，ログインノード上でJupyter Notebookが動きます．
ノートブックの保存場所は ~/.notebook/ です．ノートブックから /work ディレクトリを含めたBDEC上のファイルすべてにアクセスできます．
基本はPython環境ですが，文頭に ! をつければシェルコマンドも動きますし，
%%bashをコードの先頭行に書けば，そのコードブロックはbashとして解釈されます．なので，記録を残しながら作業をする環境として使うことができるでしょう．
システムに入っているPythonは，そのままでは最低限のライブラリしか入っていません．そこで，自分で仮想環境を構築して，それをJupyterHubから使うことができます．