このために参考となる情報はどこにあるでしょうか？
このページにまとまっています。ご覧ください。
(最終更新日 2025年4月30日)
FAQ
FAQ - よくある質問とその答え
FAQ とは "Frequently Asked (またはAnswered) Questions" の略称です。 CfCAの共同利用計算機に関して利用者各位よりこれまでに寄せられた質問のうち、質問の頻度や重要性が高いと思われる質問とそれへの典型的な回答例を以下にまとめました。 各計算機システムの利用の手引きを読んで不明な点があれば、窓口へ問い合わせる前に以下のFAQ内に必要な情報が無いかどうかを調べましょう。
計算サーバに関する質問
はい、本当です。
しかし誰もが使える訳ではありません。
iSALEの利用には幾つかの条件があります。
詳細はiSALE users group in Japan wikiをご覧ください。
iSALE自体に関する問い合わせは上記のiSALE users group in Japanへお願いします。
計算サーバの問題と思われる場合には本プロジェクトの各種問い合わせへご連絡ください。
毎年夏にはiSALEの講習会も開催されています。こちらへの参加もご検討ください。
(最終更新日 2024年以前)
はい、使えます。module コマンドを使ってください。
module load miniconda/3
なお pySALEPlot は Python 2 系にしか対応していません。
使い分けを工夫してください。
(最終更新日 2024年以前)
その通りです。
特に小さなファイルを多数書き込む場合、/mwork{1,2} への書き込み速度は以前にあった作業領域へのそれよりずっと高いです。
これは /mwork{1,2} がFreeBSDのZFSファイルシステムにssdによるキャッシュ機能を与えたものだからです。
とりわけ小さなファイルを多く書き込む利用者は、その高い速度を体感するでしょう。
(最終更新日 2024年以前)
はい、掛かっています。
利用の手引きを御覧ください。
但し、この領域でquotaの溢れが発生しても利用者には電子メールなどでの警告は届きません。
ご自分がどのくらいのファイル量を保持しているかには常に留意してください。
(最終更新日 2025年5月28日)
以下のような表示が出ます。
% echo something > /mwork2/username/output.txt /mwork2/username/output.txt: ディスク使用量制限を超過しました.
何が起こっており、私はどう対処すれば良いでしょうか？
これはディレクトリ /mwork2 が有するquota制限に抵触したためです。
試しに環境変数 LANG を C へ変更すると、より直截なメッセージが出ます。
% env LANG=C echo something > /mwork2/username/output.txt /mwork2/username/output.txt: Disk quota exceeded.
不要なファイルを削除または移動してください。
また、この下にあるQ＆A「quotaコマンドを使っても /mwork{1,2} について情報が現れません」も併わせてお読みください。
(最終更新日 2025年5月28日)
どのようにすれば情報を得られるでしょうか？
/mwork{1,2}を提供するnfsサーバ (FreeBSD) は m000 (Rocky Lonux) とOSが異なるため、現時点ではquota状況を即時に表示するコマンドが未だありません。
代替として全利用者のquota状況を記したファイル/mwork{1,2}/userspace.txtが準備されており、
これらは60分に1度の頻度で更新されています。このファイルをcatするか、以下のようにしてください。
grep `whoami` /mwork{1,2}/userspace.txt
すると以下の例のようにご自分の利用状況(右から二欄目の数値)およびquota上限値(右端欄の数値)が表示されます。
/mwork1/userspace.txt:POSIX User itootk 10.1T 24T /mwork2/userspace.txt:POSIX User itootk 224G 24T
(最終更新日 2025年5月28日)
はい、出来ます。
たとえば an14 からは以下のように見えますので是非お使いください。
an14% df -m /mwork1 /mwork2/ Filesystem 1M-blocks Used Available Use% Mounted on mfs01.cfca.nao.ac.jp:/tank0/mwork 339354538 60790429 278564109 18% /misc/mwork1 mfs02.cfca.nao.ac.jp:/tank0/mwork 339347415 71606491 267740924 22% /misc/mwork2
an14% ls -lad /misc/mwork? lrwxrwxrwx. 1 root root 12 Mar 18 19:43 /mwork1 -> /misc/mwork1/ lrwxrwxrwx. 1 root root 12 Mar 18 19:43 /mwork2 -> /misc/mwork2/
(最終更新日 2025年5月28日)
qsub: submit error (Bad UID for job execution MSG=User XXXXXX does not exist in server password file)
これは計算ノードとサーバ側の通信が一時的に途切れたものと予想されます。
やや時間を置いてから再び qsub してみてください。
もし何度か試行しても状況が改善しなければ、問い合わせページからお問い合わせください。
(最終更新日 2025年5月28日)
どのようにすれば良いでしょうか？
PBSスクリプトの書き間違えが考えられます。
例えば以下のようにオプション -N の引数に空白(スペース)が含まれるとジョブ投入は為されません (my と test の間)。
これはPBSの仕様です。
#PBS -N my test job.sh
詳しくは man pbs をご覧になり、qsubのオプション詳細をお調べください。
(最終更新日 2025年5月28日)
私はiSALE利用者なのでファイルiSALE-Dellen.zipを受け取り、それを展開して /mwork2 以下の私のディレクトリに置いていました。
すると、今朝になって多くのファイルが消えていることが分かりました。
これは何故でしょうか？
これは、配布されたiSALE関係のファイルの最終アクセス日付が /mwork2 の定期ファイル削除 (atime +120) に抵触したからと予想されます。
配布されたファイル iSALE-Dellen.zip が以下であると仮定します。
m000% ls -l 合計 3292 -rw------- 1 root root 3367828 1月 17 09:38 iSALE-Dellen.zip
このzipファイルを展開すると以下のようなファイルが現れるでしょう。
なお以下にある日付はファイルの最終アクセス日付 (atime) です。
m000% ls -lutrR iSALE-Dellen iSALE-Dellen: 合計 4140 -rw------- 1 root root 144194 7月 21 03:15 parameters.db -rw------- 1 root root 1926 7月 21 03:15 material.inp -rwx------ 1 root root 1504283 7月 21 03:15 iSALE2D -rw------- 1 root root 4610 7月 21 03:15 asteroid.inp -rw------- 1 root root 4940 7月 21 03:56 psp_setupPlots.py -rw------- 1 root root 756 7月 23 12:54 isale.pbs -rw------- 1 root root 48205 7月 23 19:10 pySALEPlot.pyc -rw------- 1 root root 67253 7月 23 19:10 pySALEPlot.py -rwx------ 1 root root 381143 7月 23 19:10 libpsp.so -rw------- 1 root root 1234 7月 23 19:15 R_TrP.py -rw------- 1 root root 1201 7月 23 19:16 tracer.py -rw------- 1 root root 1260 7月 23 19:17 profile.py -rw------- 1 root root 2655 7月 30 07:11 plot.py -rw------- 1 root root 2471 7月 30 07:13 DenTmp.py drwx------ 2 root root 4096 7月 30 07:15 eos iSALE-Dellen/eos: 合計 9068 -rw------- 1 root root 446667 7月 21 03:15 granit1.aneos -rw------- 1 root root 5544808 7月 21 03:56 h2o_ice.aneos -rw------- 1 root root 3748 7月 21 03:56 granitm.input -rw------- 1 root root 1172 7月 21 03:56 granite.tillo -rw------- 1 root root 3593 7月 21 03:56 granite.input -rw------- 1 root root 446704 7月 21 03:56 granit2.aneos -rw------- 1 root root 1284 7月 21 03:56 gabbro1.tillo -rw------- 1 root root 4009 7月 21 03:56 forstrm.input -rw------- 1 root root 3791 7月 21 03:56 fayaltm.input -rw------- 1 root root 3917 7月 21 03:56 dunite_.input -rw------- 1 root root 446681 7月 21 03:56 dunite_.aneos -rw------- 1 root root 2731 7月 21 03:56 calcite.input -rw------- 1 root root 446696 7月 21 03:56 calcite.aneos -rw------- 1 root root 3690 7月 21 03:56 basaltm.input -rw------- 1 root root 1050 7月 21 03:56 basalt_.tillo -rw------- 1 root root 441233 7月 21 03:56 basalt_.aneos -rw------- 1 root root 1114 7月 21 03:56 aluminu.tillo -rw------- 1 root root 1168 7月 21 03:56 wettuff.tillo -rw------- 1 root root 1088 7月 21 03:56 water__.tillo -rw------- 1 root root 446706 7月 21 03:56 water__.aneos -rw------- 1 root root 446729 7月 21 03:56 quarzit.aneos -rw------- 1 root root 5321 7月 21 03:56 quartzm.input -rw------- 1 root root 5216 7月 21 03:56 quartz_.input -rw------- 1 root root 1093 7月 21 03:56 pyrex__.tillo -rw------- 1 root root 1111 7月 21 03:56 polyeth.tillo -rw------- 1 root root 776 7月 21 03:56 perfgas.tillo -rw------- 1 root root 1002 7月 21 03:56 miesand.tillo -rw------- 1 root root 1175 7月 21 03:56 limesto.tillo -rw------- 1 root root 1109 7月 21 03:56 iron___.tillo -rw------- 1 root root 446656 7月 21 03:56 iron___.aneos -rw------- 1 root root 1357 7月 21 03:56 iceb___.tillo -rw------- 1 root root 1025 7月 21 03:56 ice____.tillo -rw------- 1 root root 3265 7月 21 03:56 ice____.input -rw------- 1 root root 1122 7月 21 03:56 fuseqtz.tillo -rw------- 1 root root 1170 7月 21 03:56 drytuff.tillo -rw------- 1 root root 785 7月 21 03:56 dry_air.tillo
ご覧のように、各ファイルのatimeは現在より120日以上前のものです(上記の「7月」とは2018年7月のこと)。
この場合、上記ファイルを計算サーバの作業領域 /mwork{1,2}/ 以下に置いて使うと 毎日定時のファイル削除ルーチンに引っ掛かり、ファイルが削除されてしまいます。
これを避けるためには必要なファイルにアクセスしてatimeを更新するか、もしくは定期的に削除されないディレクトリにファイルを置いてください。
(最終更新日 2025年5年29日)
具体的には、PBSジョブ終了後の通知メール内に以下が記されていました
Date: Thu, 1 Nov 2018 12:36:42 +0900 From: admSubject: PBS JOB 374683.m000.cfca.nao.ac.jp PBS Job Id: 374683.m000.cfca.nao.ac.jp Job Name: bcn0839 Post job file processing error; job 374683.m000.cfca.nao.ac.jp on host m097
これは何を意味しているでしょうか？
なお実行結果としての出力は正常なようです。
詳細を知るため、当該計算ノード上でこのジョブに関するログを探してみました。
以下が該当するようです。
20181024:10/24/2018 14:40:59;0008;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;Started, pid = 1516 20181101:11/01/2018 12:36:09;0080;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;task 00000001 terminated 20181101:11/01/2018 12:36:09;0008;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;Terminated 20181101:11/01/2018 12:36:09;0100;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;task 00000001 cput=186:34:43 20181101:11/01/2018 12:36:09;0008;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;kill_job 20181101:11/01/2018 12:36:09;0100;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;m097 cput=186:34:43 mem=14544kb 20181101:11/01/2018 12:36:09;0008;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;no active tasks 20181101:11/01/2018 12:36:09;0100;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;Obit sent 20181101:11/01/2018 12:36:09;0080;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;copy file request received 20181101:11/01/2018 12:36:09;0080;pbs_mom;Fil;sys_copy;command: /bin/cp -rp /var/spool/pbs/spool/374683.m000.cfca.nao.ac.jp.OU /mwork1/itootk/SWIFT.F0/bcn0839/Log.out status=1, try=1 20181101:11/01/2018 12:36:09;0080;pbs_mom;Fil;sys_copy;command: /bin/cp -rp /var/spool/pbs/spool/374683.m000.cfca.nao.ac.jp.OU /mwork1/itootk/SWIFT.F0/bcn0839/Log.out status=1, try=2 20181101:11/01/2018 12:36:20;0080;pbs_mom;Fil;sys_copy;command: /bin/cp -rp /var/spool/pbs/spool/374683.m000.cfca.nao.ac.jp.OU /mwork1/itootk/SWIFT.F0/bcn0839/Log.out status=1, try=3 20181101:11/01/2018 12:36:20;0080;pbs_mom;Fil;sys_copy;command: /bin/cp -rp /var/spool/pbs/spool/374683.m000.cfca.nao.ac.jp.OU /mwork1/itootk/SWIFT.F0/bcn0839/Log.out status=1, try=4 20181101:11/01/2018 12:36:41;0004;pbs_mom;Fil;374683.m000.cfca.nao.ac.jp.OU; Unable to copy file /var/spool/pbs/spool/374683.m000.cfca.nao.ac.jp.OU to m000:/mwork1/itootk/SWIFT.F0/bcn0839/Log.out 20181101:11/01/2018 12:36:41;0004;pbs_mom;Fil;374683.m000.cfca.nao.ac.jp.OU; /bin/cp: cannot create regular file '/mwork1/itootk/SWIFT.F0/bcn0839/Log.out': Permission denied 20181101:11/01/2018 12:36:42;0100;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;Job files not copied: 20181101:Unable to copy file /var/spool/pbs/spool/374683.m000.cfca.nao.ac.jp.OU to m000:/mwork1/itootk/SWIFT.F0/bcn0839/Log.out 20181101:Output retained on that host in: /var/spool/pbs/undelivered/374683.m000.cfca.nao.ac.jp.OU 20181101:11/01/2018 12:36:42;0100;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;staged 2 items out over 0:00:33 20181101:11/01/2018 12:36:42;0008;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;no active tasks 20181101:11/01/2018 12:36:42;0100;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;Obit sent 20181101:11/01/2018 12:36:42;0080;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;delete job request received 20181101:11/01/2018 12:36:42;0008;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;kill_job 20181101:11/01/2018 12:36:42;0080;pbs_mom;Job;374683.m000.cfca.nao.ac.jp;delete job request received
これによれば、このPBSジョブは正常に終了したものの標準出力を利用者指定のファイル /mwork1/itootk/SWIFT.F0/bcn0839/Log.out に書き出そうとし、失敗しています。
失敗の理由は
/mwork1/itootk/SWIFT.F0/bcn0839/Log.out': Permission denied
とあります。
よって、おそらく Log.out というファイルが既に存在し、しかもそのパーミッションが 000 といったPBSのデーモンが書き込み不可の状況にあったと推定されます。
こうした既存のファイルを削除しておけば、今回のエラーは出なかったと思われます。
なお上記のログにあるように書き出しに失敗した標準出力の内容はファイル
/var/spool/pbs/undelivered/374683.m000.cfca.nao.ac.jp.OU
として計算ノード側に保持されています。
もしもこのファイルを御所望の場合には本プロジェクトにご連絡を頂ければ手動で発掘してお渡しすることは不可能ではありません。
(最終更新日 2025年5月29日)
これは何故でしょうか？
これは計算サーバが採用しているOS (Rocky Linux)による制限です。
以下のようにして確認できます。
- /bin/csh, /bin/tcsh, /bin/zsh の場合
$ limit descriptors descriptors 1024
- /bin/sh, /bin/bash, /bin/zsh の場合
$ ulimit -n 1024
上記のような制限があるため、1024個以上のファイルを同時に開くことは出来ません。
(最終更新日 2025年5月29日)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX. Please contact your system administrator. Add correct host key in /home/****/.ssh/known_hosts to get rid of this message. Offending key in /home/****/.ssh/known_hosts:9 RSA host key for m000.cfca.nao.ac.jp has changed and you have requested strict checking. Host key verification failed.
これはご自分のホームディクトリ下の ~/.ssh/known_hosts に記録された接続先機材の情報が実際の機材情報と異なることで発生する警告です。
この現象はしばしば見られ、接続先の機材でOSが再インストールされたり、接続先のIPアドレスやホスト名が変更されることにより生じます。
このような場合にはファイル ~/.ssh/known_hosts を編集します。
このファイルを開き、m000.cfca.nao.ac.jp あるいは m000 から始まる行を削除してください。
より適切な方法は以下のコマンドを使うことです。
% ssh-keygen -R m000.cfca.nao.ac.jp /home/user/.ssh/known_hosts updated. Original contents retained as /home/user/.ssh/known_hosts.old
上記を実施した後、次のコマンドを打ち込んでも良いでしょう。
% ssh-keyscan m000.cfca.nao.ac.jp >> ~/.ssh/known_hosts
ここで使うリダイレクトは上書き > ではなく、追記 >> であることに留意しましょう。
これにてご自分の ~/.ssh/known_hosts に相手先に最新情報が記録されます。
その後に再び m000.cfca.nao.ac.jp に ssh してください。
もしログイン前に何らかの質問をされたら yes と回答します。
この現象は m000 に限らずsshを用いる機器同士では頻繁に発生する現象です。
従ってGoogleなどで検索すれば多数の情報が得られますので、御自分でお調べください。
(最終更新日 2025年5月29日)
qsubコマンドのオプション -l keyword=value で指定が可能です。
-l オプションはジョブのリソース要求を指定するもので、指定できる keyword の代表には以下があります。
cput ジョブによって使用されるCPU時間の最大値 (単位: time) file ファイルを作成する際のサイズ制限 (単位: size) mem 最大物理メモリ容量 (単位: size) ncpus 要求されたプロセッサ(コア)数 pcput ジョブ内の一つのプロセスに割り当てられる最大CPU時間 (単位: time) pmem ジョブ内の一つのプロセスで使用される最大物理メモリ容量 (単位: size) pvmem ジョブ内のすべての同時プロセスで使用される最大仮想メモリ容量 (単位: size) vmem ジョブ内のすべての同時プロセスで使用される最大仮想メモリ容量 (単位: size) walltime ジョブが実行状態にある場合の実際の時間（経過時間）の最大値 (単位: time)
cputなどを指定する場合、時間(上記のtime)は秒数(整数値)もしくは次の形式で指定します。
[[hours:]minutes:]seconds[.milliseconds]
fileやmemを指定する場合、サイズ(上記のsize)は以下のsuffixを用いて指定してください。
b またはw : バイトまたはワード kbまたはkw : キロバイトまたはキロワード mbまたはmw : メガバイトまたはメガワード gbまたはgw : ギガバイトまたはギガワード
例えば以下のような指定が出来ます。
qsub -q long -l cput=765:43:21 -l pmem=321mb スクリプト
ここで qstat -f コマンドを投入すると、
当該リソースが指定された値を持っていることが分かるでしょう。
qstat -f 上記のジョブID
Resource_List.cput = 765:43:21
Resource_List.pmem = 321mb
更に詳しい情報についてはPBS関係のドキュメントをお読みください。
(最終更新日 2024年以前)
ひょんな事から非常に大きなサイズのファイルを作ってしまい、ディスク領域を圧迫し始めました。
これを rm コマンドで消そうとしても消えないのですが、どうすれば良いでしょうか？
以下の方法で時間が短縮されるとは限らないのですが、まずは当該ファイルをサイズ0のファイルで上書きしてみましょう。
たとえば以下のコマンドを実行してください。
echo "" > 当該ファイル
または以下です。
cat /dev/null > 当該ファイル
その後で当該ファイルを削除してみてください。
rm 当該ファイル
(最終更新日 2025年6月3日)
/home/自分/ の他にそういう領域があれば嬉しいです。
/mwork[1-2]上にファイルを置くと、気付いた時には消えていることが多いです。
上記の目的のためにはファイルサーバ系の領域が使えるでしょう。
必要な申請を行い、領域を確保してください。
(最終更新日 2025年6月3日)
ここに置いた通常ファイルが一定期間後に消えることは承知していますが、ディレクトリも同様に自動削除されるのでしょうか？
いいえ、ディレクトリは自動的には削除されません。
従って、ディレクトリ内にあるファイルは削除された後には空のディレクトリだけが残ることになります。
(最終更新日 2025年6月3日)
どのようにすれば良いでしょうか？
計算ノードとの通信状況が悪い時にこれが発生することがあります。
qdel コマンドにオプション -W force を付けて実行してみてください。
qdel -W force ジョブID ...
オプション -W force の意味は "Deletes the job whether or not the job' execution host is reachable." です。
詳しくは man qdel を参照してください。
なお上記のオプションを付けてもジョブを qdel できない場合にはジョブに何らかの障害が発生している可能性があります。
その場合はこのページから報告をお願いします。
(最終更新日 2024年以前)
以下のようにしましたが、エラーは出ないものの肝心の絵窓が開きません。
gs example.ps
gs にオプション -sDEVICE=x11 を付けて実行してみてください。
gs -sDEVICE=x11 example.ps
(最終更新日 2024年以前)
これはPBSが持つ組み込み環境変数のことです。
どのようにすればその一覧を表示できるでしょうか？
あなたがPBSスクリプトをcsh文法で記しているならば以下のような方法があります。
/bin/sh や bash をお使いの場合にはそれ用に書き直してください。
なお幾つかのPBS環境変数にはデフォルト値が設定されていません。
set pbsvariables = (\
NCPUS \
OMP_NUM_THREADS \
PBS_ARRAY_ID \
PBS_ARRAY_INDEX \
PBS_ENVIRONMENT \
PBS_JOBCOOKIE \
PBS_JOBID \
PBS_JOBNAME \
PBS_MOMPORT \
PBS_NODEFILE \
PBS_NODENUM \
PBS_O_HOME \
PBS_O_HOST \
PBS_O_LANG \
PBS_O_LOGNAME \
PBS_O_MAIL \
PBS_O_PATH \
PBS_O_QUEUE \
PBS_O_SHELL \
PBS_O_SYSTEM \
PBS_O_TZ \
PBS_O_WORKDIR \
PBS_QUEUE \
PBS_TASKNUM \
TMPDIR \
)
foreach pbsvar ($pbsvariables[*])
if (`eval echo '$'${pbsvar}` == '') then
echo "$pbsvar is not defined"
else
eval echo $pbsvar='$'${pbsvar}
endif
end
(最終更新日 2025年6月3日)
PBSジョブの終了後、標準出力ファイル file.oXXXX と標準エラー出力ファイルfile.eXXXX が出来ます。
それぞれには以下の記載がありましたがその意味が分かりません。
標準出力ファイル file.oXXXX :
Warning: no access to tty (Bad file descriptor). Thus no job control in this shell.
標準エラー出力ファイル file.eXXXX :
stty: standard input: Invalid argument
これらは何を意味しているのでしょうか？
上記のメッセージに実害はあるのでしょうか？
ログインシェルに csh または tcsh が使われているとこのメッセージが出力されることがあります。
しかしジョブの実行に実害はありませんので、気にしないでください。
(最終更新日 2025年6月3日)
これは何故でしょうか？
下記には qstat -f の結果の一部を抜粋します。
$ qstat -f 562
Job Id: 562.m000.cfca.nao.ac.jp
resources_used.cput = 03:52:54
resources_used.walltime = 68:57:58
exec_host = m004/0
主に以下の二つの可能性が考えられるでしょう。
- このジョブに伴うファイル入出力にとても時間が掛かっている。
ご自分のジョブが不必要に頻繁なファイル入出力を行っていないか否かを検証してください。 - 計算ノード(上記の場合にはm004)に障害が発生している。
こちらが疑われる場合には、お手数ですがこのページから詳細の報告をお願いします。
なお後者つまり計算ノードの障害の場合には、当該 PBS ジョブを強制終了する可能性が高いです。
予めご了承ください。
(最終更新日 2025年6月3日)
以下のように言われます。
stty: standard input: Invalid argument forrtl: severe (174): SIGSEGV, possible program stack overflow occurred. Program requirements exceed current stacksize resource limit. Superusers may try increasing this resource by 'limit stacksize xxx', where xxx is unlimited or something larger than your current limit. Other users should contact your system administrator for help.
このエラーはstacksize上限を解除すると回避できることがあります。
cshやtcshの場合には以下のようにしてください。
unlimit
shや bashの場合には以下のようにしてください。
ulimit -s unlimited
PBSスクリプト内では以下のようにして上限解除の指定を追加してください。
#!/bin/sh
#PBS -r y
#PBS -m ae
#PBS -q long
#PBS -l nodes=1
# This job's working directory
echo Working directory is $PBS_O_WORKDIR
cd $PBS_O_WORKDIR
echo Running on host `hostname`
echo Time is `date`
echo Directory is `pwd`
# Run your executable
ulimit -s unlimited # ★ここに追加
./a.out
(最終更新日 2024年以前)
以下の 9391 というエラー番号は何を意味しているのでしょうか？
/var/spool/PBS/mom_priv/jobs/211.m000.SC: line 20: 9391 強制終了
PBS関係の文書の幾つかに記されていますが、エラー番号 9391 の意味は以下です。
- 実行されたジョブの仮想メモリ領域へのダイナミックメモリ割り当て要求が制限を越え、割り当てできず、結果的にカーネルがそのジョブを強制終了させた。
つまり当該PBSジョブが仮想メモリ領域を使い切り、プロセスが停止したということです。
これを解決するには、仮想メモリ制限内で動作するように扱うジョブが扱うデータを小さくするしかありません。
(最終更新日 2025年6月3日)
はい、あります。
オプション -W depend=afterok:ジョブID オプションを使用してください。
qsub -W depend=afterok:244.m000 JOB_B
これにより、JOB_A が終了した後に JOB_B が走り出します。
Job id Name User Time Use S Queue ---------------- ---------------- ---------------- -------- - ----- 244.m000 JOB_A user 00:00:09 R short 245.m000 JOB_B user 00:00:00 H short 246.m000 JOB_C user 00:00:00 R short
上記の他に afterng, afterany も指定できます。
qsub のマニュアルを御覧ください。
(最終更新日 2025年6月3日)
はい、できます。
最初の方法は tracejob コマンドです。
以下は過去30日分のPBSログファイルを対象としてジョブを検索する作業例です。
m000% tracejob -n 30 11999
Job: 11999.m000
11/22/2005 10:36:53 S Job Queued at request of user
m000[dot]cfca[dot]nao[dot]ac[dot]jp,
owner = userm000[dot]cfca[dot]nao[dot]ac[dot]jp, job name = test.sh,
queue = short
11/22/2005 10:36:53 S Job Modified at request of
Schedulerm000[dot]cfca[dot]nao[dot]ac[dot]jp
11/22/2005 10:36:53 S enqueuing into short, state 1 hop 1
11/22/2005 10:36:53 A queue=short
11/22/2005 13:26:53 L Server job limit reached
11/22/2005 13:35:27 L Considering job to run
11/22/2005 13:35:27 S Job Modified at request of
Schedulerm000[dot]cfca[dot]nao[dot]ac[dot]jp
11/22/2005 13:35:27 S Job Run at request of Schedulerm000[dot]cfca[dot]nao[dot]ac[dot]jp
on hosts m004
11/22/2005 13:35:28 L Job run
11/22/2005 13:35:28 A user=user group=naocc jobname=test.sh queue=short
ctime=1132623413 qtime=1132623413 etime=1132623413
start=1132634128 exec_host=m004/0
Resource_List.cput=00:30:00 Resource_List.ncpus=1
Resource_List.neednodes=1 Resource_List.nodect=1
Resource_List.nodes=1
11/22/2005 13:39:28 S Obit received
11/22/2005 13:39:28 S Exit_status=0 resources_used.cpupercent=8
resources_used.cput=00:00:28 resources_used.mem=4324kb
resources_used.ncpus=1 resources_used.vmem=21992kb
resources_used.walltime=00:03:59
11/22/2005 13:39:28 A user=user group=naocc jobname=test.sh queue=short
ctime=1132623413 qtime=1132623413 etime=1132623413
start=1132634128 exec_host=m004/0
Resource_List.cput=00:30:00 Resource_List.ncpus=1
Resource_List.neednodes=1 Resource_List.nodect=1
Resource_List.nodes=1 session=24075 end=1132634368
Exit_status=0 resources_used.cpupercent=8
resources_used.cput=00:00:28 resources_used.mem=4324kb
resources_used.ncpus=1 resources_used.vmem=21992kb
resources_used.walltime=00:03:59
11/22/2005 13:45:44 S dequeuing from short, state 5
もしも過去30日以内のログファイルに当該ジョブの情報が見付からなければ、以下のように言われるでしょう。
m000% tracejob -n 30 478369 tracejob: Couldn't find Job Id 478369.m000 in logs of past 30 days
次の方法はコマンド qstat -fx です。
以下が例となります。
m000% qstat -fx 478369
Job Id: 478369.m000
Job_Name = t2_Dec24
Job_Owner = itootk@m000
resources_used.cpupercent = 98
resources_used.cput = 1358:01:11
resources_used.mem = 6144kb
resources_used.ncpus = 1
resources_used.vmem = 458480kb
resources_used.walltime = 1364:51:03
job_state = R
queue = long
server = m000
Checkpoint = u
ctime = Mon Apr 7 17:13:34 2025
Error_Path = m000:/home/itootk/Log.err
exec_host = e122/0
exec_vnode = (e122:ncpus=1)
Hold_Types = n
Join_Path = n
Keep_Files = n
Mail_Points = ae
Mail_Users = itootkcfca[dot]nao[dot]ac[dot]jp
mtime = Tue Jun 3 14:04:38 2025
Output_Path = m000:/home/itootk/Log.out
Priority = 0
qtime = Mon Apr 7 17:13:34 2025
Rerunable = False
Resource_List.ncpus = 1
Resource_List.nodect = 1
Resource_List.nodes = 1
Resource_List.place = scatter
Resource_List.select = 1:ncpus=1
stime = Mon Apr 7 17:13:34 2025
session_id = 193397
jobdir = /home/itootk
substate = 42
Variable_List = PBS_O_HOME=/home/itootk,PBS_O_LANG=en_US.UTF-8,
PBS_O_LOGNAME=itootk,
PBS_O_PATH=/home/itootk/bin:/opt/pbs/bin:/usr/local/bin:/usr/bin:/us
r/local/sbin:/usr/sbin,PBS_O_MAIL=/var/spool/mail/itootk,
PBS_O_SHELL=/bin/csh,PBS_O_WORKDIR=/home/itootk,
PBS_O_SYSTEM=Linux,PBS_O_QUEUE=long,PBS_O_HOST=m000
comment = Job run at Mon Apr 07 at 17:13 on (e122:ncpus=1)
etime = Mon Apr 7 17:13:34 2025
run_count = 1
Submit_arguments = pbs_m000.sh
project = _pbs_project_default
Submit_Host = m000
(最終更新日 2025年6月3日)
何が問題でしょうか？
誠に申し訳ございませんが、当該ジョブの実行中に何らかのシステム障害が発生していた可能性があります。
またジョブ投入のPBSスクリプト内で下記のように -r n が指定されていると、システム復旧後に当該ジョブは自動的に再投入されません。
#PBS -r n
障害からの復旧後にジョブが自動再投入されるためには、PBSスクリプト内にて下記のように-r y を指定してください。
#PBS -r y
(最終更新日 2025年6月3日)
例えばm038はコア数が4なので4本のPBSジョブが走るはずですが、現在は以下のようです。
% qstat-n1 | grep m038 Job ID Username Queue Jobname SessID NDS S ETime Node Alloc --------------- -------- -------- ---------- ------ --- - ----- ---------- 435526.m000.cfc userAA long tpf 19060 1 S 1411: m038/1 435789.m000.cfc userAA long tpf 14894 1 S 1339: m038/2 437685.m000.cfc userBB long 65_7_ml5_t 19188 1 S 927:1 m038/3 450056.m000.cfc userAA long sechaos 3016 1 S 82:26 m038/0
上記ように全てのPBSジョブが status = S (suspend) の状況にあります。これは何かおかしくないでしょうか？
恐らく他利用者のarray jobsが流れているのでしょう。
qstat-n1 に -t オプションを追加してください。
% qstat-n1 -t | grep m038 Job ID Username Queue Jobname SessID NDS S ETime Node Alloc --------------- -------- -------- ---------- ------ --- - ----- ---------- 435526.m000.cfc userAA long tpf 19060 1 S 1411: m038/1 435789.m000.cfc userAA long tpf 14894 1 S 1339: m038/2 437685.m000.cfc userBB long 65_7_ml5_t 19188 1 S 927:1 m038/3 450056.m000.cfc userAA long sechaos 3016 1 S 82:26 m038/0 451693[251].m00 userCC mid c10ht.log 26201 1 R 02:41 m038/0 451693[252].m00 userCC mid c10ht.log 26413 1 R 03:07 m038/0 451693[253].m00 userCC mid c10ht.log 26655 1 R 02:41 m038/0 451693[254].m00 userCC mid c10ht.log 26794 1 R 02:54 m038/0
ご覧のように現在は利用者 userCC のarray jobs (451693[251-254])が流れ、他ジョブが suspend されています。
こうした状況は、複数の利用者による多数ジョブの qsub や qdel が繰り返される状況で時折り発生します。
障害ではありませんので、先行ジョブの終了まで今しばらくお待ちください。
(最終更新日 2025年6月3日)
私のコードをオプション -shared-intel -mcmodel=medium を付けてコンパイルし、qsubを使って投入しました。
しかし、以下のエラーが出て終わります。
./a.out: error while loading shared libraries: libifport.so.5: cannot open shared object file: No such file or directory
他のコードでは以下のエラーとなりました。
./a.out: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
qsub 経由ではなく m000 のコマンドライン上で直接実行すると、これらは正常に動きます。
何がおかしいのでしょうか？
利用者向け手引のPBS関係の記載の下部の「qsubスクリプト内でのモジュールのロード」にもありますが、PBSジョブの実行に必要なモジュールをqsubスクリプト内でも読み込んでおく必要があります。
もしqsubスクリプトがsh対応なら、実行させたいコードの前に以下を置いてください。
source /usr/share/Modules/init/sh module load intel/2024
もしqsubスクリプトがcshやtcsh対応なら、sourceするファイルを変更します。
source /usr/share/Modules/init/csh module load intel/2024
もしくは
source /usr/share/Modules/init/tcsh module load intel/2024
などです。
Intel環境以外のモジュールを読み込む際も上記と同様な記載を行います。
例えばPBSジョブ内でPython環境を同時に利用したいならば、以下のようです。
source /usr/share/Modules/init/sh module load anaconda intel/2024
必要な条件に応じて適切なモジュールを読み込んでください。
(最終更新日 2025年6月3日)
解析サーバのマニュアルによると、計算サーバの作業領域 /mwork{1,2} は解析サーバにも /misc/mwork{1,2} などとマウントされているとのことです。
しかし解析サーバ上で以下のコマンドを打っても、それらしいディレクトリは表示されません。
an09$ ls /misc fs50/ xd-work/
何がおかしいのでしょうか？
計算サーバの作業領域 /mwork{1,2} は解析サーバ上では自動マウント (automount) されています。
つまり、利用者がこれらの場所を必要とする際にしかマウントされず、それ以外の状況では見えません。
よって以下のように当該ディレクトリの内部を表示するか、もしくは直接そこへ cd してください。
an09$ ls /misc/mwork2/ an09$ cd /misc/mwork2/
(最終更新日 2025年6月3日)
module をロードすることで一応の利用は出来ます。
しかし m000 上のコマンドラインで IDL を実行することは避けてください。
他利用者の作業に大きな支障が発生します。
コマンドラインからのIDLの対話的な実行には解析サーバをご利用ください。
(最終更新日 2025年6月3日)
qstat-n1 の出力は以下の状況ですが、どこに問題があるでしょうか？
Job ID Username Queue Jobname SessID NDS S ETime Node Alloc --------------- -------- -------- ---------- ------ --- - ----- ---------- 543210.m000.cfc userABC openmp jobXYZ 9558 1 R 252:1 m234/12
上記の出力を見る限り、このジョブは 1 コアしか使っていませんね。
上記の m234/12 という表示がそれを示します (計算ノード m234 の第 12 コア)。
キュー openmp に投げたジョブが 4 コアを使う場合、qstat-n1 の表示は以下のように *4 が付加されます。
2コアの使用ならば *2 が現れます。
Job ID Username Queue Jobname SessID NDS S ETime Node Alloc --------------- -------- -------- ---------- ------ --- - ----- ---------- 550969.m000.cfc itootk openmp para_test 10810 1 R 569:5 m012/1*4
あなたのPBSジョブが 1 コアしか必要ないならば、openmp ではなく mid, long キューを使うべきでしょう。
本当に複数コアを使いたいなら、qsub 時に
$ qsub -l ncpus=使用コア数 ...
の指定が必要です (qsubスクリプト内に記すことも可)。
必要に応じて適切な選択肢を取ってください。
(最終更新日 2025年6月3日)
私が使いたい公開コードはCで書かれており、自分でコンパイルして使いたいです。
なおその実行にはかなり大きな計算資源が必要となりそうです。
はい、もちろん可能です。
m000上ではもちろんCコンパイラが使えます。
但しコンパイルとリンクに成功したとして、その後に当該のコードが望ましい形で動くか否かは計算の規模にも依存しますので、何も保証できません。
計算サーバや解析サーバの資源量に収まらない大型の計算をされる場合には、スーパーコンピュータやGPUクラスタの利用をご検討ください。
(最終更新日 2025年6月3日)
どのジョブも status が H となり、実行されません。
昨日までは普通に R 状態になり、走っていました。
何が起こったのでしょうか？
おそらく、PBSジョブからの標準出力・標準エラー出力を溜める領域に於いてquota上限に抵触したのでしょう。
利用手引きに記載があるように、この領域(/var/spool/pbs/)には 64 GB/userのquota制限があります。
この領域に於けるご自分の使用量は以下のようにして確かめられます。
xxxxxx はご自分のアカウント名に置き換えてください。
m000% egrep -e '(QUOTA|xxxxxx)' /pbslog/misc/userspace.txt TYPE NAME USED QUOTA POSIX User xxxxxx 64.5G 64G
上記では 64 GBのquota制限に対して 64.5 GBが使われており、いわゆるquota溢れとなっています。
PBSはジョブからの標準出力・標準エラー出力をこの領域に書き出そうとします。
しかしquota制限に抵触していると書き出せず、リトライを繰り返して最終的にstatusが H になります。
この挙動はOpenPBSの仕様だと思われます。
この状況に陥るのはPBSジョブが何らかの原因で異常終了したり計算ノードのハードウェア障害が生じた場合です。
システム構成上の理由により、ここでquota抵触が発生した状態からの回復は利用者自身には出来ません。
この状態が発生した場合にはお問い合わせフォームからお知らせを頂ければ、
当該領域を圧迫しているファイルを探して管理者権限で削除します。
なお、一般にコードが/var/spool/pbs/領域へ標準/エラー出力を大量に書き出すことは望ましくはありません。
標準出力・標準エラー出力の量が大きくなり過ぎないよう、ご自分のコードを見直すことを強くお薦めいたします。
(最終更新日 2025年6月3日)
例えば変数 pbs_extravar に "ABC" という値を入れ、それをqsubスクリプトに渡したいと考えています。
qsubコマンドのオプションを使い、このようなことは可能でしょうか？
はい、可能です。
それには qsub の -v オプションを使います。具体的には以下の書式
% qsub -v pbs_extravar=ABC シェルスクリプト
を使えば変数 pbs_extravar に値 "ABC" が入り、それがシェルスクリプトに渡されます。
複数の変数に同時に値を渡すこともできます。
例えば
% qsub -v pbsvarX=ABC,pbsvarY=DEF シェルスクリプト
とすると変数 pbsvarX には値 "ABC" が入り、変数 pbsvarY には値 "DEF" が入ります。
なおこの場合、変数=値 の組の間にスペースを含めないようにしてください。
例えば
% qsub -v pbsvarX=ABC, pbsvarY=DEF シェルスクリプト
などとすると、pbsvarY=DEF の部分は qsub の別種の引数と解釈されてしまいます。
その結果として変数 pbsvarX の値は渡りますが、変数 pbsvarY の値はシェルスクリプトに渡らなくなります。
詳しくは qsub のオンラインマニュアルなどを参照してください。
(最終更新日 2025年6月3日)
I tried vi, vim, and emacs, but in any of the environments, backspace key does not function as I had expected.
It just produces characters like "^?".
How can I solve this?
Can you try removing the description
stty erase ^H
that may be in your ~/.bashrc or ~/.bash_profile or ~/.zshrc, and login again?
Our experiment tells us that this would fix the issue.
Files like ~/.vimrc does not matter in this case.
Also, we found that this issue does not happen when you use csh or tcsh.
(Last updated 2025 June 3)
その他の物事に関する質問
Webログインした後で行う操作を教えてください。
これは容易です。まず、Webログインした状態でご自分の登録情報をご覧ください。
ページの上段に「○○○○ さん、ようこそ！|ログアウト」という表示があると思います。
この ○○○○ をクリックすると登録情報のページに行きますので、「編集」をクリックし、
そこの Email のボックス内にあるメールアドレスを書き換え、末尾にある「保存」をクリックして保存します。
(最終更新日 2024年以前)
Tell me what I should do after I log-in on my web area.
It is easy. First, login our webpage with your account, and see your account information.
You will see a link entitled "○○○○ さん、ようこそ！| ログアウト" at the top of each page.
Click "○○○○", and you will find your account information.
Then click "Edit", change your e-mail address in the "Email" box, and click "Save" at the bottom.
(Last updated 2024 or before)
世の中にある類似のサイトではそれが出来ますが、CfCAのウェブサイトではできないのでしょうか？
申し訳ございませんが、現状ではシステム上の制約により投稿後のPDFファイルをご確認頂けません。
ファイル内容の修正を行いたい場合や投稿の成否が不安な場合には、ご面倒ですが再提出をお願いします。
(最終更新日 2024年以前)
氏名を手で記入しようとしましたがそれも拒否されます。
このままでは承認が出来ないのですが、どうすれば良いでしょう？
私が受け取った電子メールに記されていた「これをコピペせよ」というURLは以下です。
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請
おっしゃる通り、学生からの申請については指導教員の確認を取るためすべての教員宛てに以下のメールが届くようになっております。
申請を受理するためには貴方の確認が必要です。次のURLから申請内容を確認後、送信ボタンを押してください。
URLが途中で改行されている場合には、"https://www.cfca.nao.ac.jp/supervisor_approval" から "student=○○○○" までの文字列(URL)をコピーし、ブラウザのURL欄に手動でペーストしてください。
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請 カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
しかし教員の皆様のお手元の環境(メーラ等)によっては上記のようにURLが途中で改行されます。
誤ってこの一行目だけをコピペすることで、正しくないページに誘導されることがあります。
今回ご報告されたものはその一つであり、上記URL
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請
カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
の一行目だけをコピペした結果であると想像されます。
これを避けるためには電子メールに記されているURLのすべて(複数行にわたり)コピーし、それを一行のURLとしてブラウザのURL欄に手動でペーストしてください。要するにURL
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請 カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
を手動で作ることになります。
(最終更新日 2024年以前)
I received an e-mail entitled "○○○○ 様の申請書確認依頼", but the URL seems weird. The e-mail tells me to copy
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請
カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
and paste it on my browser. However, the copied URL does not seem to work.
What should I do to reach the correct place?
This problem was presumably caused by your mailer application. You must have received an e-mail as follows:
申請を受理するためには貴方の確認が必要です。次のURLから申請内容を確認後、送信ボタンを押してください。
URLが途中で改行されている場合には、"https://www.cfca.nao.ac.jp/supervisor_approval" から
"student=○○○○" までの文字列(URL)をコピーし、ブラウザのURL欄に手動でペーストしてください。
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請 カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
However, some mailer application folds the URL description with newline characters, and divide them into several lines such as
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請
カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
This is probably because the mailer application regards text blanks as newlines.
Then if you copy just the first line of the folded URL, it would create an incomplete webpage.
To avoid this, bunch all the URL descriptions into a single line by hand such as
https://www.cfca.nao.ac.jp/supervisor_approval?id=7017&name=□□□□&email=aaaaaabbb[dot]ccc[dot]ddd[dot]eee&category=XC50利用申請 カテゴリXC-B (2019年度)&position=△△△△&student=○○○○
and paste it on your browser. It would probably take you to the right place.
(Last updated 2024 or before)
もしも使える可能性があれば利用申請を提出したいです。
もしあなたが日本国内の大学院で修士または博士号を取得されている場合は、可能です。利用申請資格の項目2を御覧ください。
該当する学位がない場合は、原則的には日本国内の研究機関・大学院にポストを持つ研究者あるいは学生であることが必要となります。
上記いずれにも該当しない場合は、プロジェクト長の判断に任されます。
また、この場合には利用開始前に該非判定の通過が必要となります。詳しくはこちらのページをお読みください。
(最終更新日 2024年以前)
どこかのページに情報がまとまっていたりしませんか？
当方のウェブサイトの構造が複雑なためこうした重要な情報がきちんと伝わっておらず、申し訳ございません。
上記のご質問への回答はこちらのページ「申請時期と利用期間」に集約されておりますので、是非ご覧ください。
(最終更新日 2024年以前)
そのための旅費は支給されるのでしょうか？
なるべく支給したい所ではありますが、その時々の予算状況に依存するので、一概には言えません。
支出不可な場合もある事をご承知おきください。
なおCfCA主催の講習会に於ける旅費支給の原則がこちらのページにまとまっています。
旅費支給のために必要な振込口座届出書についての説明もありますのでご覧ください。
昨今は講習会もzoomやWebExを用いたハイブリッドまたはオンライン開催になることが増えています。
その場合には旅費等の支給はもちろんありませんが、参加しやすくなる面はあるでしょう。
そのような形態での参加もぜひご検討ください。
(最終更新日 2025年5月23日)
はい、こちらにあります。
これらは原則として年に一度、7月上旬に更新されています。
(最終更新日 2024年以前)
それでも今年度の成果報告を提出する必要はありますか？
これはあなたの言う「アカウント」がどの種類のものであるかに依存します。
それがCfCAのウェブアカウントのみを指すならば、それはあなたがスパコンや計算サーバ等の利用申請書を提出しなかった、若しくは申請書を提出したが不採択となったことを意味するでしょう。
要するにあなたは共同利用計算機を使えなかった訳ですから、成果報告を提出する必要はありません。
一方、もしもあなたがスパコンや計算サーバらの利用申請書を提出し、それが採択された上での「アカウント」(いわゆるsshアカウント)を意味しているならば、成果報告を提出して頂く必要があります。
これはあなたが機材にログインして実際に利用したか否かには関わりません。
共同利用計算機の利用申請書を提出し、審査を経て採択されたすべての利用者が負う責務です。
(最終更新日 2025年5月23日)
例えばこちらのページ以下で一覧が公開されている論文の中には、DOI情報を辿ると登録されている出版年がここに掲載されているものと異なる論文がある気がします。
これはどのような理由でしょうか？
また、将来的にこの不整合が解消される見込みはあるでしょうか？
端的にお答えしますと、この現象はDOIのデータベース更新の頻度と時期の関係から生じるものです。
そしてこの不整合の解消が不可能とは言いませんが、数ヶ月や一年単位で計画される中期的作業になることを御了承ください。
以下ではもう少し詳しく、一般的な原則と事情を説明いたします。
冊子体の出版年、つまり論文の刊行年を定めるのは出版社です。刊行年は巻号・ページとセットで決定されます。
昨今の出版社の大半は、論文が受理されると直ちにそれにDOIを付与します。
それに加えて多くの雑誌では、正式な出版前にDOIが与えられた論文をオンラインで先行公開します。
この時にはもちろん刊行年の数値情報もDOIデータベースに与えられますが、それは最終的なものではなく、仮の数値です。
論文の最終的かつ公式な刊行年は出版社が後日改めて定めます。
冊子形態を持つ雑誌であれば、冊子形態の出版年がその位置を占めるようです。
そして、その数値は論文の受理時にDOIのデータベースに与えられた刊行年と異なることがあります。
これが上述した不整合の原因です。
経験的に、論文の受理日が12月末に近い場合にはこうした事態が発生しやすいように見えます。
DOI情報を一元的に管理するのはCrossRefという組織です。
しかしDOIに付与される情報の信頼性を担保するのはそのDOIを申請して授与された側、つまり出版社です。
まともな出版社なら、後から改めて確定させた論文の書誌情報がDOI取得当時のものと異なることが分かった時点でCrossRefに通知し、DOI情報を更新してもらうことでしょう。
CfCAがウェブ公開している計算機共同利用者の出版論文はDOIのデータベースからスクリプトにより自動的に取得されており、しかも出版直後のものが多いです。
これにより、上記の刊行年の不整合を内包している可能性を否定できません。
この不整合の解消作業は手動になるので (全情報に関してスクリプトを動かし、結果を検証して修正する)、高頻度では行えません。
また、出版社がまともでない場合には(上記の更新作業をさぼっている)、いくら私達が作業しても不整合は解消されません。
けれども、兎も角もウェブページ上では各論文のハイパーリンクから出版社のサイトへ飛べることは間違いありません。
従って、こうした不整合があったとしてもそのための実害は極小であることをご理解いただければと思います。
(最終更新日 2024年以前)
復旧してもらえませんか？
残念ながら、一旦削除されたファイルは復旧できません。
利用者のデータ保全は利用者自身が責任を負うべき事柄です。
このことは本部局が運用するすべての共同利用計算機について共通です。
(最終更新日 2025年5月23日)
削除をお願いします。
諒解しました。
ご本人であることを確認でき次第に削除作業を行いますので、
こちらの問い合わせ窓口よりその旨をご連絡ください。
(最終更新日 2024年以前)
電子メールで送付された初期パスワードを目で見て、手で打ち込んでいます。
どこに問題があり、私は何をすれば良いでしょうか？
見間違いがあるかもしれません。
ご利用の端末がお使いのフォントによっては、幾つかの文字の区別が難しい場合があります。
こちらのQAもご覧になり、今一度ぜひ慎重にお試しください。
なお初期sshパスワードの入力は電子メールからのコピペがお薦めです。
コピペを繰り返してもsshログインできない場合には改めてお知らせください。
(最終更新日 2025年5月23日)
今からでも申請を受け取って貰えるでしょうか？
いいえ、受け取れません。
公平性の観点から、締切日時を過ぎたら申請書は一切受け付けません。
どのような理由があっても不可です。
随時申請カテゴリへの申請をご検討ください。
また大型計算機の共同利用を行う機関はCfCAだけではなく、他にもあります。
以下のページなどをご一読ください。
(最終更新日 2025年5月23日)
Do you still receive my application?
No, we don't.
In the interest of fairness, we WILL NEVER accept applications that are past the deadline for any reason.
We appreciate your understanding.
Note that CfCA/NAOJ is not the only institute that operates large-scale open-use computing facility in the academic community.
You may find resources that you need through the following websites:
- Yukawa Institute for Theoretical Physics, Kyoto University
- Computer resources that HPCI Program provides
(Last updated 2025 May 23)
特に最寄駅(武蔵境駅や調布駅)から徒歩で行けないのが厳しいです。
不便であるか否かは個人の感覚よる部分が大きいでしょう。
徒歩でも来られないことはなく、たとえば武蔵境駅からは50分間も歩けば到着します。
しかし天候が悪い日や炎天下では、確かにそれは厳しい条件ですね。
国立天文台の現在の立地に関する歴史的な経緯についてはこちらのページが詳しいので、お読みください。
(最終更新日 2025年5月23日)