وكيلك كبير جدًا - مشكلة الذاكرة

حتى هذا التاريخ مع AnyLogic 8.3، هناك خلل برمجي لا يسمح لك بإنشاء وكيل يحتوي على عناصر كثيرة جدًا. الخطأ ناتج عن آلية توليد الكود التي تنشئ مُنشئ عرض كبير لـ Main، مما ينتهك حد JAVA على حجم الطريقة. الخطأ الذي يعرضه AnyLogic هو “The code of method doCreate() is exceeding the 65535 bytes limit”.

إذا فتحت وكيل Main بمحرر JAVA، سترى شيئًا مثل الشكل 1.

الشكل 1 - طريقة doCreate()

في الأساس، يمكن أن تكون هناك مئات المتغيرات المضمنة داخل هذه الطريقة، وإذا تجاوزت سلسلة المتغيرات 65535 بايت، فأنت في مشكلة. ولست في مشكلة فقط لأن الاستمرار في بناء النموذج يصبح مستحيلاً، بل أيضًا لأن إجراء تغييرات على النموذج عندما تكون قريبًا من حد 65535 بايت يصبح بطيئًا ومملاً، حتى عندما يكون لديك حاسوب رائع. لا يستطيع AnyLogic التعامل مع هذا بشكل صحيح.

دراسة الحالة التجارية

في دراسة الحالة هذه، تحتاج عدة آلات إلى اتباع بعض المسارات بترتيب دقيق جدًا للقيام ببعض العمل في مناطق مختلفة. يُظهر الشكل 2 جزءًا من العرض في main حيث كان عدد المسارات والعقد والمناطق مرتفعًا جدًا. يمكن رؤية ذلك بسهولة في الشكل.

الشكل 2 - العرض مع العديد من عناصر الترميز المكاني

هذا مجرد جزء صغير من النموذج، لكن يمكنك بالفعل رؤية كمية مسارات مضحكة!!!! لا أعرف ما هي دراسات الحالة الأخرى التي يمكن أن تمتلكها والتي ينتهي بك فيها الأمر بهذا العدد من الأشياء في وكيل. قد يكون وضعًا نادرًا، لكنه يمكن أن يحدث.

الحل

هناك حلان لهذه المشكلة.

الحل الأول هو تقليل حجم أسماء المتغيرات (مثلاً تغيير path1503 إلى p1503). يمكنك توفير بضعة بايتات بفعل ذلك، لكن حفظ المشروع أو إجراء تغييرات أو تحريك الأشياء سيكون بطيئًا جدًا، وأيضًا قد يكون لديك الكثير من المتغيرات بحيث أن تقليل الحجم قد لا يكون كافيًا لك. ومع ذلك قد يساعدك الحل في المضي قدمًا ومواصلة تطوير النموذج.

الحل الثاني، وهو أكثر أناقة وفائدة ولكن أصعب بكثير، هو فصل نموذجك إلى عدة وكلاء. كما ترى في الشكل 2، جميع المسارات تنتمي إلى منطقة لها لون معين، لذلك ما كان يجب فعله هو إعادة هيكلة النموذج وإنشاء وكيل جديد يحتوي على المسارات المرتبطة بمنطقة ذات لون معين.

لذلك مجموعة الوكلاء هذه التي تتناسب مع نسخة PLE من AnyLogic (الشكل 3)

الشكل 3 - الوكلاء المستخدمون في النموذج الأصلي

تحولت إلى هذا، الذي يمكن إنشاؤه فقط في إصدارات Pro أو University، حيث أن PLE محدود بـ 10 وكلاء.

الشكل 4 - الوكلاء المستخدمون في النموذج النهائي

والمنطقة البنفسجية المليئة بالعقد في الشكل 2 تصبح مجموعة منفردة من المسارات في أحد الوكلاء الجدد. لا يزال هناك الكثير من المسارات، لكن لا شيء إشكالي.

الشكل 5 - المسارات والعقد والعقد المستطيلة تم نقلها إلى وكيل جديد

الآن لنتذكر أنه لكي ينتقل وكيل من عقدة إلى أخرى، يجب أن تنتمي كلتا العقدتين إلى نفس الشبكة، وفصل الشبكات في وكلاء مختلفين سيولّد عددًا من الشبكات بقدر عدد الوكلاء. لذلك نحتاج إلى بناء استراتيجية في نموذج الأحداث المنفصلة أو النموذج القائم على الوكلاء باستخدام دالة jumpTo عندما يحين وقت الانتقال من عقدة وكيل إلى عقدة وكيل آخر. دالة jumpTo متاحة أيضًا في كتلة moveTo من مكتبة نمذجة العمليات باستخدام خيار “is placed (jumps) to”. لذلك يمكن للكيان المتحرك استخدام moveTo عندما تكون نفس الشبكة ولكن يجب استخدام jumpTo عندما تكون شبكة مختلفة.

الخلاصة

إذا واجهت هذه المشكلة، ستكون حالتك بالطبع مختلفة تمامًا، لكن إذا كان لديك وكيل يحتوي على عناصر كثيرة جدًا وبناء نموذجك يصبح بطيئًا جدًا، فمن الأفضل دائمًا فصل الوكيل الإشكالي إلى وكلاء أصغر وأسهل في الإدارة. تخطط AnyLogic لإصلاح هذا الخلل في الإصدار 8.4، لكن هل سيفعلون؟ سنرى ذلك في المستقبل، لكن في الوقت الحالي، هذا هو الحل البديل الذي يمكننا استخدامه وهو أيضًا على الأرجح أفضل ممارسة للاستخدام، حتى لو تم حل الخلل.