Diary July, 2009

 

31日Fri.

チリ行きまであと12

LHC students face data drought

28日Tue.

受かった!?

背景放射で拓く宇宙創成の物理 −インフレーションからダークエイジまで−

これであんなことやこんなことが・・・。

  • つくづく、羽澄さんすげえわ。 -- コマツ 2009-08-01 (土) 20:30:49
  • すげえです。 -- チノネ 2009-08-02 (日) 03:38:11

26日Sun.

KEK CMB組は以下のスケジュールで2009年天文夏の学校(草津)へ行きます。 合流する方募集中!

  • TXつくば駅 10:55 発
    • TX快速・秋葉原行
    • 33分
  • 北千住 11:28 着
    • 乗り換え 7分
  • 北千住 11:35 発
    • 東京メトロ日比谷線・中目黒行
    • 8分
  • 11:43 上野 着
    • 乗り換え 17分
  • 12:00 上野 発
    • 吾妻線
    • 新特急「草津5号」
    • 5,330円
    • 2時間33分
  • 14:33 長野原草津口 着
    • 乗り換え 7分
  • 14:40 長野原草津口 発
    • JRバス(急)
    • 22分
  • 15:02 草津温泉ホテル櫻井 着

ホテルはネットつながるかな?


24日Fri.

CMB解析において最も重要な解析は、キャリブレーション解析であると言っても過言ではない。 キャリブレーション解析は観測装置の特性を決める解析である。 CMB偏光観測で特に重要なのは

  • 電気的なシグナルを温度に変える変換係数を求める(またそのエラーを評価する) ⇒ ゲインキャリブレーション
  • 偏光の角度を決める(またそのエラーを評価する) ⇒ 角度キャリブレーション
  • 観測機器による温度から偏光へのもれ込みを決める(またそのエラーを評価する) ⇒ リーケージキャリブレーション
  • ビームの大きさを決める(またそのエラーを評価する) ⇒ ビームキャリブレーション
  • ポインティングの誤差を決める ⇒ ポインティングキャリブレーション

等である。 この論文(CMB偏光観測従事者必読!)によれば、これらは11のパラメータで記述される。 例えば、rを幾ら幾らまで測定したいと考えた場合、11パラメータを何%の精度でコントロールしなければならない、といったふうになる。


キャリブレーション解析は重要ではあるが、これで全てではない。

日々の観測はノイズドミナントで、 数ヶ月観測してようやく見えてくる様な微細なシグナルを観測する必要があるCMB偏光観測においては、 日々の観測の中で、キャリブレーションでは見えてこない好ましくない効果を推定、補正、除去しなければならない。

TOD

日々のデータにおいては、検出器のTime Order Data(=時系列データ,TOD)の解析が大変重要である。 先に述べたようように、日々の観測においてノイズドミナントなCMB観測では、 TODはほとんどノイズである。TOD解析はノイズ解析である。

noise.png

図は典型的なTOD(下)とそのスペクトラム(上)である。 まず下だけを見てもらいたい。 自分がこの絵を始めてみたときには

  • ノイズだらけ
    • 短い周期のwhiteなノイズ(この図で振幅が1ぐらい)
      • CMBはこいつに比べても圧倒的に小さい
      • でもまぁ一ヶ月も一年も積分すれば、CMB見えてくるかもね。
    • なんか全体がうねってるんですが(この図で振幅が10が程度)
      • 圧倒的にうねうねしているデータから、小さな小さなCMBのシグナルを取り出すことなんてできるの?
  • でこんなデータから本当にCMBが見えるの?

と思ったものである。 でも世の中には賢いツールがあって、そいつが回答を与えてくれる。 フーリエ変換を上手く使うのである。 上の図はTODをフーリエ変換し、スペクトラムにしたものである(とても美しい)。

このノイズスペクトラムは、ノイズの周波数特性を我々に教えてくれる。 この図から、下のTODには

  • 高周波で一定なWhiteノイズ
  • 低周波に行けば行くほど(周期が長い)大きくなるノイズ=うねうねノイズ=1/fノイズ

が含まれていることが一目で分かる。


先の疑問で書いたように、1/fノイズはCMB観測にとって好ましくない。 どうするか、答えは可能な限り除去する、である。

その方法は?

フーリエ変換をした今ならその答えは明確である。 周波数空間で左肩上がりになっているノイズ成分を、 周波数空間で除去(=フィルタリング、具体的にはノイズによって重み付けられたhigh-pass filter)すればいいのである。 そうすればwhiteなノイズだけが残り、長時間の積分が可能となる。


ここでそもそも1/fノイズの原因は何か考えてみる。 QUIETで使われるようなHEMTアンプは アンプ(検出器で検出できるように微細なシグナルを増幅する装置)に半導体(FET)を使用している。 1/fノイズは半導体の接合面に出来たエネルギー準位に、 キャリアが不規則にトラップされることで発生すると考えられている(すみません勉強不足です)。


HEMT以外にはBolometerの検出器、最近では特にTES検出器が有名である。 TESの場合、アンプに半導体を使わないので、 基本的には1/fノイズは小さいとされているが、 検出器系に線形応答システムを含む限り1/fノイズを免れることはできない。

実の所は、実験の設計として、1/fノイズドミナントな周波数領域では、CMBをできるだけ見ないように設定している。 例えばスキャンのスピードが2 deg/secであるような場合、0.1秒で0.2度(l=900)、1秒で2度(l=90)、10秒で20度(l=9)の空を見ることになるが、 これは周波数にしてそれぞれ、10,1,0.1Hzである。上の図から、この範囲(l〜10-1000)ではノイズがほとんどwhiteであることが分かる。


それでもやはり、1/fノイズは色々と厄介であるのは確かである。 可能な限り抑えたい。

フィルタリングの前の段階で1/fノイズを抑さえるために最も良く使われる方法が、modulationである (modulationはこれ以外のシステマティックも抑えることができる優秀な方法である)。 考えられる典型的な周波数(例えばスキャンの周波数、検出器の1/f)より充分早い速度で、 入力電磁波の符号を反転させ(=modulate)ることで、その揺らぎを打ち消すことが可能である。

HEMTであるQUIETは、一度modulationをかけたものの上に更にmodulation(=double-modulation)を行なう徹底ぶりである。 このことにより、QUIETは他の観測に比べて検出器の個数が小さいにも拘らず、データ量が大きくなってしまっている。


TOD/ノイズスペクトラムには、これ以外にも様々な特徴が表れる。 例えば

  • スキャンに同期したノイズ(Scan Synchronous Signal: SSS)
    • 地上観測の場合、周期的なスキャンを繰り返すため、スキャンに同期したシグナルを拾うことがある。
    • velocity=2deg/sec、amplitude=10 deg ⇒ 1/5=0.2 Hz
    • 完全に同期していれば、spikeになるはずである。この場合除去も容易である。
    • 完全には同期していない場合、broadなbumpとなる。除去は難しい。
      • Sidelobe or atmosphere ?
  • 10Hz程度のhigh frequency noise
    • データは50Hzで記録されている。観測装置の一般的な電源はAC 60Hzである。
    • 60-50=10 Hzのようなaliasingがおこっている。
      • low-pass filter or cut

等である。


重要なこと:

  • 1/fノイズ(low frequency)
    • high-pass filter
  • high frequency noise
    • low-pass
  • 様々なシステマティック
    • spike or broad SSS
  • その他特徴的なパラメータの関係
    • 書けなかったが、これもとても重要。
    • 例えばTOD、それを特徴付けるパラメータ、観測装置を特徴付けるパラメータ、天気、etc,.等の相関

実は図のスペクトラムは、TODをフーリエ変換して書いたわけではない。 パワースペクトラムをフーリエ変換してTODを書いている。 1/fノイズの生成機構自体は、難しく、実際完全に解明されているわけではない。 しかしながら1/fノイズが存在することは確かである。 そして1/fノイズは容易にモデル化でき、

pnu.png

とかける。このノイズパワースペクトラムをフーリエ変換すれば、TODの出来上がりである。

Null test

CMB解析においてNull testはTOD解析と並んで重要である(お互い独立に存在するものでもない)。 ここにきてMap Making、Power Spectrum(Clの計算)とかは重要じゃないのか、と言われるかもしれないが、 キャリブレーション解析、Null test、TOD解析に比べればこれらは重要でない。


CMBのデータ解析に於いて、null testは大変重要である。 null testをしなかった(パスしなかった)power spectrumは、怖くて見せられない。

一般的に、検出器の出力にはCMBのシグナル以外に様々なノイズやシステマティックが混入している。

そのためノイズの評価、未知のシステマティックを考慮しなかった場合のpower spectrumは、 その分誤った値となる。これを防ぐのがnull testである。

null testは、その名の通り「nullであることを確認するtest」である。 人によってはJackknife testと呼んだりもする。 もしNullにならなかった場合、システマティックがあることになる。 理想はそのシステマティックの原因を解明し改善することだが、 無理であれば、nullにならなかった分をシステマティックエラーとして計上することになる。


幾つか具体的な例を挙げる。

一年間の観測データがあった場合を考える。 そのデータを前半・後半に分け、(TOD解析を経た後に)それぞれのmapを作成する。

もし未知のノイズ、システマティックがなければこの二つのmapはノイズの範囲内で完全に一致するはずである。 つまり、二つのmapの差をとった結果が、(ノイズの範囲内で)nullであることが示せれば、 未知のノイズ、システマティックがないことになる。 逆にnullでない場合、観測の前半と後半でノイズの評価を間違っていたり、システマティックを見落としていることになる。 これらの値を定量的比較する為、差をとったmapのPower spectrum(Cl)を計算するのが一般的である。 このNull testは、時間で変化しうるシステマティック(季節変動、観測装置に長期的な安定性)に敏感である。

単純に時間を分ける以外にも

  • Detectorの角度ごとに分ける
    • 偏光を測定する為には、その角度を決める必要がある。 この角度の絶対的な精度はキャリブレートされなければならない。 また測定されるQ/U自体は、座標系の回転で任意に変化させることができる。 一方でE/B自体は変化しない。
    • つまりDetectorの角度によるNullテストは、 偏光角度のキャリブレーションのシステマティック、 Q/Uを測定する検出器のそれぞれのキャリブレーションのシステマティックに敏感である。

  • Elevationの角度ごとに分ける
    • 地上観測で広く行なわれているConstant Elevation Scan(CES)は、その名の通り一定のElevationをスキャンすることで、 天域を掃く方法である。
    • Elavationが変化すると、大気の温度(厚み)の変化する。
    • 大気を使った定常的な相対キャリブレーションにより、(偏光ではなく)温度についてはElevation補正を考えることが可能である。
    • Null testを行なうことで、この補正の正当性を確認することができる。
      • 大気の温度自体はモデルに依存している。その為このキャリブレーションで分かるのは、あくまでも相対的なゲインである。
    • QUIETでは大気を使ったキャリブレーションに加え、偏光源(TauA、最も明るい偏光点源)を使った絶対ゲインのキャリブレーションも行なっている。 しかしながら、チリでTauAを観測できるElevationは限られており、 絶対ゲインのElavation依存性を考えることができない。絶対ゲインのElevation依存は、Null testを行なうことで評価することができる。
      • 一般的には、最も大きな大気による偏光は、ice crystalであり、その寄与は充分小さいと考えられている。だが確認はするべきである。
    • ゲインのElevation変化以外にも、Elevationはground pick upにも敏感である。
      • grounf pick upとは地面からの放射・反射が検出器に入ってしまう効果である。当然好ましくない。低いElevationほど効果が大きいと考えられる。

これら以外にも

  • 検出器ごと。
    • 異なる検出器で同じものを見ているのだから、その差はNullであるべきである。
  • スキャンの速度ごと。
  • スキャンしている天域と太陽との距離。
  • スキャンしている天域と月との距離。
  • 観測装置の温度、温度変化。
  • 装置に対して何らかの操作をした前と後
    • 数ヶ月に渡る観測なので、その間にメンテナンスや修理などの作業は必ず必要になる。
  • スキャンの行きと帰り。
  • 装置の状態(ADC boardの温度が高い・低い等)
  • 天気の良し悪し
    • Humidity
    • PWV
    • sky tempareture
  • 感度・ノイズの良し悪し
    • 検出器の性能は基本的には一定だが、その間でも感度がよい場合、悪い場合がある。
    • 感度が良かろうと悪かろうと、見ているものは同じなのでその差はノイズの範囲内でNull出なければならない。
    • etc,.

様々なNull testを考えることができる。


これら全ての結果を統計的に扱うには、 例えば、それぞれのNull testでパワースペクトラムのChi-Squareを計算し、 p-valueを計算すればよい。様々なNull testのp-valueのヒストグラムを書いた場合、 p-valueが5%-95%程度で一様でああれば(Chi-Squareが良すぎず悪すぎず)、一連のNull testの結果は統計的に見てNullであると言える。

Now

今まさに以上の解析をやっている!

  • >書けなかったが、これもとても重要。 つづきお願いします! -- go to 2009-08-21 (金) 15:23:08

22日Wed.

日食見えたよ。


21日Tue.

  • 自腹で(一万円)健康診断。問題なし。問診もきっちり受けられてよかった。これでチリ行きははばっちり。
  • 健康診断が問題なかったので、いよいよサイトに連絡。 ⇒ いまだに返事こない・・・。催促するべき?
  • mysqlのlocalhost問題が解決したので、シカゴのサーバーのadminに設定のお願い。 ⇒ 未だ返事が来ない・・・。
  • 携帯電話の機種変更をした。海外でも使える(高いが)。
    • 値段高すぎ(over 4万円)。どうしてこんなことになったのか?店員に聞けば、「高性能なので、このぐらいする。今までが安すぎた。」 とか言うが(そんなのは分かっている)、その分通話料に上乗せしていたわけで。 総務省のアレやらこれやらも絡んでくるが、納得いかない。
    • 確かに「高性能」だが、その機能を使うにパケット通信が必須。 ⇒ 使いません、はい。
      • こんな「高性能」いりません。
    • 色々とオプションをつけると15,000円安くなる。パケット割とか指定割とか。一ヶ月で解約可。すぐに解約すれば実質的に9,000円ほどお得。 なんでこんな面倒なことを(最初から9,000円安くしてくれ!)・・・。 解約し忘れを狙っていたり、最初のうちに上記の「高性能」を味合わせて、もうもとの(パケット定額)生活に戻れないように仕向けているんだろうな・・・、 と心の汚い私は考えてします。
  • 授業料半免。
  • 健康診断で採決した箇所近辺が、黒ずんでいる
    arm.png
    んだが、大丈夫か?
  • 気がつけば来週は夏の学校。
  • 注文したパソコンが届かない。早く来ないかな

明日は皆既日食


17日Fri.

MySQLに於けるlocalhost、localhost.localdomain、127.0.0.1の扱い

/etc/hostsで

127.0.0.1       localhost.localdomain localhost

のように定義されている限り、localhost、localhost.localdomain、127.0.0.1はシステム上は同じに見えるはずである。

chinoney@master:~$ ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.143 ms
chinoney@master:~$ ping localhost.localdomain
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
chinoney@master:~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.055 ms

しかしMySQLではそのようになっていない。 MySQL上でlocalhostはローカルのソケット(ファイル)を通して接続を行なうが、 127.0.0.1はTCPソケットで127.0.0.1に接続を行なう。


二つのserver、masterとslaveとを考える。 両方でMySQLが稼動しており、GRANTは以下のようになっている:

  • master (mysql -u root -p -P 3306 localhost -D mysql)
    mysql> select user.User , user.Host , user.Password from user ;
    +------+-----------------------+------------------+
    | User | Host                  | Password         |
    +------+-----------------------+------------------+
    | root | localhost             | hoge             |
    | root | master                | hoge             |
    | root | 127.0.0.1             | hoge             |
    | root | localhost.localdomain | hoge             |
    +------+-----------------------+------------------+
  • slave (mysql -u root -p -P 3306 localhost -D mysql)
    mysql> select user.User , user.Host , user.Password from user ;
    +------+-----------------------+------------------+
    | User | Host                  | Password         |
    +------+-----------------------+------------------+
    | root | localhost             | hige             |
    | root | localhost.localdomain | hige             |
    | root | 127.0.0.1             | hige             |
    | root | slave                 | hige             |
    +------+-----------------------+------------------+

mysqldはポートをデフォルト=3306で起動している。 その為、「-P 3306」でポートを指定しようとしまいと、結果は同じである。 また「-h localhost」「-h localhost.localdomain」「-h 127.0.0.1」でも結果は同じである。


次にsshによるport forwardを考える。 下のようにmasterのport 3306をslaveのport 13306にforwardする:

ssh -L 13306:localhost:3306 chinoney@master       

(このコマンドはslave側から実行されている。) 人・環境によってはlocalhostではだめで、

ssh -L 13306:127.0.0.1:3306 chinoney@master       

としなければならない、という場合もあるらしい。自分は再現しなかった。

(参考)SSH port forward for MySQL

この様にport forwardを行うことで、slaveはlocalhostのport 13306にアクセスすることで、 masterのport 3306にアクセスすることができる。 (このとき、masterはlocalhostからport 3306にアクセスされたように認識する。)


しかし、先に述べたMySQL特有の性質から奇妙なことがおこる。 以下ではslaveからmasterのmysqlに繋げることを考える。

まず始めに「127.0.0.1」でport 13306にアクセスする:

[root@slave ~]# mysql -u root -p -h 127.0.0.1 -P 13306 -D mysql

このとき聞かれるパスワードはmasterのものである。slaveのパスワードではない:

mysql> select user.User , user.Host , user.Password from user ;
+------+-----------------------+------------------+
| User | Host                  | Password         |
+------+-----------------------+------------------+
| root | localhost             | hoge             |
| root | master                | hoge             |
| root | 127.0.0.1             | hoge             |
| root | localhost.localdomain | hoge             |
+------+-----------------------+------------------+

出力結果も確かにmasterのものである。

次に「localhost.localdomain」でport 13306にアクセスする:

[root@slave ~]# mysql -u root -p -h localhost.localdomain -P 13306 -D mysql

このとき聞かれるパスワードはmasterのものである。slaveのパスワードではない:

mysql> select user.User , user.Host , user.Password from user ;
+------+-----------------------+------------------+
| User | Host                  | Password         |
+------+-----------------------+------------------+
| root | localhost             | hoge             |
| root | master                | hoge             |
| root | 127.0.0.1             | hoge             |
| root | localhost.localdomain | hoge             |
+------+-----------------------+------------------+

出力結果も確かにmasterのものである。

次が問題である。「localhost」でport 13306にアクセスする:

[root@slave ~]# mysql -u root -p -h localhost -P 13306 -D mysql

このとき聞かれるパスワードはmasterのものではなく、slaveのものである:

mysql> select user.User , user.Host , user.Password from user ;
+------+-----------------------+------------------+
| User | Host                  | Password         |
+------+-----------------------+------------------+
| root | localhost             | hige             |
| root | localhost.localdomain | hige             |
| root | 127.0.0.1             | hige             |
| root | slave                 | hige             |
+------+-----------------------+------------------+

出力結果はslaveのものである。

つまり、mysqlは、接続するホストをlocalhostとした場合(デフォルト、指定しなければこれになる)、 例えポートが指定されていたとしても、ローカルのソケットファイルを使用し、ローカルのmysqldに接続してしまう。

デフォルト以外のポートを使いたい場合は、 localhostではなく「127.0.0.1」を指定しなければならない。

mysql_localhost.png


この事実を知るのに、三日かかった・・・。


12日Sun.

見てきた、破:

eva.jpg
1.jpg
2.jpg










ネタばれ掲示板


10日Fri.

binningの話:

bin.png

解説というか議論は後で


08日Wed.

いよいよチリ行きが現実のものとなってきた。

2009-04-05-chajobs-sm.jpg

旅行代理店に旅券の発行を依頼し、発券の段階までやってきた。

サイトでのシフトは2009/08/15〜2009/09/25である。 前日の8/14日にCalama入りする必要があるので、出発は12日である。 今回は北米経由なのでChicagoで一泊する。 13日にシカゴをでToronto経由で14日にSantiago入りし、更に乗り継いでCalamaへ入る。

行き:

  • Tokyo Narita Wed 12 Aug 16:55
    • 11h19m
  • Chicago Ohare 14:14

  • Chicago Ohare Thu 13 Aug 19:25
    • 1h33m
  • Toronto Pearson Intl 21:58

  • Toronto Pearson Intl 23:50
    • 10h30m
  • Santiago Fri 14 Aug 10:20

  • Santiago Fri 14 Aug 16:00
    • 2h10m
  • Calama 18:00

と、遠い・・・、果てしなく遠い。

そして本当に日本語のまったく通じない土地にひとり放り出されてどうにかなってしまわないか、結構真剣に心配している。 予習しておくべし。

帰りは9/26日にCalamaを出て29日に帰国する。

往復旅券の料金は税込みで45万円。自腹じゃ払えません(でも立て替える必要はある・・・)。


[シカゴ滞在最終日] 03日Fri./04日Sat.

再見:

see_you_again.jpg

戦利品:

tips.jpg

[シカゴ滞在6日目] 02日Thu.

研究会二日目。将来計画に関する発表が続く。

自分がマイノリティーにいるからなのかも知れないが、気にかかることがある。 「こんなにTES bolometerの観測計画があってどうするの?」

CMBを観測する検出器の技術にはは主に二つである。 「HEMT技術と」と「Bolometer技術」である。 HEMTは「電波」の技術で主に100GHzより低い周波数帯で使われる。 一方Bolometerは「温度計」で主に100GHzより高い周波数帯で使われる。

  • Bolometer
    • PSB/Spider
      • Planck
      • QUaD
      • BICEP
    • TES
      • ABS
      • Clover(canceled)
      • BICEP2/Keck
      • SPTPol
      • ACTPol
      • POLARBEAR
      • EBEX(気球)
      • SPIDER(気球)
      • CMBPol(次期衛星計画)
  • HEMT
    • CAPMAP
    • QUIET1/2

CMB B-modeを観測するの決め手となるのは、如何にノイズを減らせるかである。 単独の検出器では無理である。ではどうするか。大量の検出器を並べればいいのである。 HEMT、Bolometerそれぞれに特有のノイズはあるが、結局は数である。

それぞれで微細化・大量生産の方法はある程度確立されているが、 高周波数・テクノロジーの急速な進歩という点でBolometer、特にTES bolometerに分があるといえる (パラメータの上で。実際キャリブレーションやら、システマティックを考えると、TESだってそこまで楽ではないだろうに、と思うのだが・・・。 今後はdust fgも気になるところ。)。

この様な現状で、B-modeをいち早く検出するためには、 他のグループに先駆けて大量のTES Bolometerを使って観測を行うことである。 なので皆一生懸命に開発を行なっている。 この調子で行けばそう遠くない日にr=0.01に達せられる、、、用にも思える。 少なくともBolometerの方々はそう思っているのだろう。

この中に於いて我々のQUIETはマイノリティーである。 低周波数をHEMTで見よう、可能な限りシステマティックを消せるシステム(モジュレーション、ダブルモジュレーション、etc,.)を作ろう、 でもやはり数も大切なので、枯れたRFの技術を使いつつ、検出器の小型化もすすめよう。 それがQUIETである。

「Bolometerでいいじゃん」という人たちに一泡吹かせてやるといつもりはないが、 将来的には二つのタイプの検出器で無矛盾であるという結果が得られることが望ましいと思う。

このことに関して、パネルディスカッションの中で面白い場面があった:

panel.jpg

誰かが「CMB偏光観測を目的とした計画が沢山あるけれども・・・」といったところ、 Bruceが「いいやそうではない、Bolometerがいっぱいあるだけだ」と。

パネルディスカッションではもう一点焦点となったことがあった。

データ解析は装置の開発、観測と同等に重要である。しかしながら解析に割くことのできるマンパワー(大学院生、ポスドク)、 (次の計画の準備があるので)余裕、お金がない。どうしたものかと。 我々はコンピューターサイエンティストではない。どうしたものか。 ・・・・・とあーだこーだ議論しているうちに、火災報知機が誤作動して、皆屋外に対比してディスカッション終了。

その後は夕食、レセプションと続くのだが・・・、


[シカゴ滞在5日目] 01日Wed.

今日からCMBPol meeting。

cmbpol.jpg

やはり英語。議論・質問したくとも、英語がしゃべれないことが何事にもネックとなる。 話されている内容は完全ではないが、殆どのことはフォローしている。 それにも拘らず、議論に参加できない。

拙い英語での面と向って伝えようと努力すれば、相手も理解しようと努力してくれるので何とかなる。 今までのそれで何とかなった。英語でのtalkは準備するればどうにかなる。これも今回の会議で分かった。

でもだ。

議論がいよいよ白熱すると、皆そんな気を使っている暇がなくなる。

口を出したいのに出せない、そんなフラストレーションを感じる一日であった。


添付ファイル: filenoise.png 1777件 [詳細] filetod.png 327件 [詳細] filepnu.png 1656件 [詳細] filespectrum.png 293件 [詳細] filearm.png 537件 [詳細] filemysql_localhost.png 558件 [詳細] fileeva.jpg 696件 [詳細] file2.jpg 558件 [詳細] file1.jpg 563件 [詳細] filebin.png 541件 [詳細] filetips.jpg 548件 [詳細] filesee_you_again.jpg 531件 [詳細] filepanel.jpg 555件 [詳細] filecmbpol.jpg 539件 [詳細]