متن مقاله
مقدمه
وقتی یک مدل Revit کند میشود، معمولاً اولین واکنش این است که حجم فایل، تعداد Familyها، Warningها یا قدرت سختافزار مقصر دانسته شود. گاهی یکی از این موارد واقعاً بخشی از مشکل است، اما در بسیاری از پروژهها «سنگین شدن مدل» نتیجه یک عامل مشخص و ساده نیست. ممکن است فایل سریع باز شود اما ویرایش عناصر کند باشد، یک View خاص عملکرد ضعیفی داشته باشد،Synchronize زمان زیادی بگیرد یا تغییر یک عنصر ساده باعث چند ثانیه محاسبه شود.
به همین دلیل، قبل از اجرای راهکارهایی مانند Purge، Audit، حذف Warningها یا سبک سازی Familyها باید ابتدا مشخص شود کندی دقیقاً در کدام بخش رخ میدهد و چه عاملی آن را ایجاد میکند. تغییر هم زمان چند بخش از مدل ممکن است موقتاً عملکرد را بهتر کند، اما اگر ندانیم کدام تغییر مؤثر بوده است، علت اصلی همچنان ناشناخته باقی میماند و احتمال تکرار مشکل در همان پروژه یا پروژه بعدی وجود دارد.
در این مقاله به جای ارائه فهرستی از روشهای عمومی برای «سبک کردن Revit»، یک مسیر تشخیصی بررسی میشود؛ مسیری که از تعریف دقیق علامت شروع میشود، عوامل احتمالی را مرحله به مرحله جدا میکند و در نهایت کمک میکند راه حل متناسب با علت واقعی انتخاب شود.
سنگین شدن مدل Revit دقیقاً یعنی چه؟
وقتی کاربران میگویند «مدل Revit سنگین شده است»، این عبارت به تنهایی اطلاعات کافی برای تشخیص مشکل نمیدهد. کندی میتواند در بخشهای مختلفی از کار با مدل دیده شود و هرکدام ممکن است منشأ متفاوتی داشته باشند.
در یک پروژه ممکن است باز شدن فایل چند دقیقه طول بکشد، اما پس از باز شدن، مدل عملکرد قابل قبولی داشته باشد. در پروژهای دیگر، فایل سریع باز میشود اما تغییر یک دیوار، جابهجایی یک تجهیز یا ویرایش یک Family با تأخیر همراه است. گاهی مشکل فقط در یک View سه بعدی یا یک پلان خاص دیده میشود و گاهی نیز مدل هنگام Save یا Synchronize with Central کند میشود.
حتی افزایش حجم فایل RVT یا مصرف بالای حافظه نیز به تنهایی به معنی پایین بودن عملکرد مدل نیست. این موارد میتوانند نشانهای برای بررسی بیشتر باشند، اما هنوز مشخص نمیکنند Revit دقیقاً در انجام چه عملیاتی با مشکل مواجه شده است.
بنابراین اولین قدم در بررسی یک مدل کند، پیدا کردن «عامل سنگین کننده» نیست؛ ابتدا باید مشخص شود کدام عملیات کند شده است. آیا مشکل هنگام باز کردن مدل رخ میدهد؟ هنگام نمایش Viewها؟ بعد از ویرایش عناصر؟ هنگام ذخیره یا Synchronize؟
تا زمانی که علامت به صورت دقیق تعریف نشده باشد، اقداماتی مانند Purge، حذف Warningها، تغییر Familyها یا ارتقای سختافزار بیشتر به آزمون و خطا شباهت دارند تا بهینهسازی واقعی.
کندی یک علامت است، نه تشخیص.
حجم فایل با عملکرد مدل Revit یکی نیست
یکی از رایجترین اشتباهها در بررسی مدلهای کند Revit این است که حجم فایل RVT به عنوان معیار اصلی عملکرد در نظر گرفته شود. افزایش حجم فایل میتواند نشانهای برای بررسی باشد، اما به تنهایی توضیح نمیدهد چرا مدل کند شده است.
سه مفهوم باید از یکدیگر جدا شوند: حجم فایل، مصرف حافظه و بار محاسباتی مدل.
حجم فایل نشان میدهد چه مقدار اطلاعات در پروژه ذخیره شده است. مصرف حافظه مشخص میکند Revit هنگام کار چه مقدار از منابع سیستم را درگیر کرده است. اما بار محاسباتی به تعداد و پیچیدگی روابطی مربوط میشود که Revit باید هنگام نمایش، ویرایش یا بازتولید مدل محاسبه کند.
به همین دلیل ممکن است یک فایل نسبتاً بزرگ عملکرد قابل قبولی داشته باشد، در حالی که یک فایل کوچکتر به دلیل روابط پیچیده، Familyهای نامناسب، هندسه سنگین یا وابستگیهای متعدد، در ویرایش و نمایش بسیار کند باشد.
در عمل، هدف بهینه سازی نباید صرفاً کاهش حجم فایل باشد. کاهش حجم زمانی ارزشمند است که به حذف اطلاعات غیرضروری یا کاهش بار واقعی مدل منجر شود. اگر فقط عدد حجم فایل کمتر شود اما Revit همچنان همان محاسبات سنگین را انجام دهد، مشکل اصلی حل نشده است.
مدل سنگین الزاماً مدل بزرگ نیست؛ مدل سنگین مدلی است که Revit برای کار با آن مجبور به پردازش غیرضروری یا پیچیده باشد.
قبل از بهینه سازی، عملکرد مدل را اندازهگیری کنید
اگر ندانیم مدل در چه عملیاتی و تا چه اندازه کند شده است، نمیتوانیم بعداً مشخص کنیم یک تغییر واقعاً مؤثر بوده یا فقط احساس کاربر نسبت به عملکرد بهتر شده است. به همین دلیل، قبل از هر اقدام اصلاحی باید یک وضعیت مبنا برای عملکرد مدل ثبت شود.
برای این کار لازم نیست از ابزارهای پیچیده استفاده شود. کافی است چند عملیات تکرارشونده و قابل مقایسه انتخاب شوند؛ برای مثال زمان باز شدن مدل، باز شدن یک View مشخص، انجام یک ویرایش ساده، Save یا Synchronize with Central. این عملیات باید قبل و بعد از هر تغییر در شرایط مشابه تکرار شوند.
در همین مرحله یک سؤال دیگر نیز اهمیت زیادی دارد: مدل از ابتدا کند بوده است یا عملکرد آن در مقطع مشخصی افت کرده است؟
اگر کندی از زمان مشخصی شروع شده باشد، بررسی تغییرات همان دوره میتواند دامنه جستوجو را به شدت محدود کند. اضافه شدن یک Link، بارگذاری Family جدید، Import کردن فایل CAD، ایجاد تعداد زیادی Group یا حتی تغییر ساختار مدل ممکن است همزمان با شروع مشکل رخ داده باشد.
ثبت وضعیت مبنا دو مزیت دارد: نخست اینکه شدت واقعی مشکل مشخص میشود و دوم اینکه میتوان تأثیر هر اقدام اصلاحی را جداگانه سنجید.
برای تعریف همین خط مبنا و سنجش اثر اصلاح، مقاله چگونه میتوان اثر بهینهسازی BIM را در زمان، خطا و کیفیت تحویل اندازهگیری کرد؟ شاخصهای قابل مقایسه را توضیح میدهد.
اگر چند تغییر همزمان انجام شوند و مدل سریعتر شود، هنوز معلوم نیست کدام تغییر عامل اصلی بوده است.
بهینه سازی زمانی قابل اتکاست که بتوان تغییر عملکرد را قبل و بعد از هر اقدام اندازهگیری کرد.
آیا کندی واقعاً از فایل Revit است؟
قبل از اینکه ساختار مدل را تغییر دهیم، باید مطمئن شویم منشأ کندی خود فایل Revit است. در بعضی موارد، رفتار ضعیف پروژه بیشتر به محیط اجرای Revit مربوط میشود تا به محتوای مدل.
برای مثال ممکن است یک فایل روی یک سیستم بسیار کند باشد اما روی سیستم دیگر با شرایط مشابه عملکرد طبیعی داشته باشد. تفاوت در نسخه یا Update نرمافزار، Add-inهای فعال، درایور گرافیک، منابع سختافزاری یا حتی پردازشهای پس زمینه میتواند روی تجربه کاربر اثر بگذارد.
یک روش ساده برای محدود کردن مسئله این است که همان مدل در شرایط متفاوت آزمایش شود. اگر امکان دارد، فایل روی سیستم دیگری با نسخه مشابه Revit باز شود و رفتار آن در همان Viewها وعملیات مقایسه شود. همچنین در صورت مشکوک بودن به Add-inها میتوان عملکرد مدل را در محیطی با حداقل افزونههای فعال بررسی کرد.
هدف این مرحله پیدا کردن علت نهایی نیست؛ هدف این است که یک سؤال اساسی پاسخ داده شود:
آیا کندی همراه فایل جابهجا میشود، یا همراه محیط کاری کاربر؟
اگر مشکل روی چند سیستم و در شرایط مختلف به شکل مشابه تکرار شود، احتمال اینکه منشأ آن داخل مدل باشد بیشتر میشود. اما اگر رفتار فایل به شدت به سیستم یا محیط Revit وابسته باشد، تغییر Familyها، حذف Warningها یا Purge کردن مدل احتمالاً نقطه شروع مناسبی نیست.
برای بررسی دقیقتر مرز میان محدودیت سیستم و ضعف ساختار مدل، مقاله قبل از خرید سختافزار قویتر، چه چیزهایی را در مدل Revit بررسی کنیم؟ یک مسیر مقایسهای جداگانه ارائه میکند.
قبل از اصلاح مدل، باید ثابت شود که خود مدل بخشی از مسئله است.
آیا کندی از خود مدل است یا از Linkها و Worksharing؟
مدل Revit معمولاً به تنهایی کار نمیکند. در پروژههای واقعی، فایل اصلی ممکن است به چندین Revit Link، فایل CAD،Point Cloud یا منابع خارجی دیگر وابسته باشد و هم زمان در یک محیط Worksharing محلی، شبکهای یا ابری استفاده شود. به همین دلیل، کندی مشاهده شده همیشه از خود مدل Host ناشی نمیشود.
برای تشخیص، باید وابستگیها تا حد ممکن از یکدیگر جدا شوند. ابتدا میتوان رفتار مدل را با Linkهای غیرضروری غیرفعال یا Unload شده بررسی کرد. اگر عملکرد به شکل محسوسی بهتر شود، باید هر Link به صورت جداگانه بررسی شود تا مشخص شود کدام فایل یا ترکیب فایلها بیشترین تأثیر را ایجاد میکند.
Worksharing نیز باید جداگانه ارزیابی شود. اگر ویرایش و حرکت در مدل روان است اما Synchronize with Central یا باز کردن فایل Local زمان زیادی میگیرد، احتمالاً مسئله بیشتر به ساختار Worksharing، مسیر شبکه، ارتباط ابری یا حجم تبادل اطلاعات مربوط است تا به هندسه مدل.
در مقابل، اگر حتی یک نسخه محلی و بدون Link نیز در عملیات ساده کند باشد، احتمال وجود مشکل در خود مدل افزایش پیدا میکند.
نکته مهم این است که کندی مدل، کندی Linkها و کندی Worksharing سه مسئله یکسان نیستند. هرکدام باید به صورت مستقل آزمایش شوند؛ در غیر این صورت ممکن است یک مشکل ارتباطی یا وابستگی خارجی با عنوان «مدل سنگین» اشتباه تشخیص داده شود.
هرچه وابستگیهای بیشتری از آزمون حذف شوند، محدوده علت واقعی کوچکتر میشود.
آیا کندی فقط در بعضی Viewها اتفاق میافتد؟
اگر مدل در همه شرایط کند نیست و مشکل فقط در بعضی Viewها دیده میشود، این موضوع یک سرنخ مهم است. در چنین حالتی، احتمال اینکه کل مدل مشکل عملکردی داشته باشد کمتر میشود و باید ابتدا همان Viewها و محتوایی که در آنها نمایش داده میشود بررسی شوند.
برای مثال ممکن است یک پلان ساده روان باشد، اما یک View سهبعدی هماهنگی یا یک Section خاص با تأخیر باز شود و هنگام Pan،Zoom یا Orbit کند عمل کند. در این شرایط عواملی مانند Detail Level، نمایش Linkها، تعداد زیاد Annotationها، Transparency، Shadow، View Filterها، محدوده وسیع دید یا حجم زیاد هندسه قابل مشاهده میتوانند بر عملکرد اثر بگذارند.
یکی از آزمایشهای مفید این است که رفتار یک View کند با یک View سادهتر و کنترل شده مقایسه شود. اگر با خاموش کردن برخی Categoryها، Linkها یا تنظیمات گرافیکی عملکرد به شکل محسوسی بهتر شود، دامنه بررسی از کل مدل به همان عناصر یا تنظیمات محدود میشود.
نکته مهم این است که کندی یک View لزوماً به معنی سنگین بودن کل فایل نیست. گاهی مدل از نظر کلی سالم است، اما یک View به دلیل ترکیب خاصی از هندسه، تنظیمات نمایش و اطلاعات قابل مشاهده بار زیادی به Revit تحمیل میکند.
اگر مشکل فقط در یک View دیده میشود، ابتدا همان View را بررسی کنید؛ نه کل مدل را.
هندسه و Familyهای پیچیده چگونه بار مدل را افزایش میدهند؟
هرچه هندسهای که Revit باید نمایش دهد و بازتولید کند پیچیدهتر باشد، بار بیشتری به مدل وارد میشود. این مسئله فقط به تعداد عناصر مربوط نیست؛ شکل هندسه، میزان جزئیات، نحوه پارامتریک شدن و تعداد دفعات استفاده از آن نیز اهمیت دارد.
Familyهایی با Nested Familyهای متعدد، Voidهای پیچیده، Arrayها، فرمولهای زیاد یا هندسهای با جزئیات بیش از نیاز پروژه میتوانند هزینه محاسباتی قابل توجهی ایجاد کنند. همین موضوع درباره In-Place Familyها، هندسه واردشده از CAD یا نرمافزارهای دیگر و مدلسازی بیش از حد دقیق نیز صادق است.
اما پیچیدگی یک Family را نباید جدا از تعداد Instanceهای آن بررسی کرد. یک Family نسبتاً سنگین که دو بار در پروژه استفاده شده ممکن است اثر محدودی داشته باشد، در حالی که همان Family اگر هزاران بار تکرار شود میتواند به یکی از عوامل اصلی افت عملکرد تبدیل شود.
در بررسی این بخش، هدف حذف جزئیات به هر قیمت نیست. باید مشخص شود چه میزان از هندسه واقعاً برای طراحی، هماهنگی، مستندسازی یا تحویل پروژه لازم است. جزئیاتی که فقط ظاهر مدل را دقیقتر میکنند اما ارزش اطلاعاتی یا اجرایی ندارند، معمولاً اولین گزینه برای بازنگری هستند.
همچنین بهتر است به تغییرات اخیر پروژه توجه شود. اگر افت عملکرد پس از بارگذاری یک Family،Import کردن هندسه یا افزایش ناگهانی تعداد یک نوع عنصر شروع شده باشد، همان بخش باید در اولویت بررسی قرار گیرد.
هندسه زمانی مسئلهساز میشود که پیچیدگی آن بیشتر از ارزشی باشد که برای پروژه ایجاد میکند.
روابط و وابستگیهایی که Revit مجبور است دائماً محاسبه کند
بخشی از کندی مدل به چیزی مربوط میشود که مستقیماً در ظاهر فایل دیده نمیشود: روابطی که Revit باید پس از هر تغییر دوباره بررسی و بازتولید کند. هرچه تعداد این وابستگیها بیشتر و پیچیدهتر باشد، یک ویرایش ساده میتواند زنجیرهای از محاسبات را فعال کند.
Constraintها، Joinها، عناصر Host-Based، Groupها، Arrayها، روابط بین Familyهای Nested و وابستگیهای پارامتریک نمونههایی از این ساختار هستند. در مدلهای MEP نیز اتصال تجهیزات، Connectorها، سیستمها، Flow، Pressure و سایر محاسبات وابسته به شبکه میتوانند بار محاسباتی قابل توجهی ایجاد کنند.
به همین دلیل ممکن است یک عنصر از نظر هندسی ساده باشد، اما تغییر آن باعث تأخیر شود؛ چون Revit فقط خود عنصر را جابهجا نمیکند و باید اثر این تغییر را بر مجموعهای از روابط دیگر نیز بررسی کند.
نکته مهم این است که بسیاری از این وابستگیها ذاتاً نامناسب نیستند. Constraint،Join یا ارتباط سیستمها بخشی از منطق Revit است. مشکل زمانی ایجاد میشود که این روابط بدون نیاز واقعی، در مقیاس زیاد یا با ساختاری پیچیدهتر از نیاز پروژه ایجاد شوند.
در بررسی یک مدل کند باید پرسید: آیا تأخیر بعد از تغییر یک نوع خاص از عناصر رخ میدهد؟ آیا Edit کردن یک Group یا Family باعث Regeneration طولانی میشود؟ آیا کندی در بخشهایی از مدل بیشتر است که روابط بیشتری میان عناصر وجود دارد؟
هزینه واقعی یک عنصر فقط هندسه آن نیست؛ روابطی که Revit باید برای آن حفظ کند نیز بخشی از بار مدل هستند.
Warnings را بشماریم یا تحلیل کنیم؟
تعداد Warningها یکی از شاخصهایی است که معمولاً برای ارزیابی سلامت مدل Revit استفاده میشود، اما عدد Warning به تنهایی معیار قابل اتکایی برای تشخیص عملکرد مدل نیست. دو مدل با تعداد Warning مشابه ممکن است از نظر سرعت و پایداری رفتار کاملاً متفاوتی داشته باشند.
اهمیت Warning به نوع آن بستگی دارد. برخی Warningها بیشتر به کیفیت اطلاعات یا هماهنگی مدل مربوط هستند، در حالی که برخی دیگر میتوانند نشان دهنده روابط هندسی، Constraintها، همپوشانی عناصر یا شرایطی باشند که Revit مجبور است هنگام Regeneration بارها آنها را بررسی کند.
بنابراین هدف نباید صرفاً رساندن تعداد Warningها به صفر باشد. ابتدا باید Warningها دسته بندی شوند و مشخص شود کدام گروهها ممکن است با علامت مشاهدهشده ارتباط داشته باشند. برای مثال اگر کندی هنگام جابهجایی یا ویرایش عناصر خاص اتفاق میافتد، Warningهای مرتبط با همان عناصر و روابط آنها ارزش بررسی بیشتری دارند.
از طرف دیگر، حذف Warning بدون شناخت علت میتواند فقط صورت مسئله را تغییر دهد. اگر یک روش مدلسازی نامناسب مرتباً همان Warning را تولید میکند، پاک کردن Warningهای موجود مانع بازگشت آنها نمیشود.
در ارزیابی حرفهای مدل،Warning باید بهعنوان یک سرنخ تشخیصی دیده شود، نه یک امتیاز ثابت برای سلامت فایل.
عدد Warning یک شاخص است؛ نوع، تکرار و ارتباط آن با رفتار مدل است که اهمیت واقعی آن را مشخص میکند.
روش سیستماتیک پیدا کردن علت واقعی کندی مدل Revit
پس از مشخص شدن علامت و بررسی گروههای اصلی علت، باید تشخیص را به صورت مرحلهای انجام داد. مهمترین اصل این است که در هر مرحله فقط یک دسته از عوامل تغییر کند؛ در غیر این صورت حتی اگر عملکرد مدل بهتر شود، علت واقعی همچنان نامشخص میماند.
یک مسیر ساده و قابل تکرار میتواند شامل این مراحل باشد:
- تعریف علامت
مشخص کنید کندی دقیقاً در Open، View، Edit، Save یا Synchronize دیده میشود. - ثبت وضعیت مبنا
یک یا چند عملیات مشخص را انتخاب و زمان یا رفتار آنها را ثبت کنید. - حذف یک دسته از عوامل
برای مثال Linkها را Unload کنید، یک View سادهتر بسازید یا یک گروه مشخص از عناصر را از آزمون خارج کنید. - آزمایش مجدد
همان عملیاتی را که در وضعیت مبنا اندازهگیری شده بود دوباره تکرار کنید. - محدود کردن دامنه
اگر عملکرد بهتر شد، همان دسته را با جزئیات بیشتری بررسی کنید تا عامل دقیقتر مشخص شود. - تأیید علت
پس از پیدا کردن عامل مشکوک، باید بتوان نشان داد حذف یا اصلاح آن به طور تکرارشونده عملکرد را تغییر میدهد.
اگر هم زمان Purge انجام شود، Warningها حذف شوند، Familyها تغییر کنند و Linkها نیز Unload شوند، ممکن است مدل سریعتر شود اما هنوز معلوم نیست کدام اقدام مؤثر بوده است.
تشخیص واقعی زمانی انجام شده است که بتوان رابطه میان یک عامل مشخص و تغییر عملکرد مدل را نشان داد.
راه حل باید متناسب با علت انتخاب شود
بعد از پیدا کردن عامل اصلی کندی، مرحله اصلاح باید مستقیماً بر همان علت متمرکز شود. در این نقطه استفاده از یک فهرست ثابت از اقدامات عمومی معمولاً نتیجه مطلوبی نمیدهد، چون مدلهای مختلف ممکن است به دلایل کاملاً متفاوت کند شده باشند.
اگر مشکل از هندسه بیش از حد پیچیده باشد، باید سطح جزئیات یا روش مدلسازی بازنگری شود. اگر Family خاصی بار زیادی ایجاد میکند، اصلاح ساختار همان Family منطقیتر از حذف گسترده محتواست. اگر View مشخصی کند است، بهینه سازی تنظیمات نمایش، محدوده دید یا عناصر قابل مشاهده میتواند مؤثرتر از تغییر کل مدل باشد. در مدلهای MEP نیز ممکن است لازم باشد ساختار سیستمها، Connectorها یا محاسبات مرتبط بررسی شود.
در مشکلات Worksharing یا Linkها نیز راهحل باید در همان لایه اعمال شود. کندی Synchronize با تغییر هندسه یک Family حل نمیشود، همان طور که یک View سنگین را نمیتوان صرفاً با Compact کردن فایل اصلاح کرد.
ابزارهایی مانند Purge Unused،Audit یا Compact میتوانند بخشی از نگهداری مدل باشند، اما نباید به عنوان پاسخ پیش فرض به هر نوع کندی استفاده شوند. ارزش این ابزارها زمانی مشخص میشود که بدانیم چه مشکلی را قرار است برطرف کنند.
در نهایت، اگر یک علت مشخص مرتباً در پروژههای مختلف تکرار میشود، اصلاح یک فایل کافی نیست و باید استانداردهای مدلسازی، Templateها، Familyها یا گردشکار تیم نیز بازنگری شوند.
وقتی همین الگو از یک فایل به چند پروژه منتقل میشود، مقاله بهینهسازی BIM چیست و چه زمانی یک شرکت به آن نیاز دارد؟ مرز میان اصلاح موردی و بهینهسازی فرایند سازمانی را روشن میکند.
بهینه سازی واقعی یعنی اصلاح همان چیزی که علت مشکل است؛ نه اجرای مجموعهای ثابت از اقدامات روی هر مدل کند.
جمعبندی: مدل سالم فقط مدل کمحجم نیست
در پایان، سلامت یک مدل Revit را نمیتوان فقط با حجم فایل، تعداد Warningها یا سرعت باز شدن آن سنجید. مدل سالم مدلی است که بتواند نیازهای واقعی پروژه را با سطح مناسبی از جزئیات، روابط قابل کنترل و عملکرد قابل قبول پشتیبانی کند.
ممکن است یک فایل بزرگ باشد اما ساختار آن منظم، Familyها کنترلشده، Viewها بهینه و روابط مدل منطقی باشند. در مقابل، یک فایل کوچکتر میتواند به دلیل مدلسازی بیش از حد، وابستگیهای غیرضروری، محتوای نامناسب یا گردشکار ضعیف، عملکرد بدتری داشته باشد.
نکته مهمتر این است که کندی تکرارشونده معمولاً فقط یک مشکل فنی در یک فایل نیست. اگر در پروژههای مختلف دائماً Familyهای سنگین، Importهای کنترلنشده، Viewهای نامناسب، Warningهای مشابه یا ساختارهای Worksharing ضعیف دیده میشوند، ریشه مسئله احتمالاً به استانداردهای مدلسازی، Templateها، کتابخانه محتوا، روش کنترل کیفیت یا شیوه کار تیم برمیگردد.
در چنین شرایطی، اصلاح یک فایل فقط اثر کوتاه مدت دارد. راه حل پایدار زمانی شکل میگیرد که سازمان بتواند قواعد تولید مدل، نحوه استفاده از Familyها، سطح جزئیات، ساختار Linkها و روش کنترل عملکرد را به صورت استاندارد تعریف کند.
اگر مسئله به یک گلوگاه تکرارشونده در مدل یا گردشکار تبدیل شده باشد، خدمت بهینهسازی BIM برای تشخیص علت، آزمون اصلاح و تثبیت نتیجه طراحی شده است.
هدف بهینه سازی این نیست که مدل تا حد ممکن کوچک شود؛ هدف این است که مدل با کمترین پیچیدگی غیرضروری، عملکرد قابل اتکا و متناسب با نیاز پروژه داشته باشد.