Openfast: إكمال OpenFAST باستخدام Simulink في الخطأ VS # 11023 و LNK2019

لم يعثر Visual studio على مكتبة Matlab التي تحتوي على MEXPRINTF . قد تحتاج إلى إخبار الاستوديو المرئي بمكان ذلك.

لم يعثر Visual studio على مكتبة Matlab التي تحتوي على MEXPRINTF . قد تحتاج إلى إخبار الاستوديو المرئي بمكان ذلك.

إذا كنت تتحدث عن مسار MATLAB داخل الخصائص فقد قمت بتغييره إلى مسار MATLAB الخاص بي كما ذكرت. إذا لم يكن الأمر كذلك ، فكيف يمكنني تغييره؟

بالنظر إلى لقطة الشاشة الأولى للإخراج ، لم تجد MEXPRINTF أثناء تجميع openfast_x64.exe . لست متأكدًا من أن VS يجب أن تبني ذلك أثناء بناء Release_Matlab. bjonkman ، هل نقوم عادةً ببناء openfsat_x64.exe مع هذا؟ كنت أعتقد أن جميع معالجات ما قبل المعالج ستجعل هذا الملف القابل للتنفيذ عديم الفائدة.

يبدو أنه عثر على المكتبة المناسبة لبناء OpenFAST-Simulink_x64.lib . لذلك أتوقع أن يعمل المرء مع simulink.

@ klitz06 ، أي فرع تقوم

لقد استخدمت "git clone https://github.com/openfast/openfast.git " لاستنساخ المستودع. أنا لا أعرف أي واحد هو. كيف أتحقق منه؟

يحرر:
git branch --show-current في بوابة windows يخبرني أنه "رئيسي".

سيظهر git branch الفروع المتاحة. سيظهر main و dev كخيارين ، وسيتم تمييز الخيار الذي قمت بإنشائه (أو يكون بجواره نجمة). أعتقد أن main هو الخيار الافتراضي.

نعم إنه main واحد.

ماذا يحدث إذا جربت البرنامج النصي create_FAST_SFunc.m (بعد تعيين أي مسارات ضرورية كما هو مذكور في البرنامج النصي)؟ يجب أن تحتاج فقط إلى OpenFAST-Simulink_x64.lib للارتباط بـ Simulink ، وليس openfast_x64.exe .

يمكن تجاهل التحذيرات الأخرى بأمان (نتبع في الغالب معيار Fortran 2008 ، لكننا نعيّن فقط VS لفرض معيار Fortran 2003 ، لذلك فهو يضع علامة على الأشياء التي ليست في الواقع مشكلة).

أعتقد أنه تم إنشاؤه بنجاح. سأجرب الأمثلة وأعود.

حسنًا ، حاولت تشغيل Ren_Test01_SIG.m وهذه هي النتيجة:

لقد غيرت VSContrl = 4 ومعرفة ما إذا كان يساعد في إضافة LSSGagVxa إلى مخرجات ElastoDyn. لم يساعد.

قد تضطر إلى إضافة موقع SFunc إلى مسار matlab. addpath(genpath(('../../../install')) من دليل الأمثلة.

أنا آسف لأنني لم أستطع فهم ما تريد مني أن أفعله. هل أقوم بتشغيله فقط من خلال نافذة الأوامر؟

نعم فعلا. كنت أفكر في نافذة الأوامر. لكن الخطأ قد يشير إلى وجود مشكلة في الاختبار نفسه.

هل قمت بتهيئة الوحدة الفرعية r-test بعد الاستنساخ من جيثب؟ git submodule update --init --recursive كما هو موضح هنا: https://openfast.readthedocs.io/en/dev/source/testing/index.html

نعم لقد قمت بالفعل بتشغيل git clone --recursive https://github.com/openfast/openfast.git في بداية العملية هل يمكن أن تكون المشكلة؟ هل يجب أن أستخدم الأمر الذي أعطيته؟

هل <openfast git rootdir>/reg_tests/r-test/glue-codes/openfast/AWT_YFix_WSt/ موجود؟

نعم إنه موجود. أستطيع أن أرى ملفات الإدخال في المجلد.

لست متأكدا بعد ذلك. أنا في حيرة من أجل الأفكار. ربما يمكن لشخص آخر التعليق على ما واجهوه بهذا.

شكرا لك على مساعدتك. يمكن أن يكون من تثبيت MATLAB الخاص بي؟ لأنني لم أقم بتثبيت كل ما يأتي مع MATLAB.

تحرير: تم تثبيت Ofcourse Simulink.

لذلك بعد بعض الاختبارات ، يمكنني إعادة إنتاج الخطأ الذي تراه باستخدام MATLAB 2020b مع simulink على نظام التشغيل windows 10 VM. كان هذا باستخدام فرع OpenFAST main .

لقد نسيت أن أذكر أنه كان هناك خطأ # 641 لهذه المشكلة. تم تقديم وصف الخطأ في # 632. تم دمج هذا الإصلاح في الفرع dev ، لكن لم يتم تحويله إلى الفرع الرئيسي بعد. اعتذاري لعدم تذكر هذا في وقت سابق.

فهل يمكنك تجربة git checkout dev ثم git submodule update ، ثم إعادة البناء والمحاولة مرة أخرى؟

الآن يتم تشغيل OpenFAST عبر MATLAB ولكن لدي الآن هذا الخطأ:

تحرير: لم أقم بإعادة التحويل البرمجي من خلال VS بعد التبديل إلى فرع dev. سأحاول الآن.

بعد تحميل فرع ديف من تجميع الصفر اكتمل دون خطأ. توجد نفس التحذيرات ويعمل مثال MATLAB Test01. واحد آخر لم يعمل بسبب عدم وجود DISCON.dll.

أنا أستخدم NREL 5MW كقاعدتي (البرج والكنسة متماثلان) ويعمل بشكل جيد مع conda في WSL. عندما أرغب في محاولة تشغيل WT المصمم الخاص بي من خلال MATLAB باستخدام Run_OpenLoop.m أواجه بعض المشكلات أولاً:

ثم قمت بتغيير TwrShadow من True إلى 1 ، لقد تجاوزت هذا الخطأ على الرغم من أن هذا قد يتسبب في حدوث مشكلات في الخطوات التالية. بعد ذلك أحصل على الخطأ أدناه:

وأنا عالق هنا. هل هذا متعلق بملفات الإدخال الخاصة بي؟ لأنني تمكنت من تشغيل AWT_YFix_WSt خلال Run_OpenLoop.m . السبب في رغبتي في استخدام MATLAB هو أنني سأصمم وحدة تحكم في الملعب وإلا سأستخدم OpenFAST مع conda في WSL.

نعم فعلا. حدث تغيير في ملف الإدخال بين الإصدار 2.5.0 والفرع dev (أضفنا نموذج ظل برج آخر). تستخدم conda + WSL الإصدار 2.5.0 ، ولكن نسختك المجمعة موجودة في الفرع dev . يمكنك عمل git checkout main; git submodule update وإعادة تجميع نسختك المحلية للحصول على الإصدار v2.5.0 ، ولكن كما أذكر من المحادثة أعلاه ، لن تحصل على الخطأ في معالجة الأخطاء الموجودة في dev فرع dev وتحديث ملفات الإدخال الضرورية.

تمت الإشارة إلى تغيير ملف الإدخال هذا في الجدول الثاني المعدل في مطور OpenFAST الموجود هنا https://openfast.readthedocs.io/en/dev/source/user/api_change.html

لدي سؤالان آخران. هل هناك حالات اختبار يتم فيها التحكم في زاوية الميل من خلال المحاكاة؟ ووصف الحالات؟

عزيزي @ klitz06 ،

لا توجد أمثلة Simulink من هذا القبيل في OpenFAST repo ، ولكن قد تجد إصدار Simulink لوحدة تحكم ROSCO ذات الأهمية: https://github.com/NREL/ROSCO_toolbox.

تحياتي الحارة،

شكرا لك.

مرحبا بالجميع،

لقد تلقيت خطأ أثناء محاولة AeroDyn قراءة TwrShadow ، على الرغم من ضبط مفتاح ظل البرج على 0.

أي شخص على دراية بهذا الخطأ؟
تحياتي الحارة.

عزيزي LaurenceWETI ،

كما هو الحال مع أي مشكلة في معالجة ملف الإدخال ، أوصي بتمكين خيار Echo لتصحيح الأخطاء. هل ترى أي مشاكل في ملف الإدخال عند مقارنته بملف Echo المقابل؟

هل وضع TwrShadow = FALSE يحل المشكلة؟

تحياتي الحارة،

تضمين التغريدة

يستخدم الإصدار 2.5.0 الذي تقوم بتشغيله علامة منطقية للإدخال TwrShadow . كما اقترح jjonkman ، يجب أن يكون هذا إما True أو False

يستخدم الإصدار dev مفتاحًا بقيم 0,1,2 مع إضافة نموذج ظل برج ثانٍ.

عزيزي jjonkman و @ andrew-platt ،

شكرا لردك السريع.
أدى تعيين TwrShadow إلى True أو Flase إلى حل المشكلة في AeroDyn ، ولكن الآن يواجه ServoDyn مشكلة في قراءة CompNTMD . لم أتمكن من العثور على هذه المعلمة في ملف الإدخال الخاص بـ ErvoDyn.

هل لديك أي فكرة عن كيفية حل هذا الخطأ؟
هل توجد أي تعليمات حول كيفية التبديل إلى الإصدار dev لاستخدام مفتاح ظل البرج مرة أخرى؟

تحياتي الحارة،

نعم ، لقد قاموا بتغيير هذا الجزء في ملفات servodyn في فرع dev. ألقِ نظرة هنا على الفرع الرئيسي لرابط NREL 5mw في قسم TUNED MASS DAMPER بالملف.