CDR Control Automation Project (Part 2)

Well, untuk sementara sistem remote troubleshooting CDR via TeamViewer di lab berjalan lancar. Hasilnya selama liburan 3 hari kemarin cukup memuaskan. CDR sempat stop beberapa kali karena cuaca panas, tapi masih bisa direstart … dari ANCOL .. hehhe. Sooo, selama internet lab nggak mampus dan nggak ada mati lampu di Serpong, there will be no problem.

Sekarang bisa lanjut ke tahap berikutnya … 

TAHAP II.  SISTEM PENGARSIPAN DATA CDR KE EXTERNAL HD

Pada kondisi normal, CDR menghasilkan 1 data volume scan (yg nantinya digunakan untuk analisis) setiap enam menit. Ukuran 1 data volume scan bisa kurang dari 1 MB (tidak ada hujan) sampai 5 MB (hujan ekstrim). Dalam sejam, maksimal akan ada sekitar 50 MB data RAW, itu artinya CDR akan menghasilkan sekitar 1,2 GB data raw dalam sehari. Itu belum termasuk data surveillance dan image. Dengan ukuran sebesar itu dan koneksi internet yang ada saat ini, bisa dibilang proses pengolahan data harian secara remote akan sangat sangat sukar (walau tidak mustahil).

Masalah kedua, server lab hanya mendownload data CDR dalam format ASCII. Saya terus terang nggak suka dengan ASCII karena ukurannya yg relatif besar walaupun sudah dikompresi. Lagian data ASCII sangat rawan disalahgunakan tanpa ijin karena gampang diakses semua orang. Capek-capek ngolah data sampe keluar format ASCII, eh datanya dipake orang lain cuma dengan modal Excel atau Notepad. Saya lebih suka dengan format Binary, karena selain ukurannya jauh lebih kecil, datanya eksklusif karena hanya si programmer yg tahu tiap variabel dan cara mengakses data tersebut. Sehingga lebih aman dari sisi hak cipta (copyright).

Masalah ketiga, sistem kontrol CDR ini ada di lab, jadi mau tidak mau harus mengikuti policy jaringan di lab. Dan koneksi ftp secara langsung dari lab sangat dibatasi dengan alasan keamanan. Sistem harus terhubung dengan server lab sebelum bisa melakukan koneksi ftp. Pilihannya cuma dua, koneksi ftp via SSH atau Citrix. Really really unconvenient for a network newbie like me …

Dan .. masalah terakhir. Automatic system. Yeah. That’s also a big problem. Ini berhubungan erat dengan sistem operasi yang digunakan. Sistem kontrol CDR saat ini adalah dual-OS, Windows7 dan Linux Mint 10. Kedua OS bisa menggunakan SSH, ftp dan VNC. Tapi sistem mana yang akan digunakan untuk sistem otomatisnya ? Di Windows, kita bisa menggunakan batch file + task scheduler untuk membuat program berjalan secara otomatis, dan di linux kita bisa menggunakan shell script + cron tab. Tetapi …. kembali ke masalah nomor 3, gimana caranya membuat sistem ini melewati barikade policy jaringan lab ??? Bisakah melakukan scripting via Citrix ?

Tadinya saya berencana mengaplikasikan konsep BOS (Business Operating System) dan beberapa sistem multiplatform lain untuk mengatasi masalah ini. Tapi ujung-ujungnya malah tambah ribet, sistemnya jadi ngadat dan ada sedikit ‘kesalahpahaman’ yg timbul akibat penggunaan sistem ini. Jadi untuk sementara balik dulu ke Windows/Linux, sambil mikir alternatif lainnya.

(to be continued …)  

CDR Control Automation Project (Part 1)

Ini bukan proyek resmi dari kantor, hanya inisiatif pribadi.

Tujuan : 

• Otomatisasi pengarsipan data RAW dan Image CDR ke external HD 
• Otomatisasi pengiriman data Image ke ftp server luar untuk monitoring CDR
• Mempersiapkan media baru untuk remote trouble shooting CDR
• Mempersiapkan sistem pengolahan data CDR otomatis untuk keperluan penelitian

Hardware : Laptop Dell Latitude, prosessor iCore7, RAM 4GB

OS : Windows 7, Linux Mint 10

Tools/Softwares : TeamViewer7, VNC, NetCDF, Perl, Fortran, C, puTTY    

 

TAHAP I. SISTEM REMOTE TROUBLESHOOOTING BARU (TARGET : 17 MARET 2012) 

 

Persiapan media baru sistem remote troubleshooting. Media baru untuk remote troubleshooting diperlukan sejak sistem jaringan CDR menerapkan firewall dan ip-filtering untuk menghalau cracker. Sistem ini bak pisau bermata dua, karena walaupun efektif, namun hanya IP-IP tertentu saja yang bisa mengakses sistem CDR, misal IP JAMSTEC atau BPPT. Akibatnya, remote troubleshooting hanya bisa dilakukan di JAMSTEC atau BPPT. Bagi saya yang biasa keluar kota untuk survey dan hanya bergantung pada modem seluler, sistem seperti ini seringkali merepotkan, terutama apabila CDR mengalami masalah.

 

Solusinya adalah dengan menggunakan aplikasi remote desktop controller yang bisa menembus firewall, misalnya TeamViewer, yang diinstall pada satu laptop. Saat ini TeamViewer sudah terinstall pada laptop (Windows dan Linux), hanya tinggal perlu menginstall VNC untuk koneksi lokal.

 

(to be continued ….) 

Echo Coverage (Part 1)

Dari beberapa paper yang sudah saya pelajari (baca: sebagian saya pelajari), ada beberapa gambar menarik yang menggunakan data CAPPI radar. Salah satunya adalah Echo Coverage (EC), yang menunjukkan tutupan echo/sinyal balik dari presipitasi yang terdeteksi oleh radar. 

Salah satu paper menarik yg membahas soal EC adalah paper Mori-san (kebetulan saya jadi co-authornya .. ehm ) : Convective System Developed along the Coastline of Sumatera Island, Indonesia, Observed with an X-band Doppler Radar during the HARIMAU2006 Campaign

Analisis echo coverage ini biasanya ditunjukkan dengan beberapa plot, antara lain : 

1. Time-Height cross section. Pada grafik ini, sumbu X adalah waktu, sumbu Y adalah ketinggian, dan sumbu Z adalah echo coverage.
2. Time-Time cross section. Pada grafik ini, sumbu X adalah waktu (hari), sumbu Y adalah waktu (jam) dan sumbu Z adalah echo coverage.

Analisis EC sangat bermanfaat untuk mengetahui pola spasial (statiform atau cumuliform) dan temporal (diurnal atau semi-diurnal) dari curah hujan di suatu wilayah.

Saya sebenarnya sudah pernah melakukan analisis data yang mirip, dengan menggunakan data satelit TRMM produk TRMM3B43 dan GSMaP NRT/MWR, dengan menggunakan Time vs Time plot, tapi dimensi ketiga yang saya gunakan adalah intensitas rata-rata curah hujan (rainrate).

Kali ini rencananya saya akan melakukan analisis dengan data XDR, selama perionde IOP2011 (Desember 2011). Well, ini belum pernah saya lakukan sebelumnya, jadi waktu pagi ini habis dengan coretan di kertas untuk menghitung EC sebelum dikonversi menjadi kode program. 

Masalah : Data radar adalah data grid 641x641x20. Karena yang dibutuhkan adalah data dalam coverage 160 km, maka tidak semua data akan dimasukkan dalam perhitungan, hanya data yang lebih kecil dari diameter 160 km yg diambil.

Algoritma :

1. Buka data binary radar.
2. Assign data radar, kedalam array 3 dimensi (x,y,z).
3. Mulai hitung jarak tiap grid dari pusat radar. Grid yang jaraknya lebih kecil dari 160 km akan dihitung, yg lain akan diabaikan. Phytagoras theorm will do the trick … 
4. Periksa grid yang diperoleh dari langkah 3, apakah memiliki echo atau tidak. Bila ada, hitung berapa banyak grid yang memiliki echo.
5. EC diperoleh dengan membandingkan jumlah grid yang memiliki echo dengan jumlah total grid dalam diameter 160 km.
6. Ulangi langkah 1-5 untuk tiap data radar (10 menitan).

to be continued …. 

Radar Data Processing – #1 – System Reqs.

Tulisan ini sebenarnya dikhususkan untuk diri sendiri, soalnya aku gampang lupa dan punya penyakit yang nggak sembuh-sembuh sejak jaman sekolah dulu : malas mencatat. Berhubung hampir semua aktivitasku, mulai dari pekerjaan, riset sampai thesis berhubungan langsung dengan data radar, rasanya perlu untuk membuat catatan kecil tentang proses pengolahan data radar, mulai dari instalasi sampai proses eksekusi programnya.

Berikut sistem dasar yang diperlukan agar seluruh pengolahan data radar dapat berjalan lancar :

1. PC atau Laptop atau yang kompatibel dengan prosesor minimal pentium 4 atau yang sejenis (AMD dll), RAM minimal 512 MB, dan ruang harddisk minimal 30 GB.
2. Sistem Operasi Linux/UNIX atau yang kompatibel. Distro apapun boleh.
3. C Compiler. Disarankan menggunakan GCC (Gnu C Compiler). Bisa diperoleh lewat SPM (Synaptic Package Manager).
4. C++ Compiler. Disarankan menggunakan  G++. Bisa diperoleh lewat SPM (Synaptic Package Manager).
5. Fortran Compiler. Disarankan menggunakan Gfortran atau Ifortran. Bisa diperoleh lewat SPM (Synaptic Package Manager).
6. Text Editor (gedit, pico, emacs, vi dll).
7. Perl (Practical Extraction and Report Language).

Berikut sistem tambahan yang harus diinstalasi untuk keperluan pengolahan data :

1. NetCDF (Network Common Data Form). Bisa diunduh di : http://www.unidata.ucar.edu/software/netcdf/
2. NetCDF-Perl Extension. Bisa diunduh di : http://www.unidata.ucar.edu/software/netcdf-perl/
3. mmds (Msaka Multiple Doppler Synthesis) untuk konversi data RAW radar ke MRF dataset buatan Takeshi Maeseki. Kalo ini aku dapat ini selama training di Jepang dulu (thanks to sakurai-senpai).

Dan ini beberapa tool tambahan (opsional) untuk membantu visualisasi data yg sudah diolah : 

1. GrADS (Grid Analysis and Display System). Bisa diunduh di : http://www.iges.org/grads/
2. GTK+ (Gimp Toolkit). Bisa diunduh di : http://www.gtk.org/ 

Sebagai perbandingan, berikut spesifikasi sistem yg kupakai untuk pengolahan data radar selama ini : Dell Inspiron 1318, Processor Intel Core 2 Duo T8100 2.1 GHz, RAM 4 GB,  Harddisk 250 GB (50 GB untuk Linux), OS Linux Mint 7 Gloria.

Pada tulisan berikutnya akan diulas teknik instalasi sistem di atas .  

CDR Troubles #1 – Disk Error

Frekuensi kejadian : 5, Tingkat kesulitan : 4

Sebenarnya masalah ini sama sekali tidak berhubungan dengan komponen radar sendiri, tetapi lebih pada workstation pengontrolnya. Workstation yang digunakan CDR merupakan media pertama yang berhubungan langsung dengan komponen-komponen radar (seperti transmitter, receiver, signal processor dan lain-lain) sebelum terhubung dengan server IRIS yang mengolah data radar selanjutnya. Workstation ini pada dasarnya adalah PC branded produksi Toshiba, dengan sistem operasi SunSolaris 5.7. Aku sendiri lebih sering menyebutnya dengan Server Toshiba.

Aplikasi pengontrol CDR (DPMain) juga terinstalasi pada server Toshiba, sehingga untuk mengontrol kerja dari CDR itu sendiri, operator harus menggunakan server ini sebagai medianya. Dan tentu saja, bila terjadi masalah dengan server ini, otomatis si ‘harimau’ Serpong akan ikutan nggak beres tingkahnya.

Server Toshiba awalnya juga berfungsi sebagai pemroses data selain untuk kontrol radar. Setelah CDR dimodifikasi akhir tahun 2008 lalu, seluruh urusan pengolahan data dipindahkan ke server IRIS. Namun, ada beberapa pengaturan yang tidak bisa diubah seluruhnya. Salah satunya adalah dalam hal pemrosesan data. Seharusnya cukup server IRIS yang mengolah data si CDR, namun dalam hal ini, server Toshiba ternyata tidak bisa di-set untuk ‘meletakkan jabatannya’ kepada si server IRIS. Oleh karena itu, walaupun pada akhirnya seluruh data diolah oleh server IRIS, si server Toshiba juga tetap menyimpan sebagian data RAW (dalam format Toshiba). Karena data RAW ini ukurannya sangat besar, sementara kapasitas harddisk server Toshiba sangat terbatas (jauh lebih kecil dibandingkan server IRIS), maka data RAW (di server Toshiba) harus dihapus secara berkala. Bila tidak, harddisk akan penuh, aplikasi kontrol radar bakalan ngadat, dan kalo sudah ngadat, otomatis CDR tidak akan bisa memproses data observasi, walaupun perangkat keras seperti transmitter dll tetap bekerja sebagaimana mestinya. Biasanya program kontrol akan memberi tanda ‘Disk Error’ apabila ruang yang digunakan pada harddisk sudah melebihi 90% dari total space yang ada.

 

Normalnya, file-file RAW ini akan dihapus secara otomatis dengan memanfaatkan shell script dan crontab yang dijalankan pada SunOS, namun karena crontabnya hanya berjalan sekali sehari, terkadang aku juga harus menghapusnya secara manual.

Untuk memeriksa sisa space pada tiap partisi sistem, aku biasa menggunakan perintah ‘df -k‘ yang umum digunakan pada sistem berbasis UNIX.

 

Untuk mengetahui sisa space secara real pada sistem file root directory (UFS) bisa menggunakan perintah berikut :

df -F ufs -o i

Bila output dari kedua perintah tersebut root directory (/) dan /usr1 sudah menunjukkan angka yang melebihi 90%, maka harus dilakukan penghapusan pada beberapa file berikut :

1. RAW Files. Berada pada direktori /usr1/spf/DB/ONLINE. Setelah masuk, hapus seluruh data RAW pada sub direktori 01000000, 01000001, 01080000, 02000000, 02000001, 02060000, 03000000, 03000001 dan 03060000.
2. Mail file di /var/mail. Aku sempat nemu file mail yang besarnya lebih dari 5 MB, padahal fitur mailnya sendiri ga dipake.
3. Coredump files di /var/crash. Ini jg salah satu jenis file yang bikin penuh harddisk. Biasanya file ini dihasilkan kalo sistem lagi error atau crash.
4. Temporary file di /var/tmp. Biasanya aku pake perintah ini : ‘find /var/tmp -mtime +3 -a -user xxx -a -type f -exec rm {} ;‘. Tadinya maunya cuma file-file yang lebih dr 7 hari yg dihapus, tp supaya lebih aman mending yang di atas 3 hari sudah dihapus juga
5. Website files. Berada pada direktori /usr1/spf/WEB. Hapus semua data dalam sub direktori tr01, tr05, tr10, tv01, tv05 dan tv10.

Poin 1 aku pelajari dari orang JAMSTEC (thanks to Mori-san). Poin 2-3 cari sendiri di internet. Poin 4 aku pelajari sendiri setelah baca email dari engineer K-Weather (thanks to Iwao-san). Poin 5 murni hasil ngoprek-ngoprek server Toshiba beberapa hari yang lalu (thanks to myself LOL).

Kesimpulan : Masalah ini awalnya sempat bikin pusing karena aku belum tau penyelesaiannya (poin 2-4) dan respon dari pihak JAMSTEC juga rada lambat. Tapi setelah tau triknya, no problemo … hehhe …

Dunia Lain

Dulu aku sering berfantasi dan bertanya dalam hati, apakah kita, manusia ini adalah satu-satunya mahluk hidup yang ada di alam semesta ? Bayangkan saja, ambil segenggam pasir di pantai. Apakah kita bisa menghitung jumlah butiran pasir di genggaman kita ? Galaksi kita, BimaSakti (Milky Way) memiliki bintang yang jumlahnya lebih banyak daripada pasir di genggaman kita. Bila satu bintang memiliki satu tata surya saja, bayangkan berapa banyak planet yang mungkin ada di alam semesta ini. Apakah di antara miliaran atau bahkan trilyunan tata surya tersebut, tidak ada planet lain yang memiliki kehidupan seperti Bumi ?

Berikut beberapa planet yang sebenarnya adalah fiksi, tetapi bila ditinjau secara ilmiah, kemungkinan besar terdapat di ‘luar sana’, dan masing-masing memiliki kondisi alam dan spesies mahluk hidup yang unik satu sama lain.

Darwin IV

Darwin IV adalah planet (fiktif) yang mengorbit sepasang bintang kembar (binary star) dengan jarak sekitar 6.5 tahun cahaya dari bumi atau kurang lebih 9,46 trilyun km. Planet ini dipopulerkan oleh Wayne Barlowe melalui bukunya yg berjudul Expedition. Pada tahun 2005, Discovery Channel menayangkan program yang diangkat dari buku ini dengan judul Alien Planet, yang menggambarkan kondisi alam dan habitat mahluk hidup yang kemungkinan ada di planet tersebut.

Darwin IV adalah sebuah planet yang dulunya tertutup lautan yang luas seperti halnya Bumi kita. Namun, karena perubahan iklim yang drastis, ditambah lagi dengan gaya gravitasi yang lebih rendah, akhirnya sebagian besar air di Darwin IV menguap ke atmosfernya dan hanya menyisakan sekitar 10% dari lautan yang ada. Karena hanya memiliki sedikit lautan, maka mahluk hidup yang ada di planet ini harus mampu beradaptasi dengan kondisi alam yang sebagian besar merupakan pegunungan, daratan tinggi dan savannah.

Kondisi iklim di planet ini kurang lebih sama dengan Bumi. Yang menarik, bila malam hari, permukaan planet seakan memancarkan cahaya beraneka warna. Cahaya ini berasal dari sejumlah mahluk hidup di Darwin IV yang memiliki kemampuan memancarkan cahaya (bioluminescence).

Berbeda dengan mahluk hidup di Bumi yang sebagian besar mengandalkan penglihatan lewat mata, spesies yang ada di Darwin IV mengembangkan kemampuan sonar atau echol location sebagai indera utamanya. Salah satu spesies mahluk hidup yang paling maju (dan mungkin paling menarik) di planet ini adalah Eosapien. Eosapien memiliki kecerdasan yang kurang lebih sama dengan Homo Erectus di Bumi. Mahluk ini memiliki tentakel yang fungsinya mirip dengan tangan manusia, mampu memanfaatkan benda-benda di sekelilingnya sebagai alat, dan memiliki kantong gas yang fungsinya mirip dengan balon udara, sehingga memungkinkan eosapien bergerak di udara dengan bebas.

Aurelia

Dulu kalo nggak salah, pernah kutulis di blog ini. Diangkat dari program TV Extraterrestrial yang disiarkan oleh National Geographic tahun 2005. Aurelia, adalah suatu planet (fiktif) yang mengorbit sebuah bintang kerdil merah (Red Dwarf) atau bintang tipe-M. Karena jaraknya yang demikian dekat dengan bintang induknya, maka planet ini akan ‘terkunci’ atau dengan kata lain, Aurelia tidak dapat berotasi pada sumbunya sendiri. Akibatnya, setengah dari planet ini akan terus-menerus menghadap bintangnya dan mengalami siang abadi, sebaliknya, sisi lainnya akan mengalami malam sepanjang masa.

 

Pada bagian yang menghadap bintangnya, permukaan Aurelia memperoleh cahaya secara konstan dan terdapat sebuah badai besar yang terjadi terus menerus dengan pusat/mata di titik yang memiliki tekanan udara paling rendah di planet ini atau daerah yang paling banyak menerima radiasi bintang induknya. Pada sisi lain yang tidak memperoleh cahaya, temperatur sangat rendah, dan hampir seluruh permukaannya tertutup es abadi.

Pada bagian planet yang berada di antara sisi terang dan gelap ini lah, di mana temperatur tidak terlalu panas atau terlalu dingin serta terdapat air (liquid water), kehidupan dapat ditemukan.

Salah satu mahluk hidup yang mendominasi permukaan Aurelia adalah Stinger Fans. Stinger Fans adalah spesies hewan yang memiliki kemampuan seperti tumbuhan, yaitu melakukan fotosintesis dengan memanfaatkan cahaya bintang induk sebagai sumber energi utamanya. Stinger Fans memiliki kemampuan bergerak yg terbatas untuk berpindah tempat demi memperoleh cahaya bintang yang dibutuhkannya.

Bersambung …… 

Radar Analysis Tool Install Notes #1

Mendingan gw tulis supaya ntar kalo install ulang tools-tools nggak pusing lagi, apalagi kalo mau migrasi Linux kayak sekarang.

Daftar tools yang harus diinstalasi (sesuai urutan) :

1. GrADS (The Grid Analysis and Display System) untuk visualisasi data radar.
2. NetCDF (Network Common Data Form) untuk library dan format data radar.
3. NetCDFPerl, modul extension akses data NetCDF untuk Perl.
4. mmds, untuk konversi dan pengolahan data radar untuk format IRIS.
5. radarmkCAPPI, untuk mengolah data PPI volume scan menjadi CAPPI.

Daftar komponen linux yang sudah harus terinstalasi pada sistem sebelum instalasi tools-tools di atas :

1. C Compiler (gcc, g++), untuk kompilasi netcdf, netcdfperl dan mmds
2. Fortran Compiler (gfortran, ifort etc) untuk kompilasi netcdf, netcdfperl dan mmds
3. Perl, untuk scripting mmds, netcdf dll

Musim hujan tlah tiba …

Akhirnya, datang juga.

Citra terakhir satelit GMS (tanggal 23 Oktober 2008, jam 4.00 GMT) menunjukkan konsentrasi awan yg luar biasa di wilayah jawa, sumatera dan beberapa daerah lain di selatan ekuator. Arah angin dominan datang dari arah barat laut.

 

Hayo. siap-siap bawa payung tiap hari.

Mungkinkah Matahari Bersinar 36 Jam ? Mungkin Saja.

 

Haduh bagaimana ini ? Bukannya tadinya janji mau cuti ngeblog dulu ? Yah, gara-gara pesan YM yg bikin heboh kemarin, akhirnya saya nggak tahan pingin nulis di blog. Berikut pesannya :

"Pada tanggal 17 Oktober 2008, matahari akan terus menyinari kita selama 36 jam (1.5 hari). Dan selama itu Amerika dan tetangga2nya akan gelap 1.5 hari. Ini akan mengkonversi 3 hari menjadi 2 hari besar.Ini terjadi setiap 2400 tahun sekali. Kita beruntung dapat menyaksikan dan merasakannya,beri tahu teman2 yah.."

Dan seperti biasa, para jurnalis, peneliti, blogger sampe anak sekolah pada ribut gara-gara pesan singkat ini. Pertanyaannya tentu saja, apakah berita ini benar atau cuman hoax ?

Sebagian besar orang menganggap bahwa pesan ini adalah salah satu hoax ‘terparah’ yg pernah ada.

"Ini orang yg bikin pesan nggak pernah sekolah apa ? Anak SD aja tau kalo matahari itu bersinar tuh cuman sekitar 12 jam sehari. Kecuali kalo mau kiamat !", ketus seorang tetangga saya.

—————-

Well, menurut saya sendiri sih, pesan itu ada benarnya. Walaupun ada juga bagian ngaconya. Bingung ? Ok, kita bahas dulu yuk dari sisi scientific-nya.

Mungkinkah matahari bersinar selama 36 jam non-stop ?

Jawabannya, SANGAT MUNGKIN.

Jangankan 36 hari, matahari bisa bersinar non-stop selama 6 bulan !

Kalo misal anda lg dapat rezeki jalan-jalan ke negara-negara yg dekat kutub utara atau kutub selatan, misal Swedia, Norwegia dll anda dapat menyaksikan salah satu fenomena alam yg paling unik yg disebut Midnight Sun, atau kalo diterjemahkan secara kasar berarti Matahari di Tengah Malam.

Midnight Sun adalah fenomena yg hanya terjadi di daerah kutub utara/selatan dan sekitarnya (lingkar kutub) di mana matahari tetap terlihat bersinar di malam hari waktu setempat (24 jam non-stop). Berarti nggak ada malam dong ? Emang, dan fenomena ini nggak cuman terjadi selama 36 jam, tapi bisa berbulan-bulan. Orang yg persis berada di kutub utara atau selatan bahkan bisa mengalami ‘siang hari’ selama enam bulan non-stop tanpa ada ‘malam hari’, dan setelah itu sebaliknya, mengalami 6 bulan ‘malam hari’ non-stop tanpa ada ‘siang hari’.

Kok bisa begitu ?

 

Waktu SD mungkin kita pernah diperagakan oleh bapak dan ibu guru bagaimana bumi berotasi pada sumbunya dan meng-orbit (berevolusi) mengelilingi matahari. Nah, (dengan tidak mengurangi rasa hormat saya kepada bapak/ibu guru), umumnya ada satu bagian yg terlupa. Bahwasanya, posisi bumi terhadap matahari tidak persis tegak lurus dengan sumbu rotasi bumi, tetapi agak miring sekitar 23,4 derajat. Emang pengaruhnya apa ?

 

Karena kemiringan ini, maka pada saat bumi mengelilingi matahari, sebagian daerah bumi (dengan acuan sumbu rotasi bumi) akan memperoleh sinar matahari lebih banyak dari daerah lainnya. Hal inilah yg menjadi salah satu penyebab adanya musim di bumi (panas, gugur, dingin, semi).

1. Pada sekitar bulan Mei – Juli, matahari akan lebih banyak menyinari belahan bumi utara/BBU (>23 derajat lintang utara), sehingga pada belahan bumi utara (USA, eropa) mengalami musim panas, belahan bumi selatan/BBS mengalami musim dingin (australia).
2. Pada sekitar bulan Agustus – Oktober, daerah cakupan sinar matahari mulai turun ke selatan dan mendekati ekuator (khatulistiwa, 0 derajat lintang). Pada sekitar tanggal 22 September, terjadi Equinox, di mana matahari akan persis berada di atas khatulistiwa. Pengaruhnya, BBU mengalami musim gugur, BBS mengalami musim semi. Pada tempat-tempat di ekuator seperti Pontianak, matahari akan terlihat persis di atas kepala anda pada jam 12 siang, sehingga bayangan tubuh akan tidak terlalu terlihat.
3. Pada bulan November – Januari, daerah cakupan sinar matahari berada di BBS (>23 derajat lintang selatan), akibatnya di BBU akan mengalami musim dingin, sementara di BBS akan mengalami musim panas. Jadi jangan heran kalo natal di USA atau eropa itu pas musim dingin, sementara natal di australia ketika musim panas.
4. Pada bulan Februari – April, cakupan sinar matahari mulai berpindah lagi menuju ke utara dan kembali berada persis di atas equator di sekitar tanggal 20 Maret. Equinox terjadi lagi. Kali ini BBU mengalami musim semi dan BBS musim gugur.

OK, kembali ke Midnight Sun tadi. Pada waktu musim panas, matahari lebih banyak menyinari BBU, termasuk daerah kutub utara. Akibatnya, walaupun bumi berotasi pd sumbunya, daerah ini akan tetap terkena sinar matahari lebih dari 12 jam. Pada daerah-daerah yg sangat dekat dengan kutub utara, matahari bahkan terlihat bersinar selama 24 jam penuh, dan pada daerah kutub, ‘siang abadi’ ini bisa berlanjut sampai setengah tahun lamanya (pertengahan musim semi – pertengahan musim gugur).

Pada saat yg sama, belahan bumi selatan mengalami musim dingin. Daerah sekitar kutub selatan akan sedikit sekali menerima sinar matahari. Kutub selatan bahkan tidak terkena sinar matahari pada periode ini. Akibat yg terjadi adalah kebalikan dari kutub utara tadi. Kutub selatan, akan mengalami ‘malam abadi’ selama setengah tahun.

OK. Jadi, masuk akal kan kalo matahari itu bisa menyinari kita selama 36 jam …… asalkan pada saat itu, kita berada di kutub utara/selatan pada saat musim panas.

Apakah pada tanggal 17 oktober 2008, Amerika dan tetangga2nya akan gelap selama 36 jam ?

Tidak. Amerika utara, eropa dan asia utara berada pada akhir musim gugur pada bulan oktober ini. Siang hari akan menjadi lebih pendek, tetapi bukan berarti gelap terus-menerus. Di Barrow, Alaska (titik paling utara USA), matahari mulai tenggelam sekitar tanggal 18-19 November, dan baru terbit lagi 65-67 hari kemudian.

Pernah nonton film 30 Days of Night nggak ? Nah, walaupun kurang akurat, film itu (kecuali vampir-nya ) bisa jadi contoh bagaimana keadaan ‘malam abadi’ pada saat musim dingin di Alaska.

Apakah fenomena ini terjadi setiap 2400 tahun ?

Seperti yg saya paparkan di atas, fenomena ini terjadi setiap tahun, bukan 2400 tahun sekali.

Apakah kita juga bisa mengalaminya ?

Ya itu tadi, kalo anda berada di kutub utara/selatan saat musim panas, anda akan mengalaminya. Gimana kalo di Indonesia ?

Karena berada pada daerah tropis, nggak jauh-jauh dari ekuator, maka Indonesia tidak akan mengalami fenomena ini. Sebab, mau bagaimanapun posisi cakupan sinar matahari, tetap saja daerah tropis menerima sinar matahari lebih banyak dari daerah manapun di Bumi ini. Itu sebabnya, temperatur di daerah tropis itu relatif hangat dan konstan sepanjang tahun. Jadi, Indonesia nggak akan pernah menikmati yg namanya salju, kecuali pada daerah-daerah tertentu misal gunung Jaya Wijaya. Itupun salju abadi karena pengaruh ketinggian gunung, bukan karena musim dingin.

Halah, sok tau lu ! Kata teman gw, Indonesia ntar bakalan mengalami musim dingin bersalju !

Kalo berdasarkan ilmu geofisika, konon lempengan-lempengan bumi terus bergerak satu sama lain, dan katanya sih ntar posisi daratan di bumi nggak akan sama seperti sekarang. Dari salah satu film dokumenter yg saya tonton (The Future is Wild), kutub selatan akan berpindah ke daerah equator sekitar 100 juta tahun lagi. Daratan Indonesia akan terpecah, sulawesi dan papua akan terus bergerak ke utara, sedang jawa, sumatera dan kalimantan akan bergabung dengan daratan india di selatan.

Dan konon (lagi), Bumi akan kembali mengalami zaman es sekitar 5 juta tahun dr sekarang.

Nah, jadi secara scientific, InsyaAllah, 5-100 juta tahun lagi, orang Indonesia akan beruntung bisa ‘menikmati’ musim dingin yg bersalju. Yg jelas, anda yg saat ini lg baca tulisan saya, kemungkinan besar nggak akan bisa menikmati saat-saat itu. Tanya kenapa .

—–

Okay, sekian ulasan dr saya. Capek euy 3 jam nulis ini non-stop. Kalo ada komentar, tambahan atau sanggahan, silakan komen.

Referensi :

• http://www.arctic.noaa.gov/gallery_np_seasons.html
• http://www.athropolis.com/arctic-facts/fact-midnight-sun.htm
• http://en.wikipedia.org/wiki/Midnight_sun
• http://en.wikipedia.org/wiki/Axial_tilt
• http://en.wikipedia.org/wiki/Equinox
• berbagai sumber (internet, film dokumenter, buku meteorologi, dll)

Images were taken from

• http://fc01.deviantart.com/fs11/i/2006/209/4/0/The_Midnight_Sun_by_Isilmetriel.jpg
• http://themes.belchfire.net/screenshots/%5B4255%5DMidnight_Sun_preview.jpg
• wikipedia.org

Kisah Konversi Data Radar – Bagian 1

 

Okay. Setelah berbulan-bulan mencari dan mencari, menunggu dan menunggu, data radar cuaca BPPT sudah bisa dibaca keduanya. Data radar padang lebih beruntung. Seorang rekan peneliti dari JAMSTEC ternyata pernah membuat tool (unofficial) untuk membaca data RAW IRIS Sigmet. Karena format data radar padang sudah sesuai (data RAW), konversi ke parameter reflectivity dan doppler velocity jadi jauh lebih mudah, walaupun gw sempat jungkir balik juga buat ngoprek toolnya karena nggak serta merta bisa dijalankan alias error mulu. Ada beberapa script (dalam C) yg harus diulik-ulik dulu. But anyway, we made it.

Data radar serpong jauh lebih rumit lagi. Karena format data RAW-nya bukan format IRIS Sigmet, dan sampe sekarang JAMSTEC masih belum dapat cara yg pas buat konversi data RAW kuno tadi ke ASCII (atau RAW IRIS), kami pake cara yg sedikit ‘primitif’ untuk memperoleh data reflectivity. Caranya adalah dengan melakukan image processing terhadap data image untuk web radar. Data image ini diproses hingga pada akhirnya diperoleh nilai pixel yg unik pada tiap titik pixel data reflectivity. Setelah dikelompokkan dan di format ulang tiap grid dan koordinatnya, akan diperoleh nilai pixel yg merepresentasikan nilai reflectivity yg dicari. Cara yg menurut gw sangat-sangat ‘maksa’ karena ada beberapa keterbatasan dengan metode ini, antara lain :

1. Karena yg diproses adalah data image dan bukan data RAW, maka otomatis hanya data pada 3 sudut elevasi antena saja yg bisa diproses, yaitu pada sudut 1 derajat, 4.5 derajat dan 23.8 derajat. Dengan hanya menggunakan data pada ketiga sudut ini (dari total 18 sudut elevasi yg ada), analisis tingkat lanjut seperti estimasi ketebalan awan ataupun ground check verification mejadi sangat sukar dilakukan. Walaupun bisa, hasilnya kemungkinan besar nggak valid.
2. Hasil pembacaan data reflectivity akan sangat bergantung pada kualitas image yg diproses. Kalo saja sistem radarnya lagi error dan image-nya jadi ngaco, maka otomatis data keluarannya juga ikutan ngaco.
3. Pada image ada 2 kotak legenda yg menutupi beberapa daerah cakupan (coverage) radar, akibatnya data reflectivity pada daerah-daerah ini nggak bisa diperoleh.
4. Urutan proses menjadi sangat panjang dan kurang efisien untuk proses otomatisasi konversi data. Kira-kira begini urutannya : Data RAW (BIN) –> Data Image (GIF) –> Image Processing (ilwis) –> Data Grid dan Pixel (ASCII) –> Data Reflectivity (ASCII).
5. Karena tipe pixel dikelompokkan berdasarkan legenda citra radar, otomatis nilai reflectivity yg dihasilkan juga bergantung pada legenda radar. Akibatnya, nilainya jadi nggak spesifik/detil tapi berada pada selang-selang tertentu. Misal 5 dBZ sampai 10 dBZ, 11 dBZ – 20 dBZ dst.
6. Karena menggunakan image processing, maka yg banyak terlibat adalah orang-orang image processing/GIS. Pengetahuan gw tentang radar nggak terlalu banyak diperlukan di sini. Hehehe … emangnya gw pakar radar gitu ? … kumat .. kumat … narsis gw kumat 

Hehehe … ya udahlah gpp. Toh ini semua demi kepentingan bersama dan masyarakat. Ego pribadi harus dikesampingkan dulu. Mari maju bersama membangun bangsa. Benar nggak sodara-sodara ?

Cara ‘maksa’ ini digunakan untuk sementara saja, ntar kalo modul IRIS dipasang di radar serpong (sekitar awal tahun depan), data RAWnya udah bisa dikonversi ke data ASCII.

———–

Tahap selanjutnya adalah konversi data reflectivity ke rain rate. Secara umum hubungannya dituliskan sebagai berikut :

Z = aR^b, Z adalah reflectivity factor (dB of Z) dan R adalah rain rate (mm/hr)

Rumus di atas diperoleh dari proses panjang yg sejujurnya gw juga belum terlalu mengerti. Kebanyakan cacing-cacing integral dan dede-dede turunan sih . Yg jelas, relasi Z dan R akan terlihat jelas kalo diplotkan dan membentuk grafik persamaan linear dengan Z dan R sebagai sumbu-sumbunya. CMIIW.

Berdasarkan formula di atas, Marshall-Palmer (1948) menuliskan hubungan Z-R sebagai berikut :

dBZ = 200R^0.625, jadi a = 200 dan b = 0.625

Menurut beberapa sumber (terpercaya pastinya), nilai a dan b (koefesien dan eksponen) pada formula di atas diklaim paling mendekati nilai rain rate yg sesungguhnya (nilai default, kalo Pak Findi bilang :P). Tadinya, gw udah bikin algoritma program buat konversi data reflectivity ke rain rate dengan formula Marshall-Palmer tadi. Eh, nggak taunya, pas lagi googling, ternyata nilai a dan b tadi bisa bervariasi, tergantung pada lokasi pengamatan dan topografi setempat. Kalo di USA misalnya, pada beberapa daerah, koefisien yg digunakan bisa mencapai nilai 300 dan eksponen bernilai lebih dari satu.

Nah, kalo begitu, koefisien dan eksponen yg paling cocok untuk daerah Jakarta dan Padang berapa ? Ternyata belum ada yg melakukan penelitian tentang itu di Indonesia. Bisa buat bahan paper nih ! By the way, nilai a dan b bisa dicari dengan melakukan verifikasi data curah hujan di permukaan, ntar dicocokkan dengan nilai reflectivity dan diperolehlah korelasinya. Masalah lagi, kalo diluar negeri, verifikasi data biasanya menggunakan jaringan ARG (Automatic Rain Gauge) dan AWS (Automatic Weather Station) yg tersebar hinggan ratusan unit pada tiap 1000 kilometer persegi. Kalo Indonesia ??? Hmmmm … hmmm … ARG/AWS di Jakarta dan Padang cuman ada berapa ya ? Dan kalopun ada, belum tentu datanya bisa diperoleh dengan mudah, butuh birokrasi yg berbelit-belit dan kadang UUD (ujung-ujungnya duit). Yah, namanya juga Indonesia … hehehe.

Hhhh … ok just go on, keep fighting, tetap semangat walaupun puyeng .