Lab guncelleme hikayesi, paylasayim, belki dert ortagi cikar.

Konya OSB ARGE labimizda 14 yillik manuel triaxial cihazimiz vardi — operator dakikada bir oluku okur, defter doldurur, sonra Excel'e girer. Olcum hatasi mi var, deftere yazma hatasi mi var, Excel'e girerken yanlis hucreye yazdik mi — surekli sorgulama. Gecen ay GDS otomatik veri toplamali sisteme gecis yaptik (load cell, LVDT, pore pressure transducer, hepsi paralel kanalla bilgisayara). 1 Hz logging, GDSLAB software.

Ilk haftada bayagi sasirdim: deney 4 saat surduyse 14.400 satirlik veri cikiyor numune basi. Excel acilmiyor bile, R veya Python'la analiz etmek zorunda kaldim. Ikincisi: bizim eski sonuc raporlarini su yeni datayla karsilastirinca, bazi noktalarda manuel okumalarda 2-3 kPa kayma var oldugunu farkettim — yani 14 yildir yapilan deneylerde sistematik bir okuma hatasi varmis.

Sorularim: (1) Logging frekansi 1 Hz cogu icin yeterli mi yoksa cyclic/dinamik testlerde 10 Hz'e cikarmali miyim? (2) Eski manuel veriyi yeni dataset ile karsilastiran var mi, ne kadar fark gordunuz? (3) Yazilim tarafinda GDSLAB disinda Python script yazip post-processing otomatize eden var mi?

konya_arge_begum yazdi:

Logging frekansi 1 Hz cogu icin yeterli mi

Begum, statik CU/CD icin 1 Hz fazlasi bile aslinda — ASTM D4767 "yeterli sikliktaki veri" diyor, tipik strain rate 0.01 mm/dk ile 4 saatte %0.5 strain, 1 Hz'de strain artisi okuma basina 0.000035% — gereksiz hassas bile. Cyclic'te 10 Hz minimum, tercihen 100 Hz cunku 1 Hz frequency'inin gostermek istedigin sinyali capture edemezsin (Nyquist: 1 Hz cyclic icin minimum 2 Hz sample, pratikte 20-50 Hz).

Eski manuel verilerle karsilastirma yaptim ben de gecen yil — bizim eski Wille manuel cihaz vardi. Sistematik 2-3 kPa kayma manuel okumada normal: operator gozu skala uzerinde paralax, yuvarlama, dakika basi okuma sinifin, bunlar birikiyor. Yeni cihazda bu hata silinir. Eski raporlardaki phi' degerlerinin yaklasik %5 hatali oldugunu kabul etmek gerek bence.

Akademik tarafta Begum'a tavsiyem: Python ile post-processing scripti kesinlikle yaz, ileride zaman kazandirir. GDSLAB'in default outputu TSV, pandas ile read_csv ile aldim ben de doktora tezimde. Standart pipeline:

Raw csv -> filtreleme (rolling mean, 5-10 saniye penceresi gurultu icin) -> phase identification (saturation/consolidation/shear) -> phase basina ozet metrikler (B degeri, sigma_p' from consolidation, peak deviator, failure point) -> p'-q diagrami, sigma'-tau Mohr daireleri, secant modulus E_50 cikarisi.

Bu scripti bir kere yazdiktan sonra her test icin 5 dakika icinde rapor cikiyor. Manuel post-processing'ten cok daha hizli ve tutarli. Github'da paylasmaya hazirlanan acik kaynak triaxial post-processing kutuphaneleri de var, "py-triax" diye bir tane vardi sanirim, bakman tavsiye.

ank_ezgi yazdi:

GDSLAB'in default outputu TSV, pandas ile read_csv

Ezgi ablacim Python'a yeni baslayan biri olarak bu yol haritasi cok yardimci, tesekkurler. py-triax'i arayacagim, bulamazsam kendi script'imi yazmaya baslayacagim. ARGE birimimde stajyer arkadas Python biliyor, gorev verecegim.

Saha tarafindan: rapor okurken "data quality" parametresine bakiyorum artik. Eski manuel raporlarda bu yok, yeni otomatik raporlarda olmasi gerek. Standart sapma, sample size, sensor drift kontrolu, kalibrasyon zaman damgasi gibi seyler. Begum, raporun bu metadatasini koymaya basladiniz mi?

Bizim Plaxis kalibrasyon icin "noisy" data yerine clean data cok daha kullanisli — manuel olcumlerde her zaman bir scatter var, modeli fitlemek zor.

Taner abi metadata onemli nokta. Su an raporda log dosyasi adi, baslangic-bitis tarih, kalibrasyon sertifikasi numarasi, software versiyonu var. Ama drift kontrolu eklemedim, baslarim. Sensor drift'i her ay kalibrasyon checklist'le takip ediyoruz, ama rapora yansitmiyorduk — su sonra koyacagim.

Eski manuel/yeni otomatik konusu beni 17 yilima goturuyor. 2008'lerde manuel triaxial cihazi vardi bizim labda, bir sefer cihazin loglu kati elektriksiz oldugu icin 6 saatlik test bosa gitti, operator butun veriyi defterden hatirlamaya calisti — kabaca yazildi rapora. O test bilirkisi davasinda incelenmisti hatta. Otomatik sistemler bu tur kazalari onler — log her an disk'te.

Begum, 14 yil onceki manuel raporlarinizi yeni dataset ile karsilastirip yayin yaparsaniz bilim icin guzel olur. "Manuel vs automated triaxial: case study from a Turkish industrial laboratory" gibi.

Cyclic test perspektifinden konusayim, Furkan zaten degindi ama altini cizeyim: 1 Hz cyclic loading icin minimum 50-100 Hz logging gerekli. ASTM D5311 "20 noktanin minimum cycle basina alinmasi" der, yani 1 Hz cyclic icin en az 20 Hz log. Begum, cyclic test yapiyor musunuz lab'da, GDS sisteminde bu frekansa cikabiliyor mu?

izm_inz_pinar yazdi:

cyclic test yapiyor musunuz lab'da

Pinar, cyclic test yapmiyoruz su an, sadece statik CU/CD. Cyclic icin ayri bir cihaz/setup gerekiyor, butce talebimizde ileride var. GDS sistemimiz hardware acidan 100 Hz log destekliyor ama yazilim cyclic option licensed, ek lisans gerekecek.

14 yilda 14.400 manuel okuma yapti operator, simdi 1 deneyde 14.400 otomatik veri geliyor. Bu dunyada zaman kayboluyor. Operator istifa etmis midir lab'dan?

Operatorlerimiz hala tam zamanli, sadece is yuku degisti. Defter yazma yerine Python ogreniyoruz simdi, bu anlamda iyi degisim ama uyumsa belli bir sure aldi.

Bir uyari: GDSLAB software'inin default ayarlari her zaman dogru degil. Calibration factor'u senin kanal sensor'unun specsine gore manuel ayarlanmali. Default factory degerleri ihmal edilirse pore pressure veya load cell'de %2-5 sistematik hata olusur. Senin "eski manuel ile yeni otomatik %2-3 fark" dediginde bu bias'in bir kismi yeni cihazinizda da olabilir, manuel cihazi sucsuz yapmiyor mutlaka.

Periyodik kalibrasyon (3 ayda bir, deadweight + reference voltage) standart pratik olmalidir.

Burak'a +1. Bir de logger'in time-stamp dogrulugu kontrol edilmeli. Bilgisayar saat NTP server'a senkronize mi? Cihaz icindeki RTC'nin pili eskidiginde drift basliyor, deney suresi yanlis kayit olabiliyor. Standart sounds gibi gozukuyor ama proje denetimlerinde gerekli.

GDS log dosyasinin yapisi konusunda Furkan'la onceki bir konuda Python'la real-time okuma tartismistik. Begum, post-processing icin onun kodlarina bakabilirsin, baslangic noktasi olur.

Begum lab'iniz yazilim tarafini guncellerken metadata sablonunuzu paylasirsaniz cok faydali olur. Biz Izmir'de hala manuel rapor formatini kullaniyoruz, yenileme yapmak istiyorum ama elimde sablon yok. Sample report PDF'i atabilirseniz teyit alirim.

Deniz abla, gelecek hafta lab'da rapor sablonunun yeni versiyonunu cikartiyoruz, sana ozelden mail atayim hazir olunca.

Burak ve Ezgi, kalibrasyon takvimini ve NTP'yi kontrol listesine ekliyorum. Cok faydaliydi bu konu.

Ozet: 1 Hz statik icin yeterli, cyclic icin 50-100 Hz; Python post-processing scripti yazmak zorunlu denecek seviye onemli; metadata (kalibrasyon, drift, software versiyonu) rapora konsa iyi olur; 3 ayli deadweight kalibrasyon + NTP zaman senkronu rutinde olmali. Bir-iki ayda Python kutuphanemizi paylasmayi planliyoruz, GitHub linkini bu basliga atarim.