متن مقاله
مقدمه
وقتی سرعت کار در Revit کاهش پیدا میکند، یکی از اولین واکنشها این است که مشکل را به سختافزار نسبت دهیم؛ رم بیشتر، پردازنده سریعتر یا یک Workstation جدید. در بسیاری از پروژهها، این تصمیم حتی پیش از آن گرفته میشود که مشخص شود کندی دقیقاً در کدام بخش اتفاق میافتد و چه عاملی آن را ایجاد کرده است.
اما عملکرد ضعیف Revit همیشه به معنی ضعیف بودن سیستم نیست. پیچیدگی Familyها، جزئیات بیش از نیاز، ساختار Viewها، نحوه تقسیم مدل، Linkها، روابط میان عناصر و حتی روش Worksharing میتوانند به تدریج هزینه پردازشی مدل را افزایش دهند. در چنین شرایطی، سختافزار قویتر ممکن است سرعت کار را بهتر کند، اما علت اصلی مشکل را برطرف نمیکند.
پیش از تصمیم برای ارتقای سیستم، بهتر است ابتدا مشخص کنیم Revit دقیقاً در چه مرحلهای کند شده است و سپس ساختار مدل و فرایند کار را بررسی کنیم. هدف این مقاله ارائه یک فهرست از ترفندهای افزایش سرعت Revit نیست؛ بلکه بررسی یک مسیر تشخیصی است تا بتوان میان مشکل مدل، فرایند همکاری و محدودیت واقعی سختافزار تفاوت قائل شد.
چرا کند شدن Revit الزاماً به معنی ضعیف بودن سیستم نیست؟
وقتی یک مدل Revit به تدریج کند میشود، معمولاً اولین مظنون سختافزار است. افزایش زمان باز شدن فایل، تأخیر در جابهجایی میان Viewها، کندی هنگام انتخاب یا ویرایش عناصر و طولانی شدن عملیات Synchronize میتواند این تصور را ایجاد کند که سیستم دیگر توان پردازش پروژه را ندارد. این احتمال وجود دارد، اما نباید بدون بررسی به عنوان علت اصلی پذیرفته شود.
عملکرد Revit نتیجه تعامل چند عامل است: پیچیدگی مدل، تعداد و نوع عناصر، Familyها، روابط میان اجزا، تنظیمات Viewها، مدلهای Link شده، روش Worksharing و در نهایت توان سختافزار. بنابراین دو پروژه با حجم فایل مشابه میتوانند رفتار کاملاً متفاوتی داشته باشند و حتی یک پروژه مشخص نیز ممکن است روی یک سیستم مناسب، صرفاً به دلیل ساختار نامناسب مدل، عملکرد ضعیفی داشته باشد.
ارتقای سختافزار میتواند زمان برخی عملیات را کاهش دهد، اما اگر علت اصلی، پیچیدگی غیر ضروری مدل یا یک گردشکار نامناسب باشد، این بهبود معمولاً پایدار نیست. پروژه با ادامه مدلسازی دوباره به نقطهای میرسد که همان مشکلات ظاهر میشوند؛ فقط این بار روی سیستم قویتر.
بنابراین پیش از تصمیم برای خرید Workstation جدید، باید یک سؤال ساده پاسخ داده شود: آیا سیستم واقعاً محدود کننده است، یا مدل و نحوه استفاده از Revit منابع بیشتری از آنچه لازم است مصرف میکنند؟
برای تشخیص اینکه خود فایل و ساختار مدل بخشی از مسئله هستند، مقاله چرا مدل Revit سنگین میشود و چگونه علت واقعی آن را پیدا کنیم؟ مسیر آزمایش مرحلهای را توضیح میدهد.
اول مشخص کنیم «کند بودن» دقیقاً کجا اتفاق میافتد
گفتن اینکه «Revit کند شده است» برای شروع بررسی کافی نیست. کندی میتواند در بخشهای مختلفی از کار ظاهر شود و هرکدام علتهای متفاوتی داشته باشند. اگر محل بروز مشکل مشخص نباشد، ممکن است زمان زیادی صرف بررسی بخشهایی شود که اصلاً عامل اصلی نیستند.
برای مثال، کند بودن باز شدن فایل با کند بودن یک View خاص یک مسئله نیست. طولانی شدن Synchronize نیز الزاماً به پیچیدگی هندسی مدل مربوط نمیشود و ممکن است بیشتر به Worksharing، شبکه یا Central Model ارتباط داشته باشد. در مقابل، اگر فقط هنگام باز کردن یک نمای سه بعدی یا پلان مشخص افت عملکرد دیده میشود، بهتر است ابتدا همان View، عناصر قابل مشاهده و تنظیمات گرافیکی آن بررسی شوند.
در مرحله اول باید مشخص شود مشکل بیشتر در کدام عملیات دیده میشود:
- باز کردن یا ذخیره مدل
- جابهجایی میان Viewها
- کار در نماهای سه بعدی
- انتخاب و ویرایش عناصر
- Synchronize with Central
- باز کردن Sheetها و Scheduleها
- چاپ یا Export
- کار با مدلهای Link شده
این تفکیک کمک میکند دامنه بررسی محدود شود. اگر همه عملیات کند هستند، احتمال یک مشکل عمومی در مدل یا سختافزار بیشتر است. اما اگر فقط یک عملیات یا یک بخش مشخص مشکل دارد، معمولاً میتوان علت را هدفمندتر جستوجو کرد.
«کند بودن Revit» یک علامت است، نه تشخیص.
چرا حجم فایل به تنهایی معیار مناسبی برای سلامت مدل نیست؟
حجم فایل Revit معمولاً یکی از اولین چیزهایی است که هنگام بررسی کندی پروژه به آن توجه میشود. وقتی یک فایل به چندصد مگابایت میرسد، طبیعی است که تصور کنیم اندازه زیاد آن علت اصلی افت عملکرد است. اما حجم فایل به تنهایی اطلاعات کافی درباره سلامت یا کارایی مدل نمیدهد.
دو مدل با حجم تقریباً یکسان میتوانند رفتار کاملاً متفاوتی داشته باشند. یک مدل ممکن است شامل تعداد زیادی عنصر ساده باشد و همچنان عملکرد قابل قبولی داشته باشد، در حالی که مدل دیگری با حجم مشابه به دلیل Familyهای پیچیده، روابط زیاد میان عناصر، Viewهای سنگین یا Linkهای متعدد کندتر عمل کند.
همچنین افزایش حجم فایل همیشه به معنی وجود مشکل نیست. با پیشرفت طبیعی پروژه، اضافه شدن اطلاعات، جزئیات و مدارک باعث بزرگتر شدن فایل میشود. مسئله زمانی جدیتر است که افزایش حجم همراه با افت محسوس عملکرد، افزایش زمان باز شدن یا ذخیره فایل و دشوار شدن عملیات روزمره باشد.
بنابراین بهتر است حجم فایل به عنوان یک نشانه برای بررسی بیشتر دیده شود، نه یک معیار قطعی برای تصمیمگیری.
آنچه اهمیت بیشتری دارد این است که بدانیم این حجم از چه چیزی تشکیل شده و Revit برای پردازش آن چه میزان محاسبه انجام میدهد.
فایل بزرگ الزاماً مدل ناسالم نیست؛ همانطور که فایل کوچک نیز الزاماً مدل بهینه نیست.
آیا Familyهای پروژه بیش از حد سنگین یا پیچیده شدهاند؟
Familyها یکی از رایجترین منابع پیچیدگی در مدل Revit هستند، اما صرفاً بزرگ بودن فایل یک Family به معنی مشکل ساز بودن آن نیست. مسئله اصلی این است که هر Family چه مقدار هندسه، رابطه و محاسبه را وارد مدل میکند و چند بار در پروژه تکرار شده است.
Familyهایی که از منابع خارجی دریافت میشوند، به خصوص محتوای تولیدکنندگان، ممکن است جزئیاتی داشته باشند که برای مدل BIM پروژه ضروری نیستند. هندسه بسیار ریز، nested Familyهای متعدد، Arrayها، Voidهای زیاد، فرمولهای پیچیده یا Importهای CAD میتوانند هزینه پردازشی هر Instance را افزایش دهند. وقتی چنین Familyای صدها یا هزاران بار در پروژه استفاده شود، اثر آن دیگر محدود به یک عنصر نیست.
در بررسی Familyها بهتر است چند سؤال مطرح شود:
- آیا سطح جزئیات با نیاز واقعی پروژه متناسب است؟
- آیا هندسهای وجود دارد که در خروجیهای پروژه استفاده نمیشود؟
- آیا میتوان بخشی از جزئیات را با Symbolic Line یا نمایش سادهتر جایگزین کرد؟
- آیا nested Familyها و پارامترها واقعاً برای عملکرد عنصر لازماند؟
- آیا یک Family پیچیده در تعداد بسیار زیادی Instance استفاده شده است؟
هدف حذف جزئیات به هر قیمت نیست. Family باید اطلاعات و هندسه لازم برای طراحی، هماهنگی و تولید مدارک را داشته باشد، اما پیچیدگیای که هیچ خروجی مشخصی ایجاد نمیکند، تنها بار اضافی به مدل تحمیل میکند.
Family مناسب،Family پرجزئیات نیست؛ Family متناسب با نیاز پروژه است.
آیا مدل بیش از آنچه پروژه نیاز دارد پیچیده شده است؟
یکی از دلایل رایج افت عملکرد در Revit این است که مدل به تدریج جزئیاتی را در خود جمع میکند که برای هدف واقعی پروژه ضروری نیستند. این اتفاق معمولاً از یک تصمیم بزرگ ناشی نمیشود؛ بلکه نتیجه مجموعهای از انتخابهای کوچک در طول زمان است: مدلکردن اجزای بسیار ریز، استفاده از روشهای پیچیده برای عناصر ساده، اضافه کردن جزئیات هندسی که فقط در یک خروجی محدود دیده میشوند یا افزایش سطح مدلسازی بدون ارتباط روشن با نیاز پروژه.
پیچیدگی زمانی مسئلهساز میشود که Revit مجبور باشد تعداد زیادی عنصر، اتصال، Join، Sketch یا هندسه را مرتباً بازسازی و کنترل کند، در حالی که بخشی از این اطلاعات هیچ نقشی در هماهنگی، متره، مستندسازی یا تصمیمگیری پروژه ندارند.
در این مرحله باید پرسید:
- آیا این جزئیات در خروجی مشخصی استفاده میشوند؟
- آیا برای هماهنگی بین رشتهای ضروریاند؟
- آیا میتوان بخشی از اطلاعات را به شکل سادهتری نمایش داد؟
- آیا سطح مدلسازی با مرحله فعلی پروژه متناسب است؟
- آیا پیچیدگی هندسی واقعاً ارزش اطلاعاتی ایجاد میکند؟
هدف، سادهسازی کورکورانه مدل نیست. برخی پروژهها ذاتاً به هندسه و اطلاعات پیچیده نیاز دارند. مسئله این است که هر میزان پیچیدگی باید دلیل مشخصی داشته باشد.
اگر یک عنصر فقط به این دلیل با جزئیات بالا مدل شده که «امکان مدل کردنش وجود داشته»، احتمالاً باید دوباره ضرورت آن بررسی شود.
مدل بهینه کم جزئیات نیست؛ بهاندازه نیاز پروژه جزئیات دارد.
آیا Viewها و ساختار تولید مدارک باعث کندی شدهاند؟
گاهی خود مدل سه بعدی مشکل اصلی نیست و افت عملکرد بیشتر در Viewها و فرایند تولید مدارک دیده میشود. یک پروژه ممکن است در نمای ساده عملکرد مناسبی داشته باشد، اما باز کردن بعضی پلانها، مقاطع، Sheetها یا نماهای سه بعدی زمان زیادی بگیرد. در این حالت باید بار گرافیکی و اطلاعاتی همان Viewها بررسی شود.
تنظیماتی مانند Detail Level بالا، نمایش تعداد زیادی Category، Filterهای متعدد، Transparency، Shadow، Section Boxهای بزرگ یا نمایش هم زمان چند Link میتوانند پردازش یک View را سنگین کنند. در پروژههای بزرگ، Viewهایی که برای کار روزمره ساخته شدهاند نیز ممکن است به تدریج به محل تجمع Annotationها، Detail Componentها، Tagها و اطلاعات اضافی تبدیل شوند.
ساختار تولید مدارک نیز اهمیت دارد. تعداد زیاد Viewهای تکراری، Scheduleهای پیچیده، DWGهای وارد شده برای تکمیل نقشهها و Detailهای سنگین میتوانند باعث شوند بخشی از پروژه کندتر از خود مدل اصلی عمل کند.
برای تشخیص بهتر، مقایسه سادهای مفید است: اگر مدل در یک View سبک عملکرد مناسبی دارد اما در چند View مشخص کند میشود، احتمالاً باید ابتدا همان Viewها و محتوای قابل نمایش آنها بررسی شوند، نه اینکه مستقیماً سختافزار مقصر شناخته شود.
گاهی آنچه کند شده مدل نیست؛ نحوه نمایش و مستندسازی مدل است.
ساختار مدلها و Linkها چگونه بر عملکرد Revit اثر میگذارد؟
در پروژههای بزرگ، کندی Revit همیشه از داخل یک فایل منفرد ناشی نمیشود. گاهی مسئله اصلی در نحوه تقسیم پروژه میان مدلهای مختلف و شیوه استفاده از Linkهاست. اگر ساختار مدلها بدون توجه به نیاز واقعی تیمها شکل گرفته باشد، هر کاربر ممکن است مجبور شود اطلاعاتی را بارگذاری و پردازش کند که برای کار او ضروری نیست.
برای مثال، یک مدل معماری ممکن است هم زمان چند مدل سازه، تأسیسات، سایت و مدلهای کمکی را Link کرده باشد؛ در حالی که همه این اطلاعات در تمام Viewها و برای همه کاربران موردنیاز نیستند. Nested Linkها، مدلهای بسیار بزرگ، CADهای Link یا Import شده و تقسیم بندی نامناسب پروژه نیز میتوانند این وضعیت را پیچیدهتر کنند.
نکته مهم این است که تعداد Linkها به تنهایی معیار خوبی نیست. چند مدل کوچک و منطقی ممکن است بهتر از یک مدل بسیار بزرگ عمل کنند، اما اگر ساختار Linkها پیچیده، تودرتو یا بدون کنترل باشد، همین تقسیم بندی نیز میتواند مشکل ساز شود.
در بررسی این بخش باید پرسید:
- آیا تقسیم پروژه میان مدلها با ساختار واقعی تیمها و رشتهها هماهنگ است؟
- آیا همه Linkها برای همه کاربران لازماند؟
- آیا Linkهای تودرتو یا تکراری وجود دارند؟
- آیا مدلهایی بارگذاری میشوند که فقط در بخش محدودی از پروژه موردنیازند؟
- آیا فایلهای CAD یا دادههای خارجی بدون کنترل وارد ساختار پروژه شدهاند؟
مسئله فقط تعداد Linkها نیست؛ معماری ارتباط میان مدلهاست که اهمیت دارد.
آیا روابط و وابستگیهای داخل مدل بیش از حد پیچیده شدهاند؟
Revit فقط هندسه را نمایش نمیدهد؛ بخش زیادی از رفتار مدل به روابط میان عناصر وابسته است. Constraintها، Joinها، عناصر Host شده، Groupها، Arrayها، Sketchهای پیچیده و وابستگیهای پارامتریک باعث میشوند نرمافزار هنگام هر تغییر بخشی از مدل را دوباره بررسی و بازسازی کند. هرچه این روابط بیشتر و پیچیدهتر شوند، هزینه پردازشی مدل نیز میتواند افزایش پیدا کند.
در پروژههای بزرگ، این پیچیدگی معمولاً به صورت تدریجی شکل میگیرد. برای مثال، Joinهای متعدد میان عناصر، Constraintهایی که دیگر ضرورت ندارند یا Groupهایی که بارها و با تغییرات متفاوت استفاده شدهاند، ممکن است بدون آنکه مستقیماً دیده شوند، رفتار مدل را سنگینتر کنند.
Warningها نیز در این مرحله میتوانند سرنخ مفیدی باشند، اما تعداد Warning به تنهایی معیار مناسبی برای سنجش سلامت یا سرعت مدل نیست. برخی Warningها تأثیر محدودی دارند، در حالی که بعضی دیگر میتوانند نشان دهنده روابط پیچیده، عناصر تکراری یا مشکلات ساختاری در مدل باشند.
بنابراین بهتر است به جای تلاش برای رساندن تعداد Warningها به صفر، الگوی آنها بررسی شود: چه نوع خطاهایی مرتب تکرار میشوند و آیا به یک روش مدلسازی مشخص مربوط هستند؟
هر رابطهای که در مدل ایجاد میشود، باید دلیل مشخصی داشته باشد؛ وابستگیهای غیر ضروری میتوانند به تدریج هزینه نگهداری و پردازش مدل را افزایش دهند.
آیا مشکل از مدل است یا از Worksharing و زیرساخت همکاری؟
وقتی چند نفر به صورت هم زمان روی یک پروژه کار میکنند، هر افت عملکردی را نباید مستقیماً به خود مدل نسبت داد. در محیط Worksharing، سرعت کار به وضعیت Central Model، فایلهای Local، شبکه و نحوه Synchronize کاربران نیز وابسته است.
برای مثال، اگر باز کردن Viewها و ویرایش عناصر روی سیستم کاربر روان است اما Synchronize زمان زیادی میبرد، احتمال دارد مسئله بیشتر به ارتباط با Central Model یا زیرساخت شبکه مربوط باشد تا پیچیدگی هندسی پروژه. در مقابل، اگر مدل حتی در حالت جدا از Central نیز کند عمل میکند، باید بیشتر روی ساختار و محتوای خود فایل تمرکز کرد.
چند نشانه میتواند به تفکیک این دو وضعیت کمک کند:
- آیا همه کاربران در Synchronize مشکل دارند یا فقط یک نفر؟
- آیا کندی در ساعات خاصی بیشتر میشود؟
- آیا Local Fileها بهدرستی ساخته و بهروزرسانی میشوند؟
- آیا مسیر دسترسی به Central Model پایدار و سریع است؟
- آیا مدل از طریق VPN، شبکه داخلی یا یک محیط Cloud Collaboration استفاده میشود؟
- آیا کاربران حجم زیادی از تغییرات را برای مدت طولانی بدون Synchronize نگه میدارند؟
در چنین شرایطی، ارتقای Workstation ممکن است تأثیر بسیار محدودی داشته باشد؛ زیرا گلوگاه در جایی خارج از پردازنده و حافظه سیستم قرار دارد.
اگر کندی عمدتاً هنگام همکاری و تبادل اطلاعات رخ میدهد، باید زیرساخت Worksharing را نیز بهاندازه خود مدل جدی گرفت.
چگونه بفهمیم مشکل از مدل است یا واقعاً از سختافزار؟
پس از بررسی ساختار مدل، Viewها، Familyها، Linkها و Worksharing، باید بتوانیم مشخص کنیم آیا سختافزار واقعاً به گلوگاه تبدیل شده است یا خیر. بهترین روش، مقایسه رفتار Revit در شرایط مختلف است، نه تکیه بر یک نشانه منفرد.
برای مثال، اگر یک پروژه روی چند سیستم مختلف کند است، احتمال وجود مشکل در مدل یا گردشکار بیشتر میشود. اگر همان پروژه روی سیستمهای دیگر عملکرد مناسبی دارد اما روی یک Workstation خاص کند است، سختافزار یا تنظیمات آن سیستم باید جدیتر بررسی شود.
چند مقایسه ساده میتواند جهت بررسی را روشن کند:
- اگر فقط یک View کند است، ابتدا همان View را بررسی کنید.
- اگر فقط یک پروژه کند است، ساختار همان مدل مظنون اصلی است.
- اگر همه پروژهها روی یک سیستم کند هستند، محدودیت سختافزار محتملتر است.
- اگر Synchronize برای همه کاربران کند است، شبکه یا زیرساخت همکاری باید بررسی شود.
- اگر عملکرد پروژه به تدریج در طول زمان افت کرده، رشد پیچیدگی مدل یا گردشکار محتمل است.
- اگر مدل روی سیستم قویتر نیز همچنان مشکل دارد، ارتقای سختافزار به تنهایی راهحل مناسبی نیست.
در کنار این مقایسهها، بررسی مصرف CPU، RAM و سایر منابع سیستم نیز میتواند مفید باشد؛ اما اعداد سختافزاری باید در کنار رفتار واقعی پروژه تفسیر شوند.
اگر قرار است اثر هر اصلاح با وضعیت قبل مقایسه شود، مقاله چگونه میتوان اثر بهینهسازی BIM را در زمان، خطا و کیفیت تحویل اندازهگیری کرد؟ روش تعریف خط مبنا و شاخصهای قابل مقایسه را توضیح میدهد.
هدف این نیست که ثابت کنیم مشکل از مدل است یا از سیستم؛ هدف این است که پیش از هزینه کردن، گلوگاه واقعی را پیدا کنیم.
چه زمانی ارتقای سیستم واقعاً توجیه دارد؟
بررسی مدل و فرایند کار به این معنی نیست که سختافزار اهمیت ندارد. Revit برای برخی عملیات به توان پردازشی، حافظه کافی و ذخیرهسازی سریع نیاز دارد و در پروژههای بزرگ یا پیچیده ممکن است سیستم فعلی واقعاً به محدودیت برسد.
ارتقای سختافزار زمانی منطقیتر است که پس از بررسی مدل، نشانههای مشخصی از کمبود منابع دیده شود. برای مثال، اگر چند پروژه سالم و با ساختار متفاوت روی یک سیستم عملکرد ضعیفی دارند، یا هنگام کار معمولی مصرف RAM به طور مداوم به سقف نزدیک میشود، باید محدودیت Workstation را جدی گرفت.
همچنین تغییر نوع پروژه میتواند نیاز سختافزاری را افزایش دهد. کار با مدلهای بزرگتر، Point Cloud، چند نرمافزار به صورت هم زمان، هماهنگی مدلهای متعدد یا خروجیهای سنگین ممکن است نیازمند سیستمی باشد که از ابتدا برای چنین بار کاری طراحی شده باشد.
اما تصمیم برای ارتقا بهتر است بر اساس یک الگوی قابل اندازه گیری گرفته شود، نه صرفاً احساس کندی. مقایسه همان مدل روی سیستمهای مختلف، بررسی مصرف منابع و ارزیابی نوع فعالیتهایی که بیشترین افت عملکرد را دارند، تصویر دقیقتری ارائه میدهد.
نکته اصلی این است که سختافزار مناسب باید پاسخگوی بار کاری واقعی باشد، نه اینکه ضعف در ساختار مدل یا گردشکار را پنهان کند.
هدف بهینه سازی، حذف نیاز به سختافزار مناسب نیست؛ هدف این است که سختافزار برای حل مسئله درست خریداری شود.
وقتی مشکل در چند پروژه تکرار میشود، باید فرایند BIM را بررسی کرد
اگر کندی Revit فقط در یک پروژه دیده شود، احتمالاً باید همان مدل، محتوا و شرایط خاص آن بررسی شود. اما وقتی الگوی مشابهی در چند پروژه تکرار میشود، مسئله دیگر صرفاً یک فایل سنگین نیست و باید به سطح فرایندهای BIM در سازمان نگاه کرد.
در این نقطه، مقاله بهینهسازی BIM چیست و چه زمانی یک شرکت به آن نیاز دارد؟ کمک میکند مشخص شود مشکل از یک فایل منفرد عبور کرده و به ضعف تکرارشونده در فرایند سازمان رسیده است.
برای مثال، اگر در پروژههای مختلف Familyهای بیش از حد پیچیده استفاده میشوند، مدلها بدون منطق مشخص تقسیم میشوند، Viewهای متعدد و تکراری ساخته میشوند یا استاندارد روشنی برای استفاده ا ز Linkها وجود ندارد، طبیعی است که مشکلات مشابه دوباره ظاهر شوند. در این شرایط، اصلاح هر پروژه به صورت جداگانه تنها بخشی از مسئله را حل میکند.
ریشه مشکل ممکن است در مواردی مانند این باشد:
- نبود استاندارد مشخص برای ساخت و تأیید Familyها
- تعریف نشدن سطح مناسب مدلسازی برای مراحل مختلف پروژه
- نبود قواعد مشخص برای تقسیم مدل و مدیریت Linkها
- Templateهایی که بدون کنترل در طول زمان پیچیده شدهاند
- نبود فرایند منظم برای بررسی سلامت مدل
- روشهای متفاوت و ناسازگار میان اعضای تیم
وقتی این الگوها تکرار میشوند، بهینه سازی نباید فقط به حذف چند عنصر یا سبک کردن یک فایل محدود شود. باید مشخص شود چه تصمیمها و روشهایی باعث شدهاند مدلها در طول پروژه به همان نقطه برسند.
اگر چند پروژه به شکل مشابه کند میشوند، احتمال دارد مشکل اصلی در خود مدلها نباشد؛ بلکه در روشی باشد که سازمان مدلها را تولید و مدیریت میکند.
جمعبندی: قبل از خرید سختافزار، مسئله را اندازهگیری کنید
کند شدن Revit میتواند دلایل مختلفی داشته باشد و سختافزار فقط یکی از آنهاست. گاهی مشکل از Familyهای پیچیده یا Viewهای سنگین است، گاهی از ساختار Linkها و روابط داخل مدل و در بعضی پروژهها نیز Worksharing یا زیرساخت همکاری گلوگاه اصلی را ایجاد میکند.
به همین دلیل، تصمیم برای ارتقای سیستم بهتر است آخرین مرحله تشخیص باشد، نه اولین واکنش. پیش از خرید Workstation جدید باید مشخص شود کندی دقیقاً در چه عملیاتی دیده میشود، آیا مشکل در یک View یا یک پروژه محدود است، آیا کاربران دیگر نیز همان رفتار را تجربه میکنند و آیا نشانهای از محدودیت واقعی منابع سیستم وجود دارد.
یک مسیر منطقی برای بررسی میتواند این ترتیب را داشته باشد:
- محل دقیق بروز کندی را مشخص کنید.
- ساختار مدل، Familyها، Viewها و Linkها را بررسی کنید.
- وضعیت Worksharing و زیرساخت همکاری را جداگانه ارزیابی کنید.
- رفتار همان پروژه را روی سیستمها یا شرایط مختلف مقایسه کنید.
- سپس مصرف منابع سختافزاری را بررسی و درباره ارتقا تصمیم بگیرید.
در بعضی پروژهها نتیجه این بررسی واقعاً خرید سیستم قویتر خواهد بود. در بعضی دیگر، اصلاح مدل یا گردشکار تأثیر بیشتری دارد. مهم این است که تصمیم بر اساس علت واقعی گرفته شود.
اگر گلوگاه در مدل، مستندسازی یا گردشکار باشد، خدمت بهینهسازی BIM مسیر تشخیص، آزمون اصلاح و سنجش نتیجه در پروژه واقعی را توضیح میدهد.
قبل از افزایش توان سختافزار، باید بدانیم این توان قرار است کدام گلوگاه را برطرف کند.