張兆波, 孟曉明
(1 甘肅農(nóng)業(yè)大學(xué)水利水電工程學(xué)院,蘭州 730070;2 中國建筑西南設(shè)計(jì)研究院有限公司,成都 610041)
建筑與結(jié)構(gòu)是建筑設(shè)計(jì)過程中最重要的兩個(gè)專業(yè),二者相互協(xié)調(diào)、相互制約。建筑結(jié)構(gòu)設(shè)計(jì)的流程一般是建筑專業(yè)將設(shè)計(jì)說明和建筑方案提供給結(jié)構(gòu)專業(yè),結(jié)構(gòu)專業(yè)完成結(jié)構(gòu)選型、分析計(jì)算、結(jié)構(gòu)構(gòu)件尺寸確定及定位工作。BIM技術(shù)能夠?qū)崿F(xiàn)建筑工程項(xiàng)目的協(xié)同設(shè)計(jì),可以提高建筑設(shè)計(jì)效率和質(zhì)量[1-4]。BIM技術(shù)在建筑專業(yè)的應(yīng)用點(diǎn)較多也相對比較成熟,如可視化展示、方案比選等,而其在結(jié)構(gòu)專業(yè)的應(yīng)用一直是脫節(jié)的[5]。造成這種狀況的原因有3種:1)對BIM的認(rèn)識不足;2)增量成本高,不愿意花費(fèi)額外的精力、資本跳出穩(wěn)定且成熟的二維提資模式,轉(zhuǎn)入基于BIM的工作模式;3)法律與標(biāo)準(zhǔn)體系不完善。前兩個(gè)原因究其根本,是目前沒有可行的協(xié)同模式和穩(wěn)定成熟的可互操作的應(yīng)用程序環(huán)境使得結(jié)構(gòu)專業(yè)愿意參與到基于BIM的建筑結(jié)構(gòu)設(shè)計(jì)工作流中。
互操作性是指一個(gè)系統(tǒng)(應(yīng)用程序、工作流、過程等)與其他系統(tǒng)一起工作的能力[6]??苫ゲ僮鞯膬蓚€(gè)應(yīng)用程序之間可以互相傳遞信息,而且傳遞信息時(shí)不會(huì)包含錯(cuò)誤、遺漏或數(shù)據(jù)丟失。目前,由于各軟件專有的數(shù)據(jù)格式不同,主流的建筑BIM軟件與結(jié)構(gòu)設(shè)計(jì)、分析軟件對彼此的信息交互支持度較低,無法滿足互操作性的要求。在BIM工作流中,結(jié)構(gòu)專業(yè)仍然需要重復(fù)勞動(dòng)、重新建模,從而導(dǎo)致出錯(cuò)概率增加,設(shè)計(jì)效率降低。
表1列出了主流建筑BIM軟件與結(jié)構(gòu)設(shè)計(jì)、分析軟件的專有數(shù)據(jù)格式與可導(dǎo)出的數(shù)據(jù)格式。由表1可知,只有個(gè)別軟件開發(fā)了針對特定軟件的非開放接口或插件,但經(jīng)過筆者的實(shí)例驗(yàn)證,利用插件或接口從建筑信息模型向結(jié)構(gòu)分析計(jì)算模型的轉(zhuǎn)換難以保證較高的準(zhǔn)確性,會(huì)出現(xiàn)構(gòu)件丟失、節(jié)點(diǎn)偏心實(shí)現(xiàn)困難、構(gòu)件ID混亂、準(zhǔn)換后的模型排錯(cuò)困難等問題。另外,如果只針對個(gè)別軟件開發(fā)插件或接口,會(huì)使設(shè)計(jì)人員對個(gè)別軟件產(chǎn)生依賴,當(dāng)合同指定軟件或因設(shè)計(jì)、分析需要變更軟件時(shí),會(huì)陷入被動(dòng)。因此,開放、標(biāo)準(zhǔn)化、獨(dú)立于專業(yè)軟件的數(shù)據(jù)交換格式十分必要。
表1 主流軟件數(shù)據(jù)格式
工業(yè)基礎(chǔ)類 (industry foundation classes,IFC) 是由buildingSMART開發(fā)的一種開放的、中立的數(shù)據(jù)交換格式和數(shù)據(jù)模型,它用面向?qū)ο蟮姆椒ū硎窘ㄖP偷膸缀魏驼Z義信息。IFC將建筑信息數(shù)據(jù)化,可以表示建筑構(gòu)件和不同的建筑空間,還可以表示二者的相互關(guān)系。目前,IFC已被建筑領(lǐng)域100余種軟件支持,幾乎可以用于建筑物生命周期中的任何數(shù)據(jù)交換場景[7],因此它為建筑與結(jié)構(gòu)專業(yè)之間的信息交互提供了方法。
基于IFC的建筑結(jié)構(gòu)專業(yè)信息交互研究可以分為以下3類:1)采用中央模型,胡振中等[8]采用算法和基于IFC的中央信息模型來加強(qiáng)建筑與結(jié)構(gòu)模型及結(jié)構(gòu)模型之間的互操作性;Sibenik等[9]用.NET Framework and C#開發(fā)的解析器IFCtoJSON parser將IFC文件解析為JSON格式作為中央數(shù)據(jù)文件,然后基于中央數(shù)據(jù)文件和幾何平臺OpenCasCade實(shí)現(xiàn)建筑模型到結(jié)構(gòu)模型的轉(zhuǎn)換;2)基于IFC的軟件數(shù)據(jù)接口,劉照球等[10]從Revit軟件導(dǎo)出IFC文件,用C++與Fortran語言開發(fā)IFC與YJK/PKPM的數(shù)據(jù)接口,以實(shí)現(xiàn)兩類軟件的數(shù)據(jù)交互;3)采用模型視圖定義(MVD,可以理解為是IFC的過濾器)可以從IFC文件中過濾出特定專業(yè)軟件需要的信息,明鑫[11]將MVD與結(jié)構(gòu)分析模型的標(biāo)準(zhǔn)化表達(dá)相結(jié)合,與IFC實(shí)體對象進(jìn)行關(guān)聯(lián)以指導(dǎo)實(shí)現(xiàn)結(jié)構(gòu)分析模型的數(shù)據(jù)共享與轉(zhuǎn)換。
本文的IFC文件采用STEP物理格式,后綴為.ifc,可以以文本方式打開或閱讀[12]。建筑模型導(dǎo)出IFC文件時(shí),經(jīng)常采用MVD Coordination View,此MVD被很多建筑BIM軟件支持。目前,MVD的開發(fā)者主要是研究機(jī)構(gòu)和標(biāo)準(zhǔn)化組織,而結(jié)構(gòu)分析領(lǐng)域MVD的研究非常少,專門針對結(jié)構(gòu)分析的MVD Structural Analysis View目前只被少數(shù)BIM軟件支持,Revit的導(dǎo)出選項(xiàng)中就不包括此MVD。
IFC文件按照IFC Schema定義,它在數(shù)據(jù)結(jié)構(gòu)層面有很高的完整性,但存在文件龐大,冗余度過高的問題。比如,在進(jìn)行三維幾何形狀描述時(shí),IFC Schema提供了邊界表示(B-rep)、擠壓平面立體(Extruded Area Solid)等多種方式,BIM軟件自主、隨機(jī)選擇形體生成方式并導(dǎo)出IFC文件,有時(shí)候簡單形體用復(fù)雜的方式表達(dá),忽視了模型表達(dá)效率。另外,在IFC文件中,同一實(shí)體經(jīng)常被多個(gè)不同的實(shí)體管理和引用,使得同一實(shí)體在文件內(nèi)有多個(gè)副本,造成大量重復(fù)實(shí)體出現(xiàn)。因此為了避免建筑專業(yè)與結(jié)構(gòu)專業(yè)信息交互過程中出現(xiàn)IFC文件信息冗余度高導(dǎo)致的軟硬件資源消耗大、交互效率低等問題,對IFC文件進(jìn)行輕量化優(yōu)化很有必要。
另外,建筑BIM模型及其導(dǎo)出的IFC文件中往往存在大量與結(jié)構(gòu)無關(guān)的信息。以一個(gè)高層住宅樓建筑信息模型為例(圖1),此模型導(dǎo)出的IFC文件包含374 895行數(shù)據(jù),大小為23.8MB。其中包含了大量與結(jié)構(gòu)無關(guān)的實(shí)體,比如門IfcDoor、窗IfcWindow、裝飾條IfcBuildingElementProxy等實(shí)體及其引用的實(shí)體和屬性。因此,基于IFC的建筑與結(jié)構(gòu)信息交互工作流程中,快速、準(zhǔn)確地從建筑IFC模型中抽取與結(jié)構(gòu)計(jì)算、分析相關(guān)的實(shí)體及其屬性,生成結(jié)構(gòu)信息模型,對整個(gè)工作流程的實(shí)現(xiàn)十分關(guān)鍵。
圖1 高層住宅樓建筑信息模型
在建筑結(jié)構(gòu)設(shè)計(jì)時(shí),建筑模型中結(jié)構(gòu)構(gòu)件的定義和布置通常是借助于建筑師具備的基本結(jié)構(gòu)概念來完成,結(jié)構(gòu)工程師在建筑方案階段一般參與較少[13]。結(jié)構(gòu)工程師通常是等建筑師給出一個(gè)表現(xiàn)空間形式的方案后,以結(jié)構(gòu)專業(yè)方法去實(shí)現(xiàn)。這可能會(huì)造成建筑方案被采納而結(jié)構(gòu)上不可行,需要進(jìn)行反復(fù)多次的截面尺寸、結(jié)構(gòu)布置、甚至結(jié)構(gòu)體系的修改[14]。
因此,在基于BIM的建筑、結(jié)構(gòu)工作流中,結(jié)構(gòu)工程師應(yīng)及早介入方案設(shè)計(jì)階段,在結(jié)構(gòu)計(jì)算分析之前,充分利用建筑信息數(shù)據(jù)化、數(shù)據(jù)開放性、可自動(dòng)讀取的優(yōu)勢,借助從建筑信息模型中提取的結(jié)構(gòu)信息模型,設(shè)計(jì)自動(dòng)簡化計(jì)算算法模塊,計(jì)算重力荷載、重力荷載下結(jié)構(gòu)內(nèi)力、構(gòu)件截面初步尺寸、主體抗側(cè)力結(jié)構(gòu)剛度等。使結(jié)構(gòu)工程師在結(jié)構(gòu)分析計(jì)算之前快速得到結(jié)構(gòu)近似力學(xué)指標(biāo)和斷面尺寸,從而從整體上控制結(jié)構(gòu)的剛度、構(gòu)件承載力,避免在結(jié)構(gòu)分析時(shí)進(jìn)行反復(fù)多次計(jì)算與調(diào)整,提高設(shè)計(jì)效率。
簡化計(jì)算后,結(jié)構(gòu)信息模型有較高的可信度,但在進(jìn)行結(jié)構(gòu)計(jì)算分析時(shí),需要使用結(jié)構(gòu)分析模型。結(jié)構(gòu)分析模型是結(jié)構(gòu)信息模型的簡化表示,二者存在差異:1)結(jié)構(gòu)信息模型中,梁、板、柱、墻構(gòu)件是由截面拉伸或邊界面組合表示,構(gòu)件本身具有截面參數(shù)、長度等屬性。而在結(jié)構(gòu)分析模型中,梁、柱由線形元素和被賦予的截面和材料屬性表示;墻、板由平面元素和被賦予的截面和材料屬性表示;2)結(jié)構(gòu)信息模型中,構(gòu)件的連接關(guān)系是由邊界點(diǎn)的坐標(biāo)值確定,結(jié)構(gòu)分析模型中,構(gòu)件先是通過共用點(diǎn)或共用線實(shí)現(xiàn)連接,再設(shè)置剛接、鉸接等力學(xué)連接方式;3)結(jié)構(gòu)分析模型中,材料性質(zhì)(密度、材料強(qiáng)度、彈性模量、泊松比等)和構(gòu)件所受的荷載是結(jié)構(gòu)分析的必要元素,而在結(jié)構(gòu)信息模型中為非必要元素。重新建立結(jié)構(gòu)分析模型不符合BIM工作流的原則,因此,需要將結(jié)構(gòu)信息模型轉(zhuǎn)換為結(jié)構(gòu)分析模型。
綜合以上分析,本文提出了基于IFC的建筑結(jié)構(gòu)信息交互框架,如圖2所示。該框架由4個(gè)模塊、5個(gè)步驟組成,對其解釋如下:
圖2 建筑結(jié)構(gòu)信息交互框架
第1步:從建筑BIM模型中,通過模型視圖定義Coordination View 2.0導(dǎo)出IFC文件。
第2步:開發(fā)優(yōu)化算法模塊對導(dǎo)出的IFC文件進(jìn)行優(yōu)化,得到優(yōu)化的IFC文件。
第3步:開發(fā)結(jié)構(gòu)信息提取算法模塊從優(yōu)化的IFC文件中提取結(jié)構(gòu)信息模型。
第4步:開發(fā)簡化計(jì)算算法模塊。首先,結(jié)構(gòu)工程師將材料屬性等簡化計(jì)算所需參數(shù)輸入到結(jié)構(gòu)信息模型中,然后利用結(jié)構(gòu)信息模型并通過簡化計(jì)算模塊計(jì)算結(jié)構(gòu)力學(xué)指標(biāo),根據(jù)計(jì)算結(jié)果初步確定合理的構(gòu)件斷面尺寸。
第5步:結(jié)構(gòu)信息模型被結(jié)構(gòu)專業(yè)確認(rèn)無誤后,通過開發(fā)的模型轉(zhuǎn)換算法模塊,將結(jié)構(gòu)信息模型轉(zhuǎn)換為結(jié)構(gòu)分析模型,進(jìn)行結(jié)構(gòu)分析計(jì)算。
第1步在主流建筑BIM軟件中都可以實(shí)現(xiàn),本文進(jìn)行第2、3步的研究工作,分別對應(yīng)后文中的第3、4節(jié)。為了驗(yàn)證這兩部分研究成果的可行性,本文第5節(jié)選取一框架結(jié)構(gòu)建筑信息模型算例進(jìn)行驗(yàn)證。
根據(jù)上述IFC文件冗余度分析,且為了提高第3步結(jié)構(gòu)信息模型提取算法的運(yùn)行效率,需要對BIM模型預(yù)處理、對IFC文件進(jìn)行優(yōu)化處理,包括以下3個(gè)方面:
(1)導(dǎo)出前BIM模型預(yù)處理
不同建筑BIM軟件有不同的IFC導(dǎo)出設(shè)置方法,為了保證導(dǎo)出IFC模型的準(zhǔn)確性,本文需要定義的模型預(yù)處理原則包括:1)不導(dǎo)出模型空間邊界;2)按樓層標(biāo)高拆分墻柱;3)導(dǎo)出公用屬性集;4)模型精度設(shè)置為為低。
(2)過濾與結(jié)構(gòu)無關(guān)的信息
在IFC文件中,有很多與結(jié)構(gòu)無關(guān)的信息、實(shí)體和引用的實(shí)體需要被過濾,比如IFC頭文件(HEADER)信息、與結(jié)構(gòu)無關(guān)的度量單位實(shí)體、填充墻、門和門洞、窗與窗洞、裝飾構(gòu)件實(shí)體、人和組織的屬性O(shè)wner History對應(yīng)的IfcOwnerHistory、IfcPerson、IfcOrganization實(shí)體等。以上部分實(shí)體在引用新的實(shí)體時(shí),有可能與結(jié)構(gòu)構(gòu)件實(shí)體共同引用同一個(gè)或多個(gè)實(shí)體,如窗和柱均引用樓層實(shí)體IfcBuildingStory、建筑物實(shí)體IfcBuilding和場地實(shí)體IfcSite,如果將窗實(shí)體及其引用的所有實(shí)體全部過濾,可能會(huì)導(dǎo)致結(jié)構(gòu)信息模型提取時(shí)數(shù)據(jù)缺失。因此,此部分只過濾可以明確判斷為與結(jié)構(gòu)無關(guān)的實(shí)體,即只過濾首層實(shí)體,而保留其引用的全部實(shí)體,節(jié)省時(shí)間與算力。結(jié)合IFC Schema,對與結(jié)構(gòu)無關(guān)的實(shí)體進(jìn)行判定,形成無關(guān)實(shí)體庫,用Python語言開發(fā)算法對無關(guān)實(shí)體進(jìn)行過濾。
(3)刪除重復(fù)實(shí)體
IFC文件中實(shí)體由#開頭,圖3所示實(shí)體編號為#20392,名稱為IfcProductDefinitionShape,它用來定義產(chǎn)品形狀相關(guān)信息,它包含了3個(gè)屬性分別是:“名稱”、“描述”、“表示”。名稱和描述屬性為可選屬性,已被省略?!氨硎尽睂傩砸昧藢?shí)體#20390,該實(shí)體也包含屬性及引用的實(shí)體,如此形成層層嵌套關(guān)系。
圖3 實(shí)體
在IFC文件中,通常有多組同名、同屬性、不同編號的實(shí)體,比如IfcAxis2Placement3D實(shí)體,該實(shí)體用來定義構(gòu)件或空間局部坐標(biāo)系的坐標(biāo)軸方向及坐標(biāo)原點(diǎn)的位置。在圖1所示高層住宅樓建筑IFC文件中,同名、同屬性的實(shí)體IfcAxis2Placement3D有6 002個(gè),然而只需要保留其中一個(gè)供其他實(shí)體引用,并用這個(gè)保留的實(shí)體編號去替換引用實(shí)體中重復(fù)實(shí)體的編號,如圖4所示。替換完成后,再次檢查新的IFC文件是否出現(xiàn)新的重復(fù)實(shí)體,如果有,繼續(xù)進(jìn)行替換、刪除操作。
圖4 實(shí)體替換
在以上分析的基礎(chǔ)上,用Python語言開發(fā)優(yōu)化算法對IFC文件進(jìn)行優(yōu)化。
首先,根據(jù)IFC Schema,對IFC文件數(shù)據(jù)結(jié)構(gòu)進(jìn)行深入分析,從復(fù)雜的實(shí)體繼承和引用關(guān)系出發(fā),推理與結(jié)構(gòu)構(gòu)件信息相關(guān)的實(shí)體和屬性。
在IFC Schema中,實(shí)體分為對象實(shí)體和關(guān)系實(shí)體,對象實(shí)體用屬性來描述對象的特征。關(guān)系實(shí)體通過指向不同的對象實(shí)體來描述對象實(shí)體之間的關(guān)系。實(shí)體屬性采用繼承機(jī)制,見圖5。
圖5 實(shí)體繼承
在圖5這個(gè)繼承關(guān)系中,對象實(shí)體IfcObject的空間位置和幾何信息由實(shí)體IfcProduct和IfcElement的屬性來表達(dá),而不同的IfcElement之間的連接或從屬關(guān)系通過關(guān)系實(shí)體IfcRelConnectsElements來表達(dá)。最終,這些實(shí)體的屬性被更為具體的實(shí)體所繼承,如柱IfcColumn、梁IfcBeam、墻IfcWall等。圖6為一個(gè)簡單示例建筑模型導(dǎo)出的IFC文件中#272柱實(shí)體及屬性。如圖6所示,柱從IfcProduct繼承的屬性O(shè)bjectPlacement和Representation用于定義柱的幾何信息和位置信息。
圖6 建筑模型導(dǎo)出的IFC文件中#272柱實(shí)體及屬性
ObjectPlacement屬性在IFC文件中對應(yīng)編號#271的實(shí)體IfcLocalPlacement,該實(shí)體包含兩個(gè)重要的屬性PlacementRelTo和RelativePlacement,屬性PlacementRelTo定義柱局部坐標(biāo)系位于樓層局部坐標(biāo)系內(nèi);屬性RelativePlacement定義柱局部坐標(biāo)系坐標(biāo)軸方向及及其原點(diǎn)在樓層坐標(biāo)系內(nèi)的坐標(biāo)值。同理,還可以定義樓層局部坐標(biāo)系在建筑局部坐標(biāo)系內(nèi)坐標(biāo)軸方向及其原點(diǎn)位置、建筑局部坐標(biāo)系在場地坐標(biāo)系內(nèi)的坐標(biāo)軸方向及其原點(diǎn)位置。最終,通過多次坐標(biāo)變換,確定柱局部坐標(biāo)系在場地(絕對)坐標(biāo)系內(nèi)的坐標(biāo)軸方向及其原點(diǎn)位置。
Representation屬性在IFC文件中對應(yīng)編號#268的實(shí)體IfcProductDefintionShape,通過分析該實(shí)體與其他實(shí)體的引用關(guān)系(圖7)可知,經(jīng)過5層引用,柱的幾何信息包含在#254實(shí)體即IfcExtrudedAreaSolid中,該實(shí)體定義幾何體可以通過擠壓平面生成。它包含4個(gè)屬性,分別是起點(diǎn)位置Position,被擠壓平面SweptArea、擠壓方向ExtrudedDirection、擠壓長度Depth。
圖7 實(shí)體引用
IFC文件中每個(gè)構(gòu)件都有其所屬的空間,例如,柱定義在柱底標(biāo)高所在的樓層空間。在IFC Schema中,構(gòu)件和空間的從屬關(guān)系通過關(guān)系實(shí)體IfcRelContainedInSpatialStructure表達(dá),它可以將柱實(shí)體IfcColumn關(guān)聯(lián)在柱所在的樓層實(shí)體IfcBuildingStory。
用同樣的方法推理與結(jié)構(gòu)相關(guān)的所有實(shí)體及其屬性、引用實(shí)體及其屬性、關(guān)系實(shí)體及其屬性。將優(yōu)化后的IFC文件作為輸入文件,利用IfcOpenSell工具箱,用Python語言開發(fā)提取算法模塊從輸入文件中提取結(jié)構(gòu)信息模型。
為了測試所開發(fā)算法的可行性和運(yùn)行效果,選取了一個(gè)三層框架結(jié)構(gòu)教學(xué)樓建筑信息模型進(jìn)行驗(yàn)證,如圖8所示。該模型由Revit 2019創(chuàng)建,選擇模型視圖定義Coordination View 2.0導(dǎo)出IFC文件,文件大小為3.35MB,包含實(shí)體64 075個(gè)。
圖8 教學(xué)樓建筑信息模型
用優(yōu)化算法模塊優(yōu)化IFC文件,先根據(jù)無關(guān)實(shí)體庫過濾與結(jié)構(gòu)無關(guān)的信息和實(shí)體。表2中列出了部分過濾的無關(guān)實(shí)體的名稱及數(shù)量。過濾實(shí)體的總數(shù)量為1 452個(gè)。過濾完成后,查找重復(fù)實(shí)體,第一輪共查找到2 641組重復(fù)實(shí)體,最小重復(fù)數(shù)為2,最大重復(fù)數(shù)為353,為實(shí)體IfcAxis2Placement3D(#6,$,$),即存在353個(gè)不同編號但同名、同屬性的實(shí)體。查找完成后,總重復(fù)數(shù)為8 502,重復(fù)率為R=13.6%。選取每組重復(fù)實(shí)體中編號最小的實(shí)體作為保留實(shí)體,則其他實(shí)體為可刪除實(shí)體。在刪除之前,搜索確定每一個(gè)可刪除實(shí)體的被引用情況,用保留實(shí)體在IFC文件中替換被引用的可刪除實(shí)體,最后刪除可刪除實(shí)體。替換、刪除完成后,進(jìn)行第二輪查找,將前兩輪查找結(jié)果列于表3中。
表2 無關(guān)實(shí)體的名稱及數(shù)量
表3 查找結(jié)果
由表3可知,前兩輪優(yōu)化共刪除重復(fù)實(shí)體9 895個(gè),占實(shí)體總數(shù)的16%,第一輪的優(yōu)化效果遠(yuǎn)好于第二輪,因此,為了提高框架整體運(yùn)行效率、節(jié)省算力。此部分優(yōu)化止于第二輪。經(jīng)過過濾、刪除后的IFC文件共包含52 728個(gè)實(shí)體,優(yōu)化率為18%。
用提取算法模塊提取結(jié)構(gòu)信息模型,提取出的IFC文件中包含12 210個(gè)實(shí)體,占優(yōu)化后實(shí)體總數(shù)的23%。將提取出的結(jié)構(gòu)信息模型分別導(dǎo)入Revit和IFC Viewer中均能正確加載和顯示,沒有出現(xiàn)IFC文件語法錯(cuò)誤,沒有發(fā)現(xiàn)構(gòu)件丟失、構(gòu)件重疊等情況,如圖9、10所示。
圖9 結(jié)構(gòu)信息模型(導(dǎo)入Revit)
圖10 結(jié)構(gòu)信息模型(導(dǎo)入IFC Viewer)
本文從建筑與結(jié)構(gòu)專業(yè)的工作模式出發(fā),針對主流的建筑BIM軟件與結(jié)構(gòu)設(shè)計(jì)、分析軟件信息交互支持度低這一問題,分析了已有基于IFC的建筑結(jié)構(gòu)信息交互研究現(xiàn)狀及存在的問題,提出了基于IFC的建筑結(jié)構(gòu)信息交互框架。該框架由4個(gè)算法模塊組成,共包含5個(gè)步驟。為了實(shí)現(xiàn)該框架,用Python語言開發(fā)了優(yōu)化算法模塊和結(jié)構(gòu)信息模型提取算法模塊,并用一個(gè)建筑信息模型驗(yàn)證了算法的有效性,通過驗(yàn)證,得出以下結(jié)論:
(1)兩個(gè)算法模塊在實(shí)際應(yīng)用時(shí)是可行的。從所得數(shù)據(jù)可知,優(yōu)化算法模塊可以有效地過濾IFC文件中的無用信息、查找并刪除重復(fù)的實(shí)體,使IFC文件輕量化,以間接提高提取算法模塊的運(yùn)行效率。
(2)提取算法模塊可以準(zhǔn)確地從IFC文件中提取出結(jié)構(gòu)信息模型,且無IFC語法錯(cuò)誤,無構(gòu)件丟失、構(gòu)件重疊等情況。
(3)優(yōu)化算法模塊的優(yōu)化能力還可以繼續(xù)提升,這需要對IFC Schema進(jìn)行更深入的研究;提取算法模塊在信息提取時(shí)運(yùn)行時(shí)間較長,在后續(xù)的研究中需要對算法進(jìn)行優(yōu)化以縮短運(yùn)行時(shí)間。
(4)后續(xù)將用更多不同結(jié)構(gòu)類型的算例驗(yàn)證前述研究成果的可行性。后續(xù)的研究中會(huì)將簡化計(jì)算算法模塊和模型轉(zhuǎn)換算法模塊的開發(fā)作為重點(diǎn)內(nèi)容,以完全實(shí)現(xiàn)基于IFC的建筑結(jié)構(gòu)信息交互框架。