04_machine-learning

@yamamoto.kosukeさんがチャンネルに参加しました

@kobayashi_yusukeさんがチャンネルに参加しました

@uwatokoさんがチャンネルに参加しました

@takao-yさんがチャンネルに参加しました

@keiyoshi08さんがチャンネルに参加しました

@takao-y
吉兼先生

先日の打合せではありがとうございました。
打合せでお話しのございました1点ではなく7x7の49点 で計測した結果をお伝えいたします。

-----
RをPythonに変換したプログラムでの全体の処理時間計測
環境: EORCの計算機(zico-n)

処理時間:8時間46分10秒
(auto.shの開始時間から終了時間まで)

パラメータ:
テスト年:2007～2018年の7月
学習年:2007～2018年の7月(テスト年を除く)
データ: RESTECで全国を5つに分けて作成したMSM,解析雨量データセット
サイト:siteC(西日本・九州)
地点(x,y) 7x7の49点
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70 80'
ガンマ: 0.5,0.05,0.005,0.0005,0.00005,0.000005,0.0000005,0.00000005の8通り
コスト:10
エプシロン:0.001
-----

また、吉兼先生のRでの時間も別途計測しました。こちらは吉兼先生のデータを用いて行っております。
-----
Rでの全体の処理時間計測
環境: EORCの計算機(zico-n)

処理時間:18時間18分2秒
(auto.shの開始時間から終了時間まで)

パラメータ:
テスト年:2007～2018年の7月
学習年:2007～2018年の7月(テスト年を除く)
データ: 吉兼先生のサンプルデータデータセット(MSM,レーダ)
地点(x,y) 7x7の49点
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70 80'
ガンマ: 0.5,0.05,0.005,0.0005,0.00005,0.000005,0.0000005,0.00000005の8通り
コスト:10
エプシロン:0.001
-----

計算は2台で並行して行いますが、１つあたりの時間がかかりすぎておりますので、時間がかかりすぎていることに対する対応は検討させてください。

以上、よろしくお願いいたします。

@kobayashi_yusuke 小林様

ありがとうございます。少し遅い気もしますが、12年間全てをデータ変換から実施するとそのくらいはかかるのかもしれません。もしよろしければ、結果の図を添付してもらえますでしょうか。

@takao-y
吉兼先生

RをPythonに変換したプログラムでのグラフを添付します。
パラメータは以下のとおりです。
また、現在RとPythonでのstep別の処理時間を計算しております。
よろしくお願いします。


全体の処理時間計測
環境: EORCの計算機(zico-n)

処理時間:8時間46分10秒
(auto.shの開始時間から終了時間まで)

パラメータ:
テスト年:2007～2018年の7月
学習年:2007～2018年の7月(テスト年を除く)
データ: RESTECで全国を5つに分けて作成したMSM,解析雨量データセット
サイト:siteC(西日本・九州)
地点(x,y) 7x7の49点
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70 80'
ガンマ: 0.5,0.05,0.005,0.0005,0.00005,0.000005,0.0000005,0.00000005の8通り
コスト:10
エプシロン:0.001
-----

@kobayashi_yusuke 小林様。ありがとうございます。図を見る限り正常に作動しているように思います。それでは、同様にしてRegion AからEまで同様に実施していただけますでしょうか。領域の広さの違いと欠損値に注意する必要がありますが、基本的には、それぞれの領域に対してauto.shを変更すれば大丈夫だと思います。

@takao-y
吉兼先生
お返事ありがとうございます。正常に作動しているように思えるとのご意見をいただき、ありがたく思います。
同様にしてsiteAからsiteEまで処理するにあたり、領域の大きさや形が異なりますが、xnumとynumは20から80までの10ごとでよろしいでしょうか。siteごとに変える必要がございましたらご教授ください。
まずは欠損値の処理の対応を行い、次にsiteごとにガンマ値を変えたグラフを出力したいと考えております。


siteAからsiteEの位置は以下のとおりです。
X:東経、Y:北緯
 (X,Yともに0.06度ごと。南西を原点に北東へ正)
siteA　X:139-147 Y:40-46
siteB　X:135-143 Y:33-40
siteC　X:129-135 Y:30-36
siteD　X:126-131 Y:24-30
siteE　X:122-127 Y:23-28


パラメータは以下のとおりです。これでよろしければこのままsiteAからsiteEまで計算します。
------
allyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
testyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
months='07’

## Grids
xnums='20 30 40 50 60 70 80'
ynums='20 30 40 50 60 70 80'

nums='441'
rg2='10'
## Hyper-parameter (Gamma)
gm='0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'
## Hyper-parameter (Cost)
c2='10'
## Hyper-parameter (Epsilon)
ep='0.001'
------
よろしくお願いいたします。

@takao-y
吉兼先生
お世話になっております。

PythonとRによるstepごとの時間計測を行いましたのでお知らせします。
変更したのはstep02のためこの時間がRよりPythonのほうが短くなっておりますが、やはりstep02で時間はかかっております。
2台で並行して処理できますので、まずは欠損値の処理の対応を行い、次にこのままsiteごとにガンマ値等パラメータを変えて結果を出したいと考えております。
よろしくお願いいたします。

---
Python:
step01:5分
step02:8時間23分43秒
step03:46分55秒
step04,終了:1分10秒
全体:9時間16分48秒

---
R:
step01:4分48秒
step02:14時間13分23秒
step03:52分59秒
step04,終了:4秒
全体:15時間11分14秒
※step04,終了の時間でRが極端に短いのはstep04のRのほうのプログラムをLinuxの環境に調整しておらず、プログラムが動かない箇所があるためで、動けばPythonと同様1分程度かかると考えられます。

-----
パラメータ:
テスト年:2007～2018年の7月
学習年:2007～2018年の7月(テスト年を除く)
データ: RESTECで全国を5つに分けて作成したMSM,解析雨量データセット
サイト:siteC(西日本・九州)
地点(x,y) 7x7の49点
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70 80'
ガンマ: 0.5,0.05,0.005,0.0005,0.00005,0.000005,0.0000005,0.00000005の8通り
コスト:10
エプシロン:0.001
-----

@kobayashi_yusuke 小林様。ご報告ありがとうございます。「siteAからsiteEまで処理するにあたり、領域の大きさや形が異なりますが、xnumとynumは20から80までの10ごと」は領域の大きさに合わせて適宜調整してもらえますでしょうか。計算量が多くなるようでしたら、15グリッドごとのようにグリッド数を減らしても大丈夫です。よろしくお願いいたします。

@takao-y
吉兼先生

お返事ありがとうございます。吉兼先生のご意見を踏まえ、領域の大きさにあわせ以下のように設定しました。134グリッドある場合につきましては15グリッドごとにし、領域が100より小さい場合にはそれに合わせて減らしました。

siteAのメッシュ数 (x,y)= (100,134)
パラメータ
x='20 30 40 50 60 70 80'
y='20 35 50 65 80 95 110'

siteBのメッシュ数 (x,y)= (117,134)
パラメータ
x='20 30 40 50 60 70 80'
y='20 35 50 65 80 95 110'

siteCのメッシュ数 (x,y)= (100,100)
パラメータ
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70 80'

siteDのメッシュ数 (x,y)= (100,84)
パラメータ
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70'

siteEのメッシュ数 (x,y)= (84,84)
パラメータ
x='20 30 40 50 60 70'
y='20 30 40 50 60 70'

こちらで行いたいと考えております。
以上、よろしくお願いいたします。

@takao-y
吉兼先生

現状のご報告をいたします。
上記のパラメータでそれぞれのsiteで動かしたところ不具合が発生し、その対応を行っております。不具合が解消し、ガンマの結果が出た時点で、結果が出たところから吉兼先生にその結果のグラフをご報告いたします。そしてその時点で、ガンマのパラメータの決定と次のパラメータにつきましてご相談させてください。
よろしくお願いいたします。

@kobayashi_yusuke
小林様
もしよろしければ、不具合の内容を共有していただけますでしょうか。

@takao-y
吉兼先生
ご連絡ありがとうございます。
弊財団で作成したMSM,解析雨量のデータセットから指定された位置での学習、そしてパラメータごとの精度を出すことを行っております。
その作業におきまして、現在の不具合は、MSM,解析雨量のデータセットから読み込む場所および指定された位置の値の抽出のところで発生しております。現在、Fortranでセグメンテーションフォルトが起きる場合がありその対応を行っております。
このFortranの不具合は弊財団でFortranに詳しいものが修正を行っております。
引き続きよろしくお願いいたします。

@kobayashi_yusuke
小林様
ありがとうございます。セグメンテーションエラーの多くは、定義した変数の次元が一致していなかったり、ファイル指定が適切でなかったりします。もしよろしければ、フォートランのエラーメッセージを添付してもらえますでしょうか。

@takao-y
吉兼先生

お返事ありがとうございます。フォートランのエラーメッセージを添付します。またエラー発生箇所であるstep01-make_training_data.shも添付します。

直接ご覧になりたい場合には、
/goemon_disk2/trmmauto/AI_GSMaP/tool/ml-region3/ml-region3-check-CUI-siteA/
においておりますのでご覧ください。

siteAはセグメンテーションフォルトの原因となっている配列はmrain2(m,kk)で、kkの値が248の場合に発生します。
しかし必ず発生するわけではなくiyという変数の値が95または110の場合にkkが248になると発生します。
kkの範囲は(1~248),iyは(20,35,50,65,80,95,110)サンプルのynumの座標です。ynumはsiteAの大きさに応じて変更しております。
kk,iyの値はいずれも必ず処理する値で、なぜこの組み合わせになった場合だけセグメンテーションフォルトになるのかは分かっておりません。
auto-check.shのynumは以下のように修正しております。
xnums='020 030 040 050 060 070 080'
ynums='020 035 050 065 080 095 110'

原因がわかりましたらご教授いただけると大変ありがたく思います。
以上、よろしくお願いいたします。

@kobayashi_yusuke
小林様。ynums=110の時にセグメンエラーになっているので、恐らくこれは選択した領域の外側になっていると思われます。確認をお願いいたします。

@takao-y
吉兼先生

ありがとうございます。確認いたします。

@kobayashi_yusuke
小林様。確認の結果はいかがでしょうか。例えば、ynums の110を削除する、もしくは96などに変更して試してみると手っ取り早いかと思います。それから、フォートランのwarningが多くて見にくいので、warningをoffにした方が良いかもしれません。

@takao-y
吉兼先生
ご連絡ありがとうございます。今回の修正はFortranとshellに詳しいものが担当しているのですが、全国を5領域に分けたMSM,解析雨量を読み込むための修正(大きさが異なる、ハイパーパラメター解析対象地点の変更等)により、このセグメンテーションフォルトだけでなく、全体的に修正が必要になってくると考えております。今、その確認をお願いしておりますので、その進捗を随時ご報告いたします。
よろしくお願いいたします。

@kobayashi_yusuke
小林様。現時点の作業はハイパーパラメータを決めるための過程ですので、あまり難しく考えずにそれぞれの領域で臨機応変に対応していただければ問題ないかと思います。基本的にはxnums,ynumsを調整すれば済むと思います。あるいは何か別の問題があるのでしょうか。詳細に教えていただけますでしょうか。

@takao-y
吉兼先生
お返事ありがとうございます。臨機応変の対応承知しました。現在問題は、吉兼先生からいただいたサンプルのMSM、レーダのデータを弊財団で作成した全国5領域に区切ったMSM、解析雨量に切り替えて結果を出すというところです。もちろん、セグメンテーションフォールトのようにxnum,ynumで不具合を起こしているというのもございます。

y=110で選択した領域の外側とのことでしたので、一旦これを外した以下のパラメータで動かしてみたいと思います。
アドアイスありがとうございます。

siteAのメッシュ数 (x,y)= (100,134)
パラメータ
x='20 30 40 50 60 70 80'
y='20 35 50 65 80 95'

siteBのメッシュ数 (x,y)= (117,134)
パラメータ
x='20 30 40 50 60 70 80'
y='20 35 50 65 80 95'

siteCのメッシュ数 (x,y)= (100,100)
パラメータ
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70 80'

siteDのメッシュ数 (x,y)= (100,84)
パラメータ
x='20 30 40 50 60 70 80'
y='20 30 40 50 60 70'

siteEのメッシュ数 (x,y)= (84,84)
パラメータ
x='20 30 40 50 60 70'
y='20 30 40 50 60 70'

@kobayashi_yusuke
小林様。ありがとうございます。承知いたしました。５つの領域について、同時平行RUNができれば短時間で終わると思いますが、そちらの環境では可能でしょうか。同じファイルシステム内で、4RUN程度であれば問題なく作動すると思います。よろしくお願いいたします。

@takao-y
吉兼先生　
ご連絡ありがとうございます。弊財団で作成した５つの領域のMSMと解析雨量を用いたプログラムが正常に動くようにしましたら上記パラメータで結果を出します。
そしてその際の解析についてですが、2台のマシンを同時に動かせますのでまずそこで分散させます。そしてそれぞれで複数プロセスで動かすことで同時に処理をしたいと考えております。よろしくお願いいたします。

@kobayashi_yusuke
小林様。もし不都合がなければ、終了したものから図を添付していただけますでしょうか。
よろしくお願いいたします。

@takao-y
吉兼先生
ご連絡ありがとうございます。不具合の解消を弊財団でFortranに詳しいものが行っておりました。
プログラムを確認したところ、吉兼先生から頂いたプログラムにおきましてx,yの定義が逆であった箇所があったとのことです。

step01-make_training_data.sh / step01-make_testing_data.sh
のfortranプログラムの最初のところで定義している
parameter (idem2=${ydim},jdim2=${xdim},nn2=249,nn2b=248)
parameter (idem3=${ydim},jdim3=${xdim})
のxdimとydimを逆にして
parameter (idem2=${xdim},jdim2=${ydim},nn2=249,nn2b=248)
parameter (idem3=${xdim},jdim3=${ydim})
としたところ、セグメンテーションフォールトは発生しなくなりました。
これでsiteAを計算をさせており、他に不具合が出ずに結果が出ましたらご連絡いたします。

以上、よろしくお願いいたします。

siteD,siteEにつきましては別途計算させておりましたが、Fortranのセグメンテーションフォールトは発生しませんでしたが、
RuntimeWarning: invalid value encountered in true_divide
とどこかで0で割っているためエラーが発生しております。
こちらも別途原因を探り、不具合を修正したいと考えております。

@takao-y
吉兼先生

siteC,siteEにつきましてガンマの違いによる結果が出ましたのでお伝えいたします。
あわせて領域図も添付します。

siteCのパラメータは以下のとおりです。

allyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
testyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
months=${mon} #07
## Grids
xnums='20 30 40 50 60 70 80'
ynums='20 30 40 50 60 70 80'

nums='441'
rg2='10'

## Hyper-parameter (Gamma)
gm='0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'
## Hyper-parameter (Cost)
c2='10'
## Hyper-parameter (Epsilon)
ep='0.001'

また、siteEのパラメータは以下のとおりです。
allyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
testyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
months=${mon} #07
## Grids
xnums='20 30 40 50 60 70'
ynums='20 30 40 50 60 70'
nums='441'
rg2='10'
## Hyper-parameter (Gamma)
gm='0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'
## Hyper-parameter (Cost)
c2='10'
## Hyper-parameter (Epsilon)
ep='0.001'

なお、siteAについてはうまくpointに出力されず、siteC,siteDは相関係数がうまく出力されないエラーが発生しておりますので確認の上、修正いたします。

@kobayashi_yusuke
小林様。ありがとうございます。
図を見る限り、他の領域でも最適値はほとんど変わらないように思われます。相関係数が出力されないのは、データ欠損値の処理などで0割を起こしている可能性が高いと思います。もしフォートランをあまり得意とされていないのであれば、他の言語で変換していただいても構いません。もしpythonに慣れている場合は、pythonを使って変換された方が簡単かもしれません。
よろしくお願いいたします。

@takao-y
吉兼先生　お返事ありがとうございます。
相関係数が出力されない点を調べたところ、吉兼先生がおっしゃるとおり欠損値処理の問題のようで、欠損値を除外してグラフ出力の部分だけ動かしましたらグラフが出ました。そのため、欠損値除外するコードを入れたうえで現在siteBとsiteDでプログラム全体を動かしております。
フォートランは社内の別の者が担当しており、その者が修正を行っております。フォートランからpythonへの変換には時間を要すると考えられるため、このまま社内の者がフォートランの修正を行いたいと考えております。
以上、よろしくお願いいたします。

@takao-y
吉兼先生

siteD(南西諸島)につきましてガンマの違いによる結果が出ましたのでお伝えいたします。
エラーを修正し、グラフが出るようにいたしました。ご確認ください。
siteAは計算中、siteBは途中でエラーがでましたので修正いたします。

よろしくお願いいたします。

siteDのパラメータは以下のとおりです。
allyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
testyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'

months=${mon} #07
## Grids
xnums='20 30 40 50 60 70 80'
ynums='20 30 40 50 60 70'

nums='441'
rg2='10'
##
## Hyper-parameter (Gamma)
gm='0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'
## Hyper-parameter (Cost)
c2='10'
## Hyper-parameter (Epsilon)
ep='0.001'

@takao-y
吉兼先生
siteA(北海道)につきましてガンマの違いによる結果が出ましたのでお伝えいたします。
エラーを修正し、グラフが出るようにいたしました。ご確認ください。
残っているsiteBは途中でエラーが出ておりますので修正いたします。

siteAのパラメータは以下のとおりです。3桁に修正しております。

以上、よろしくお願いいたします。

allyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
testyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
#testyears='2015'
months=${mon} #07
## Grids
xnums='020 030 040 050 060 070 080'
ynums='020 035 050 065 080 095 110'

nums='441'
rg2='10'
##
## Hyper-parameter (Gamma)
gm='0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'
## Hyper-parameter (Cost)
c2='10'
## Hyper-parameter (Epsilon)
ep='0.001'

@kobayashi_yusuke
小林様。ありがとうございます。siteBについて、エラーメッセージを添付していただけますでしょうか。

@takao-y
吉兼先生
siteBにつきましてもグラフを出力することができました。後ほどお伝えいたします。

@takao-y
吉兼先生
siteB(東日本)につきましてガンマの違いによる結果が出ましたのでお伝えいたします。
エラーを修正し、グラフが出るようにいたしました。ご確認ください。

これでsiteA～siteEすべて出力できるようになりました。
ご確認いただいてsiteA～siteEそれぞれでのガンマのパラメータを確定させ、次のコストやエプシロンのパラメータのご指示をいただけると幸いです。
なお、コメントアウトされているコストとエプシロンのパラメータは以下のとおりです。
## Hyper-parameter (Cost)
#c2='50 40 30 20 10 8 6 4 2 1'
## Hyper-parameter (Epsilon)
#ep='1.0 0.1 0.01 0.001 0.0001 0.00001'


また、今回作成したグラフのsiteBのパラメータは以下のとおりです。

以上、よろしくお願いいたします。

allyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
testyears='2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018'
months=${mon}
## Grids
xnums='020 030 040 050 060 070 080'
ynums='020 035 050 065 080 095 110'

nums='441'
rg2='10'
##
## Hyper-parameter (Gamma)
gm='0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'
## Hyper-parameter (Cost)
c2='10'
## Hyper-parameter (Epsilon)
ep='0.001'

@kobayashi_yusuke
小林様。ありがとうございます。早速で申し訳ないのですが、次は7月についてお願いできますでしょうか。

@takao-y
吉兼先生
お返事ありがとうございます。今回の計算対象はsiteA～Eまですべて7月で行っております。グラフをご確認いただき、ご意見をいただけると幸いです。

@kobayashi_yusuke
小林様。ありがとうございます。すみません。よく確認していませんでした。それでは、1月をお願いできますでしょうか。その後で、4月,10月も同様に実施していただけますでしょうか。

@takao-y
吉兼先生
承知しました。
ガンマにつきまして1月を行い、その後4月、10月も同様に行います。
結果が出ましたら改めてご連絡いたします。よろしくお願いします。

@kobayashi_yusuke
小林様。すみません。勘違いしていました。今はガンマだけだったのですね。それでは、CとEpsilonについても同様にお願いできますでしょうか。まずは7月ですね。

@takao-y
吉兼先生
ご連絡ありがとうございます。
7月につきましてsiteAからsiteEのコストとエプシロンを出すようにいたします。
まず、コストを決めるにあたってガンマを固定する必要がございますが、ガンマの値はいくつにすればよろしいでしょうか。
これまでご提示しましたグラフをもとにsiteA・siteB・siteC・siteD・siteEそれぞれのガンマ値をご教授くださると大変ありがたく思います。

またコストにつきまして、以下でよろしいでしょうか。
## Hyper-parameter (Cost)
#c2='50 40 30 20 10 8 6 4 2 1'

コストのグラフを出力するにあたって、プログラムの改修が必要ですのでそちらに着手いたします。

以上、よろしくお願いいたします。

@kobayashi_yusuke
小林様。ありがとうございます。基本的には相関係数の中央値でみてもっともパフォーマンスの良い値を選択していただけますでしょうか。Cについてはとりあえずそれで問題ないと思います。Cが終了しましたら、同様にepsilonをお願いいたします。

@takao-y
吉兼先生
承知いたしました。まずはコストのグラフ出力ができるようプログラム改修を行います。その後にsiteA～siteEまでガンマを相関係数の中央値で最大値として、7月を対象にグラフ出力をいたします。引き続きよろしくお願いいたします。

機械学習の入出力のバイナリ化ですが、経度方向で一括してバイナリ化することにより、I/Oへの負担を大幅に低減(1/経度方向のグリッド数)できました。これに伴い、識別器ファイルの生成も高速化し、今までの1/2以下の時間で終了できるようになりました。近日中に整備して皆様に使っていただけるようにいたします。
1kmへのダウンスケール実験もI/Oへの負荷をかけずに高速に処理できるようになると考えています。（当初は、全グリッドを一括で読み込むことを考えていたのですが、思った以上に行列計算にかなり時間がかかることから、データを小分けにして対処しています。計算効率的には小分けの範囲を少し拡大しても良いかもしれませんが、今後1kmダウンスケーリングを実施する際に処理する格子点数が多くなることを考慮すると、この方法が効率的かなと考えています。）
I/Oが大幅に軽減できたことにより、書き込み遅延などサーバーのトラブルのリスクが小さくなり、複数CPUによる並行処理も可能になると考えています。今は5つの領域に分けていますが、たとえば30領域に分けて並行処理をすることにより、全国1kmリアルタイムダウンスケーリングも現実的になると想定しています。
報告まで。

すばらしいです！詳細ぜひ教えて下さい。

@takao-y
吉兼先生

7月のsiteA～siteEのコストの結果が出ました。
コストは、どのパラメータも大きな差はございませんでした。
引き続き、コストの相関係数の中央値が最も大きいものを採用し、エプシロンを行います。
コストの結果は以下の通りです。(siteごとに1つずつ書き込みます)

@takao-y
吉兼先生

7月のsiteAのコストのグラフは添付のとおりです。
ガンマのパラメータは5x10の-7乗です。
この結果、コストは8を採用して、エプシロンを計算します。

@takao-y
吉兼先生

7月のsiteBのコストのグラフは添付のとおりです。
ガンマのパラメータは5x10の-6乗です。
この結果、コストは4を採用して、エプシロンを計算します。

@takao-y
吉兼先生

7月のsiteCのコストのグラフは添付のとおりです。
ガンマのパラメータは5x10の-7乗です。
この結果、コストは4を採用して、エプシロンを計算します。

@takao-y
吉兼先生

7月のsiteDのコストのグラフは添付のとおりです。
ガンマのパラメータは5x10の-8乗です。
この結果、コストは10を採用して、エプシロンを計算します。

@takao-y
吉兼先生

7月のsiteEのコストのグラフは添付のとおりです。
ガンマのパラメータは5x10の-3乗です。
この結果、コストは2を採用して、エプシロンを計算します。

各領域のコストの結果は以上となります。あわせて各領域の位置図を添付します。
引き続きよろしくお願いします。

@kobayashi_yusuke
小林様。ありがとうございます。epsilonについてもお願いいたします。

@takao-y
吉兼先生
小林です。お世話になっております。
epsilonにつきまして結果が出ましたのでご報告いたします。

2007～2018年の7月の結果は添付のエクセルファイルのとおりです。
epsilonは変化させても相関係数の中央値はほとんど変わりませんでした。
(MAE,RMSEでepsilon=1.0のみ大きい値となっております)

siteA 0.001
siteB 0.001,0.0001,0.00001(同じ)
siteC 0.01,0.001,0.0001,0.00001(同じ)
siteD 0.001
siteE 0.0001,0.00001(同じ)

今回の手法は以下のとおりです。
(1) cost=10, epsilon=0.001に固定し、gammaを'0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'と変化させ、相関係数の中央値が最も高いgammaを採用
(2) gammaを(1)で定めた値、epsilon=0.001に固定し、costを'50 40 30 20 10 8 6 4 2 1'と変化させ、相関係数の中央値が最も高いcostを採用
(3) gammaを(1)で定めた値、costを(2)で定めた値とし、epsilonを'1.0 0.1 0.01 0.001 0.0001 0.00001'と変化させ、相関係数の中央値が最も高いepsilonを採用

それぞれの結果のグラフは以下に示します。

7月のsiteAのepsilonのグラフは添付のとおりです。epsilonを変化させても相関係数の中央値はほとんど変わりませんでしたが、その中で最も高かったのは0.001です。

7月のsiteBのepsilonのグラフは添付のとおりです。epsilonを変化させても相関係数の中央値はほとんど変わりませんでしたが、その中で0.001,0.0001,0.00001が同じで最も高くなりました。

7月のsiteCのepsilonのグラフは添付のとおりです。epsilonを変化させても相関係数の中央値はほとんど変わりませんでしたが、その中で0.01,0.001,0.0001,0.00001が同じで最も高くなりました。

7月のsiteDのepsilonのグラフは添付のとおりです。epsilonを変化させても相関係数の中央値はほとんど変わりませんでしたが、その中で最も高かったのは0.001です。

7月のsiteEのepsilonのグラフは添付のとおりです。epsilonを変化させても相関係数の中央値はほとんど変わりませんでしたが、その中で0.0001,0.00001が同じで最も高くなりました。
最初のエクセルのまとめ、並びに各結果のグラフをご確認いただけると幸いです。

以上、よろしくお願いいたします。

@kobayashi_yusuke
小林様。ありがとうございます。ここで推定されたCとepsilonの最適値を用いて、もう一度gamma値について計算していただけますでしょうか。その結果をみた後で特に大きな変化がなければ、ハイパーパラメータを決定して良いかと思います。

@takao-y
吉兼先生
お返事ありがとうございます。今回推定されたCとepsilonを用いて、再度gamma値を計算いたします。その際のepsilonにつきまして、siteB,C,Eで最大が同値のため、以下のようにさせていただきます。

siteB:0.0001 (0.001,0.0001,0.00001で同じ)
siteC: 0.001 (0.01,0.001,0.0001,0.00001で同じ)
siteE 0.0001 (0.0001,0.00001で同じ)

結果が出ましたらご連絡いたします。
よろしくお願いいたします。

機械学習の入出力のバイナリ化ですが、概要図を添付します。
バイナリ化の前後でI/Oのアクセス数が1/nlat(緯度方向のグリッド数)になっており、書き込み遅延などによるサーバーへの負担を大幅に軽減できると思います。実行時間に関しては、今回70x70の領域で実施した結果、以前よりも10~20%程度早くなっていました。実行時間の大半が、識別機の作成であることを考慮すると、それほど時間短縮にはなっていません。ただ、同時並行数を増やすことによって、結果的に時間を短縮になるのではと考えています。
とりあえず、ソースコードを以下に置きました。時間があるときに試していただければ幸いです。
https://www.dropbox.com/s/x7r62s6z5960kkc/ml-region1-all-20200915.tar.gz?dl=0

@takao-y
吉兼先生
小林です。お世話になっております。
gammaにつきまして再解析した結果が出ましたのでご報告いたします。
結果はsiteA～siteEまですべて当初採用したgamma値が相関係数の中央値の最大でした。
cost,epsilon値等詳細は添付のエクセルファイルをご参照ください。

対象は、2007～2018年の7月です。

手法は以下のとおりです。
(1) cost=10, epsilon=0.001に固定し、gammaを'0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'と変化させ、相関係数の中央値が最も高いgammaを採用
(2) gammaを(1)で定めた値、epsilon=0.001に固定し、costを'50 40 30 20 10 8 6 4 2 1'と変化させ、相関係数の中央値が最も高いcostを採用
(3) gammaを(1)で定めた値、costを(2)で定めた値とし、epsilonを'1.0 0.1 0.01 0.001 0.0001 0.00001'と変化させ、相関係数の中央値が最も高いepsilonを採用
(4) costを(2)で定めた値、epsilonを(3)で定めた値とし、gammaを'0.5 0.05 0.005 0.0005 0.00005 0.000005 0.0000005 0.00000005'と変化させて再計算を行い、相関係数の中央値が最も高いgammaを確認

gammaの結果は結果は以下の通りです。(siteごとに1つずつ書き込みます)

siteAのガンマの再解析のグラフは添付の通りです。
ガンマのパラメータは5x10の-7乗で相関係数の中央値の最大となりました。

siteBのガンマの再解析のグラフは添付の通りです。
ガンマのパラメータは5x10の-6乗で相関係数の中央値の最大となりました。

siteCのガンマの再解析のグラフは添付の通りです。
ガンマのパラメータは5x10の-7乗で相関係数の中央値の最大となりました。

siteDのガンマの再解析のグラフは添付の通りです。
ガンマのパラメータは5x10の-8乗で相関係数の中央値の最大となりました。

siteEのガンマの再解析のグラフは添付の通りです。
ガンマのパラメータは5x10の-3乗で相関係数の中央値の最大となりました。
これにて、ハイパーパラメータがすべて決まりました。ご意見ありがとうございました。

次はこのハイパーパラメータを用いた推定に入ると考えております。
その作業は別途相談させてください。

以上、よろしくお願いいたします。

@kobayashi_yusuke
小林様。ありがとうございます。結果を見る限りは大きな違いはなさそうです。D,E領域については、もともとMSMの海上での再現性が良くないこともあるのでしょうか。もし時間がありましたら、D,Eについて島嶼領域（陸上）のみをピックアップして試していただけますでしょうか。琉球、八重山諸島の標高は高くてもせいぜい500m程度ですので、地形性降水の効果は小さいかもしれませんが。

@takao-y
吉兼先生
ご意見ありがとうございます。結果を見る限りは大きな違いはないとのご意見をいただき、ありがたく思います。時間がございましたら、D,Eについて島嶼領域（陸上）のみをピックアップして試したいと考えております。
ありがとうございました。

@kobayashi_yusuke
小林様。D,Eについてはいかがでしょうか。もし可能でしたら、1月、4月, 10月についても並行してお願いできますでしょうか。

皆様。吉兼です。
現在、小林さんに簡易実験を実施していただいていますが、以下の２点について検討できればと考えています。
1. 特徴量の範囲の季節による違い
2. バイナリ化した改良版での複数CPU実験
1.について、現在21x21(約105kmx105km)の特徴量の範囲を設定していますが、冬季と夏季で降水特性が異なることから、範囲を変更することによりパフォーマンスが変わってくる可能性があります。本件とは別のd4PDFの推定実験で気づいたことですが、夏季の場合、範囲を広げすぎると結果的に過大評価になる傾向があることが分かりました。夏季は線状降水帯のような狭い範囲で形成される降水が多く、特徴量を広く設定するとノイズも大きくなりあまり関係性のない降水まで関係があるかのように認識し、結果的に降水頻度自体が多くなってCDFを適用したあとで過大評価になるようです。もちろん、MSM-GPV自体の線状降水帯の再現性も影響するのですが、あまり広く取りすぎると、MSM-GPVの再現性の悪さがAIでの推定に影響を与えてしまうようです。d4PDFの実験結果から、60kmx60km程度が良さそうですので、特徴量の範囲を変えた調査もいくつか実施してみても良いのではと考えています。季節以外に地域による違いもありそうです。

2. は技術的な課題ですが、現在は5つの領域で実施していますが、実用面を考えるともっと細かく分割して並行処理を実施し、日本全域を同時に出力できるようになればと考えています。入力データのバイナリ化の改良版により、同時並行処理が可能と思いますので、例えば、陸域を中心に32分割して、32コアで同時並行処理を試していただくのは難しいでしょうか。バイナリ化によりメモリ消費も低減されていると思いますので、多分実行できるのではと考えています。さらにコア数を増やして64分割64コア同時並行ができればさらに実行時間は短縮されるのではないかと考えています。日本全域のバイアス補正データを統合できれば、TE-Japanへ入力も比較的容易になると思います。1kmでの運用を見据えて、さらに128コア, 256コア同時並行処理もできればと思いますが。深層学習に移行してGPUを活かした手法を開発した方が良いかなとも考えています。（個人的には今後は発展性のある深層学習に力を入れていきたいと考えています）

ご意見いただければ幸いです。

@kubota.takujiさんがチャンネルに参加しました

@takao-y
吉兼先生
お世話になっております。D,Eの件はまだ着手出来ておりません。申し訳ございません。
できあがりましたらご連絡いたします。

@kobayashi_yusuke
小林様。ご連絡ありがとうございます。もし難しいようでしたら後回しにして、1月,4月,10月を実施していただけますでしょうか。

@takao-y
吉兼先生
承知しました。1月、4月、10月を行います。結果が出ましたらご連絡いたします。

@kobayashi_yusuke
小林様。進捗はいかがでしょうか。もし問題などありましたら、遠慮せずにご連絡ください。

@takao-y
吉兼先生　ご連絡ありがとうございます。経過報告をせずに申し訳ございません。解析は順次進めております。結果が出ましたら改めてご連絡いたします。以上、よろしくお願いいたします。

@takao-y
吉兼先生
小林です。お世話になっております。

1月,4月,10月のgamma⇒cost⇒epsilon⇒gamma再解析が終わりましたのでご連絡します。
1月の各パラメータの一覧表と手法と学習年等を記載したものをexcelとして添付します。

以下にsiteごとに、gamma,cost,epsilon,gamma再解析ごとの結果を書き込みます。

1月のsiteAのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

1月のsiteAのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは8のため、これを採用します。
これを用いてepsilonを計算しました。

1月のsiteAのepsilonのグラフは添付のとおりです。
相関係数の中央値が最も高くなったepsilonのパラメータは0.01のため、これを採用します。
これを用いてgammaの再計算をしました。

1月のsiteAのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、1月のsiteAのパラメータは cost=8,epsilon=0.01,gamma=5x10の-6乗となりました。

1月のsiteBのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-5乗のため、これを採用します。
これを用いてcostを計算しました。

1月のsiteBのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは8のため、これを採用します。
これを用いてepsilonを計算しました。

1月のsiteBのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.01のため、これを採用します。
これを用いてgammaの再計算をしました。

1月のsiteBのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-5乗のため、これを採用します。
これで、1月のsiteBのパラメータは cost=8,epsilon=0.01,gamma=5x10の-5乗となりました。

1月のsiteCのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

1月のsiteCのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは4のため、これを採用します。
これを用いてepsilonを計算しました。

1月のsiteCのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.001(0.1と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

1月のsiteCのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、1月のsiteCのパラメータは cost=4,epsilon=0.001,gamma=5x10の-6乗となりました。

1月のsiteDのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

1月のsiteDのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは4のため、これを採用します。
これを用いてepsilonを計算しました。

1月のsiteDのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001(0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

1月のsiteDのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、1月のsiteDのパラメータは cost=4,epsilon=0.0001,gamma=5x10の-6乗となりました。

1月のsiteEのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-7乗のため、これを採用します。
これを用いてcostを計算しました。

1月のsiteEのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは10のため、これを採用します。
これを用いてepsilonを計算しました。

1月のsiteEのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.001(0.01と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

1月のsiteEのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-7乗のため、これを採用します。
これで、1月のsiteEのパラメータは cost=10,epsilon=0.001,gamma=5x10の-7乗となりました。

@takao-y
吉兼先生
小林です。お世話になっております。

続きまして、4月のgamma⇒cost⇒epsilon⇒gamma再解析が終わりましたのでご連絡します。
各パラメータの一覧表と手法と学習年等を記載したものをexcelとして添付します。

以下にsiteごとに、gamma,cost,epsilon,gamma再解析ごとの結果を書き込みます。

4月のsiteAのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

4月のsiteAのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは10のため、これを採用します。
これを用いてepsilonを計算しました。

4月のsiteAのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.001のため、これを採用します。
これを用いてgammaの再計算をしました。

4月のsiteAのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、4月のsiteAのパラメータは cost=10,epsilon=0.001,gamma=5x10の-6乗となりました。

4月のsiteBのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-5乗のため、これを採用します。
これを用いてcostを計算しました。

4月のsiteBのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは8のため、これを採用します。
これを用いてepsilonを計算しました。

4月のsiteBのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001 (0.001,0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

4月のsiteBのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-5乗のため、これを採用します。
これで、4月のsiteBのパラメータは cost=8,epsilon=0.0001 ,gamma=5x10の-5乗となりました。

4月のsiteCのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

4月のsiteCのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001 (0.001,0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

4月のsiteCのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、4月のsiteCのパラメータは cost=10,epsilon=0.0001,gamma=5x10の-6乗となりました。

4月のsiteDのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-7乗のため、これを採用します。
これを用いてcostを計算しました。

4月のsiteDのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは20のため、これを採用します。
これを用いてepsilonを計算しました。

4月のsiteDのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001 (0.001,0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

4月のsiteDのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-7乗のため、これを採用します。
これで、4月のsiteDのパラメータは cost=20,epsilon=0.0001,gamma=5x10の-7乗となりました。

4月のsiteEのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-8乗のため、これを採用します。
これを用いてcostを計算しました。

4月のsiteEのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは1のため、これを採用します。
これを用いてepsilonを計算しました。

4月のsiteEのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.001 (0.01と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

4月のsiteEのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-8乗のため、これを採用します。
これで、4月のsiteEのパラメータは cost=1,epsilon=0.001,gamma=5x10の-8乗となりました。

@takao-y
吉兼先生
小林です。お世話になっております。

続きまして、10月のgamma⇒cost⇒epsilon⇒gamma再解析が終わりましたのでご連絡します。
各パラメータの一覧表と手法と学習年等を記載したものをexcelとして添付します。

以下にsiteごとに、gamma,cost,epsilon,gamma再解析ごとの結果を書き込みます。

10月のsiteAのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

10月のsiteAのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは20のため、これを採用します。
これを用いてepsilonを計算しました。

10月のsiteAのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.001のため、これを採用します。
これを用いてgammaの再計算をしました。

10月のsiteAのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、10月のsiteAのパラメータは cost=20,epsilon=0.001,gamma=5x10の-6乗となりました。

10月のsiteBのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-6乗のため、これを採用します。
これを用いてcostを計算しました。

10月のsiteBのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは20(30,10と同値)のため、これを採用します。
これを用いてepsilonを計算しました。

10月のsiteBのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001 (0.001,0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

10月のsiteBのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-6乗のため、これを採用します。
これで、10月のsiteBのパラメータは cost=20,epsilon=0.0001 ,gamma=5x10の-6乗となりました。

10月のsiteCのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-7乗のため、これを採用します。
これを用いてcostを計算しました。

10月のsiteCのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは20のため、これを採用します。
これを用いてepsilonを計算しました。

10月のsiteCのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001(0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

10月のsiteCのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-7乗(5x10の-8乗と同値)のため、これを採用します。
これで、10月のsiteCのパラメータは cost=20,epsilon=0.0001,gamma=5x10の-7乗となりました。

10月のsiteDのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-7乗のため、これを採用します。
これを用いてcostを計算しました。

10月のsiteDのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは8(10,6と同値)のため、これを採用します。
これを用いてepsilonを計算しました。

10月のsiteDのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.0001(0.00001と同値)のため、これを採用します。
これを用いてgammaの再計算をしました。

10月のsiteDのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-7乗のため、これを採用します。
これで、10月のsiteDのパラメータは cost=8,epsilon=0.0001,gamma=5x10の-7乗となりました。

10月のsiteEのgammaのグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaのパラメータは5x10の-8乗のため、これを採用します。
これを用いてcostを計算しました。

10月のsiteEのcostのグラフは添付のとおりです。
どのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったcostのパラメータは4のため、これを採用します。
これを用いてepsilonを計算しました。

10月のsiteEのepsilonのグラフは添付のとおりです。
1.0以外はどのパラメータでも大きく変わりませんでした。
相関係数の中央値が最も高くなったepsilonのパラメータは0.00001のため、これを採用します。
これを用いてgammaの再計算をしました。

10月のsiteEのgammaの再解析のグラフは添付のとおりです。
相関係数の中央値が最も高くなったgammaの再解析のパラメータは5x10の-8乗のため、これを採用します。
これで、10月のsiteEのパラメータは cost=1,epsilon=0.001,gamma=5x10の-8乗となりました。

これにて、1月、4月、7月、10月のハイパーパラメータの設定は終わります。
全体的な傾向として、gammaは影響しますが、cost、epsilon(1.0を除く)のパラメータは変化させてもほとんど変わらないことがわかりました。
残りとしまして、7月のsiteD,siteEにおける陸上につきまして行いたいと考えております。

以上、よろしくお願いいたします。

小林様。ありがとうございます。5x10-8で最も相関係数が高いケースについて、5x10-9, 5x10-10を追加して（5x10-1, 5x10-2の代わりに）、再度実施してもらえますでしょうか。

@takao-y
吉兼先生
小林です。お世話になっております。
5x10-8で最も相関係数が高いケースにつきまして、5x10-9, 5x10-10を追加して（5x10-1, 5x10-2の代わりに）、再度gammaを実施いたします。この際のcost, epsilonのパラメータはこれまでで最も相関が高い値を利用します。結果が出ましたらお伝えいたします。
以上、よろしくお願いいたします。

@takao-y
吉兼先生
小林です。お世話になっております。
5x10-8で最も相関係数が高いケースにつきまして、5x10-9, 5x10-10を追加して（5x10-1, 5x10-2の代わりに）、gammaを再計算しました。

5x10-8で最も相関係数が高くなったのは、
(1) 4月のsiteE, (2)7月 siteD (3)10月 siteEでした。
この結果、(1) 4月のsiteEは5x10-10で最大、(2)7月 siteDは5x10-8で最大、(3)10月 siteEは5x10-8で最大となりました。

(1) 4月のsiteEは5x10-10で最大となったため、5x10-11, 5x10-12を追加して（5x10-3, 5x10-4の代わりに）、gammaを再計算しました。
この結果、(1) 4月のsiteEは5x10-10で最大となりました。なお、5x10-10と5x10-12で相関係数の中央値は同値でした。

以下にグラフを載せます。

まず、(1) 4月のsiteEの結果です。
パラメータはcost=1, epsilon=0.001としました。5x10-10と5x10-12で最大となりました。
5x10-8より小さい場合はほとんど変化はございませんでした。

続いて、(2)7月 siteDの結果です。
パラメータはcost=2, epsilon=0.0001としました。5x10-8で最大となりました。
5x10-7より小さい場合はほとんど変化はございませんでした。

最後に、(3)10月 siteEの結果です。
パラメータはcost=4, epsilon=0.00001としました。5x10-8で最大となりました。

これで残りはsiteD,siteEの陸上での結果のみとなりました。
こちらも改めて結果をご連絡いたします。

以上、よろしくお願いいたします。

小林様。ありがとうございます。D,Eの陸上での実験と平行して、ここで算出したハイパーパラメータを用いて全グリッドでの推定をお願いできますでしょうか。プログラムは以下の場所にあります。python用に一部書き換えが必要ですが、もし問題などありましたらご連絡ください。

小林様。すみません。dropboxのアドレスを忘れていました。
https://www.dropbox.com/s/x7r62s6z5960kkc/ml-region1-all-20200915.tar.gz?dl=0
よろしくお願いいたします。

@takao-y
吉兼先生
お返事ありがとうございます。D,Eの陸上の結果につきましては改めてご連絡いたします。
そして、pythonの書き換えを含む新たなプログラムを用いた全グリッド推定の件につきましては、現在弊財団はJAXA様との契約で動いておりますので、一旦確認させていただいたのちに引き受けの可否をご回答させていただけると幸いです。
以上、よろしくお願いいたします。

@takao-y
吉兼先生

siteD,siteEの陸上での結果が出ましたのでご報告いたします。
7月のデータを用いて、cost,epsilonのパラメータは最適となりましたものを用いて行いました。

まずはsiteDにつきましてご報告いたします。
最適となりましたcost=10,epsilon=0.001で緯度経度(127.8,26.4)の地図で示した位置1か所で行いました。
結果は図のとおりです。

参考として、siteD全体
x:20 30 40 50 60 70 80
y:20 30 40 50 60 70
での結果は図のとおりです(再掲)。パラメータは上と同じです。

続いてsiteEにつきましてご報告いたします。
最適となりましたcost=2,epsilon=0.0001で緯度経度(123.8,24.32)の地図で示した位置1か所で行いました。
結果は図のとおりです。

参考として、siteE全体
x:20 30 40 50 60 70
y:20 30 40 50 60 70
での結果は図のとおりです(再掲)。パラメータは上と同じです。

これにて前回の打合せで依頼を受けましたハイパーパラメータ設定に関しての作業は完了いたしました。
以上、よろしくお願いいたします。

小林様。ありがとうございます。何となく陸上ではよくなっているようですが、もし可能であれば、多少海上が入っても良いので間隔を開けないで複数地点で実施してもらうことはできますでしょうか。

小林様。少し説明不足だったかもしれません。例えば、沖縄本島が収まる（長方形の）領域を設定し、10グリッド毎ではなく, 1グリッド毎で評価することにより、島嶼全体としての特性が見えてくるのではないかと考えています。

@takao-y 様、@kobayashi_yusuke様
きちんと追いついておらず、確認が遅れまして申し訳ありません。再計算や確認等で小林さんの負担が少し重くなってしまっているようで恐縮です。RESTECさんにお願いしている作業量の問題もあり、具体的な今後の作業方針は明後日の会議で相談させていただければと思いますが、取りそぎ以下の点について確認させてください。

・現状、すべてのサイトで1,4,7,10月のガンマ、コスト、イプシロンの最適値が求まっていると思います。ただ、前回の打ち合わせでは、「5領域毎、月毎で最も精度の高いもの見つける」と認識合わせをしたつもりですので、全期間推定の前にまずは1～12月の各月でパラメータの最適値を決定する必要があると考えていますが、如何でしょうか。

・今年度中には最適パラメータで全期間推定を終わらせて、CDF補正までかけた状態での精度評価を行い、TE-Japanへの入力試験までできればよいと考えています（この結果をもとに定常運用システム構築に着手できればベストです）。なので、前年からRESTECさんにお願いしている作業量を減らしていることを考えると、現在吉兼先生からお願いされているsite D,Eでの再実験は、重要度がそれほど高くなければスキップしてもよいかと考えているのですが、如何でしょうか（もしどうしても必要であれば、先生にJAXA計算機で直接作業いただくか、私が作業するかで対応したいと思っています）。

@yamamoto.kosuke
山本様
いつも大変お世話になっております。
今回は弊財団が環境構築を行い、解析は東京大学様がJAXA環境に入って行う、という認識でおりました。
その中で前回の打合せで、パラメータの最適値を弊財団で行うことになり、5領域ごとにガンマ、コスト、エプシロン、そしてガンマの再計算を行うことになりました。5領域ごとに行うことは認識しておりましたが、月につきましては認識しておりませんでしたので、各月ごとに行うのではなく7月を行い、追加で1,4,10月を行ったという認識でおりました。もともと環境構築が弊財団の担当と認識しておりましたので、パラメータの最適値作業は(契約内で)追加作業で行っているという認識でおります。そのため、新たなお願いに対してはJAXA様と協議した次第です。
今年度の目標に向けて、JAXA様との契約の範囲内で進めさせていただけると幸いです。
以上、よろしくお願いいたします。

@gyinさんがチャンネルに参加しました

@takao-y
吉兼先生
本日は打合せをさせていただきありがとうございました。そして早速ですが特徴量ベクトルにつきまして相談させていただきたく思います。

吉兼先生から受領したプログラムのうち、auto-check.shに以下の記述がございます。
-----
## Range of feature vectors (2xRG+1)x (2xRG+1) : e.g. RG=15: 31x31 grids =961 grids (almost 180km x180km) resolution: 0.6 deg
#nums='961'
#rg2='15'
nums='441'
rg2='10'
-----
いただいたファイルではrg2='10'となっており、(10+1)x(10+1)で現在は行っているものと考えております。
こちらのrg2を変えることでよろしいのでしょうか。
また、その変える値につきましてご教授いただけると幸いです。
siteA～siteEの5領域に対し、1,4,7,10月でcost,epsilonは決まった値で固定し、gammaでグラフを作成することを考えております。

教えていただけると幸いです。
以上、よろしくお願いいたします。

小林様
吉兼です。auto-check.shのnumsとrg2を変更して特徴ベクトルの範囲を変更します。numsとrg2の関係は(rg2x2+1)(rg2x2+1)=numsです。
今はnums=441, rg2=10となっていますが、これを

1. rg2=4, nums=81
2. rg2=6, nums=161
3. rg2=8,nums=289
4. rg2=12,nums=625
で実施していただけますでしょうか。
よろしくお願いいたします。

吉兼先生
リモート・センシング技術センターの小林です。いつもお世話になっております。
さっそくのお返事ありがとうございます。

以下の4通りで順次行ってまいります。
1. rg2=4, nums=81
2. rg2=6, nums=161
3. rg2=8,nums=289
4. rg2=12,nums=625
以上、よろしくお願いいたします。

小林様
計算間違えていました。2.ng2=6,nums=169ですね。

@takao-y
吉兼先生
ご連絡ありがとうございます。2.はng2=6,nums=169で承知しました。結果が出ましたらご連絡いたします。

@takao-y さま
お世話になります。先日の打ち合わせで整理させていただいた今後の作業項目のうち、
「３．全格子・各月毎で識別機作成＋CDF補正」
の作業に備えて、JAXAの計算機スペックの情報をお伝えすることになっていた点ですが、以下の通りお知らせします。

計算機名：zico-n, pele-n
・物理CPU数:2
・コア数:24
・スレッド数:2
・論理CPU数:96
・メモリ:131[GB]
・クロック周波数:3000[MHz]

こちら、二台ともほぼ機械学習占有で使えるはずですが、全格子・各月毎での計算に耐えられそうか、情報頂ければ幸いです。よろしくお願いいたします。

山本様
ありがとうございます。24コア同時計算できればかなり早くなるかと思いますが、バイナリ化されていないとI/Oでエラーが起こる可能性があります。もし時間がありましたら、とりあえず10コア同時計算を実施してもらえますでしょうか。よろしくお願いいたします。

山本様。現状ではマシントラブルが起こる可能性が高いので、バイナリ化したシステムができるまで待っていただけますでしょうか。近日中にお渡しできると思います。

@takao-y
吉兼先生

特徴量ベクトルのうち、1月、4月、7月の結果が出ましたのでお伝えいたします。
cost,epsilonはそれぞれこれまでのハイパーパラメータ決定で相関係数の中央値が最大の者を採用しました。詳細は添付のエクセルをご参照ください。

まず1月の結果は表の右2列となります。特徴量ベクトルは10もしくは12、gammaは当初の結果と同じになりました。ただ、特徴量ベクトルはrg2=8,10,12で大きな差はございませんでした。

まずは1月のsiteA,rg2=4の結果です。

1月のsiteA,rg2=6の結果です。

1月のsiteA,rg2=8の結果です。

1月のsiteA,rg2=10の結果です。

1月のsiteA,rg2=12の結果です。
1月のsiteAではrg2=10でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

1月のsiteB,rg2=4の結果です。

1月のsiteB,rg2=6の結果です。

1月のsiteB,rg2=8の結果です。

1月のsiteB,rg2=10の結果です。

1月のsiteB,rg2=12の結果です。
1月のsiteBではrg2=12でgammaが5x10-5のとき、相関係数の中央値が最も高くなりました。

1月のsiteC,rg2=4の結果です。

1月のsiteC,rg2=6の結果です。

1月のsiteC,rg2=8の結果です。

1月のsiteC,rg2=10の結果です。

1月のsiteC,rg2=12の結果です。
1月のsiteCではrg2=12でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

1月のsiteD,rg2=4の結果です。

1月のsiteD,rg2=6の結果です。

1月のsiteD,rg2=8の結果です。

1月のsiteD,rg2=10の結果です。

1月のsiteD,rg2=12の結果です。
1月のsiteDではrg2=10でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

1月のsiteE,rg2=4の結果です。

1月のsiteE,rg2=6の結果です。

1月のsiteE,rg2=8の結果です。

1月のsiteE,rg2=10の結果です。

1月のsiteE,rg2=12の結果です。
1月のsiteEではrg2=10でgammaが5x10-7のとき、相関係数の中央値が最も高くなりました。

続いて4月の結果は表の右2列となります。特徴量ベクトルは10もしくは12、gammaは当初の結果と同じになりました。ただ、特徴量ベクトルはrg2=8,10,12で大きな差はございませんでした。
cost,epsilonはそれぞれこれまでのハイパーパラメータ決定で相関係数の中央値が最大の者を採用しました。詳細は添付のエクセルをご参照ください。

まずは4月のsiteA,rg2=4の結果です。

4月のsiteA,rg2=6の結果です。

4月のsiteA,rg2=8の結果です。

4月のsiteA,rg2=10の結果です。

4月のsiteA,rg2=12の結果です。
4月のsiteAではrg2=12でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

4月のsiteB,rg2=4の結果です。

4月のsiteB,rg2=6の結果です。

4月のsiteB,rg2=8の結果です。

4月のsiteB,rg2=10の結果です。

4月のsiteB,rg2=12の結果です。
4月のsiteBではrg2=10でgammaが5x10-5のとき、相関係数の中央値が最も高くなりました。

4月のsiteC,rg2=4の結果です。

4月のsiteC,rg2=6の結果です。

4月のsiteC,rg2=8の結果です。

4月のsiteC,rg2=10の結果です。

4月のsiteC,rg2=12の結果です。
4月のsiteCではrg2=12でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

4月のsiteD,rg2=4の結果です。

4月のsiteD,rg2=6の結果です。

4月のsiteD,rg2=8の結果です。

4月のsiteD,rg2=10の結果です。

4月のsiteD,rg2=12の結果です。
4月のsiteDではrg2=10でgammaが5x10-7のとき、相関係数の中央値が最も高くなりました。

4月のsiteE,rg2=4の結果です。なお、ここからはgammaは5x10-5から5x10-12の範囲で行なっております。

4月のsiteE,rg2=6の結果です。

4月のsiteE,rg2=8の結果です。

4月のsiteE,rg2=10の結果です。

4月のsiteE,rg2=12の結果です。
4月のsiteEではrg2=12でgammaが5x10-10のとき、相関係数の中央値が最も高くなりました。

最後に7月の結果は表の右2列となります。特徴量ベクトルは10もしくは12、gammaは当初の結果と同じになりました。ただ、特徴量ベクトルはrg2=8,10,12で大きな差はございませんでした。
cost,epsilonはそれぞれこれまでのハイパーパラメータ決定で相関係数の中央値が最大の者を採用しました。詳細は添付のエクセルをご参照ください。

まずは7月のsiteA,rg2=4の結果です。

7月のsiteA,rg2=6の結果です。

7月のsiteA,rg2=8の結果です。

7月のsiteA,rg2=10の結果です。(誤っていたため、削除の上一番最後に載せました)

7月のsiteA,rg2=12の結果です。
7月のsiteAではrg2=12でgammaが5x10-7のとき、相関係数の中央値が最も高くなりました。

7月のsiteB,rg2=4の結果です。

7月のsiteB,rg2=6の結果です。

7月のsiteB,rg2=8の結果です。

7月のsiteB,rg2=10の結果です。

7月のsiteB,rg2=12の結果です。
7月のsiteBではrg2=10でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

7月のsiteC,rg2=4の結果です。

7月のsiteC,rg2=6の結果です。

7月のsiteC,rg2=8の結果です。

7月のsiteC,rg2=10の結果です。

7月のsiteC,rg2=12の結果です。
7月のsiteCではrg2=10でgammaが5x10-7のとき、相関係数の中央値が最も高くなりました。

7月のsiteD,rg2=4の結果です。

7月のsiteD,rg2=6の結果です。

7月のsiteD,rg2=8の結果です。

7月のsiteD,rg2=10の結果です。

7月のsiteD,rg2=12の結果です。
7月のsiteDではrg2=12でgammaが5x10-8のとき、相関係数の中央値が最も高くなりました。

7月のsiteE,rg2=4の結果です。

7月のsiteE,rg2=6の結果です。

7月のsiteE,rg2=8の結果です。

7月のsiteE,rg2=10の結果です。

7月のsiteE,rg2=12の結果です。
7月のsiteEではrg2=12でgammaが5x10-3のとき、相関係数の中央値が最も高くなりました。

1,4,7月をまとめますと、特徴量ベクトルは10もしくは12のときに相関係数の中央値が最も高くなりましたが。8,10,12でほとんど差はございませんでした。
gammaの値はすべて当初のgamma値と同じ値で最大になりました。
途中のエクセルファイルにまとめておりますのでご参照ください。

引き続き、10月の処理を行ってまいります。
以上、よろしくお願いいたします。

7月のsiteA,rg2=10の結果が誤ったグラフを載せておりましたのでこちらでアップロードします。失礼しました。

小林様。ありがとうございます。7月などは特に領域Cで梅雨前線による降水が多くなるため、領域を狭めた方がパフォーマンスが良いかと思ったのですが、必ずしもそうではなさそうですね。計算機のパフォーマンスも含めて考えた場合に、どの設定がベストでしょうか？

@takao-y
吉兼先生
ご連絡ありがとうございます。
パフォーマンスは10もしくは12がほぼ同じくらいで高くなっております。その際のsiteCでかかった時間は、
　10のとき、8時間4分
　12のとき、11時間39分
となりました。なお、ともに並列で複数計算しているため単純比較はできませんが、10より12のほうが多く時間がかかることは確かです。

まだ10月を計算中ですが、1月,4月,7月で計算機のパフォーマンスも含めて考えた場合には10がベストと考えております。
以上、よろしくお願いいたします。

山本様、小林様
お世話になっております。吉兼です。
pythonバイナリ化版を作成しました。
https://www.dropbox.com/s/om2co27l0wadx64/ml-bin2.tar.gz?dl=0
よりダウンロードして動作確認をお願いできますでしょうか。
（以前は接続できたのですが、今回久しぶりに実行するとVPN: Pulse Secureの接続でエラーとなり、今の所解決できていません。私のPCに問題があるのかも。）

python化によって、Rを使っていたよりも大幅に（77%）計算時間が削減されました。結果も図で確認する限りほとんど同じです。（水曜日のY-labでの結果は図を間違えていました）

I/Oへの負担も大幅に軽減されていると思いますので、複数コア同時実行でも問題はないかなと思います。差し当たり12コア程度で試していただければと思います。

よろしくお願いいたします。

Yin-san,

I think you are also going to work on JAXA’s server (lili?) from the next month. The system is different from that in isotope2/3. If you have any questions about JAXA’s server, please ask Yamamoto-san and Kobayashi-san. Kobayashi-san is a specialist of machine learning system.

----
You can use the machine learning system in the python virtual environment (python venv) on isotope3. (It does not work on isotope2 so far.) I put the system in the following directory. Please copy the system to your directory.
isotope3: /data28/yoshikane/pub/ml-bin.tar.gz

I think you can also use the system on your PC. If you have time, please try it.

The details (how to use and how to make the python venv) are written in README file.
Please refer to README-R.txt and README-python.txt.

If you have any questions, please let us know.

T. Yoshikane

Dear Yoshikane-sensei,

Thank you for your guidance! I have copied the system to my directory and I will start exploring it. I will let you know if I meet any problem.
As for the JAXA's server, am I supposed to have an account on it later?

Best regards,
Gaohong

Yin-san, Kobayashi-san,

I uploaded the PPT file of our research plans.
https://www.dropbox.com/s/etpjmji8agvewzc/20201104-yoshikane.pptx?dl=0
We are trying to investigate the applicability of the machine learning method in Japan area and will provide the estimated data to TE-Japan (Flood forecasting system) in this business year (by the end of March in 2021). For the time being, we want you to try to use the machine learning system include the simple evaluation method for parameter setting (hyper-parameters and range of feature vector). And we wish you could summarize the research (1) in PPT (verification of the method applying to the Japan area every season) as a scientific paper. I think you will take over a part of Kobayashi-san’s work in JAXA’s server. Kobayashi-san, please tell her how to use the system. I think your system is optimized in the server. (If possible, could you replace the system by the new one including binary data conversion?)
If you have any questions, please let me know.
T. Yoshikane

チャンネル名を「機械学習」から「machine-learning」に変更しました

Yin-san,

Were you able to login to JAXA’s server?

By the way, I uploaded my presentation file about our study. If you would like, please check it.
https://www.dropbox.com/s/m66s004p96nalfd/20201005.pptx?dl=0
This presentation is written in Japanese but I added the explanations in English in note flame in PowerPoint.

If you have any questions, please let us know.

T. Yoshikane

Dear Yoshikane-sensei,

Yes, I can login to the JAXA's server now. I will go through the slides carefully and let you know if I have any questions!
Thank you!

Best regards,
Gaohong

吉兼です。現在までと今後のワークフローをまとめてみました。step 3はYinさんと私が担当いたします。JAXAのサーバでの実行環境の詳細について教えていただければ幸いです。もし可能であれば、一度引き継ぎの打ち合わせを作業担当者(小林さん、Yinさん、私、その他？）だけで行えればと考えていますが、いかがでしょうか。step 4（小林さん担当？）との関係もあると思いますので、細かい作業内容について確認ができればと思います。よろしくお願いいたします。

Workflow

Restec
1. Obtain the optimal values of hyper-parameters

We have to investigate the following four factors such as hyper-parameters and the size of feature vector (simulated precipitation distribution) before estimating the precipitation in all grids.
Hyper-prameters: Gamma (Gm), Cost (C), Epsilon (Ep)
The size of feature (Fv) initial 21x21 (rg2=10) rg2: the number of grid points from the center of FV

Initial valuese and assumed ranges are obtained from random search at some points.

Step 1: For hyper parameters
1.1 Gm (Change the values), C (Fixed), Ep (Fixed), Fv (Fixed)
If the minimum or maximum values are selected, please extend the range and try it again.
1.2 Gm (Fixed), C (Change), Ep (Fixed), Fv (Fixed)
If the minimum or maximum values are selected, please extend the range and try it again.
1.3 Gm (Fixed), C (Fixed), Ep (Change), Fv (Fixed)
If the minimum or maximum values are selected, please extend the range and try it again.
1.4 Gm (Change), C (Fixed), Ep (Fixed), Fv (Fixed)
If the Gm values are not largely different from the values of 1.1, the oprtimal values are determined.
If not, please repeat the cycle from 1.2 to 1.4

We confirm the sensitivity of C and Ep is not large.
For the reason, we fixed the C and Ep by optimal values obtained in the step1.

Step 2: For the size of FV
2.1 Gm (Change the values), C (Fixed by Optimal values), Ep (Fixed by Optimal values), Fv (rg2=4)
If the minimum or maximum values are selected, please extend the range and try it again.
2.2 Gm (Change the values), C (Fixed), Ep (Fixed), Fv (rg2=6)
If the minimum or maximum values are selected, please extend the range and try it again.
2.3 Gm (Change the values), C (Fixed), Ep (Fixed), Fv (rg2=8)
If the minimum or maximum values are selected, please extend the range and try it again.
2.4 Gm (Change the values), C (Fixed), Ep (Fixed), Fv (rg2=12)
If the minimum or maximum values are selected, please extend the range and try it again.
If the performance does not largely improved, the size of FV (rg2=10) is determined.
2.5 Gm (Change the values), C (Fixed), Ep (Fixed), Fv (rg2=14)
If the minimum or maximum values are selected, please extend the range and try it again.
If the performance does not largely improved, the size of FV (rg2=12) is determined.

We confirmed the performance in the case of rg2=12 does not largely change as those of rg2=10 in all cases.
For the reason, we determined the rg2 as 10.

It is necessary to obtain the optimal values in January, April, July, and October in all regions (A,B,C,D, and E).

----- Almost finished? (2020.11.12)

Step 3 Estimate the precipitation in all grid points by ML + CDF (transform?) using optimal values

( Yin-san and I are in charge.)
This process will be conducted on the JAXA’s server.
We’d appreciate it if you could tell us about the environmental setting on JAXA’s server.

3.1 Need to modify the “ml-bin” according to the environment of JAXA’s server.
How can we get the Input data and adjust the domains?
3.2 Check the server performance.
Is the concurrent execution (e.g. using 10 cores) of the machine learning system possible?
3.3 Execute the ML system using analysis data of MSM-GPV from 2007 to 2018.
Estimation of precipitation in all months
From December to February using optimal parameters in January.
From March to May using optimal parameters in April.
From June to August using optimal parameters in July.
From September to November using optimal parameters in October.
3.4 Execute the ML system using forecast data of MSM-GPV in 2019?
Estimation of precipitation in all months by ML with the classifiers produced by the training form 2007 to 2018.
(CDF-transform method would be applied.)
From December to February using optimal parameters in January.
From March to May using optimal parameters in April.
From June to August using optimal parameters in July.
From September to November using optimal parameters in October.
3.5 Check the performance
Advantages and disadvantages of this method
Which month is the best? And why?
How can we improve the problems?
3.6 Submit a paper to a scientific journal (Yin-san).

Step 4 Construction of ML system for TE-Japan
( Kobayashi-san is in charge?)

4.1 Construction of ML system using the classifiers of old version.

4.2 ML system is improved using the classifiers produced by step 3.4.
The classifiers are produced by using the data of MSMGPV and Radar_AMeDAS from 2007 to 2018.

4.3 ML system is improved by applying the CDF-transform method?

吉兼先生

小林です。お世話になっております。
打合せにつきまして承知しました。可能ならJAXAの山本様にもご参加いただいたほうがよろしいかと考えております。山本様を含めた形で日程調整させていただけると幸いです。
Step4につきましては弊財団で担当しますが、詳細は私からですとご説明が難しいため、
Step2からStep3の引継ぎのみ打合せさせていただけると幸いです。

なお、Step2につきまして10月が残っておりますが、解析は完了しましたが整理できておらず、
ご報告できておりません。
整理が完了し、ご報告できるかたちになりましたらこちらでご報告いたします。

以上、よろしくお願いいたします。

小林様
吉兼です。ご連絡ありがとうございます。承知いたしました。Step4については別の機会に打ち合わせができればと思います。（基本的には、Step3で作成した識別器をStep4で用いることを想定して進めていきたいと考えています。）よろしくお願いいたします。

吉兼です。
バイナリ化版のCDF-transform法適用版を以下に置きました。
https://www.dropbox.com/s/wkfq13qeh44utkz/mlcdft-bin.tar.gz?dl=0
これにより、観測最大値で頭打ちになる問題に対応できると考えています。（例えば、昨年の台風19号のケースなどで降水量ピークが頭打ちとなる問題の改善を確認）これにより、山本さんの結果にもみられた2018年7月の西日本豪雨での河川流量の過小評価についてもある程度改善できるのではないかと考えています。CDF-transformの概要図と2015年1月の降水量推定値の結果を添付します。観測とシミュレーションの現在のCDFを評価対象年を除く11年間として、将来CDFに相当するものを評価対象年を含む12年間で与えています。（これにより、CDFでは評価が難しかった年々変動の議論もできるのではないかと期待しています。）このケースでは問題なさそうですが、他の数事例に適用して問題ないことを確認した後で、正式に採用できればと考えています。よろしくお願いいたします。

Yin-san, I produced another version of the ML system. You can get the system from the following site. This works on Mac. If you have time, please try it on your Mac.
https://www.dropbox.com/s/wkfq13qeh44utkz/mlcdft-bin.tar.gz?dl=0
I used the CDF-transform method in this version. Usually, CDF-transform method is used to estimate the values for the future climate change. I will attach the figure of the concept of method and the results (estimated monthly precipitation distribution in January 2015). I think we can solve the problem of the limitation of peak value by the observed maximum value. In the CDF-transform, the present CDFs of observation and simulation were produced by the 11 years data from 2007 to 2018 excluding the target year and the assumed future CDFs of simulation were produced by the 12 years data including the target year. And then, I took the estimated precipitation in the target year out from the estimated precipitation in the assumed future observation data. It is expected that we can discuss the inter-annual variation of estimated precipitation, which was difficult in the CDF method. After checking the performance, I hope this method is applied formally. If you have any questions, please let me know.

@takao-y
吉兼先生特徴量ベクトルのうち、残っておりました10月の結果を整理しましたのでお伝えいたします。
cost,epsilonはそれぞれこれまでのハイパーパラメータ決定で相関係数の中央値が最大のものを採用しました。詳細は添付のエクセルをご参照ください。結果は表の右2列となります。特徴量ベクトルは8もしくは12で最大、gammaは当初の結果と同じになりました。ただ、特徴量ベクトルはrg2=8,10,12で大きな差はございませんでした。

まずは10月のsiteA,rg2=4の結果です。

10月のsiteA,rg2=6の結果です。

10月のsiteA,rg2=8の結果です。

10月のsiteA,rg2=10の結果です。

10月のsiteA,rg2=12の結果です。
10月のsiteAではrg2=12でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

次に、10月のsiteB,rg2=4の結果です。

10月のsiteB,rg2=6の結果です。

10月のsiteB,rg2=8の結果です。

10月のsiteB,rg2=10の結果です。

10月のsiteB,rg2=12の結果です。
10月のsiteBではrg2=8でgammaが5x10-6のとき、相関係数の中央値が最も高くなりました。

続いて、10月のsiteC,rg2=4の結果です。

10月のsiteC,rg2=6の結果です。

10月のsiteC,rg2=8の結果です。

10月のsiteC,rg2=10の結果です。

10月のsiteC,rg2=12の結果です。
10月のsiteCではrg2=12でgammaが5x10-7のとき、相関係数の中央値が最も高くなりました。

10月のsiteD,rg2=4の結果です。

10月のsiteD,rg2=6の結果です。

10月のsiteD,rg2=8の結果です。

10月のsiteD,rg2=10の結果です。

10月のsiteD,rg2=12の結果です。
10月のsiteDではrg2=8でgammaが5x10-7のとき、相関係数の中央値が最も高くなりました。

最後に、10月のsiteEの結果です。
まず、10月のsiteE,rg2=4の結果です。

10月のsiteE,rg2=6の結果です。

10月のsiteE,rg2=8の結果です。

10月のsiteE,rg2=10の結果です。

10月のsiteE,rg2=12の結果です。
10月のsiteEではrg2=12でgammaが5x10-8のとき、相関係数の中央値が最も高くなりました。

10月をまとめますと、特徴量ベクトルは8もしくは12のときに相関係数の中央値が最も高くなりました。ただ、8,10,12でほとんど差はございませんでした。
gammaの値はすべて当初のgamma値と同じ値で最大になりました。
最初のエクセルファイルにまとめておりますのでご参照ください。

1,4,7,10月をまとめますと、特徴量ベクトルは8,10もしくは12のときに相関係数の中央値が最も高くなりました。ただ、8,10,12でほとんど差はございませんでした。

計算機のパフォーマンスを考えた場合には、8もしくは10がベストではないかと考えております。
以上、よろしくお願いいたします。

小林様
吉兼です。ありがとうございます。8以上でそれほど差がないということは、MSM-GPV(5km)の降水特性を認識するには、約75km四方以上の領域であれば良いということでしょうか。メソベータスケール（寒冷前線、温暖前線、停滞前線など）に伴う降水特性を認識するにはその程度の大きさが必要？

吉兼先生
小林です。お返事ありがとうございます。8ですと17x17になりますので、約85km四方以上となります。降雨特性については私は不勉強のところですが、統計的には8,10,12でそれほど変わらない結果となっております。以上、よろしくお願いいたします。

吉兼です。確認のため、機械学習の訓練期間とテスト期間およびCDF作成のためのデータのフローチャートを作成してみました。図を添付します。機械学習で訓練年にテスト年を含むと答えを教えていることになり推定の意味がなくなるため、テスト年を除いた11年間で訓練します。（テスト年を含めた場合、統計処理をしているので全く同じになることはないのですが、影響を強く受けますので結果として汎化能力が低下します。）CDF過程も同様に対象年を除いてCDFを作成します。その場合は年々変動により対象年毎にCDFが変化します。あまりにも変動の影響が大きい場合はそれが誤差要因となり、パフォーマンスが低下します。なるべく長期間でCDFを作成した方が年々変動による誤差を小さくできます。対象年を含めてCDFを作る場合はどの年も同じCDFを適用するため年々変動が見かけ上なくなるのですが、作成したCDFに偏りがないかどうかのチェックもできなくなるため、別の年を推定する際の信頼性が低くなります。作成したCDFの信頼性を調査するために対象年を除いてCDFを作成しています。機械学習、CDF過程を経て得られた結果に問題ないかをチェックした上で、予報値の補正を行います。このような（面倒かつ複雑な）手順を踏むことにより、信頼性の高い推定値を得ることが可能になります。

問題点や説明がよく分からないなどありましたら、ご指摘いただければ幸いです。

とはいえ、12年程度では特に夏季は機械学習、CDF補正共に十分ではないため、データを増やす必要があります。今までは月毎で学習していましたが、対象月を中心に3ヶ月間に学習期間を増やした方が良さそうです。（確か、以前に小林さんに実施していただいたものは3ヶ月で学習されていたと思います。若干時間がかかりますが、その方が良さそうです。）　吉兼

吉兼です。バイナリ版についてpele-nの/home/takao-y/mlcdft-bin/ml-region1-all-python4-jaxaにコピーして、領域限定でテストを行なっています。（学習期間を対象月を挟んで3ヶ月で設定。とりあえず20072014までの8年間を学習、20152019の5年間をテスト。CDFも20072014で作成し、20152019を補正）。今の所順調に作動しています。同じものをisotope3でも動かしており、終了後に出力データの確認を行います。もしよろしければ、コピーして動作確認をお願いできますでしょうか。（学習を3ヶ月に拡張したことにより、プロセスの一部を手動で行う必要があります。全自動化を検討中。）

また、作業用ディレクトリとして我々も/goemon_disk2を使わせていただいてもよろしいでしょうか。

バイナリ版では、I/Oのアクセスが軽減しており、計算機への負荷も軽減されると期待しています。ただ、同時並行計算を実施した場合のサーバーへの影響を把握していないため、もし可能でしたら計算サーバー（およびネットワーク）の負荷をモニタリングしていただければ幸いです。

よろしくお願いいたします。

小林様
お世話になっております。吉兼です。
2019年のデータですが、JAXAサーバーで利用は可能でしょうか。参考までに、芳村研で購入した2019年分の雨量解析データを
pele-n:/home/takao-y/pub/に置きました。もしよろしければ、差し当たりお使いいただければ幸いです。よろしくお願いいたします。

小林様
度々すみません。Yinさんからの情報によると、
/goemon_disk2/trmmauto/AI_GSMaP/svm-msm-wj-201906/MSMGPV/data1/siteB
の2007年4月のデータについて、データサイズが117(longitude)x134(latitude)x723(1ヶ月のデータ数:　実際には720であるはず）となっていて、さらに全ての-999,000,000.（欠測？）となっているそうです。（siteCなどは特に問題はないそうです。）ご確認いただけますでしょうか。
よろしくお願いいたします。

小林様
計算領域ですが、現在設定されているSiteA,B,C,D,Eでは日本全域をカバーできないようです。ご確認いただけますでしょうか。
吉兼

吉兼です。
小林さんが設定された領域に近くなるように再設定してみました。ご確認いただけますでしょうか。
各領域の緯度、経度は以下の通りです。
FVはMSMGPV作成のためのデータ領域です。
Site A 138.6 147.0 39.8 45.8
Site A FV 138.0 147.6 39.2 46.4
Site B 135.0 142.8 33.2 40.4
Site B FV 134.4 143.4 32.6 41.0
Site C 128.4 135.6 29.6 36.8
Site C FV 127.8 136.2 29.0 37.4
Site D 126.6 132.0 24.8 30.32
Site D FV 126.0 132.6 24.2 30.92
Site E 122.4 127.2 23.6 27.2
Site E FV 121.8 127.8 23.0 27.8
Site E 122.4 127.2 23.6 27.2
Site E FV 121.8 127.8 23.0 27.8

領域設定ツールを作成しましたので、もし修正の必要がありましたら、ご利用ください。
（小林さんが作成された切り出し方法の詳細については十分に把握していませんので、私の設定は適切でないかもしれません。適宜修正していただければ幸いです。）
https://www.dropbox.com/s/7ammd3rczu29vzn/domain.tar.gz?dl=0
120E,20Nを始点として解像度0.06degで日本全域をカバーしています。domain.shで、x?1,x?2,y?1,y?2（始点からのグリッド数）を設定します。rg2=10は特徴量の範囲(21x21)に対応します。上の添付図の赤破線が特徴量の範囲、青線が推定値出力です。

問題がなければ、各領域の切り出しデータをYinさんにお渡しいただければと思います。その時点で識別器ファイルの容量を見積もります。

よろしくお願いいたします。

すみません、ご確認が遅くなりました。
昨年９月に判明し、4月データを作成し直して処理を進めたのですが、
処理はjsbach11で実施したため、goemon_disk2にあるデータの更新
しておりませんでした。
更新しましたので、ご確認お願いします。

吉兼です。
13日に報告させていただいた領域設定について、その後いかがでしょうか。もし設定に問題がありましたら、ご指摘いただければと思います。もし可能でしたら、各領域で変換されたデータについても早めにいただけると助かります。
よろしくお願いいたします。

失礼しました。ご連絡頂いているのに気づいてなくて対応しておりませんでした。
早速検討致します。
すみません、少しお待ちいただければと思います。

@takao-y さん
すみません、再度確認ですが、MSMGPV作成のためのデータ領域とある
FVがMSMの切り出し領域と考えればよろしいでしょうか。

あと、siteEですが、緯度の範囲がこれまで23.0～28.0だったのがFVだと23.0～27.8と少し狭くなっていますが、これは問題ないでしょうか。

Dear Yin-san,
Could you check the new sites (A to E) using the domain-setting tool?(https://www.dropbox.com/s/7ammd3rczu29vzn/domain.tar.gz?dl=0)
It covers all of Japan with a resolution of 0.06deg, starting from 120E,20N. I think you can draw the estimated precipitation map in whole of Japan area directly (without any interpolation tools).
x?1,x?2,y?1,y?2 in domain.sh are the number of grids from the starting point.
rg2=10 corresponds to the feature range (21x21).
Best Regards,
T. Yoshikane

siteEの件、了解しました。また、切り出しですが、Radar_AMeDASは切り出しの準備はしてなかったのですが、そちらも対応致します。
宜しくお願いします。

@takao-y @uwatoko
将来的にはMEPSの降水量も切り出して同じような処理をしていきたいと考えています。芳村研の方で少し過去分ですがMEPSのデータを気象庁からそのまま出された形で持っています（1時間毎）。こちらを使うことにするか、業務支援センターから出されているもの（3時間毎）を使うべきか、どう考えますか？前者は、データ自体がかなり複雑な構造をしているのと、オリジナル解像度なので、空間内挿しなければいけないのですが、気象庁と同じ内挿というものができない可能性があります。後者は3時間毎というのがネックです。

@takao-y 様、@yamamoto.kosuke 様
ご依頼の切り出しの件です。
MSMは2007年～2018年まで作成済ですが、解析雨量は時間がかかるので、
とりあえず3年分(2007年～2009年)を用意しました。
また、3年分毎に出来上がったらお知らせします。

MSMは　jsbach11:/data/trmmauto/AI_GSMaP/svm-msm-wj/MSMGPV/data1x/siteX/yyyymm
解析雨量は　sbach11:/data/trmmauto/AI_GSMaP/svm-msm-wj/wget-Analyses_precipitation/data1x/siteX/yyyymm

@gyin -san,
Thank you for the meeting today! Could you share your slides?
Now MSM and Radar-AMeDAS data are ready, so we move on to prepare the classifier for each grid and each month in JAXA server toward the real-time operation. For securing enough space, could you tell the approximate storage needed to store all classifiers?

@takao-y 先生
頂いているツールはこちら（https://jaxa-ut-restec.slack.com/archives/C019QUY6WJD/p1607134874035800）が最新で、既にCDFt手法を含んでいただいてるもののようでした。過去分を処理するにはこちらを使用するのでOKかと思うのですが、定常運用化（リアルタイム処理）に向けては少し変更が必要かと思うので、ご対応いただければと思います。その際、以下の点について確認させてください。
• MSMの39時間予報をツールに入力するときのファイル形式はどのように考えていらっしゃいますか？ここが決まれば、こちらで先にMSM39時間予測切り出しの定常運用化を始めたいと思っています。
• 現状のツールでは、SVMの結果を出力した後、CDFtで再読み込みして結果出力という形になっていますが、定常運用では両者をひとまとめで処理したほうが処理時間短縮につながるのではと考えていますが、如何でしょうか。

@yamamoto.kosuke 様
zico-n/pele-nに吉兼先生のアカウントはありますので、
gaohongさんのアカウントを作成しました。
(初期パスワード：Ka#8Aba6)
また、ご依頼のデータは下記に置きました。
解析雨量：/lebron_disk09/GPM/AI_GSMaP/DATA/SRF_GPV_Ggis1km_cut/siteX/yyyymm
MSM：/lebron_disk09/GPM/AI_GSMaP/DATA/MSM_GPV_Rjp_cut/siteX/yyyymm
ご依頼の2020年までの切り出しは行います。完了したらお知らせします。

@yamamoto.kosuke 様
「gaohong」さんのアカウントの件、了解しました。
ディスクですが。/lebron_disk09/をお使いください。
宜しくお願いします。

@yamamoto.kosuke様
先日作ってもらったアカウントは「gaohong」は削除しました。
また、作成依頼のあった/lebron_disk09/gyin/も作成致しました。
よろしくお願いいたします。

対応が遅くなり申し訳ありません。機械学習+CDFtの39時間予報に対応したソースコードを以下に添付します。基本的には以前にお渡ししたものと同じで、39時間予報値のデータをソースコードで指定したディレクトリに置けば作動すると思います。
https://www.dropbox.com/s/mngkwh8dqk8o4p6/mlcdft-bin-39h-src.tar.gz?dl=0

手順としては、解凍後に
1.ml-region1-all-python-39hに移動

2. auto-step01.shを実行: 識別器作成の入力用データの作成し、識別器を作成（オペレーション時は予め作成された識別器を使用するため、省略）

3. auto-step02.shを実行: 39時間予報値の入力データを作成後、2の識別器を使って機械学習推定値を出力
----以上が39時間予報値の機械学習推定過程---

4. ml-region1-all-python-39h-cdftに移動

5. data2ディレクトリに、2007年から2018年までの機械学習推定値（それぞれ推定対象年を除く期間で学習して対象年を推定したたもの）を置く。（オペレーション時は予め作成された推定値が置かれていることを想定）

6. auto-step03.shを実行: dataディレクトリに3,で出力した39時間予報値の機械学習推定がコピーされ、CDFtによる量的補正を実施。

7.data-outディレクトリに推定値データが出力 。
8. TE-Japanへ入力？

機械学習入力用データを作成するための中間ファイルについては、以前とフォーマットは同じですが、時間方向は744ではなく39のデータ数になります。

よろしくお願いいたします。
吉兼

Dear Yin-san,

I have checked the test case using 39 hours forecast data in my directory on isotope2/3. I think you can get the ML system including input dataset. If you have time, please check the system after recovering isotope2/3.
I will inform you the directory later.

The procedure is as follows.

1. move to “ml-region1-all-python-39h”
2. execute “auto-step01.sh”
the program produces the input data and then, make classifiers using input data from 2007 to 2018 (if you select e.g. 2019).
3. execute “auto-step02.sh”
The program produces the input data for 39 hours forecast and then, estimate the precipitation using the classifiers. which is made in procedure 2.
4. move to “ml-region1-all-python-39h-cdft”
5. execute “auto-step03.sh”
The program corrects the amount of estimated precipitation produced in procedure 3 using the estimated precipitation (and observation data) from 2007 to 2018, which were produced in advance.

Best Regards,
T. Yoshikane

@yamamoto.kosuke様
解析雨量の2019～2020年データ作成が完了いたしました。
MSMについては来週前半になる見込みです。
/lebron_disk09/GPM/AI_GSMaP/DATA/SRF_GPV_Ggis1km_cut/siteX/yyyymm

識別器ですが、グリッドによっても異なるのですが1グリッドあたり大凡3MB（12年間学習した場合）となっています。私が実施している東日本領域(80x60 grids)では合計8.6GBになります。

ご参考になれば幸いです。
吉兼

役割分担について再度確認させてください。

1. 新領域AEについて、MSM-GPV,雨量解析データの切り出し (RESTEC)
　　（来週中に終了予定）

2. 新領域AEについて、2007年から2018年までのデータを用いて機械学習推定値を出力 (定常運用CDFtで使用）(東京大学）

3. 新領域A~Eについて、2007年から2018年までの12年間のデータを用いて識別器作成（定常運用で使用）（東京大学）

4. 2,3で作成したデータを定常運用に提供

5. 定常運用：39時間予報値を用いて機械学習＋CDFtを適用して算出された推定値をTE-Japanに適用（RESTEC)

もし問題がありましたらご指摘いただければ幸いです。
吉兼

Dear Yin-san,

We have to provide the estimated precipitation data from 2007 to 2018 by ML and the classifier files produced by using 12 years data form 2007 to 2018 in A to E regions using the optimal hyper-parameters which is estimated by Kobayashi-san. The new regions are a little bit different from old ones but I think it can be ignored.

Could you start the experiments after finishing the RESTEC-san’s data conversion?
If you need some helps, please let me know. I will help you.

After finishing our tasks, we will prvide the estimated precipitation by ML and the classifiers to RESTEC because those are necessary for the routine operation of the TE-Japan.

If you have any questions, please let me know.

Best Regards,
T. Yoshikane

上記に間違いがありました。2007年から2018年ではなく、正しくは2007年から2020年（現在）までのデータを使って、各年の推定値及び識別器を作成でした。
吉兼

@yamamoto.kosuke様、@takao-y 様
MSMの2019年、2020年分のデータ作成が完了致しました。
MSM：/lebron_disk09/GPM/AI_GSMaP/DATA/MSM_GPV_Rjp_cut/siteX/yyyymm

ありがとうございます。データについて２点だけ質問させてください。
1. 閏年2月29日は変換されていますでしょうか。
2. 雨量解析ですが、2020年分のデータは最近公開されたデータを変換されたのでしょうか。
よろしくお願いいたします。
吉兼

作成していただいた解析雨量とMSM-GPVですが、1時間のズレがあるようです。データの確認をお願いできますでしょうか。

例えば、0UTCのデータでは、
MSM-GPVの地表面データでは、データの初期時刻（t=1）では降水プロダクト以外の0UTCの解析値が入力されており、t=2（次のタイムステップ）で、0UTC~1UTCの積算降水量が入っています。
http://www.jmbsc.or.jp/jp/online/file/f-online10200.html
解析雨量では、データの初期時刻では前1時間値、つまり前日の23UTCから0UTCまでの積算降水量が入っています。
http://www.jmbsc.or.jp/jp/offline/cd0100.html
---
特記事項
2003年5月までは1時間毎、2003年6月以降は30分毎の値がそれぞれ収録されています。
　ただし、どちらも前1時間降水量です。
---

（私がかなり以前に作成したプログラムでは、解析雨量の0UTCノ初期時刻の積算降水を0UTCから1UTCまでの積算値として出力していました。）

よろしくお願いいたします。

@uwatoko様
解析雨量データのMSMデータとの時間のズレの問題ですが、その後進捗はいかがでしょうか。とりあえず確認だけしていただいて、問題が確認できた段階で、対処法について検討できればと考えています。
よろしくお願いいたします。
吉兼

Dear Yin-san,

I will attach the conversion program of Radar_AMeDAS for 1h data shift.

Could you convert the Radar_AMeDAS files after we confirmed the data are not corresponded to the MSM-GPV?

The procedure is as follows.
1. extract the tar.gz file in your directory.
2. move the old files of Radar_AMeDAS to “old” directory.
3. edit the auto-shift1h.sh
4. execute the auto-shift1h.sh
This program requires the grads software. So, please set the path before executing the program.

データのズレの問題ですが、修正プログラムを作成しました。全ての領域に適用しても１時間程度あれば変換できると思います。ただ、変換にはGradsを使用していますので、gradsがインストールされている環境で実施する必要があります。JAXAでgradsが使えるサーバーを教えていただけますでしょうか。
吉兼

@takao-y 様：

作成した解析雨量とMSM-GPVですが、1時間のズレですが、認識を確認させてください。
現状こちらは、上記の認識でデータは用意していると思っています。
認識はどういうものかというとその時刻のデータはGSMaPは、0UTCのファイル名は、
0時から0時59分のデータと理解しております。これは、スタートの時刻が入っています。

MSM-GPVの地表面データと解析雨量はそうでなくて、エンドの時刻が入っていると理解しております。

そうすると、吉兼先生の理解と同じで、MSM-GPVの地表面データであれば、データの初期時刻
（t=1）はつまり前日の23UTCから0UTCまでの積算降水量が入っています。
解析雨量では、データの初期時刻では前1時間値で、つまり前日の23UTCから0UTCまでの積算降水量と
理解しております。

こちらはファイル名の命名規則を同じになるようにして作成しているので、その意味ではずれてないと
思っております。

1時間のずれがファイル名とマッチングしているので、ずれているという話であれば、そうですねという
理解で、こちらは吉兼先生のプログラムと同じ入力を入れれるようにしていますので、そこに関しては
何もいじっておりませんというお話になります。

私の指摘があっているのかわかりませんが、もし違うのであれば、zoom等でお話しできませんでしょうか。

@takao-y 様：
すみません、１の閏年2月29日に関しては、こちらの不手際でです。
こちらで作成をしましたので、今日中に準備できると思います。出来ましたら、お知らせします。

２の雨量解析ですが、2020年分のデータは最近公開されたデータですかというご質問ですが、
こちらは、最近公開されたというのは、気象業務支援センターでrenewとなっているもので
しょうかというご質問でしょうか。こちらは、JAXAさんが直接ネット（気象協会？）経由で入手
しているものですので、renewの定義がわからないのでなんともいえないのですが、バージョンが
あがったとか聞いてないので、当初のネットワーク経由で頂いたものそのままという理解です。

@takao-y様
閏年2月29日の抜けていた解析雨量とMSM-GPVの下記の期間を用意しました。
2008年2月29日
2012年2月29日
2016年2月29日
2020年2月29日
場所は前回と同じで、下記のところになります。
解析雨量：/lebron_disk09/GPM/AI_GSMaP/DATA/SRF_GPV_Ggis1km_cut/siteX/yyyymm
MSM：/lebron_disk09/GPM/AI_GSMaP/DATA/MSM_GPV_Rjp_cut/siteX/yyyymm
宜しくお願いします。

@takao-y様
もし可能であれば、17時くらいに打ち合わせできますか（すみません、本日打ち合わせが
立て込んでおりまして、その時間までちょっと空きそうにないので）。
一応再度確認した方が良いみたいです。
宜しくお願いします。

本日(3/18) 17時からZoomでのご相談承知いたしました。
Zoomスケジュールを設定いたしました。
もしよろしければ、下記をお使いいただければと思います。
------------
トピック: Zoom meeting invitation
時間: 2021年3月18日 05:00 PM 大阪、札幌、東京

Zoomミーティングに参加する
https://u-tokyo-ac-jp.zoom.us/j/91933424757?pwd=K2VKeUJGSEZLUDdzVTFYMFd0bTY1UT09

ミーティングID: 919 3342 4757
パスコード: 133421
-----------
よろしくお願いいたします。

Dear Yin-san,

Could you confirm whether the MSM-GPV data produced by RESTEC is the same as our data or not just in case?

And could you wait to modify the data until finishing the meeting with Higashiuwatoko-san? I will tell you the detail of data conversion plan immediately after meeting.

Best Regards,
T. Yoshikane

@takao-y
Dear Yoshikane-sensei,

I have finished the 1hour shift for Radar-AMeDAS data for sites A-E from 2007-2020.

The shifted data are put at:
/lebron_disk09/gyin/Radar_new

I conducted the shift on server lala, and the codes are at:
/home/gyin/shift_siteA(or B, C, D, E)

I checked the new data and it look okay. But due to the lack of data in 2021, on December 31 2020, the last one hour data are missing.

Could you please check the shifted data if you have time? Thank you very much!

Best regards,
Gaohong

Dear Yin-san,

Thank you for your quick response!
I will ask Higashiuwatoko-san about the data in 2021.

Best Regards,
T. Yoshikane

@uwatoko様
解析雨量ですが、2021年1月のオンラインデータは入手できますでしょうか？オフラインデータは恐らく9月頃になるので、オンラインデータを使わせていただければありがたいのですが。
吉兼

@takao-y 様
解析雨量はありますが、まだ処理が未解決なので、少しお待ちください。

@uwatoko様
ご連絡ありがとうございます。
よろしくお願いいたします。

@takao-y様

解析雨量とMSMの2021年1月のデータを作成して以下に格納致しました。
1時間ずれも対応しております。
解析雨量：/lebron_disk09/GPM/AI_GSMaP/DATA/SRF_GPV_Ggis1km_cut/siteX/202101
MSM：/lebron_disk09/GPM/AI_GSMaP/DATA/MSM_GPV_Rjp_cut/siteX/202101
ご確認頂けますでしょうか。
宜しくお願いします。

@uwatoko様@gyin 様
ありがとうございました。

Yin-san,

Could you check the Radar_AMeDAS data in January 2021?

/lebron_disk09/GPM/AI_GSMaP/DATA/SRF_GPV_Ggis1km_cut/siteX/202101

Best Regards,
T. Yoshikane

チャンネル名を「machine-learning」から「01_machine-learning」に変更しました

* RULES FOR USING THIS SLACK **
• Please make new thread ONLY when you post a new topic.
• Please REPLY IN THREADS when you discuss or answer existing topic.
• Please MENTION someone you want to talk to by using "@" .
**

@takao-y様
お世話になります。現状の役割分担と進捗状況を今一度確認させてください。

• 2007年から2020年までのMSMデータを使った定常運用用の識別機作成（＠JAXAサーバ）の状況はいかがでしょうか。JAXAサーバ上での実施で問題がありましたらお知らせください（東上床さんと話して、定常処理化に向けて識別機のサンプルを頂ければありがたいとのことでした）。
• 定常運用用に、MSM39時間予測の領域切り出しを東上床さんに定常化していただこうとしています。定常化に向けて、以下二点確認させてください。
a. 現状ではsiteA-E毎に推定を行いますが、TE-Jへの入力時にすべての領域をつなげるので、機械学習推定も領域で分けずに全域で行ったほうが、処理後に繋げる必要がなくて良いと思うのですが、如何でしょうか。
b. 現状のツールでは、SVMの結果を出力した後、CDFtで再読み込みして結果出力という形になっていますが、定常運用では両者をひとまとめで処理したほうが処理時間短縮につながるのではと考えていますが、如何でしょうか。
a,bに関しては、今回の定常化では間に合わないとしても、今後の処理の早期化に向けて考えたいことですので、お考えを聞かせていただけますと幸いです。よろしくお願いいたします。

@rkanekoさんがチャンネルに参加しました

「1kmへのダウンスケーリングについて」

SVMは極めてシンプルで扱いやすいのですが、1kmへのダウンスケーリングの実施に合わせて深層学習に移行した方が良いかなと考えています。
I/Oへの負荷が大幅に軽減されることと、一旦識別器を作成すれば推論部分ではかなり大幅な時短が期待されます。識別器作成にマシンパワーが必要になりますが、板谷さんによるとSVMの数倍程度の時間で済むとのことですので、特に大きな問題はなさそうです。

一方で、深層学習でも量まで合わせるのはかなり難しいので、分位マッピングの処理は必要と思われます。並列化も含めて効率的に計算する方法を検討した方が良さそうです。

以前の計算結果と概要についてPPTファイルを添付します。ご参考にしていただければ幸いです。

https://www.dropbox.com/s/xba7yalwucmkgvt/20210407-downscaling.pptx?dl=0

取り急ぎ、報告まで。
吉兼

@takao-y
Dear Yoshikane-sensei,
Here is some update on the classifier generating. Since we decided to ignore those grids not covered by Radar-AMeDAS (always show -999000000), I updated the code and rerun classifier after last week’s meeting.

I found that the running was much slower than I expected. Therefore, I checked the time spent for each step. For one grid pixel, the time spend for making training data is ~5 seconds, but the time for generating classifier is ~48 seconds. Therefore, with this speed, to generate classifiers for one site and one month, it will take about ~53 sec/grid ~15000 grids = 795,000 sec = ~9 days.*

Therefore, I think I over-predict the running speed last time during the meeting. I am sorry for the wrong information provided previously. I am currently running for siteC (Dec-Jan-Feb as one running job; Jun-Jul-Aug as one job; Sep-Oct-Nov as one job). I did not run for more jobs because I am worrying that running more jobs will slow down the current process.

I also attached the codes I used for classifier generating here (siteC example).

Thank you very much!

Best regards,
Gaohong

Dear @takao-y @uwatoko ,

I am currently still running for generating classifiers. However, it seems there is some problem with Radar-AMeDAS data in December.

I randomly selected some years and checked December data in sites A-E, but it seems all the values are given as -999000000. Could you please check it when you have time? Thank you very much!

Best regards,
Gaohong

@gyinさん、@takao-y 先生
了解しました。チェックします。

@takao-y 先生
お世話になっております。東上床＠RESTECです。
頂いたプログラムのテストを行っておりますが、auto-step03で止まるところがあります。
auto-step03の入力データに2007-2018年のcsvファイルがありますが、これがないためテストできない
状況です。テストでも構わないので作成済のデータがございましたら、提供して頂けないでしょうか。
宜しくお願いします。

@uwatoko様
ご連絡ありがとうございます。データをlili:/home/takao-y/pub/ml-region1-all-python/data-out　以下に置きました。ただ、39時間予報の設定と微妙に変わっている可能性がありますので、ご確認いただけますでしょうか。機械学習推定値（CDF適用前）に関しては、Yinさんがすでに実施されていますので、詳細についてはYinさんの方にお問い合わせいただけますでしょうか。（リアルタイム予報で実際に使うのは、Yinさんが作成されているデータです）
@gyin san,
Could you tell us the data directory of estimated precipitation by ML before applying CDF? It seems that Higashiuwatoko-san needs the test data for 39 hour forecast to apply to the CDF.
Best Regards,
T. Yoshikane

チャンネル名を「01_machine-learning」から「04_machine-learning」に変更しました

チャンネルのトピックを設定 : 機械学習による雨量推定

@snm1.nextさんがチャンネルに参加しました

@andoh_takafusaさんがチャンネルに参加しました

@hayakawa-gen1010さんがチャンネルに参加しました

@suzuki.s-hyさんがチャンネルに参加しました

@oki.rikoさんがチャンネルに参加しました

@kakuda_ryosukeさんがチャンネルに参加しました

@fujii.hideyukiさんがチャンネルに参加しました

@kenshi.hibinoさんがチャンネルに参加しました

@ooishi.h-ieさんがチャンネルに参加しました

@yixisi1505さんがチャンネルに参加しました

@sasage.e-heさんがチャンネルに参加しました

@fujishima.s-fcさんがチャンネルに参加しました

Dear @takao-y -sensei, @uwatoko -san,

The classifiers for sites A-E from Jan to Dec generated by using data from 2007-2020 are now available in:
/lebron_disk09/gyin/classifier_2007_2020

I am sorry that the process was a little slower than I expected. Please let me know if there is any problem or missing files. Thank you very much!

Best regards,
Gaohong

@takao-y 様、@gyin様
ありがとうございます。
了解しました。

@takao-y 様、@gyin様
/lebron_disk09/gyin/classifier_2007_2020のディレクトリに
mod1_xxx_xxx-gamma_0.000005-cost_4-epsilon_0.0001.pkl
ファイルがsite毎、月事に存在する事を確認いたしました。このファイルが識別器なのでしょうか。
これまでの識別器はmod1_xx_xx.cmp というファイル名で600Kbyte程度だったのに対し、このファイルは20Mbyte以上あります。

@takao-y 様、@gyin様
すみません、サイトAで確かめているのですが、
新しい識別器(mod1_xxx_xxx-gamma_0.0000005-cost_8-epsilon_0.001.pkl)で
動作確認(auto-step02.sh)を実施したところ、データの読み込みはできたのですが、
predictedY1 = clf.predict(X)
を実行した際に以下のエラーとなります。
ValueError: X.shape[1] = 440 should be equal to 625, the number of features at training time
(学習時と特徴量が合っていない？）
新しい識別器に対応する推定処理プログラムがありますでしょうか。

@yamamoto.kosuke さん
すみません、teamsに入れてないトラブルに見舞われております。

@yamamoto.kosuke @uwatoko @kubota.takuji
Thank you very much for just now.
I have finished sending the invitation to participate in our work-group of the S2S-AI-Challenge competition.
I would highly appreciate it if you would participate in our group.

Best Regards,
Ryo Kaneko

昨日の補足ですが、3時間積算値の降水分布が過去12年間では類似した事例がなく、学習できなかった可能性があります。過去の似た事例（降水が少ない？）に当てはめて推定しているのかもしれません。とりあえず、台風１９号の事例を学習に取り入れて過学習を意図的に起こして推定できるのか確認いたします。

対策としては、
1. 外れ値（異常値）検出を実施し、予測に使用しない
2. 特徴量の範囲を狭めて強雨事例を学習しやすくする

1.では通常のパターンに当てはまらないパターンを検出し除去するもので、台風19号のようなケースを異常値として扱い、予測に使用しないようにします。

2.はYinさんが説明されていたように、特徴量の範囲を変えるとその範囲での強雨事例が増えることから極端な過小評価は解消されます。ただし、結果的に分布特性はMSMに近くなり、分布のバイアス補正効果が小さくなります（RG=0では実質的に分位マッピングと同じで単にアンサンブルメンバーが増えただけの効果しかない？）。1を活用して、異常値には特徴量範囲を狭めることもできるかと思います。

量的にはCDF-transform法を用いることにより、MSMの予報値を反映した値が推定されるため、過去に観測されていない降水にも対応可能です。特に台風19号のようなケースには効果的と推測されますが、元々は温暖化実験で使われているものを予報用に（やや強引に）適用したもので、もう少し検証が必要かもしれません。