random

@rkaneko様
ご連絡ありがとうございます！参加いただけるとのこと承知しました。どうぞよろしくお願いします。

Dear Kaneko-san,

Thank you very much for sharing the information!
It is an interesting project, particularly the precipitation categorization for evaluation. I am looking forward to having more discussion with you in the future!

Best,
Gaohong

@gyin
Dear Yin-san,

Thank you for looking my slide!
Yeah, I would like to discuss with you too!
I'm looking forward to hearing about your next progress.

Best,
Ryo

@gyin-san
Please use the following environment for netCDF4.
For C language
/export/trmm5/tool/RHEL8/gnu/netcdf-c-4.4.1.1
For Fortran
>/export/trmm5/tool/RHEL8/gnu/netcdf-fortran-4.4.4

Dear @uwatoko -san,

Thank you so much for your reply! I will try with the information you provided.

Best regards,
Gaohong

Dear @takao-y -sensei, @uwatoko -san, @yamamoto.kosuke -san,

I run classifiers for sites A-C on JAXA server and sites D-E on isotope3.

For each site and each month, it will generate three folders: (1) data-training (saved training data); (2) data-model (saved classifiers); and (3) data-svm (intermediate files combining training data of all 14 years). The size of them are approximately 2/5, 1/5, 2/5 of all storage, respectively.

If we want to keep all of the files, then the current storage is just about enough for sites A-C (or slightly smaller; site B running not finished yet). We will need more space for sites D-E (Site D folder size is 8.3T, and site E is 5.8 T).

If we do not need to save the intermediate files (data-svm), then the current space should be enough for all sites and all months. In my opinion, there is no need to save the intermediate files, but in case you need them, can I have your guidance on this? Thank you very much!

Best regards,
Gaohong

Dear Yin-san,

Thank you for your reply.
I don’t think the intermediate files are necessary to keep.
If you need additional disk-space to task for conversion of data, please let us know.
Thanks.
Best Regards,
T. Yoshikane

@uwatoko さま
ありがとうございます。今の所、中間ファイルを削除すれば問題なさそうです。対処が難しくなりましたら、相談させていただければ幸いです。
よろしくお願いいたします。

@takao-y 様
了解しました。また、何かありましたらご依頼ください。

芳村様
承知いたしました。
（連絡が遅くなり申し訳ありません）
会議終了後に確認をいたします。

@takao-y 先生
はい。そこは大丈夫で、今の
39時間の入力データ(バイナリ）のサイズはそれぞれ以下のようになっています。
siteA:3225600(byte) =(1601204(39+3))
siteB:3528000(byte) =(1501404*(39+3))
siteC:3292800(byte) =(1401404*(39+3))
siteD:2069760(byte) =(1101124*(39+3))
siteE:1344000(byte) =(100804(39+3))
宜しくお願いします。

@uwatoko さま
ありがとうございます。それでは、いくつかの段階に分けてデータ出力（可能なら図示）して確認していっていただけますでしょうか。どこで問題が起こっったのか分かれば対処は簡単にできるかと思います。

@takao-y先生
上記、了解しました。
すみません、確認させていただきたいところがあります。
上記はプログラムの情報をそのまま使っているですが、MSMの39時間予報
の入力のところを39+3で計算しているのですが、このプラス３というのは何
でしょうか。

@takao-y先生
上記、了解しました。
すみません、確認させていただきたいところがあります。
上記はプログラムの情報をそのまま使っているですが、MSMの39時間予報
の入力のところを39+3で計算しているのですが、このプラス３というのは何
でしょうか。

@uwatoko さま
説明不足で申し訳ありません。私の方では、39+3がどのようにして得られたものなのかよくわかっていません。というのもソースコードに39+3と指定した箇所はなかったと思います。39+3というのはどのようにして得られた数値でしょうか。

参考までに、オリジナルのコードをそのまま使用して計算が正常にできているか確認をお願いできますか？

例えば、step02-make_classifier.shではレコード数をm3=${TIME2}${TTRAIN}${NLAT} という形で指定しています。TIME2が1ヵ月の3時間毎のデータ数（1月なら248)、TTRAINがデータの年数:ここでは2007年から2018年までの12年間、NLATが緯度方向のグリッド数（100)です。step01-make_training_data.shで緯度方向のデータをまとめてバイナリ化することによりファイルのオープン数を減らしてI/Oへのアクセスの負担を軽減しています。恐らくこの辺りの設定に問題があると推測しているのですが、39+3というのがどこにあるのか、よくわかっていません。私のプログラムに問題があるのであれば、39+3に相当するプログラム部分があると思うのですが。恐らく、プログラムのどこかで変数の数値を出力したものと思いますが、そのプログラムと変数を教えていただければ幸いです。よろしくお願いいたします。

今、気づいたいのですが、上記のディメンジョンはデータサイズから計算されたものでしょうか。だとするとディメンジョン自体が間違っていると思います。基本的には、auto-allgrid.shでxnum?,ynum?を指定することにより、プログラムの方で自動的に変換されますので、特にデータサイズを意識する必要はありあせん。入力データサイズは(特徴量のサイズ441+目的変数1緯度方向のグリッド数)4byteとなっていますので、ご確認いただければと思います。yyyymm-svm_lon.datについては、step01-make_training_data.shで出力されます。step02-make_classifier.shではcatで1ヵ月のデータ数24812年間12年間(特徴量の範囲+目的変数:442)*緯度方向のデータ数が1ファイルのデータサイズになります。
私のプログラムを利用される場合は、auto-allgrid.shで設定していただき、ファイルサイズを確認する必要がある場合は、適宜変数部分をプリント出力してご確認いただく方が早いかと思います。よろしくお願いいたします。

@uwatoko さま
バイナリ化の概要を添付いたします。ご参考にしていただければ幸いです。

ちなみに39時間予報の入力ファイルでは時間方向のデータ数は248ではなく39ですね。

@takao-y 先生
すみません、お時間があれば、zoomで直接話をさせていただけないでしょうか。

@uwatoko さま
今週はあまり時間がないので、slackで情報共有していただければありがたいです。この件に関しては、口頭で説明するよりもslackでプログラムを示しながら情報交換した方が早く解決すると思います。原因さえ分ければ、すぐに解決すると思います。

@takao-y様
了解しました。お忙しいところ申し訳ございません。
本日は担当者がお休みしているので、明日ご相談させてください。

状況を把握するために、以下にご回答いただけないでしょうか。
1. 入力データのバイナリサイズとは具体的にはどのファイルでしょうか
2. オリジナルのプログラムでは100x100の領域で次元設定していますが、それぞれのサイトに合うように修正されていますでしょうか
3. オリジナルのプログラムの動作確認をしていただけましたでしょうか。
よろしくお願いいたします。

@takao-y様
上記の質問は明日、回答します。
宜しくお願いします。

@uwatoko さま
ありがとうございます。
承知いたしました。
よろしくお願いいたします。

@takao-y 様
ご依頼の件、担当に確認しました。

１．入力データのバイナリサイズとは具体的にはどのファイルでしょうか

入力データとは
step02-make_testing_data.sh
の52行目でopenするrsms-yyyymmdd.grd ファイルを指しています。

２．オリジナルのプログラムでは100x100の領域で次元設定していますが、それぞれのサイトに合うように修正されていますでしょうか

step02-make_testing_data.sh　のidim2 jdim2 に指定する引数を追加しています。指定する値はそれぞれ以下のようにしています。
siteA: idem2=160, jdim2=120
siteB: idem2=150, jdim2=140
siteC: idem2=140, jdim2=140
siteD: idem2=110, jdim2=112
siteE: idem2=100, jdim2=80

３．オリジナルのプログラムの動作確認をしていただけましたでしょうか。

オリジナルのままでは動作させておりません。
オリジナルのまま動作させる場合、
入力データ（step02-make_testing_data.shの52行目でopenするファイル）
はどのようにすればよろしいのでしょうか。

宜しくお願いします。

@uwatoko さま
ありがとうございます。詳細についてはメールで送付いたしました。ご確認いただけますでしょうか。よろしくお願いいたします。

@takao-y先生
39時間の入力データ(バイナリ）のサイズはそれぞれ以下のようになっています。
siteA:3225600(byte) =(1601204(39+3))
siteB:3528000(byte) =(1501404*(39+3))
siteC:3292800(byte) =(1401404*(39+3))
siteD:2069760(byte) =(1101124*(39+3))
siteE:1344000(byte) =(100804(39+3))

上記の39+3の部分です。
39時間予報のデータなので、39時間はわかるのですが、プラス３が
わかってないです。

宜しくお願いします。

@takao-y 先生
下記の返事をしようと思っていたのですが、プログラムを頼んでいた人の
ミスがわかりましたので問題ありません。
39＋３の所がミスで、39＋1が正解ですね（39時間予報分＋初期時刻1時間=39+1）。
MSMの39時間予報のの入力データ(バイナリ）のサイズは下記が正解であることがわかりました。
siteA:3225600(byte) =(1601204(39+3))　→　siteA:3225600(byte) =(1601204*(39+1))
siteB:3528000(byte) =(1501404*(39+3))　→　siteB:3528000(byte) =(1501404*(39+1))　
siteC:3292800(byte) =(1401404*(39+3))　→　siteC:3292800(byte) =(1401404*(39+1))　
siteD:2069760(byte) =(1101124*(39+3))　→　siteD:2069760(byte) =(1101124*(39+1))　
siteE:1344000(byte) =(100804*(39+3))　　→　siteE:1344000(byte) =(100804(39+1))　
これが問題点の決定的なところがわかりませんが、ひとつはこれだとわかりました。
お手数をおかけしました。

@takao-y 様：
はい。可能です。坂本 和宏 <sakamoto_kazuhiro@restec.or.jp>というものです。
本日はお休みしてますが、メールしていただいても大丈夫です。

@keiyoshi08 先生
情報ありがとうございます。JAXAでは今のところ良さそうな解が他でない（課金するとしてもユーザごとのライセンスとなり、新規追加が面倒そう）ので、東大のEnterprize契約で我々も利用できるのであれば大変ありがたいです。
（@uwatoko さま、RESTECでの動き含め何かご意見あればお願いします）

@keiyoshi08 先生、@yamamoto.kosuke様
当初、アクセスできるのは 1 チャンネルのみではありますが、シングルチャンネルゲストは無料なので、その枠でできないかと考えていました。「コネクト」機能が特別に使えるのであれば、そちらの方が良いと思います。
尚、mattermostも検討していますが、時間的には間に合わないので、「コネクト」機能でできないことがあれば、次年度提案はありかと思います。あと、discordもありのよう気もしますが、セキュリティがちょっと気になります。

@uwatoko様
ありがとうございます。シングルチャンネルゲストって、一つのワークスペースの中の１チャンネルのみ無料で利用できるってことなんですね。。これだとなかなか不便かもしれませんね。
> • シングルチャンネルゲストは無料で、アクセスできるのは 1 チャンネルのみとなっています。ワークスペースの有料アクティブメンバー 1 人につき 5 人まで、シングルチャンネルゲストを招待できます。例えば、ワークスペースのメンバー数が 10 人の場合、招待できるシングルチャンネルゲストは最大 50 人です。