Openfast: خطأ في التجميع على PowerPC64 بسبب النوع الحقيقي غير المدعوم

هل لديك أي معلومات تكوين حول كيفية إنشاء gfortran على هذا النظام (هل يتضمن هذه العلامات: --disable-libquadmath أو --disable-libquadmath-support )؟

أم أنه من الممكن الترقية إلى gfortran 8.x؟ من بحث Google المختصر ، يبدو أن هذه كانت مشكلة في 7.x على PPC64 و PPC64el. بعض المعلومات في هذا الموضوع: https://lists.debian.org/debian-powerpc/2018/04/msg00005.html

@ andrew-platt لحسن الحظ ، فإن النظام معطل للصيانة اليوم ، لذلك سأنتظر للتحقق من إعدادات إنشاء gfortran عندما يعود إلى الاتصال بالإنترنت في اليوم التالي أو نحو ذلك.

فيما يتعلق باستخدام إصدار أحدث من GCC / gfortran ، قد يكون ذلك صعبًا نظرًا لأننا نبني بنية هجينة ونحتاج إلى التأكد من أن مترجم المضيف ومكتبات MPI وإصدارات NVIDIA CUDA تعمل بشكل جيد عند بناء جانب nalu-wind من الأشياء وللتأكد من أننا نستخدم نفس المحول البرمجي + مكدس MPI لواجهة برمجة تطبيقات OpenFAST C ++ لتجنب حالات عدم توافق المكتبة. أيضًا إذا تم إنشاء 8.x أو أعلى باستخدام --disable-libquadmath فربما نواجه نفس المشكلة. لكنني سأبحث في هذا عندما يعود النظام إلى الإنترنت.

إذا اضطررنا إلى الالتزام بمكدس دول مجلس التعاون الخليجي 7.4.0 الذي تم اختباره جيدًا والذي تم اختباره / قياسه على نطاق واسع في فترة السنتين الماليتين 2020 و الربع الثاني ، فما هو تأثير الاختراق الذي أدخلته للحصول على الأشياء التي يجب تجميعها؟ هل توجد مسارات رمز على وحدات التوربينات الأرضية التي تستخدم QuKi وتسبب مشاكل؟ بالتناوب ، ما هي أنظف طريقة لتعطيل QuKi kind في OpenFAST؟

كنت أظن أنه قد يكون هناك بعض الاعتبارات الإضافية حول تغيير المجمعين.

لا أرى أي سبب لتعطيل QuKi شأنه أن يسبب مشاكل لحالة الاستخدام الخاصة بك. ربما يجب علينا إضافة خيار DISABLE_QUAD لتكوين cmake؟ أنا قلق قليلاً من احتمال حدوث عواقب غير مقصودة على الأنظمة الأساسية الأخرى بمجرد التحقق من __GFC_REAL_16__ .

نعم ، كان __GFC_REAL_16__ خاصًا بالمترجم gfortran كنت أتعامل معه ، وربما لم يكن الطريقة الصحيحة لمعالجته. باستخدام DISABLE_QUAD سيتعين عليك تحديث جميع الواجهات التي توفر المتغيرات r16 وتطبيقاتها.

@ andrew-platt لقد قمت بتشغيل برنامج الاختبار التالي مقابل جميع إصدارات دول مجلس التعاون الخليجي المتوفرة في قمة ORNL. يبدو أن أيا من الإصدارات المتوفرة لا تدعم quadmath. إعادة تجميع دول مجلس التعاون الخليجي الخاصة بنا لن تنجح لأننا نريد استخدام Spectrum-MPI الذي يوفره النظام.

program test
INTEGER, PARAMETER :: quki = SELECTED_REAL_KIND(20, 500)

write(*,*) "SELECTED_REAL_KIND(20, 500)", quki
end program

$ for ver in 4.8.5 5.4.0 6.4.0 7.4.0 8.1.0 8.1.1 9.1.0 ; do  
    module unload gcc 2>/dev/null
    module load gcc/${ver} 2> /dev/null 
    echo "==> Using GCC version ${ver}"

    gfortran test.F90 && ./a.out
done

==> Using GCC version 4.8.5
GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-37)
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

 SELECTED_REAL_KIND(20, 500)          -2
==> Using GCC version 5.4.0
GNU Fortran (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

 SELECTED_REAL_KIND(20, 500)          -2
==> Using GCC version 6.4.0
GNU Fortran (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 SELECTED_REAL_KIND(20, 500)          -2
==> Using GCC version 7.4.0
GNU Fortran (GCC) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 SELECTED_REAL_KIND(20, 500)          -2
==> Using GCC version 8.1.0
GNU Fortran (GCC) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 SELECTED_REAL_KIND(20, 500)          -2
==> Using GCC version 8.1.1
GNU Fortran (GCC) 8.1.1 20180519
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 SELECTED_REAL_KIND(20, 500)          -2
==> Using GCC version 9.1.0
GNU Fortran (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 SELECTED_REAL_KIND(20, 500)          -2

هنا أيضًا ناتج gfortran -v

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/autofs/nccs-svm1_sw/summit/gcc/7.4.0/bin/../libexec/gcc/powerpc64le-none-linux-gnu/7.4.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: powerpc64le-none-linux-gnu
Configured with: /sw/summit/gcc/7.4.0/src/gcc-7.4.0/configure --prefix=/sw/summit/gcc/7.4.0 --build=powerpc64le-none-linux-gnu --host=powerpc64le-none-linux-gnu --target=powerpc64le-none-linux-gnu --enable-offload-targets=nvptx-none --with-cuda-driver=/sw/summit/cuda/9.2.148 --disable-multilib CFLAGS=-m64
Thread model: posix
gcc version 7.4.0 (GCC)

sayerhs شكرا على التحديث! سأبحث في أفضل طريقة لإضافته كعلم CMake. في الوقت الحالي ، أظن أن طريقتك يجب أن تعمل دون تقديم أي مشاكل رقمية.

هل كان عليك تعطيل أي واجهات لإجراءات الوحدة النمطية داخل مكتبة nwtc_library لجعلها تقوم بالتجميع؟

@ andrew-platt مع الاختراق الذي عرضته أعلاه ، لم أضطر إلى تعطيل أي واجهات لإجراءات الوحدة حتى يتم تجميعها. ومع ذلك، لم يكن هذا أول فكرتي ... وكانت أول فكرتي لتعطيل QuKi ثم فما استقاموا لكم فاستقيموا إلى #ifdef من مجموعة كاملة من الاشياء في NWTC_Library وNWTC_IO التي توفر r16 واجهات

أنا ألاحظ نفس الشيء. تم تحديد عدد معقول من إجراءات الواجهة على النحو التالي SiKi و R8Ki و QuKi . بالنسبة لأولئك الذين يمكنني ببساطة #ifndef حول إصدارات QuKi في interface .

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

أشعر بالفضول حقًا بشأن ماهية QuKi عند تعيينه أعلاه. هل هو 12 بايت؟

البرنامج التالي ينتج 16 على القمة

program test
INTEGER, PARAMETER :: quki = SELECTED_REAL_KIND(20, 120)
real(kind=quki) :: r16

write(*, *) sizeof(r16)

end program

وهذا الناتج 16 و 5 ، لذلك لا توجد مشاكل حشو غريبة تحدث

program test
INTEGER, PARAMETER :: quki = SELECTED_REAL_KIND(20, 120)
real(kind=quki) :: r16, a16(5)

write(*, *) sizeof(r16), sizeof(a16) / sizeof(r16)

end program

اختبار واحد أكثر والإخراج

program test
INTEGER, PARAMETER :: quki = SELECTED_REAL_KIND(20, 120)
INTEGER, PARAMETER :: r8ki = selected_real_kind(14, 300)
real(kind=r8ki) :: r8, a8(5)
real(kind=quki) :: r16, a16(5)

write(*, *) sizeof(r8), sizeof(a8) / sizeof(r8)
write(*, *) sizeof(r16), sizeof(a16) / sizeof(r16)

end program
                    8                    5
                   16                    5

بالمناسبة أنا أستخدم gfortran 7.4.0 في Summit.

زوجان من الأفكار:

1. يمكنك استبدال بيانات SELECTED_REAL_KIND بالأرقام 4 و 8 و 16. لا أعرف أي مترجم فورتران حديث لا يستخدم عدد البايتات في مواصفات النوع. كان هناك مترجم قديم واحد استخدم REAL (1) و REAL (2) للأرقام من 4 إلى 8 بايت ، ولكن هذا كان منذ زمن بعيد لدرجة أنه لم يعد ذا صلة. لا أعرف ما إذا كان معيار فورتران الحالي يحدد فعليًا كيف من المفترض أن يتم تعيينها الآن (تركت نسختي من معيار 2003 في NREL) ، ولكن يبدو أن المجمعين قد استقروا على الحقيقي (4) ، الحقيقي (8 ) ، وتعريفات حقيقية (16). هذا لا يساعد هؤلاء المترجمين القدامى الذين لا يدعمون الدقة الرباعية.

1. أؤيد التخلص من QuKi تمامًا ، ما لم يكن لدى شخص ما بالفعل حاجة إلى هذا النوع من الدقة. يمكنك تعيين DbKi = R8Ki بحيث يكون 8 بايت بغض النظر عن إشارات الدقة المفردة / المزدوجة ، وجعل جميع إصدارات الواجهات من SiKi و R8Ki فقط (لا ReKi إصدارات DbKi ).

أفكار؟

أنا حقًا أحب الفكرة رقم 2. لقد بدأت فرعًا حيث كنت أقوم بإزالة QuKi اختياريًا ، لكنني سأقوم بالتركيز على إزالتها تمامًا. قد يكون لدي علاقات عامة للمراجعة في غضون أيام قليلة لهذا الغرض.

في رقم 1 ، هل من المحتمل أن تكون هناك بعض بنى الرقاقة التي من شأنها أن تدعم حجم 12 بايت (أو حجم "غريب" آخر) حقيقي؟

ماذا عن استخدام real64 و real128 من ISO_FORTRAN_ENV ، هل هذا ممكن داخل OpenFAST؟

$ cat test.F90 && gfortran test.F90 && ./a.out
program test
  use, intrinsic :: iso_fortran_env , only: real32, real64, real128
  real(real32) :: r4
  real(real64) :: r8
  real(real128) :: r16

  write(*,*) real32, real64, real128
  write(*, *) precision(r4), range(r4)
  write(*, *) precision(r8), range(r8)
  write(*, *) precision(r16), range(r16)

end program

           4           8          16
           6          37
          15         307
          31         291

وأيضًا @ andrew-platt ، أشك في أن أي بنية تستخدم 12 بايتًا حقيقيًا. قد يتطلب ذلك حشوًا بخطوط ذاكرة التخزين المؤقت التي يبلغ عرضها 64 أو 128.

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

bjonkman شكرا. لقد أغفلت عن متطلبات Fortran2003 لـ OpenFAST. لقد اختبرته على أقدم إصدار مترجم متوفر على هذا الجهاز (GCC 4.8.5) وهو يتعرف على تلك الثوابت.

$ cat test.F90 && gfortran test.F90 && ./a.out && gfortran --version

program test
  use, intrinsic :: iso_fortran_env , only: real32, real64, real128
  real(real32) :: r4
  real(real64) :: r8
  real(real128) :: r16

  write(*,*) real32, real64, real128
  write(*, *) precision(r4), range(r4)
  write(*, *) precision(r8), range(r8)
  write(*, *) precision(r16), range(r16)

end program



md5-ceacddb5f317cc80bc79df5c268d21d7



           4           8          16
           6          37
          15         307
          31         291
GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-37)
Copyright (C) 2015 Free Software Foundation, Inc.

bjonkman أيضًا يبدو أننا نستخدم بالفعل بعض ميزات Fortran2008 (على سبيل المثال ، compiler_version في # 507) ، لذلك من المحتمل أن نكون آمنين؟

نعم ، لقد انتهكت ذلك عن غير قصد. لا توجد اعتراضات على استخدام معيار 2008 من نهايتي.

طالما أنك على ما يرام مع الحلول البديلة للمجمّعين الأقدم (مثل المشكلة مع compiler_version إصلاحها في https://github.com/OpenFAST/openfast/pull/454 ، وربما تم كسرها مرة أخرى في https: / /github.com/OpenFAST/openfast/pull/507) ، ليس لدي مشكلة في ذلك.

bjonkmanrafmudaf @ أندرو-بلات يرجى الاطلاع رقم 512 لمجموعة من التغييرات المقترحة أنني قد نفذت لبلدي قمة البناء. هذا يجب أن يصلح الانحدار من # 507 أيضًا.

ثابت في # 512