[JS] 水文統計改為 JavaScript

利用假日把水文統計網頁改為 JavaScript ，可在 Edge / Chrome 中執行，有問題再反映。

水文統計：http://www.hisdt.com/Tools/stat/Stat.asp

Chrome 執行畫面

舊版 VBScript 網頁在文末有超連結，仍可用 Edge 開啟 IE 相容模式執行。

[AI] 關於類神經網路的學習經驗分享

話說五月下旬在：

台灣「人工智慧」社團 https://www.facebook.com/groups/Taiwan.AI.Group/

回了一篇落落長的文，要找的時候才發現被砍文了。
在別人的地盤發文的缺點就是刀在人家手上，想砍隨便砍…

看這張擷圖，我在回這篇前幾天寫了一篇落落長的回文，在這篇回應時提到另一篇給樓主看，兩天前要找已經找不到了。

有圖有真相

我也忘了那篇不見的文章在講啥，就輕鬆分享一些我的想法吧。

1992 (民81) 升大三的暑假，我參加了我唸研究所指導教授的研究生 meeting ，就當成研究會好了，我還記得陳德源學長念混沌 (chaos)、劉業主學長負責念模糊 (fuzzy)，還有幾個學長念啥我忘了，一個負責專家系統，我負責念類神經網路 (ANN) ，這是我最早接觸人工智慧 (AI) 的年代，當時念類神經網路應該是一本倚天出的電腦書，那本書大概只有概念，沒辦法依據這個概念去實作。

1994 (民83) 碩一上，去成大電機所念碩博合開的類神經網路，授課教授規定作業都要交程式碼跟運行結果，所以我就買了葉怡成教授的類神經網路，那時候葉老師的書是有 C的程式碼，我則是看懂後，改用 Quick Basic 4.5 寫作業，果然，實作才是王道，我終於開始入門了。後來葉怡成老師新改版的書已經抽掉程式碼。

碩士作業 類神經網路原始碼

碩士班搞了很多東西，主要包含 GIS 跟 NetFlow Programming，到了碩二下的三月，指導教授叫我列出來得及畢業的論文方向，並簡易試作，其中網流規劃我是計畫專任助理，會跟計畫成果有重疊，所以碩士論文就決定是類神經網路。

四月春假把原先的 QB 程式碼改用 Visual Basic 3 改寫後，每天晚上研究室的多台電腦都被我借來做算不同案例的批次學習，一早我再去每台電腦把計算結果拷貝到電腦進行分析檢討。

我的碩士論文是從曾文水庫九個電傳雨量站去預報未來一小時後曾文水庫的進水量，內容可到我個人網站找，網誌這邊沒有。

一開始滿白目的，犯了一個通盤的錯誤，所以我學習訓練的結果我總合來說，不用學習就可以使用公式：
f(t+1)=f(t)
來取代。

認真去看很多論文，其實都犯了這個錯誤，只用觀測量去推估預測量，例如預測一小時後，得到的結論是預測得很好，預測值只落後觀測值一小時。這種結論其實就是：
f(t+1)=f(t)

好在那時有念時序列分析，當我自己得到跟別人相同結論：「預測得很好，預測值只落後觀測值一小時」時，我是很洩氣，為啥大家做的都差不多，那到底用 ANN 還有甚麼意義？看著看著就想到時系列分析的 AR 模式，然後回想到非線性規劃，我就悟了。

這個狀況在五月初發現，說實在的，以碩士論文程度來說，沒發現也不會怎樣，更不要說那個年代沒幾個人懂，繼續往下做也沒關係，反正就是多一篇垃圾，當然發現得早就是指導教授會要我改… 所以我在 BPN (倒傳遞網路) 裡面加入了不學習的輸出節點當成系統內能，再轉入下一個時段的輸入節點。

這邊就要說，如果使用現成的套件，是不可能自己改架構的，學習不可能允許一個輸出值不被控制，所以能的話還是自己開發比較好，架構可以隨意調整，學習目標也可以任意變動，前期的值域，選擇的反映函數，輸出的映射，學習的目標函數，參數的最佳化等，才能自行變動。

再忙到七月論文口試之前，又體驗了過度描述 (over fitting) 問題。

用基本的數學原理來看問題。
一條變數、一條方程式可以得到一個唯一解。
所以當 n 個變數時，至少需要簡化後方程式還有 n 個方程式才能得到唯一解。
若小於上述條件時，將為無限多組解，當大於上述條件時，將得到近似解。

這段說得很饒口，我再舉一個簡例，大家都會線性回歸吧？線性回歸直接有公式算，在 Excel 只要在圖上按一下滑鼠右鍵就可以加入。
y=ax+b

有兩個變數 a, b
當只有一點 (x1,y1) 時，可以決定出無限多條直線方程式。
當有兩點 (x1,y1)、(x2,y2) 時，可以得到唯一一條直線方程式。 (這兩行是國中數學)
當有三點 (x1,y1)、(x2,y2)、(x3,y3)、…、(xn,yn) 以上時，可得到一條近似方程式最接近所有的點，也就是回歸方程式。 (這行是高中數學)

所以從上面的簡例可以知道，要有一個正確解，至少方程式要大於等於變數量，你才能得到唯一解或近似解來接近真正解，而不是無意義的無限多組解來拚運氣。

以 BPN 來說，參數量很好計算，是依據反應函數方程式來推，所以一層隱藏層就是 3 次方的參數量，而要學習的數據有限，所以只能透過降低參數量來改善過度描述的問題。

比如說一個七次方程式如果因為曲率變化不大，我們可能可以降階到改用三次方程式描述這個函數，所以就減少了四參數。

因此，我需要修剪我的 BPN ，把不重要的因子去掉，保留重要的因子進行分析，所以透過敏感度分析後，把影響不大的變數優先移除掉，以確保我的變數量小於我要學習的組數。

如果是說倒傳遞網路 (BPN) 的批次學習，我的理解是參數量x6 是最少的批次學習尺度，參數量的計算是 神經元數 + 兩兩層數相乘，假設是標準的超越函數，原因是依據數學方成組理論來，變數大於方程組，無限多組解，變數等於方程組，唯一解，變數小於方程組 在目標函數下跑最佳化才有意義，也就是說學習才有意義。大於參數量 是有義解，3 倍學習量是建議最小值，如果是高度非線性，例如三角函數，至少需 6 倍學習量才能良好的描述，所以學習的筆數少於參數量，從數學來看是無義解。

我是覺得當時我碩士論文針對 ANN 找到這些重點算滿大貢獻的了，不過青睞的人不多，還好葉怡成教授看上了，還發個 eMail 給我說要放到參考資料內，我 Outlook 內還有留 1997/11/21 回給葉老師的信…

碩士論文全文可到臺灣博碩士論文知識加值系統下載：https://ndltd.ncl.edu.tw/

鄭子璉，「分佈型類神經網路降雨逕流模式之研究」，碩士論文，國立成功大學水利及海洋工程研究所，民國 85 年 6月。

當然直接在臺灣博碩士論文知識加值系統可以搜尋到更多其他人的論文，做研究這個網站很重要。

當兵的時候，指導教授有要我把論文精簡後投研討會論文：
http://www.hisdt.com/Paper/ANNRunoff/97topic.htm

當兵的時候，慢慢的想通所謂的學習，就是等同參數最佳化，就是非線性規劃的一種，ANN 通常採用的反應函數都是超越函數，透過微分 (牛頓法) 得到參數變化率的斜率，針對該斜率修正參數，逐步逼近最佳參數，達成最佳學習。

這裡面又有兩個關鍵點：
1. 參數最佳化
2. 評估函數 (目標函數)

首先先談參數最佳化。
牛頓法由於透過斜率為 0 來逼近最佳解，從高三數學教微積分就會教到，這會掉到區域最佳解。所以 ANN 透過多次亂數為起始值進行學習，來盡量找到全域最佳解。
非線性規劃屬於數學規劃的一種，而非線性規劃裡面談到最多的就是怎樣閃掉區域最佳解，所以為了解決這個問題，發展出多種參數逼近的方式。
在人工智慧裡面有個旁支是遺傳演算法，遺傳演算法若從非線性規劃的角度去解釋的話，可以當成格網縮放法 + 隨機格網，可以找到很多研究關於類神經網路與遺傳演算法的混和應用，我個人對於那種把兩種方法分兩步驟用的，沒有感覺，我認為拿遺傳演算法來做學習的，才叫做混和應用。
比如說牛頓法的原理是微分斜率為 0 ，重點就是連續可微。但是實際的應用大多數是有界的，就會產生不連續面，也就是不可微分點，如果還硬用牛頓法硬套，很大的可能結果是一直落在邊界附近的區域最佳解。
這種情形數學理論上來說，應該改用可處理有界或是不連續的非線性規畫法來推參數，也就是所謂的學習，而不是直接用既有的函數庫硬套學習，牛頓法如果能成為通解，後面也不會有一堆數學家研究非線性規劃的方法冒出來。
當然，非線性規劃有很多方法，用其他方法來取代牛頓法進行學習都是提高 ANN 的價值，回到老問題，想要做到這件事，就得自己開發軟體。

其次很重要的是評估函數。
大多數 BPN 可能會用均方根誤差來做評估函數，均方根越小，就認定參數越好，均方根縮小的曲線，就被稱為學習曲線。
很多軟體允許使用者選擇評估函數，但是也是有限的幾種。
從前面討論的線性回歸來看評估函數，線性回歸的公式應該是高二下在教，是利用 y 軸的最小距離平方法來推導，又稱最小平方法或是最小二乘方法。
均方根顧名思義，就是把誤差開根號取平均，最小平方法就是把誤差取平方。兩個在應用上的差別是容易受少數特異點影響，而造成回歸式改變，而均方根誤差，則是因為不受少數特異點影響而改變。
舉個例子好了，比如說要預測雨量，以南部地區來說大部分的情況下是不下雨的，只有少數情形是下雨。所以我不用任何 AI 模式或衛星雲圖，我直接給你 f(t+1)=0 ，也就是說我永遠預測未來一小時後降雨量為 0 ，我的準確率可達 98% 以上，因為南部下雨天數少於 60 天，所以算起來超過 98% 是不下雨的，那麼我到底準還是不準？以降雨預測資料進行學習，若使用均方根誤差，則預測的降雨會偏向 0 ，若使用最小平方法，則預設的降雨會比較大，因為小值的誤差，平方後幾乎沒影響，大值平方後影響就會很大，所以預測的結果就會跟著變化。
拿線性回歸來玩，可以玩甚麼？不要再套用線性回歸，而改用非線性規劃來推估
y=ax+b
的 a, b 兩參數。
比如說就用最小均方根誤差、最大相關係數來比。
我找到了一篇剛好在討論這件事，也用了線性回歸來檢討：
機器學習大神最常用的 5 個回歸損失函數，你知道幾個？ https://buzzorange.com/techorange/2018/06/22/computer-learning-5-tips/

從輸出資料的特性，需正確選對評估函數，再使用此評估函數進行參數最佳化 (學習) ，整個設計的模型才會有意義。

用非線性規劃去做 ANN 的參數最佳化是退伍後才領悟的，放在前面是為了比較好的說明，當兵時主要想通的是評估函數這塊。退伍後，回到成大做研究助理，考博士班，所以回學校後就繼續參加研究會，那時相關的論文就多了。

我 ANN 的 VB3 原始碼先給一位直升碩士班的大四吳學弟做直升生的專題研究。

念博士班以後，把我原先的 ANN 模式升級到 VB6 後，幫一個無心唸碩士的學弟做颱風降雨預測。 (http://www.hisdt.com/Paper/rain00/rain00.htm)

類神經網路的 VB6 原始碼

又到工業及資訊管理研究所去念數學規劃，才把這塊讀通。到了博三升博四的那年暑假，指導教授要我自己列研究方向決定博士論文，我列了六個方向，其中類神經網路部分，當時有個逢甲來的博一陳學弟碩士做這塊，指導教授要我讓給學弟，最後依據系上大老蔡教授的建議下，走第七個方向 Hydro-Information ，所以才把人工智慧擺在一旁。

AI 人工智慧，在現代資訊技術進步下，應該明確的重新定義。

人工智慧的核心在模擬思考，只會計算的，那叫做計算機 (computer) 。
人腦不是記憶龐大就會產生智慧，更不是透過雲端查詢問題解決方案 (你以為打電話給廠商客服就算你有智慧嗎？)
人工智慧的
第一步是建造出模擬人類思考的正確模型，類神經網路只是簡化後的 Lite 版。
第二步是正確思考。
第三步是獨立思考。
第四部是創造性思考。

換種想法吧，就像養小孩，第一步老天爺做完了，所以第二步是你要教小孩甚麼是對的，第三步是你要信任小孩做正確的事，第四步是他能創造出新的價值。

所以 AI 的核心在第一步。
那麼跟雲端有啥關係？是認為目前電腦的計算速度跟儲存速度比不上人腦嗎？
演算法建模並驗證完成後，成為一個穩定的產品時，才是考慮雲端的時機，就跟檔案空間一樣，一台電腦只能服務你，一台雲端可以服務無數的你。
開發測試 AI 是小範圍的事，已開發完成的 AI 服務大眾才需要雲端，至少是第六步以後的事。

很多人把 AI 過度神化，我就問個問題，我現在要算 4 個數字的平均。
麻煩使用 AI 模型建立平均的架構，我要求也不高，算出來的平均誤差在 1% 以內就好。

ㄜ…

我以前玩過，會讓你懷疑人生，不是，是懷疑所謂的人工智慧。這種類型的硬要凹人工智慧的話，應該改用專家系統做，當然啦，平均直接用個函數就算出來了，是誰教你用所謂的人工智慧做？當然未來希望能整合進人工智慧裡，那就是要像人腦一樣，分理性跟感性，專家系統做理性，類神經網路做感性。

就跟幾年前雲端大熱一樣，雲端不就是伺服器(群)？改個名詞而已。

目前的人工智慧比較流於前人開發好的架構去套用，比如說人臉辨識的架構去套用不同的人臉沒啥問題，你拿來用衛星雲圖預測颱風路徑試看看。

人工智慧的模型、評估函數、參數最佳化、反應函數都是實務應用的重點，目前並沒有標準化的模型，深入理解後架構出來的東西才有意義。

不要跟幾年前雲端一樣，一頭熱不知道在熱啥。

[Stat] 數值 常態分佈累積機率函數 比較

最近開始整理水文統計網頁，打算重新用 ASP.NET 再寫一遍。 (關於 水文統計 – 線上分析 網頁)
最早的程式碼使用 Quick Basic 4.5 開發，是大四上 (1993) 修水文統計時開始寫的，當時以周文德[1]水文學原文為主。
念博一前半年 (2000) 的時候改寫成 ASP，採用 VBScript，那時工作要做動態網頁，所以當練功將大四的程式碼拿來改。

開始改寫時，想說精益求精，就開始把相關數值模型重新 research 。

參考維基百科[2] 的內容，原來數值模型還有好幾種，興起比較的意圖。

先用原先周文德水文學的方程式係數找到原作者跟年分[3]，分別把方程式使用 Excel 2013 VBA 寫成函數比較，另外加入 Excel 內建的 Excel NORM.S.DIST 函數一起比較，如下表：

標準差	1	2	3	4	5	6
Wiki 表	0.8413447460685000	0.9772498680520000	0.9986501019685000	0.9999683287580000	0.9999997133485000	0.9999999990135000
Excel NORM.S.DIST	0.8413447460685430	0.9772498680518210	0.9986501019683700	0.9999683287581670	0.9999997133484280	0.9999999990134120
Abramowitz and Stegun, 1965 周文德水文學	0.8411238352705170	0.9774369986442540	0.9984208362961290	0.9999107486493130	0.9999941679910000	0.9999995054414810
Zelen and Severo, 1964	0.8413447404219760	0.9772499379836130	0.9986500327776380	0.9999683139654060	0.9999997128950000	0.9999999990098780
Hart, 1968	0.8413447460685430	0.9772498680518210	0.9986501019683700	0.9999683287581670	0.9999997133484280	0.9999999990134120
Marsaglia, 2004	0.8413447461005850	0.9772498680966180	0.9986500987983220	0.9999401630918050	0.9935899936665050	0.8832228594191580

由於不知道正確數值該多少，所以從維基百科[2]的表格做為比對依據，網頁上的數值位數有限，拿來跟 Excel 函數比對，假定 Excel 函數是正確的。

Marsaglia 使用泰勒級數展開，初步測試，17 項以上，小數點就沒有太大的變化，所以使用 20 項，2*20+1 = 41 ，x 的最高次方項為 x^41 。做到泰勒級數展開式時，不得不回來幹繳 VBA 7.1 LongLong 的識別字元是 ^ ，搞得我級數函數一值錯…

[VBA] LongLong 超長整數

Hart 則直接參考 West 2009 年的論文[4]，裡面直接用 VB6 寫，剪來貼就可以了，West 說他把原始的 Fortran 函數轉成 VB 函數，果然我以前 Fortran 沒白學，以前的學者都用 Fortran 。

從比較表來看，以前水文統計使用周文德的累積機率函數誤差有點大，Zelen 的誤差都小於該函數，而 Hart 跟 Excel 結果完全一致，該不會 Excel 也用此函數來近似吧？

而 Marsaglia 使用泰勒級數展開，照理說泰勒級數展開應該要更準，不知道是寫錯還是其他問題，我懷疑也有可能是數值精度誤差問題，因為 x ^ 41 已經非常小，算完再去做除數，感覺誤差就被放大了。

所以我決定新版的水文統計在常態分佈累積機率函數就使用 Hart 了。(皮卡丘就是你了)

寫在這也希望給水利海洋相關從業人員參考，找個新函數比周文德的教科書更逼近，好吧，這是資訊從業人員的一種病。

1. https://zh.wikipedia.org/wiki/%E5%91%A8%E6%96%87%E5%BE%B7
2. https://en.wikipedia.org/wiki/Normal_distribution#Numerical_approximations_for_the_normal_CDF
3. https://books.google.com.tw/books?id=V1pHDwAAQBAJ&pg=PT523&lpg=PT523
4. https://s2.smu.edu/~aleskovs/emis/sqc2/accuratecumnorm.pdf

銀河的歷史，又翻過一頁~ 今年要重畫了，好期待~~~

關於 水文統計 – 線上分析 網頁

說實在的，我自己沒在用，所以從當練功在 2002 年寫好後，基本上沒啥改。

而我自己在 2005 就算是離開水利界了，有興趣的可以在這個網誌上翻到過去發生的事，所以，要不是有人問我不見一事，其實我根本忘了這個網頁。哈~~~

昨天收到有人透過 FB Messenger / 網誌線上留言給我，還說願意付費買，才知道還有人用。

先說找不到的狀況吧。

免費網域 twbbs.org 歷經 18 年終於停止服務，所以我另外申請新的免費網域，所以原先所有 tlcheng.twbbs.org 的全部改為 www.tlcheng.tk (現為 www.hisdt.com)。

水文統計線上分析的網址就變為：
http://www.hisdt.com/Tools/stat/Stat.asp

其次，這個網頁是在 2002 年寫的，那個年代只有 IE5 ，到現在都過了 16 年了，所以對新版相容度不夠，所以請改用桌面版的 IE 來瀏覽，最新版本的 IE11@Win7/8/8.1/10 仍然可以使用，但動態磚版本的 IE/Edge 或是 HTML5 瀏覽器 Chrome/FireFox 等就不能用。

因為早先這個網頁是基於推廣 VB 而採用 VBScript 寫的。

下面畫面是使用 IE11@Win2012r2 跑的。

使用 IE11 瀏覽水文統計線上分析網頁

我在這個網頁有加模擬 IE6 ，因此使用 IE 瀏覽時，不要在框架下用，直接瀏覽這個位置，才會啟用模擬功能，否則新版 IE11 會因為預設禁用 VBScript 而不能正常執行。

回歸曲線圖

既然仍有人用，我今年會抽點時間改用 ASP.NET + JavaScript 改寫新版，這樣就能用 Chrome 開，自然也可以用行動裝置開了。

如果有建議可以在下面留言，我規畫時一併納入，如果希望加入不同機率分布函數，公式要需求的人提供，我沒時間做文獻回顧，所以有功能需求的請把資料整理給我。

其實我不太滿意當時的作法，不過一時之間也沒其他想法，可能就直接重寫，不動架構吧。

[VBNET] 快速呈現縮放選擇框

常常在論壇上看到有人討論順暢的顯示控制項變化，一直沒想到以縮放選擇框為例來做說明，因為核心原始碼真的很短，而且取得容易，所以一直沒考慮過要寫類似的主題。

今天又看到類似的問題，一時興起，把以前的原始碼摘出來，並且用 CamStudio 2.0 錄影作為展示，以 1440×900 、每秒 30 格速度錄製。

用的電腦是 2007 買的，都在這個網誌有資料可查：
1. OS: Win2012r2 : [Windows] 超舊主機板安裝 Windows 2012 R2
2. 顯卡 EN210 : [硬體] ASUS EN8600GT 爆電容
3. CPU Intel Core Q6600 :  四核新電腦 – 華碩平台【四核魔神】DVD燒錄遊戲電腦

先說背景的原因是因為讓看倌知道，是用很舊的編譯器、硬體在跑，都可以很順暢時，不用擔心用新電腦會速度太慢。

一開始我碰上控制項變化會在螢幕殘影時，因為初始畫面很正常，我就很納悶，微軟是怎麼處理。

例如你開一個 Form1.vb 好了，微軟就會自動開一個 Form1.Designer.vb，如果你想到這麼做，你這篇基本上不用看了，答案就在 .Designer.vb 檔案中。

你會發現，微軟自動產生的原始碼，一開始都會讓控制項做
object.SuspendLayout()

最後做
object.ResumeLayout(False)
object.PerformLayout()

然後對照線上手冊說明後，你會發現，就這麼簡單。是的，所以根本沒想到要去寫一篇文來談這件事。

當然，經過測試後，大多數情形，只需要將容器做 object.SuspendLayout() ，裡面的控制項有沒有做 .SuspendLayout() 就影響不大了。常見的容器可能是 Form、PictureBox、Panel 等。

我有做了一個地理資訊展示，所以考量放大需求，需要一個控制項在地圖上框來框去，當滑鼠事件觸發後，統一呼叫 SetSelectRect ：

---

Private Overloads Function SetSelectRect(ByVal rect  As Hisdt.Drawing.RectangleD) As Hisdt.Drawing.RectangleD

   With shpSelectRect
      .SuspendLayout()

      .Location = rect.Location.ToPoint + picImage.Location
      .Size = rect.Size.ToSize

      .ResumeLayout(False)
      .PerformLayout()

      If .Size.Width <> 0 OrElse .Size.Height <> 0 Then .Visible = True
   End With
OnMapSelectChanged()
Return rect
End Function

---

因此當需要變動大量控制項，又很注重螢幕展示效能的時候，配合 SuspendLayout() 即可做到最大程度的改善。

那為什麼要呼叫 SuspendLayout() ？

從 VB 起，微軟設計上會讓應用程式開發工具自動化的工作。因此當你有任何控制項變更時，就會透過內部事件觸發重繪。到了 VBNET、C# 時，延續 VB 精神，將此功能內建在系統內，所以變成只有 C++ 需要人工重繪，而在 VBNET 及 C# 下，都可以輕鬆得開發程式。但反過來，太自動的時候，就會做了多餘的動作，因此大量控制項屬性變更時，先暫止自動觸發內部重繪事件，等到所有變更完成後，才允許自動重繪，就可以把展示的效能提升上來。

更進階就是使用記憶體繪圖、雙緩衝顯示之類的部分，就不在這篇討論範圍了。

影片中，滑鼠操作動作因為看不見選單，所以簡單解釋一下：
左鍵點選拖拉 -> 框選放大範圍
左鍵雙擊 -> 滑鼠位置中心放大 1.1 倍
右鍵單擊 -> 滑鼠位置中心縮小 1.1 倍
右鍵點選拖拉 -> 移動顯示範圍
滾輪下捲 -> 滑鼠位置中心放大 1.1 倍
滾輪上捲 -> 滑鼠位置中心縮小 1.1 倍

將克利金用在等照度線上

公司的暗房完成了，但是沒有對應軟體可以即時繪製等照度線，測試光照強度。

先前剛好有做克利金相關分析：克利金法類別雛型開發完成

所以拿來套用在這隻程式上。

程式是用 VB2013 來寫的，考慮到 XP 相容性，所以 .Net framework 版本使用 2.0 版，考慮到便於攜帶，所以先選用 odbc + access 2k 的資料庫，讓程式免安裝，可以直接拷貝到監測設備電腦上。現場是使用 Win7 x64 ，所以編譯成 x86 模式來執行。

架構套用先前氣象局案子的殼，為了那個案子做好圖層功能、列印、存檔，所以拿來套用最快，這些功能僅須小幅修改，原先自行定義 PointD 的結構，模擬 .Net framework 內建的 PointF ，只是使用倍精度，雖然會造成計算變慢，但可以確保計算誤差降到最低。大概花了三周弄完，又花了一周調適照度計。

目前先提供幾個基本圖層：

格線座標軸、照度計量測值、照度等值線、照度計配置圖、建物平面圖、底圖。

所有的圖檔都是使用向量檔，便於放大檢視。

現場展示的 PC 大概 1.3 秒可完成一次克利金等值線計算，不過考慮不需要把時間逼太緊，造成 CPU 資源使用過度，因此 10 秒跑一次等值線，照度計每秒更新一次，45 個照度計，分到 3 顆 AD 轉換器讀取，一顆 AD 轉換器約耗時 200 ~ 300 ms ，勉強在 1 秒可更新一次。

燈源是 LED 路燈，安裝在電動升降台上，可依據需求升高、降低，最高可達八米高，距暗房屋頂大概還有六米左右，若有需求未來可把升降台軌道再往上加。

顏色要由使用單位回饋，現在暫時沒變更，圖示版面設計師構思，反正是先拼裝出來，再慢慢改，至少東西跟分析都可以做了。

克利金法目前的參數設定的有點問題，有空再針對參數做最佳化，不過我想先在克利金法內加入線性模式，因為先前模仿 Surfer 時，只做了一般克利金與指數克利金，所以有些情況會跌入 local minimum ，而造成影響半徑縮小，因此這部分參數看起來要動態算才對。

克利金用在等照度上

[ASPNET] 詭異的時間轉換失敗，重啟網頁服務可恢復

說實在的，我不知道問題如何發生，上次發生問題剛好就是截圖內的時間，2011/11/10 ，這次發生在 2012/05/16 15:00，大概是半年一次。

話說有同事通知我網頁跳錯誤，我就進 Server 用除錯模式查，一查，第一筆字串 2010/04/10 可以正確轉成時間，第二筆 2012/05/16 15:00 不能轉成時間，一時之間，忘了先前碰過，怎樣測都找不出問題來，想說弄個空白的測試檔，只放時間轉換測看看好了，忽然發現目錄內有保留上次的測試檔，內容只有四行，也就是截圖內的四行：

<%

Response.Write(CDate(“2011/11/10 17:00:00″))

Response.Write(CDate(“2011/11/10 17:00:00″))

%>

是吧？怎樣看都看不出這樣程式碼會有問題：

我想起來上次直接把 w3wp.exe 砍掉，讓 IIS 服務重新產生一個新的即可，砍之前還看了一下，w3wp.exe 只使用了 74 MB 記憶體。

砍完後重新執行測試網頁及原先網頁就正常了。

我是懷疑可能是執行緒的地區語言特性那個資料出問題，造成有些時間字串可以轉時間變數，有些時間字串會卡住，總之，留個紀錄，持續觀察。

監察院-莫拉克颱風期間曾文水庫調查報告

http://www.cy.gov.tw/ourpaper.asp?AP_Code=eDoc&Func_Code=t01&case_id=098000567

電子文件事由與說明

類　　別	調查報告
審議日期	981215	修改日期	2009/12/16
案　　由	陳委員健民調查，莫拉克八八水災專案調查研議：莫拉克颱風侵台造成台南縣嚴重水災，中央及地方主管機關平時有無落實災害演練、相關預警通報系統有無達成預期效果，災時有無及時通報聯繫，有無發揮應有整合效能，各級災害應變中心緊急應變處置有無失當等，均有深入調查之必要乙案之調查報告。
備　　註

098000567 電子文件

 

先前個人相關網誌：

2009/8/8 曾文水庫進水量破史上最高

2009/8/9 南水局應澈底檢討曾文水庫集水區電傳雨量

2009/8/9 曾文水庫放水記錄恐需詳查

2009/8/12 [小論]曾文水庫開啟閘門延宕時機的原因

 

芭瑪颱風與米勒颱風不知會否發生共伴效應

這應該是昨天晚上發布的了，昨天跑去高雄，回來晚了，就沒看 eMail ，早上起來看 eMail ，收到最新的資料如下。

在芭瑪颱風與米勒颱風剛好中間的位置，還有個熱帶性低氣壓，圖上看不出來，這個熱帶性低氣壓被兩個颱風夾住，相距各 1,000 公里左右，不知道會不會被吃掉，還是會發展成颱風…

兩個颱風與一個熱帶性低氣壓都是往台灣近海方向，算是滿熱鬧的，等到中午過後收到新資料再來看看~ 到時新圖再補上來。

 

 

[9/30 14:15 補]

 

[10/1 1:32 補]

 

[10/2 01:13 補]

 

[10/2 13:14 補]

 

[10/3 01:16 補]

 

[10/3 16:52 補] 中午出門吃飯逛逛，剛回來，右迴旋阿~

 

[10/4 01:12 補]

 

[10/5 01:12 補] 可以看到路徑與上面迥異，這也是個怪颱，最慘的是預報連續五天都打算在菲律賓混… 這是天要滅國嗎？

 

[10/5 13:32 補]

[作業級]交替區塊法求設計雨型

弄了個解作業的網頁，裡面有範例題目，對一般非水利的人大概沒啥作用，水利的可以玩看看…

設計雨型  http://www.hisdt.com/Tools/Hydrology/Hyetograph.htm

第一次試用的時候，直接按下 雨量組體計算 按鈕，會解範例，依照範例格式修改文字框，就可以算其他的案例。

這是用降雨強度公式來求不同延時的設計雨型，降雨強度公式 I(t) 記住使用 t 為變量，範例採分為單位，省去單位換算的問題，要求兩日或三日設計雨型時，就用 2,880 分或 4,320 分取代。

[作業級]水資源多目標計畫的成本分攤

弄了個解作業的網頁，裡面有範例題目，對一般非水利的人大概沒啥作用，水利的可以玩看看…

 

水資源多目標計畫的成本分攤 http://www.hisdt.com/Tools/WaterResource/Costs.htm

 

第一次試用的時候，直接按下 成本分攤計算 按鈕，會解範例，依照範例格式修改文字框，就可以算其他的案例。

 

[補充]

這個東西也可以運用在公司內部成本分攤上，比如說假設有個共同元件開發總需 70 萬，有三個專案要用，分別為 A, B, C 三個專案：

項目	A	B	C
元件可分離成本	14	23	15
預估效益	15	25	18
單獨專案開發成本	32	45	35

 

這個元件中 A 專案專用的功能要 14 萬，如果元件只開發給 A 專案要 32 萬 (表示 18 = 32 – 14 是跟其他專案共用功能) ，A 專案在元件 A 的部分可獲利 15 萬，B, C 專案同上，因為三個專案可能由公司內不同的 Team 開發或不同的合作廠商開發，現在合作開發後，須計算各專案應負擔的成本，把表格內容貼到網址內計算 (將下面文字複製貼入)：

---

項目,A,B,C
元件可分離成本,14,23,15
預估效益,15,25,18
單獨專案開發成本,32,45,35

---

可得計算結果：

剩餘效益法 (Remaining-benefits)						替代計畫適當經費法 (Alternative justifiable-expenditure)
[0]	項目	A	B	C	總計	[0]	項目	A	B	C	總計
[1]	元件可分離成本	14	23	15	52	[1]	元件可分離成本	14	23	15	52
[2]	預估效益	15	25	18	58	[2]	預估效益	15	25	18	58
[3]	單獨專案開發成本	32	45	35	112	[3]	單獨專案開發成本	32	45	35	112
[4]	Min([2],[3])	15	25	18	58	[4]	單目標替代計畫成本	32	45	35	112
[5]	剩餘效益	1	2	3	6	[5]	剩餘效益	18	22	20	60
	[4]-[1]						[4]-[1]
[6]	剩益比	16.67%	33.33%	50.00%	100.00%	[6]	剩益比	30.00%	36.67%	33.33%	100.00%
	[5]/Sum([5])						[5]/Sum([5])
[7]	聯合成本分配	3	6	9	18	[7]	聯合成本分配	5.4	6.6	6	18
	聯合成本*[6]						聯合成本*[6]
[8]	總分配款項	17	29	24	70	[8]	總分配款項	19.4	29.6	21	70
	[1]+[7]						[1]+[7]
[9]	總分配比例	24.29%	41.43%	34.29%	100.00%	[9]	總分配比例	27.71%	42.29%	30.00%	100.00%
[10]	節省成本	15	16	11	42	[10]	節省成本	12.6	15.4	14	42
	[3]-[8]						[3]-[8]
[11]	總預估效益	30	41	29	100	[11]	總預估效益	27.6	40.4	32	100
	[10]+[2]						[10]+[2]

 

所以聯合開發可以增加效益 100 萬，但是哪個專案該分攤多少成本或是增加多少利潤，就可以用這個網頁算，兩種方法分攤的成本不同，增加的利潤自然也不同，但總算是有了依據，不會各開發 Team 在吵工作獎金。 (老闆曰：都是我的錢，再吵就沒收…)

 

其他類型的成本分攤也可以仿效處理。

高雄縣長你還真有臉啊~

引述新聞：楊秋興稱可爭取國賠 「曾文水庫越域引水工程脫不了關係，應該可以爭取國賠！」

http://news.chinatimes.com/2007Cti/2007Cti-Rtn/2007Cti-Rtn-Content/0,4526,110110+112009081401488,00.html

http://www.libertytimes.com.tw/2009/new/aug/15/today-fo5.htm

 

為什麼要蓋曾文水庫越域引水？因為民進黨誤導高雄縣民，讓高雄縣以為蓋水庫是不好的，所以美濃水庫、瑪家水庫都被抵制而蓋不成。

所以要把高雄縣的水蓄到台南縣、嘉義縣，再回供給高雄縣用。 而曾文越域引水計畫目前多數報告都分析出一年會提高曾文水庫洩洪量 8,000 萬噸以上。

 

馬的~ 憑什麼都是高雄爽，台南淹水？現在還要國賠？為什麼不是你高雄縣出？

 

上次卡玫基颱風造成南化水庫下游淹水 (卡玫基颱風淹水責任在誰身上？)， 也是高雄縣甲仙鄉的水蓄在南化水庫，再經內門跟岡山回供高雄，造成提高南化水庫下游淹水潛勢的提高。

 

告訴我，高雄縣憑什麼可以不蓋美濃水庫、瑪家水庫，反而把水蓄在台南，造成台南淹水？

國賠？你高雄縣自己出吧~

 

我是反對曾文越域引水計畫，拒絕再讓台南增加淹水潛勢，請高雄在高屏溪流域上自建水庫，不要打台南水庫的主意，不要打台南水的主意。

[小論]曾文水庫開啟閘門延宕時機的原因

這次颱風期間，曾文水庫到今天早上 8:00 ，進水量已達 11.7 億噸，放水量也超過了 7.5 億噸 (紀錄為 7.3 億噸) ，就總量來說，蓄洪總量 4.2 億噸，已經是非常高的量了。11.7 億噸有多誇張呢？大概是過去曾文水庫歷次洪水中的兩倍，大台南地區 37 萬戶的缺水，以每戶四人計，120 萬人，每人每日用水量 250 公升 (節約用水狀態下為 200 ~ 220 公升) 換算，大台南地區每日不過需水 30 萬噸，含機關用水才達到 36 萬噸。可以看出這個水量多恐佈，根本不在一個級距上，可以讓大台南地區使用超過 8 年~

從運轉歷線上來看，不計可能疑似有問題的放水下(綠線)，曾文水庫約消減洪峰 3,000 CMS，延遲洪峰時間 5 小時，對於下游地區避免更大洪災有莫大貢獻，這也是水庫存在的價值，只要有水庫在，就可消減洪峰與延遲洪峰。

 

 

大洪水自然有大災情，這是不可避免的，但是從這次運轉操作上，可看出曾文水庫延遲開啟閘門五小時以上，是滿大的遺憾。

有閘門水庫不怕在高水位碰上大洪水，最怕在低水位碰上大洪水。這個不但土木的不懂，也有很多念水的不懂。

最基本的原因是水利法施行細則51條的限制：

---

第 51 條 設有洩洪閘門之水庫，於洪水期間水庫水位上升段，其最高放水流量，不得大於流入水庫之最高流入量；水庫放水流量之增加率，不得超過該水庫流入量之最高增加率。但有危及水庫安全之虞時，得依前條防洪操作及緊急運轉措施辦理。

---

由於低水位碰上大洪水時，等到洪水進到防洪運轉起始水位，水庫受到放水增率限制，將來不及在短時間內將放水量提高到足以維護水庫安全的操作，故曾文水庫運用要點內有特別注意到這種情況：

---

十五、   本水庫防洪運轉依下列規定執行：
(一) 颱風或豪雨情況時，水庫水位超過標高二百二十三公尺或水庫水位及水庫進水量達到附表二之水庫水位及水庫進水量，得開始防洪運轉，但水庫進水量及水庫水位達到同條第二款之情事時，得開始防洪運轉。

附表二：颱風或豪雨情況下得開始防洪運轉之水庫進水量

水庫水位（標高公尺）	223	222	221	220	219	218	217	216	215
水庫進水量（秒立方公尺）	100	400	800	1200	1700	2200	3000	4000	5000

---

這個附表二就是針對水庫在低水位碰上大洪水，要提早進入操作。

 

以前翡翠水庫運用要點內是沒考慮這個情形，當翡翠水庫在低水位碰上設計最大洪水 (PMF) 時，確定無法在合法的範圍內排放洪水，所以我在起草翡翠水庫運用要點有加入此條件，但受限水供構造物限制，仍須進一步檢討翡翠水庫放水規則，這部分相關著作發表：

---

郭常康、朱孝恩、周乃昉、鄭子璉，「翡翠水庫防洪運轉規則檢討」，九十三年度農業工程研討會光碟論文集，台灣，桃園農田水利會，第 469 – 482 頁（論文摘要集：第 127 頁），民國 93 年 10 月。

---

 

大部分的水庫運用要點根本沒有考慮到這件事，例如第三大水庫石門水庫就是如此，在防洪運轉規則中，只有啟始運轉水位，沒有低水位碰上高流量的規則。照理說，這在各水庫每五年一次定期的大壩安全報告檢查中是要檢討，但是一般僅檢討高水位碰上設計最大洪水。

 

因此在水庫達到可能違法放水警訊時，按往例經驗在高水位碰上洪水時，會誤認為還有蓄水空間，此外，上級單位與下游民代會在颱洪期間不斷的打電話給水庫管理單位，指手畫腳的壓力，也會間接造成水庫運轉單位不敢放水的因素，導致一發現不得不放水時，反而來不及依往例放水，甚至第三小時放水增量就違反水利法施行細則第51條。

 

我個人的看法是，這次應該在 8/8 17:00 起就以 300 CMS 開始排放，即使受到長官及下游民代壓力，300 CMS 對於進水量僅有不到 5% 的放水量，卻能讓水庫不會太被動。曾文水庫運用要點對啟始放水是有限制的：

---

十八、　　南水局應於溢洪道洩洪開始一小時前，由該局將洩洪量迅速向下游地區發布洩洪警報，並以電話及傳真通報經濟部水利署及轄區內台南縣市政府、消防局、警察機關、第六河川局及嘉南農田水利會，迅速轉知下游居民，開始洩洪運轉之第一小時，並應以最低容許洩洪量洩放，以示警告。

---

所以這次第一小時放水量達 450 CMS (含 Pro. 540 CMS)，就違反了這個規定，但從曾文水庫當時的蓄水位與進水量來看，變成看起來像是設計最大洪水進來，以設計最大洪水方式排放，這就變成人為的操作造成不恰當的地方。

 

不管任何水庫，在進水量遠高於最小放水量 5 倍以上時，當達到啟始防洪運轉條件後，都應盡速以最低容許洩洪量排放，這樣對水庫管理單位來說，進可增放水量，退可關閉閘門，握有充足的彈性，而不會像這次防洪運轉如此被動。

 

曾文水庫還算好了，擁有全台最大的防洪運轉空間，約有 1.5 億噸，光是防洪運轉空間就比南化水庫蓄水空間大了，這次在操作上都這麼艱辛，當翡翠水庫、石門水庫碰上這個洪水的話，翡翠水庫受限水工構造物必定得違法，石門水庫運用要點也是會讓水庫處於潰壩危機而違法操作。

 

有閘門的水庫管理人員，需要加深警覺，在低水位碰上高流量時，可不是件可以輕鬆應對的問題，除了曾文水庫、翡翠水庫運用要點外，根本沒水庫再注意這種東西，若不好好操作，主官就得扛起違反水利法施行細則的行政責任了。

曾文水庫放水記錄恐需詳查

本日 15:00 發佈水庫進水量 14:00 ~ 15:00 為 677 cms ，到了 16:00 修改為 0 cms。

依照水庫集水區退水的狀況，一般來說進水量減少的趨勢約為前時刻的 0.6 ~ 0.9 ，這叫做退水係數，曾文水庫退水係數約在 0.8 上下，但高流量的洪峰有可能突降，比如說 0.5 左右。

而 14:00 進水量為 5,700 CMS，洪峰又已過，氣象局、南水局雨量仍有 10 mm ，退水係數應仍在 0.8 左右。就算以對半來說，約為 2,750 cms ，但卻記錄為 0 cms ，而水庫水位快速由 229.6 降至 227.49 公尺，放水量記錄 5,506 CMS 恐有不實，有可能放水閘門操作錯誤，或未依閘門操作指令操作。

以 1997 年曾文水庫的 HAV 曲線概估：

標高 (公尺)	227	230
體積 (萬噸)	60893	66363

每公尺蓄水量為 1823.3 萬噸 =(66363 – 60893)/3
229.6 降至 227.49 為 2.11 公尺，也就是說放出水量為 3847.3 萬噸 =1823.3 * 2.11
在一個小時內排放出去，也就是 3600 秒，因此 (放水量 – 進水量) 為：
10686.7 = 3847.3 * 10000 / 3600 = 噸 / 秒 = 秒立方公尺 = CMS
因此，即使進水量為 0 ，曾文水庫放水量也高達 10,686 CMS ，非網頁上所公告的 5,506 CMS ，若加上至少應有的進水量，即高達 13,436 CMS ，比洪峰進水量還高。

洪水波前進到下游河口，約 3 ~ 5 小時，這個可能是現在下游災害將會非常嚴重。

整個防洪運轉記錄有重大問題，曾文水庫這次運轉又恐涉及國賠，可能需要台南地檢署去保存證據並調查。

[18:03 補]
曾文水庫上網公告的防洪運轉記錄有對應水位，229.6 蓄水量為 63073 萬噸，227.49 蓄水量為 59187 萬噸，所以小時水庫減少 3886 萬噸蓄水，也就是至少放水量 10,794 CMS ，加上至少應有進水量為 13,544 CMS 。但上網公告的防洪運轉記錄僅放出 2014 萬噸，也就是 5594 CMS ，大有問題。

[8/11 12:21 補]
整理了一張運轉過程有問題的簡圖：
 

南水局應澈底檢討曾文水庫集水區電傳雨量

[續前篇]

另外這次過後，南水局應該澈底檢討曾文水庫集水區的自建電傳雨量站了，一般水文角度來看，逕流係數約在 0.7 ~ 0.9 ，也就是說逕流深度是降雨量的 0.7 ~ 0.9 ，雖然還有集流時間的問題，但可以用總量概估，以莫拉克颱風總雨量這麼高來說，應該有 0.98 的水準，但事實上逕流係數高達 1.40 (=2285.4/1627.5) ，也就是說南水局的降雨量偏低 1.40 倍以上，跟氣象局同時段的平均雨量比對，氣象局雨量觀測雨量比南水局觀測雨量平均高 1.46 倍，也就是說氣象局的雨量較接近莫拉克颱風的逕流深度。

水庫集水區降雨量約在 3 ~ 5 小時內流入水庫，是水庫用來決策放水策略的重要依據，這個重大誤差，可能導致對水量預估偏低，導致啟動防洪運轉過晚，水庫防洪運轉水位創新高。

 

[8/10 21:35 更新雨量統計表及文中數據]

---

時間	曾文水庫集水區平均雨量				進水量轉換逕流深度
	氣象局	南水局	比率	差值
08/06 14	0.2	0.7		-0.5	0.1
08/06 15	0.3	0.7		-0.4	0.1
08/06 16	1.8	1.7	1.06	0.1	0.0
08/06 17	2.3	1.6	1.44	0.7	0.1
08/06 18	2.7	3.0	0.90	-0.3	0.1
08/06 19	1.3	0.9		0.4	0.1
08/06 20	3.8	2.1	1.81	1.7	0.2
08/06 21	11.0	7.2	1.53	3.8	0.2
08/06 22	10.4	8.6	1.21	1.8	0.6
08/06 23	9.2	8.7	1.06	0.5	1.4
08/07 00	25.6	20.6	1.24	5.0	3.6
08/07 01	18.8	20.0	0.94	-1.2	6.0
08/07 02	11.2	9.8	1.14	1.4	6.2
08/07 03	16.4	15.4	1.06	1.0	3.7
08/07 04	16.5	13.7	1.20	2.8	2.4
08/07 05	26.0	18.2	1.43	7.8	4.5
08/07 06	23.2	15.9	1.46	7.3	8.5
08/07 07	14.9	10.4	1.43	4.5	8.2
08/07 08	16.8	13.6	1.24	3.2	7.4
08/07 09	21.3	14.6	1.46	6.7	9.2
08/07 10	17.7	12.6	1.40	5.1	10.2
08/07 11	8.4	5.4	1.56	3.0	9.2
08/07 12	10.4	6.5	1.60	3.9	7.8
08/07 13	16.1	9.9	1.63	6.2	8.1
08/07 14	10.8	7.9	1.37	2.9	8.8
08/07 15	15.3	12.2	1.25	3.1	8.9
08/07 16	11.0	7.0	1.57	4.0	9.0
08/07 17	16.1	13.1	1.23	3.0	8.6
08/07 18		11.8			10.3
08/07 19		9.5			10.0
08/07 20	21.4	14.6	1.47	6.8	10.1
08/07 21		13.1			12.6
08/07 22		10.8			11.5
08/07 23		18.2			11.1
08/08 00		13.3			13.4
08/08 01		16.6			11.6
08/08 02		28.4			15.0
08/08 03		18.3			18.2
08/08 04		22.3			16.9
08/08 05		20.9			16.3
08/08 06		15.4			16.0
08/08 07	30.2	26.1	1.16	4.1	18.9
08/08 08	31.7	27.6	1.15	4.1	23.3
08/08 09	28.9	22.0	1.31	6.9	20.6
08/08 10	26.0	19.8	1.31	6.2	19.3
08/08 11		17.6			19.0
08/08 12		21.3			19.5
08/08 13		25.7			22.6
08/08 14		37.0			29.1
08/08 15		38.0			35.3
08/08 16		40.7			43.4
08/08 17		40.1			52.9
08/08 18		40.6			47.0
08/08 19		33.4			47.1
08/08 20	53.6	37.8	1.42	15.8	44.2
08/08 21	62.8	49.3	1.27	13.5	59.5
08/08 22	71.9	58.9	1.22	13.0	72.8
08/08 23	71.1	53.6	1.33	17.5	84.4
08/09 00	67.5	49.0	1.38	18.5	72.1
08/09 01	65.3	45.3	1.44	20.0	69.0
08/09 02	66.8	32.6	2.05	34.2	59.7
08/09 03	70.3	41.2	1.71	29.1	59.4
08/09 04	56.9	37.0	1.54	19.9	84.6
08/09 05	41.5	35.4	1.17	6.1	80.1
08/09 06	26.9	23.7	1.14	3.2	58.9
08/09 07	32.6	37.6	0.87	-5.0	66.8
08/09 08	47.1	30.4	1.55	16.7	61.8
08/09 09	33.0	20.6	1.60	12.4	56.2
08/09 10	34.0	19.6	1.73	14.4	53.8
08/09 11	34.4	19.1	1.80	15.3	55.0
08/09 12	22.8	13.5	1.69	9.3	51.8
08/09 13	20.3	20.1	1.01	0.2	46.7
08/09 14	19.1	11.1	1.72	8.0	42.7
08/09 15	13.8	9.8	1.41	4.0	33.3
08/09 16	13.5	9.4	1.44	4.1	23.9
08/09 17	8.3	15.0	0.55	-6.7	25.0
08/09 18	6.8	6.9	0.99	-0.1	19.6
08/09 19	7.4	3.6	2.06	3.8	17.3
08/09 20	4.8	3.1	1.55	1.7	21.4
08/09 21	3.7	4.1	0.90	-0.4	21.2
08/09 22	4.7	1.5	3.13	3.2	10.2
08/09 23	4.3	2.6	1.65	1.7	12.1
08/10 00	6.1	2.7	2.26	3.4	11.0
08/10 01	7.5	5.6	1.34	1.9	10.2
08/10 02	10.4	0.8		9.6	9.8
08/10 03	9.2	15.9	0.58	-6.7	11.0
08/10 04	9.3	1.9	4.89	7.4	10.6
08/10 05	8.7	1.8	4.83	6.9	11.0
08/10 06	4.6	5.5	0.84	-0.9	15.2
08/10 07	2.0	0.5		1.5	12.1
08/10 08	2.6	4.9	0.53	-2.3	9.4
08/10 09	1.1	0.0		1.1	8.6
08/10 10	0.7	0.4		0.3	8.6
08/10 11	2.1	2.9	0.72	-0.8	9.8
08/10 12	3.6	0.6		3.0	7.5
08/10 13	8.3	4.4	1.89	3.9	9.4
08/10 14	6.1	17.1	0.36	-11.0	9.8
08/10 15	6.2	3.9	1.59	2.3	10.1
08/10 16	5.3	0.6		4.7	10.5
08/10 17	7.5	1.0		6.5	11.7
08/10 18	4.0	0.1		3.9	10.9
08/10 19	2.3	0.0		2.3	10.5
08/10 20	2.0	0.0		2.0	9.8
合計		1627.5		418.0	2285.4
平均比率			1.46		1.40

註：

1. 逕流深度使用曾文水庫集水面積 481 平方公里轉換

2. 氣象局雨量空白者表示曾文水庫暨曾文溪流域水情蒐集分析查詢系統因氣象局 ftp 無該時段資料無法抓取

3. 比率任一雨量小於 1 者跳掉，避免比率出現過大影響平均

4. 08/09 15:00 曾文水庫進水量有問題，以上下兩值取平均

曾文水庫進水量破史上最高

曾文水庫進水量破史上最高，在 08/08 22:00 9,721 CMS ，超過賀伯颱風與九三水災，到了 23:00 達到 11,279 CMS ，有問鼎最大可能洪水的離譜洪峰~

 

但是目前的放水有點怪，依照最新 (98/7/6) 修訂的運用要點來說 (主要是調降防洪啟始運轉水位 2 公尺)，在 16:00 就可以開始發佈進行防洪運轉：

---

十五、   本水庫防洪運轉依下列規定執行：
(一) 颱風或豪雨情況時，水庫水位超過標高二百二十三公尺或水庫水位及水庫進水量達到附表二之水庫水位及水庫進水量，得開始防洪運轉，但水庫進水量及水庫水位達到同條第二款之情事時，得開始防洪運轉。

附表二：颱風或豪雨情況下得開始防洪運轉之水庫進水量

水庫水位（標高公尺）	223	222	221	220	219	218	217	216	215
水庫進水量（秒立方公尺）	100	400	800	1200	1700	2200	3000	4000	5000

---

卻拖到 21:00 才開始放水，而溢洪道閘門放水量為 450 CMS，疑似為 30 分鐘操作一次的放水量，可能的組合是先放 300 ，再放 650 ，平均為 450 CMS 。這個放水量很有問題，違反運用要點第十八條：

---

十八、　　南水局應於溢洪道洩洪開始一小時前，由該局將洩洪量迅速向下游地區發布洩洪警報，並以電話及傳真通報經濟部水利署及轄區內台南縣市政府、消防局、警察機關、第六河川局及嘉南農田水利會，迅速轉知下游居民，開始洩洪運轉之第一小時，並應以最低容許洩洪量洩放，以示警告。

---

也就是說洩洪的第一小時，溢洪道只能放 300 CMS ，這個 450 CMS 將來會出問題。

 

22:00 ~ 23:00 洩洪量已提升至 2,250 CMS ，就往例來說，這也是很少見的快速提高放水量的操作，當然還在合於法規內，但是可以預期下游山上、大內、官田等地，可能會因為洩洪量提高過快，而造成淹水水位快速提高，最後坐困家中，無法在短時間內撤離。

 

接下來還有很長抗戰要打，再看看曾文水庫如何操作吧。

 

[8/9 00:28 補]

23:00 ~ 00:00 放水量達 4950 CMS ，放水增加率為 2,700 CMS ，超過目前已發生的最大進水增率 2,051 CMS (20:00 ~ 21:00) ，違反水利法施行細則第 51 條：

---

第 51 條 設有洩洪閘門之水庫，於洪水期間水庫水位上升段，其最高放水流量，不得大於流入水庫之最高流入量；水庫放水流量之增加率，不得超過該水庫流入量之最高增加率。但有危及水庫安全之虞時，得依前條防洪操作及緊急運轉措施辦理。

---

這下糗大了，行政責任跟國賠跑不掉了… 大概要換局長了…

 

[8/9 13:45 補]

8/9 03:00 ~ 04:00 平均進水量 11,309 CMS 再創史上新高，07:00 水庫水位 230.96 公尺，超過滿庫水位 230 公尺，也創史上最高蓄水位，上次蓄水到 230 公尺是在納莉颱風防洪運轉期間，放水量也創史上新高，最高放水量在 8,277 CMS ，破三個曾文水庫自民國 62 年建庫以來的記錄，雨量還沒統計，不過看氣象局的資料應該已經破記錄了。

 

[8/9 16:17 補]

又糗了~

依據曾文水庫運用要點：

---

十六、
（二）洪峰流量過後，水位低於標高二百三十公尺，洩洪量不得大於進水流量加上附表五之可增放水量，且不得大於進水流量之洪峰流量。

附表五：洪峰流量通過後水位低於標高230公尺時之可增放水量

水庫水位（標高公尺）	230	229	228	227	226	225以下
水庫可增放水量（秒立方公尺）	1000	900	800	700	600	500

---

14:00 ~ 15:00 進水量低到 0 (???原先標記 677 ，之後 16:00 修改為 0) ，所以上面來說，就算用 229 來算，15:00 ~ 16:00 只能放水放到 900 CMS ，可是卻放了 3600 CMS …

 

---

項目	平均雨量	水位	進水量	放水量
設施				溢洪道				河道放水口			電廠	合計
閘門				1	2	3	小計	1	2	小計
日-時	mm	El.M	CMS	CMS	CMS	CMS	CMS	CMS	CMS	CMS	CMS	CMS
08-01	16.6	204.27	1,544	0	0	0	0	15	15	30	0	30
08-02	28.4	204.85	2,001	0	0	0	0	15	15	30	0	30
08-03	18.3	205.55	2,438	0	0	0	0	15	15	30	0	30
08-04	22.3	206.19	2,261	0	0	0	0	15	15	30	0	30
08-05	20.9	206.80	2,184	0	0	0	0	15	15	30	0	30
08-06	15.4	207.39	2,137	0	0	0	0	15	15	30	0	30
08-07	26.1	208.08	2,525	0	0	0	0	15	15	30	0	30
08-08	27.6	208.92	3,117	0	0	0	0	15	15	30	0	30
08-09	22.0	209.65	2,755	0	0	0	0	15	15	30	0	30
08-10	19.8	210.31	2,573	0	0	0	0	15	15	30	50	80
08-11	17.6	210.94	2,544	0	0	0	0	45	45	90	50	140
08-12	21.3	211.58	2,607	0	0	0	0	45	45	90	50	140
08-13	25.7	212.32	3,024	0	0	0	0	45	45	90	50	140
08-14	37.0	213.27	3,892	0	0	0	0	45	45	90	50	140
08-15	38.0	214.41	4,719	0	0	0	0	45	45	90	50	140
08-16	40.7	215.79	5,797	0	0	0	0	45	45	90	50	140
08-17	40.1	217.44	7,067	0	0	0	0	45	45	90	5	95
08-18	40.6	218.87	6,279	0	0	0	0	45	45	90	50	140
08-19	33.4	220.28	6,298	0	0	0	0	45	45	90	50	140
08-20	37.8	221.59	5,900	0	0	0	0	45	45	90	0	90
08-21	49.3	223.33	7,951	0	0	0	0	45	45	90	0	90
08-22	58.9	225.29	9,721	0	300	150	450	45	45	90	0	540
08-23	53.6	227.13	11,279	750	750	750	2,250	45	45	90	0	2,340
09-00	49.0	228.05	9,640	1,650	1,650	1,650	4,950	45	45	90	0	5,040
09-01	45.3	228.78	9,217	1,800	1,800	1,800	5,400	45	45	90	0	5,490
09-02	32.6	229.26	7,971	1,800	1,800	1,800	5,400	45	45	90	0	5,490
09-03	41.2	229.73	7,940	1,800	1,800	1,800	5,400	45	45	90	0	5,490
09-04	37.0	230.34	11,309	2,670	2,670	2,670	8,010	45	45	90	0	8,100
09-05	35.4	230.83	10,699	2,670	2,670	2,670	8,010	45	45	90	0	8,100
09-06	23.7	230.85	7,872	2,559	2,559	2,559	7,676	45	45	90	0	7,766
09-07	37.6	230.96	8,924	2,749	2,749	2,749	8,248	45	45	90	0	8,338
09-08	30.4	230.94	8,260	2,759	2,759	2,759	8,277	45	45	90	0	8,367
09-09	20.6	230.79	7,514	2,741	2,741	2,741	8,222	45	45	90	0	8,312
09-10	19.6	230.60	7,193	2,704	2,704	2,704	8,112	45	45	90	0	8,202
09-11	19.1	230.46	7,352	2,668	2,668	2,668	8,004	45	45	90	0	8,094
09-12	13.5	230.26	6,927	2,631	2,631	2,631	7,894	45	45	90	0	7,984
09-13	20.1	229.96	6,241	2,577	2,577	2,577	7,731	45	45	90	0	7,821
09-14	11.1	229.60	5,710	2,502	2,502	2,502	7,506	45	45	90	0	7,596
09-15	9.8	227.49	0	1,835	1,835	1,835	5,506	45	45	90	0	5,596
09-16	9.4	227.39	3,192	1,200	1,200	1,200	3,600	45	45	90	0	3,690
09-17	15.0	227.50	3,338	900	900	900	2,700	45	45	90	0	2,790
09-18	6.9	227.54	2,615	775	775	775	2,325	45	45	90	0	2,415

 

莫拉克颱風-可能會侵台的颱風

中午新聞氣象局表示，若預期颱風路徑不變，可能會侵台，稍解缺水之渴。

剛剛 eMail 收到 UTC 08/04 00:00 氣象資料，截圖下來大家參考。

 

[2009/8/5 補]

 eMail 收到 UTC 08/05 00:00 氣象資料，截圖下來大家參考。

 

[2009/8/6 補]

 eMail 收到 UTC 08/06 00:00 氣象資料，截圖下來大家參考。

 

[2009/8/10 補]

 eMail 收到 UTC 08/10 00:00 氣象資料，截圖下來大家參考。

海洋數位服務平台原始碼升級到 VB2008 相容

話說，VB2008 可支援 .Net 2.0 的專案，理論上不需要同時安裝 VB2005 ，可是就是這麼鳥，在 VB2008 中有個重大的新增限制，擋住我的程式碼升級，主要是這個：[VB2008] 結構或類別中 LayoutKind.Sequential 跟泛型不能同時使用

 

最近有空修改，就把這段原始碼加上人工 Byte() 匯出、讀入，因為這個還有 Server 端程式，所以做了交叉測試：

1. VB2005 Client 修改後 <-> Server 修改前

2. VB2005 Client 修改後 <-> VB2005 Server 修改後

3. VB2008 Client 升級後 <-> Server 修改前

4. VB2008 Client 升級後 <-> VB2008 Server 升級後

5. Client 修改前 <-> VB2008 Server 升級後

 

目前暫時不發布修改版，在我電腦多跑幾天測看看。

克利金等值線功能加入到曾文流域防洪系統中

剛剛把克利金法的成果，轉到網頁上可即時展現，網頁的部分，把底圖跟等值線切成兩張圖，讓 VML 動態載入，這樣單張圖檔就降到 20 kb 左右，而底圖固定，就可以讓它自動快取節省流量，以後要抽換較美觀的底圖也比較方便。

 

由於網頁系統反應本來就比較遲鈍，等值線需要計算 5 秒居然在網頁系統感覺不出來… 可見習慣網路慢也是一種罪~

 

瀏覽時，先檢查有沒有計算完的成果，沒有的話才重算，算完存檔，有的話就直接使用既有圖檔，節省 CPU 資源。

 

網頁系統圖形輸出支援 bmp/gif/png/jpg/emf ，在 1000×800 左右的大小下，png 圖檔比 emf 更小，考慮到 VML 使用 emf 列印時可確保以向量列印，保留最大解析度，故最後還是決定使用 VML 來展示與疊圖。

 

 

(註：點圖放大瀏覽原圖)

克利金等值線 DLL 初版建成

前篇：克利金法類別雛型開發完成 說到克利金法 (Kriging) 開發完成了，但是前篇開發完成的類別僅適合科學計算用，也就是說可以輸出任意指定點的推估值，但不會畫成圖，所以要用迴圈自己跑格網，跑完後存成 Surfer 支援的 ASCII Grid 格式，所以當然就沒辦法直接輸出圖形了。

先前開發格網等值線 (Contour) 時，用的是 GIS 裡面的 Point 類別，早期開發 GIS 類別時，是沿襲 VB6 開發慣例，所以裡面沒有運算子或型別轉換，這在 .Net 中十分不便，所以趁此機會把整個 GridContour 類別重整，然後合併克利金法建成 KrigingContour.dll ，再丟給 WinForm 來測試，測試結果如下：

以曾文溪流域為範疇，將周遭 79 個氣象局雨量站拿進來畫，使用的資料是 2008/9/14 15:00 的雨量。建構成 DLL 的好處就是程式碼照抄，就可以變成 ASP.NET 網頁輸出，先前有個風玫瑰圖的案例就是這樣處理，這樣比較方便視窗除錯。

目前效能還算差，大概上面這張圖要跑 15 秒，以一小時跑 15 秒算是還可以接受，但是相同的參數 Surfer 大概只要跑 2 秒，所以應該還有加速空間。一般來說，當點數過多時，通常推估目標點不會全取，而是取附近的鄰近點 10 ~ 20 點左右，我目前是使用所有雨量站資料推估，所以要建立 80×80 的反矩陣計算，且反矩陣計算目前是用高斯消去法，計算尺度是 O(2) ，也是慢的原因之一，接下來再考慮這部分的加速。風場推估則是同時做 u, v 兩向量的推估，再合併成方向與風力。

註：先前建立的即時玫瑰風圖網頁，直接從資料庫拉小時資料後進行統計分析繪圖：