practicalBIM

Viimeaikona on ollut vapaata aikaa googlata ympäri nettiä etsien BIM aiheisia juttuja.

Törmäsin tällaiseen blogiin:
http://practicalbim.blogspot.fi/

Käykääpä lukaisemassa tietomalleista Australialaisen arkkitehdin näkövinkkelistä - loistavaa tekstiä ja kaverilla on selvästi erittäin laaja näkemys ja kokemus asioista.

Esimerkiksi tätä on mukava lukea:
http://practicalbim.blogspot.com.au/2013/02/real-collaboration-working-with.html

Pikkuisen häiritsee Revit -uskonnollisuus, mutta en anna sen häiritä itseäni...

Uutta LOD -speksiä jenkeiltä

Käsittääkseni myös AIA:n hyväksymä (American Institute of Architects, paikallinen "SAFA") speksi tietomallien sisällön tasosta ja kehitysasteesta on päässyt luonnosvaiheeseen.

Drafti ohjeesta on saatavilla täältä:
http://bimforum.org/lod/
Kunhan antaa omat tiedot, niin latauslinkki napsahtaa sähköpostiin

Lisää taustatietoa täällä:
http://www.aecbytes.com/viewpoint/2013/issue_68.html

http://practicalbim.blogspot.fi/2013/03/what-is-this-thing-called-lod.html

En ole syvällisesti perehtynyt LOD ajatteluun, mutta jotain tuon suuntaista on hyvä olla olemassa.

Muistelen, että Level 500 tasoa on useampikin kollega ihmetellyt ja kysellyt, että onko sellaisen teko edes mahdollista.

Liian tarkka ohjeistus (tai vaatimus) voi aiheuttaa turhaa työtä joissakin kohteissa, jos vain vaaditaan jotain asiaa ilman että siitä on kenellekään mitään hyötyä.

Tämähän on ainakin suomessa nykyisten eri ohjeistusten pienimuotoinen ongelma. Jos on kirjoitettu ohjeet / vaatimukset, niin joku vetovastuussa oleva henkilö voi vaatia niiden noudattamista pilkuntarkasti sellaisissakin asioissa, joilla ei ole mitään tekemistä itse kyseessäolevan kohteen suunnittelussa / rakentamisessa / ylläpidossa.

No, parempi olla kuitenkin jotkut ohjeet, kuin että ei olisi mitään.

Ym. asiankin IPD / Allianssihankkeet ja Lean Construction -filosofia korjaisi... saisi tehdä juuri sitä, mikä on hyväksi kyseessä olevan kohteen tilaajalle ja loppukäyttäjälle.

IFC, energialaskenta, Spaceboundaryt

Hiljaista on ollut bloginpitäjän kirjoitustahti, mutta jotain tekstiä sentään syntyy töissä...

Aika usein kysellään miksi arkkitehdin tekemä IFC ei mene sisälle energiasimulointisoftaan oikeantyyppisesti.

Tässä eräs kokemusperäinen syy asiaan. Kyseessä osa erästä sähköpostia, jonka kirjoitin kun asiaa kysyttiin. Pientä editointia on sisältöön suoritettu:

---

Vaikuttaa haasteelliselta projektilta saada toimivaa ifc:tä ulos energialaskentaohjelmistojen näkökulmasta.

Kun pelataan ifc:n kanssa, niin pitäisi juuri päästä eroon tuosta miljoonasta ohjeesta eri sovelluksille. IFC:n toimivuus energialaskentaohjelmistoissa (huom, ei siis Riuskan, Riuska seuraa IFC:n speksiä) vaatii sen, että mallissa on tiloja sekä ns. SpaceBoundaryt luotuna.

SpaceBoundaryt luodaan ifc exportin yhteydessä automaattisesti sovellusohjelman toimesta. Toiset ohjelmat luovat ne paremmin, toiset huonommin. Jotta SB:t yleensä voivat syntyä, tarvitaan malliin tilaobjektit (Space) jotka ovat olleet "peruskauraa" jo kauan arkkitehtisovelluksissa. Tilan tulisi myös rajautua ympäröiviin rakenteisiin (aika normaali vaade tuokin kun oikeaa tietomallia tehdään). Yleensä sovelluksissa on käsky, jolla "klikataan" tilaa ja se klikkaus luo tilaobjektin siten, että ohjelma tunnistaa ympäristönsä.

Suunnittelu on tietenkin muuttamista, ja kun tämän "klikkauksen" jälkeen siirretään esim. seinää, niin sovelluksesta riippuen se joko osaa liikuttaa myös tilaobjektia tai sitten ei. Ja osa sovellukista osaa kyllä suurentaa / pienentää tilaobjektia, mutta hajoittaa sisäisesti tilaobjektin ja ympäröivien objektien relaatiot (jotka ovat elintärkeitä spaceboundaryjen syntymiselle).

Joissain ohjelmissa on "Space Update" -tyyppisiä käskyjä joka tsekkaa tilaobjektit uudelleen ja luo relaatiot kasaan jne. "korjaa" sisäisen rakenteen kuntoon. Jälleen sama virsi: toiset ohjelmat toimii paremmin kuin toiset.

Eli suomeksi: olemme sellaisessa kehitysvaiheessa varsinkin xxx -firman tuotteiden kanssa, että ark sovellukset eivät osaa tehdä IFC-speksin mukaista ifc-tiedostoa "oikeassa elämässä". Demoilla saadaan homma toimimaan, mutta harvemmin todellisissa suunnittelukohteissa.

---

 

Ym. viestin sanoma on siis se, että kun pystytään tekemään "kerralla oikein", niin IFC-tiedosto tuntuu olevan kunnossa. Kun taas ark mallia käytetään normaalisti, eli muutetaan, viilataan ja pyöritellään tiloja, niin se tuntuu ajan saatossa sekoavan sisäisesti siten, että sieltä ei saada toimivaa IFC:tä ulos. (vaikka olisi saatu esim. jollain alkuversiolla onnistumaankin).

 

Ja toinen esimerkki, joka konkretisoi ark sovellusten ifc-kirjoituksen puutteellisuuden on kerroksellisuus. Spaceboundaryjen kautta ifc-speksin mukaisesti pystytään tutkimaan esim. vesikaton päällä olevat lämpimät tilat (vrt. IV-konehuone tasakaton keskellä). IV-konehuoneen alla olevat tilat osaavat ymmärtää spaceboundaryjen kautta, että päällä on lämpimää tilaa. Ja jos IV-konehuoneen seinä katkaisee allaolevan tilan, niin tilan katto jakautuu kahteen tai useampaan lohkoon, joista toinen on kylmää pintaa ja toinen lämmintä. Tai siis näin on ifc-speksissä.

 

Erittäin harva (jos yhtään?) ark-sovellusta osaa luoda kerrosten välille oikeanlaisia spaceboundaryjä. Eli laatan (lattian / katon) läpi ei tunnu tieto siirtyvän.

 

Minä tulkitsen tuon siten, että softafirmat vasta harjoittelevat SB:n käyttöä seinien ja ikkunoiden kanssa.

 

Taustatietona vielä sekin, että spaceboundary -speksi ifc:ssä on ollut olemassa jo about kymmenen vuotta... voiko joku softafirma oikeasti väittää, että heitä kiinnostaa energialaskentamallin tuottaminen?

 

Kuukauden kuva:

Sinisellä ne pinnat, joiden spaceboundaryjen luonti epäonnistunut (ei relaatiota).

Eli tuo määrä seinä, ikkuna tms. pinta-alaa puuttuu rakennuksesta energialaskentaohjelmiston näkökulmasta.

 

Muutoin kohde on "ihan normaali" mallinnuskohde ja navikset, bimsightit jne. pystyvät käyttämään mallia ongelmitta, koska niitä ei spaceboundaryt / relaatiot kiinnosta.