Bir Hesabı Okumak ile Doğrulamak Arasındaki Fark

1. Okumak neden yetmez?

Kafes motorundaki hata iki satırdaydı: Rijitlik matrisinde 1/L çarpanı yoktu, kuvvet hesabında ise vardı. Her satır tek başına makuldü; sorun, ikisinin farklı varsayımlarla yazılmış olmasıydı. Cross motorunda da taşıma işlemi doğru katsayıyla (0,5) yapılıyordu, yalnızca yanlış çubuğa. Kodu satır satır okuyan biri, her satırı "doğru" diye onaylayabilirdi.

Okumak, kodun niyetini anlamak için iyidir. Ama kodun yaptığını anlamanın tek güvenilir yolu onu çalıştırıp sonucunu koddan bağımsız bir şeyle karşılaştırmaktır.

2. Doğrulayıcıyı doğrulamak

Denetimin en öğretici anı bir yanılgıydı. Açı-yer değiştirme, üç moment ve matris rijitlik sayfalarının kodu okunduğunda doğru görünüyordu. Yine de her biri 20 rastgele girdiyle çalıştırıldı ve ayrı yazılmış bir referans çözücüyle karşılaştırıldı. İki sayfa uyuştu; üç moment sayfası %107 sapma gösterdi.

Sonuca varmadan önce elle çözülebilir iki durum doğrudan denetlendi: iki eşit açıklık (bilinen cevap M_B = −qL²/8 = −45 kNm) ve 6 m + 4 m (−35 kNm). Sayfa ikisinde de tam doğruydu. Hata, referans çözücüdeydi: Mesnet tepkisi formülünde bir işaret ters yazılmıştı. Düzeltilince uyum tamamlandı.

3. Eksik olanı okuyarak bulamazsınız

Tepki spektrumu sayfası, TBDY'deki uzun periyot bölgesini (T > T_L = 6 s) hiç içermiyordu; bu periyotlarda %33 fazla ivme veriyordu. Var olan kodun her satırı doğruydu. Yanlış olan, yazılmamış bir satırdı. Okuyarak bir eksikliği bulmak, neyin eksik olduğunu önceden bilmeyi gerektirir.

Bu hatayı bulan, girdilerin tüm aralığını taramaktı: Rastgele girdilerin bir kısmı bilinçli olarak 6 s'nin üzerinde seçildi ve sonuç sitenin TBDY motoruyla karşılaştırıldı.

4. Ekranın dürüstlüğü

İki hata hesapla değil, ekranla ilgiliydi. Spektrum sayfası kullanıcıdan sönüm oranı istiyor ama bu değeri hiçbir hesapta kullanmıyordu: %2 de girilse %20 de sonuç aynıydı. Yönetmelik paketi seçicisi ise bazı durumlarda düğmede ABD yönetmeliğini gösterirken hesabı TBDY'ye göre yapıyordu.

İkisinde de hesap motoru doğru çalışıyordu. Ama kullanıcı, ekrandan hesabın neye dayandığı konusunda yanlış bir bilgi alıyordu. Bir mühendis için bu, yanlış bir sayı kadar tehlikelidir.

5. Yuvarlama da bir hata kaynağıdır

Sayfa içi hesapları denetleyen testin ilk sürümü iki sayfada "uyuşmazlık" buldu. İkisi de testin kendi hatasıydı. Sayfa a = 21,1 mm gösteriyordu, motor 21,05 mm; fark yalnızca ekrandaki tek ondalık yuvarlamaydı. Bir temel örneğinde q_min neredeyse sıfırdı (1,69 kPa) ve göreli tolerans orada anlamsızlaşıyordu.

6. Beş kural

1. Her hesap için en az bir elle çözülebilir durum. Bu, iki uygulama uyuşmadığında hakem olur.
2. Bağımsız bir ikinci uygulama. Farklı bir yöntem (Cross'a karşı açı-yer değiştirme) ya da farklı bir yazar.
3. Rastgele ve sınır girdileri. Formülün bölge değiştirdiği noktalar ve aralığın uçları dahil.
4. Kullanıcının gördüğünü denetlemek. Yalnızca motorun değil, ekrandaki her değerin ve her etiketin.
5. Doğrulayıcıyı doğrulamak. Referans çözücü de, test de, tolerans da hata yapabilir.

Bu kurallar archi-civil.com'un testlerine eklendi; her biri, denetimde gerçekten yaşanmış bir durumdan çıkarıldı.