ENKA Yelken Grubu Fahir Çelikbaş Kupası II IRC 2 Birincisi

ENKA Yelken Grubu Fahir Çelikbaş Kupası II IRC 2 Birincisi.
Yeni MAT 1010'umuzla katıldığımız ilk kupanın her iki yarışında da birinci olduk.
MAVİ EKİP'teki takım arkadaşlarımı tebrik eder, tüm yarışanlara iyi bir sezon dilerim.

Navisworks Model Compare

Burcu'nun sorusu:

"Patron Merhaba,

Navisworks de iki dosya (Dosyalar aynı dosyanın içinde ceiling editini değiştirdim, duvar sildim, kapı sildim) arasında compare yaptığımda rengine göre değişikliğin çeşiti her seferinde farklılık gösteriyor.

Id ye göre ve geometriye göre farklı compare'ler yaptım.

Birinde sarı olan diğerinde kırmızı oluyor.Helpinde renklerin tanımı var ama tutarsızlık oluyor.

Bu konuda araştırabileceğim kaynak dosya yada video varsa çok sevinirim.

Bu arada sorunun cevabını merakla bekliyom.

İyi çalışmalar..."

Karşılaştığım bir tutorial hatırlamıyorum. Zaten bu konular daha çok projeciler tarafından bilindiği için pek tutorial olacağını da zannetmiyorum.

Navisworks'ün gösterdiği renklerde bir tutarsızlığa ben rastlamadım. Sorunun yaklaşımında olduğunu düşünüyorum. Biraz bu tool'un kullanım amacını anlatayım, bir iki de tüyo vereyim, konuyu halledelim.

Öncelikle bu tool'un adının "Compare" olması kafalarda biraz karışıklığa sebep oluyor. Özellikle Revit alt yapısı olanlar bunu Revit'in "Compare Models"'i ile kıyaslıyor. Senin de hazırladığın test ortamı tam Revit "Compare Models"lik olmuş.

A.rvt isimli ilk dosya

B.rvt (Kapı ve Duvar silinmiş, Ceiling edit'i değişmiş.)

Revit CompareModels

Yukarıda görüldüğü gibi "Compare Models" değişiklikleri ne kadar güzel veriyor. Hatta dikkat ederseniz iki duvarı da veriyor. Birine B.rvt'de yok diyor. Öbürüne ise değişti diyor.

Bu kıyaslamanın raporunu da alabiliyoruz. Modelleme ile ilgili kıyaslamaları bu tool ile yapmamız en iyi yoldur.

Gerçek hayatta başlıca iki sebepten model compare yapıyoruz.

1) Internal: Modele hakim olmak için. (Çok bariz)

2) Standartlar gereği. (Bunu açalım)

ProjectWise kullanmış olan ekibim hatırlasın. Ne yapıyorduk? Modeller "Work in Progress" çalışılıyor daha sonra Interface/Responsible ve BIM onayı alınca Read-Only olarak Hindistan ve Filipinler'deki diğer disiplinlerle paylaşılıyordu. Aynı işlemi onlar da yapıyordu.

Yukarıdaki senaryo içerisinde bir örnek vereyim.

Mesela Mimari grup tasarımının başında kolon kiriş gibi statik elemanları modelledi. Daha sonra "Konunun Sahibi"(disiplin değil, kontratta o konu kimin işi ise) Mimari Modeli kullanarak modellemeye başladı ve statik modelini yayınladı.

İşte bu noktada Mimari Grup "Ay kolonları çıkarsak mı çıkarmasak mı?" diye düşünmez.

Standartlar çok nettir. Gruplar tasarım amaçlı placeholder (Hayri bu kelime senin için) modeller yapabilir.

Fakat "Konunun Sahibi" (Originator) yayın yaptığı anda modellerinden bu elemanları çıkartmak ve derhal revizyon yayınlamak zorundadırlar.

İşte tutorial dünyasının dışında, gerçek hayat projelerinde "Model Compare" koordinasyon grupları tarafından bu amaçla kullanılır. Gelen modeller tek tek, eleman eleman incelenip internal ve external commentler (hatırlayın) verilir.

Gelelim Navisworks'e. Copyright'li tarifimi yineleyeyim hemen. "Navisworks ham dataya sopayla dalma aracıdır." Sopayla tek tek dalınır. (Koordinasyoncular gibi..)

Peki ya Mimari Revit ile çalıştı. Statik Tekla ile, MEP AutoCad MEP kullandı?

Navisworks için fark etmez! O bir çekiçtir. Herşey onun için çividir! (Bu lafı daha önce de kullanmamış mıydım ben yahu?)

Navisworks Compare'e bu mantıkla bakın. Help'inde yazanları tekrarlamayacağım.

"Find Differences In" tarafında teker teker gidin! (En azından hakim olana kadar.)

Results'ta önce "Save as Selection Sets" ile başlayın. (Var/Yok ları yakalayabilmek için.Compare:Unmatched diye geçer.)

Daha sonra "Save each difference as Set"'i ekleyin. Mesela yukarıdaki örneğimize bu seçenek tek başına seçili ise silinmiş elemanlar için Set oluşturmaz. Çünkü olmayan bir duvarla var olan bir duvarın farkı olmaz.

Bunun gibi Set oluşturmayan sorgular yine de bizi uyarmak için o an ki ViewPoint'te Appearance değişikliği yapar. Unutmayın Appearance ViewPoint'te tutulur. Selection Set'te değil.

Gerekiyorsa Home > Project > Reset All > Appearance yapıp resetleyin.

Peşinde olduğumuz renkler değil elemanlar! Ve tabi elemanları da manalı Selection Set'ler ürettirerek yakalayacağız.

"Remove old results" kalsın. Silinmemesini istediğiniz eski selection set'leri Rename yapmanız yeterli.

Ve bir de bu işlemleri yaparken Comments'i mutlaka açın.(Yine comment dedim. Galiba Serkan'ın haklılık payı var :)

Az bilinen birşeydir. Zaten onun için herkesin aklı karışır.

Compare tool'u yarattığı Selection Set'lere sorguda neden o elemanları yakaladığını Comment olarak koyar. Bunları inceleyince herşeyini çözersiniz.

Ben Compare yapacağımda Selection Tree, Sets, Comments ve Properties açarım. Önce dosyaları compare ederim. Gerekirse Selection Tree'de alt Class'larda Compare'e devam ederim.

Herkese iyi Koordinasyonlar..

Bim Sorusu 01: Tepenin Kralı COMMENTS

Öncelikle cevap gönderen herkese çok teşekkürler. "EMPG BIM Dream Team" ruhunun ölmediğini görmek güzel!
(Cevaplar sms, mail, linkedin gibi çok çeşitli yerden geldiği için blog comment'lerini yayınlamadım. Bir de bundan sonrası için şöyle birşeye karar verelim. Sağdaki bana ulaşınla gelenleri yayınlamayayım, comment ile gelenleri yayınlayayım.)

Komik cevap alanında Serkan tek finalist iken, iyi cevaplarda Nurullah ve Nihal yarıştı.
Kazanan Nihal oldu!

Bu arada çok acayip cevaplar geldiği için bir disclaimer yapmak faydalı olacak.
BIM sorusu bir oyun!
On saat align yapmış olmanın tost'a çevirdiği beyinlere bir nebze su serpmek adına, ekiplerin yetenek ve bilgilerini, araştırma ve kurcalamaya teşvik ederek geliştiren bir motivasyon oyunu!
Can sıkıntısına SFW şekilde iyi gelen bir aktivite!
Hiç bir koşulda "best practice", "case study", "workflow" vs. değil!
Yani cevap bir halta yaramaz, cevap aranırken öğrenilir.
Bunları yazıyorum çünkü "Ülkemizde BIM gakgukken, sizin gakguk doğru bulmuyorum." gibi yetmiş milyon adına bu aktiviteyi eleştiren arkadaşlar da çıkmadı değil!
10.000'i doldurmayan ne kadar çok adam türedi bu aralar farkında mısınız?

Şimdi gelelim Comment'e : (Evet doğrusu Comments ama üşendim düzeltmeye)

O Bir Sevgili!
Hayri "Serkan "Mehmet Comment vermeyi seviyordur bence ondan" dedi" dedi.
Ülen Allah'tan iyi cevap geldi! Ya hediyeyi bu cevapla kapsaydın? Bir de tee Bakü'ye yollamak var!
Kesin yollamazdım ama. Geldiğinde al falan derdim. Ya da giden birinin eline tutuştururdum.

O Bir Schedule'larda Filter Tab'inde gelen bir Field! (Nihal'in cevabı)
Schedule edilebilen parametrelerin hepsi yine aynı schedule'un filtresi olarak kullanılamayabilir.
Comment bu anlamda filtrelenebilen bir parametredir.
Tecrübesiz bir ekibe, hiçbir ekstra iş yapılmadan (parametre oluşturmadan vs.) filtreleme amacıyla kullandırılabilir.
Cevabında Nihal'in de belirttiği gibi doğru bir yol DEGİLDİR! Ama günü kurtarabilir!

O Bir Tag'lenebilen ve Schedule'a giren System Parameter!

Revit'teki parametre tipleri için Paul Aubin'in tablosuna bakalım. Aslında bu tablo biraz eksik.
Comment bu tabloya göre System Parameter'dır. Her sistem parametresi eşit yaratılmamıştır.
Tablodaki tag'lenebilir schedule'a girer tabirleri çoğunluk için geçerlidir. Comment genele uyar hem taglenebilir hem de schedule'a girer.

O Bir Shared Parameter gibi Multi Category Tag'lenebilen!

Farklı kategorilerde aynı shared parameter'ı kullanıyorsanız, bunları kategorilerden bağımsız olarak tek bir Multi-Category tag ile tagleyebilirsiniz.
Mesela kapı, pencere ve duvarlarda "Smoke Proof" diye bir veriniz var. Bu sizin geleneksel verilerinizden değil. Yangıncının istediği birşey. Belki de sadece yangın paftalarında kullanılacak.

Öyleyse her zaman kullandığınız door, window vs. taglerinizi mundar etmeye gerek yok. Aynı shared parameter'ı kullanan bu elemanlar için multi category SmokeProof Tag yaparsınız. O paftaları tagler geçersiniz.

Multi Category tag'lere shared parameter'ların yanı sıra az sayıda şanslı System Parameter'da girer. Bizim comment orada da var!
Yani shared parameter gibi multi category taglenebilir. Bir tane Comment multi cat. tagi yaparsanız içinde comment olan her category'i bu tagle taglersiniz.

O Bir Project Parameter gibi Key Schedule'a giren!
Key Schedule. Bilginin Anatasyon aracı!

Revit'te model yapma seviyemiz Proje başında ve süresince verdiğimiz stratejik bir karar. Kontrata göre, istenenlere göre bir takım elemanları modelliyoruz. Bazılarını ise annotation ile çözüyoruz. Yani bir detayda vida görünüyor diye vida modellemek durumunda değiliz.
Ya da modelleyeceksekte bu işi Construction Modelling periyodunda yapıyoruz. SD ve ya DD zamanında değil! Herkes bu konsepte alıştı.

Bu BIM'in M'si. Peki aynı şey I için de geçerli değil mi? Modele bir takım veriler de girmek durumunda değil miyiz?
İşte bu verileri modellemeyi yapanları öldürmeden düzenli ve doğru girmenin en güçlü aracı Key Schedule'lardır. Modeli yapan tek bir parametreyi değiştirerek onlarca schedule parametresini doğru girmiş olur.

Paul'ün tablosunda eksik gördüğüm konuyu izah edeyim. Project parameter oluşturmak istediğimizde karşımıza çıkan iki seçeneğe bakalım.
Bir gariban Project Parameter var. Bir de Shared Parameter.
Maşallah shared'de yok yok.ODBC diyor, schedule diyor, tag diyor, tek gecelik düşünme multi-project & family diyor..
Diyor da diyor..

Ülen o zaman niye Project parameter yapayım, dayarım shared'i?
Ama gariban Project Parameter'ın pek herkes tarafından bilinmeyen bir yönü var.
Project Parameter Key Schedula'a girer! Nınının nınının nı nı nı nıııınnnn!

Key Schedula girebilen çok az sayıda şanslı azınlık System Parameter vardır. Onlar da ancak kendi category'lerinde girebilir bu elit listeye!

Peki bizim Comment ne durumda? 108 key schedule category'sinin 89'unda vardır. Olmadığı 19 category'de yukarıdaki gibi pek te Key Schedule'luk konular değildir. Ve Comment parametreler arasında tartışılmaz Key Schedule Şampiyonudur!

Şampiyon category'ler ise yukarıda görünen:
Door Style Schedule
Electrical Circuit Style Schedule
Electrical Equipment Style Schedule
Plumbing Fixture Style Schedule
Room Style Schedule
Space Style Schedule

Bu Category'lerde data amaçlı schedule'lar oluşturulacağında mutlaka Key Schedule'dan faydalanabilir miyiz diye düşünmek gerekir.

Evet kazanan Nihal, şampiyon Comments!
Bu bilgi comments kullanımınız hariç pek çok işinize yarayacak muhtemelen..
Oyun böyle birşey işte..