كيف يمكنك استخدام بيانات Fortran 90 وحدة

Question

دعنا نقول أن لديك وحدة فورتران 90 تحتوي على الكثير من المتغيرات والوظائف والتحولات الفرعية. في الخاص بك USE بيان، ما هي الاتفاقية التي تتبعها:

1. تعلن صراحة التي المتغيرات / الوظائف / الفرعية التي تستخدمها مع , only : بناء جملة، مثل USE [module_name], only : variable1, variable2, ...?
2. إدراج بطانية USE [module_name]?

من ناحية، only جملة تجعل الرمز أكثر سرعة أكثر. ومع ذلك، فإنه يجبرك على تكرار نفسك في التعليمات البرمجية وإذا كانت الوحدة النمطية الخاصة بك الكثير من المتغيرات / الوظائف / الروتين الفرعي، تبدأ الأمور في أن تبدو جامقة.

إليك مثال:

module constants
  implicit none
  real, parameter :: PI=3.14
  real, parameter :: E=2.71828183
  integer, parameter :: answer=42
  real, parameter :: earthRadiusMeters=6.38e6
end module constants

program test
! Option #1:  blanket "use constants"
!  use constants
! Option #2:  Specify EACH variable you wish to use.
  use constants, only : PI,E,answer,earthRadiusMeters
  implicit none

  write(6,*) "Hello world.  Here are some constants:"
  write(6,*) PI, &
       E, &
       answer, &
       earthRadiusInMeters
end program test

تحديثنأمل أن يقول شخص ما "فورتران؟ فقط أعدها في C #!" حتى أتمكن من خفض التصويت لك.

---

تحديث

انا يعجبني إجابة تيم ويتكومب, ، الذي يقارن fortran USE modulename مع بيثون from modulename import *. وبعد موضوع كان على تجاوز مكدس قبل:

• "وحدة استيراد" أو "من وحدة استيراد الوحدة"

  • في إجابة, ، مارك رودي المذكورة:

    لا تستخدم "من الوحدة النمطية للاستيراد *". لأي مجموعة كبيرة معقولة من التعليمات البرمجية، إذا كنت تقوم "باستيراد *" من المحتمل أن تعززها في الوحدة النمطية، غير قادر على إزالتها. هذا لأنه من الصعب تحديد العناصر المستخدمة في التعليمات البرمجية قادمة من "الوحدة النمطية"، مما يجعلها شرقا للوصول إلى النقطة التي تعتقد أنها لا تستخدم الاستيراد بعد الآن ولكن من الصعب للغاية أن تكون متأكدا.

• ما هي قواعد الإبهام جيدة لاستيراد Python؟

  • إجابة DBR يحتوي على

    لا تفعل من X Import * - إنه يجعل الشفوف الخاص بك يصعب فهمه، لأنه لا يمكنك بسهولة معرفة المكان الذي جاءت فيه الطريقة من (من x استيراد *؛ من Y استيراد *؛ my_func () - أين يعرف my_func؟)

لذلك، أنا أتميل نحو إجماع تفيد صراحة بجميع العناصر التي أستخدمها في وحدة

USE modulename, only : var1, var2, ...

و كما ستيفانو بوريني يذكر,

if] لديك وحدة نمطية كبيرة جدا تشعر بأنك مضطر لإضافة فقط، فهذا يعني أن الوحدة النمطية الخاصة بك كبيرة جدا. تقسيمها.

Answer 1

انها مسألة التوازن.

إذا كنت تستخدم بعض الأشياء فقط من الوحدة النمطية، فمن المنطقي إذا أضفت فقط، لتحديد ما الذي تستخدمه بوضوح.

إذا كنت تستخدم الكثير من الأشياء من الوحدة النمطية، فسيتم تحديدها فقط من خلال الكثير من الأشياء، لذلك فإنه أقل معنى أقل. أنت أساسا اختيار الكرز ما تستخدمه، ولكن الحقيقة الحقيقية هي أنك تعتمد على تلك الوحدة ككل.

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

تحديث: فورتران؟ فقط أعدها في بيثون؛)

Answer 2

اعتدت أن أفعل فقط use modulename - إذن، كما نمت طلبي، وجدت أنه أكثر صعوبة في العثور على المصدر للوظائف (دون الدوران إلى GREP) - لا يزال بعض التعليمات البرمجية الأخرى التي تطفو حول المكتب تستخدم ملف واحد فرعي لكل ملف مجموعة مشاكلها الخاصة، لكنها تجعل الأمر أسهل بكثير استخدام محرر نصوص لنقلها من خلال التعليمات البرمجية وتتبع ما تحتاجه بسرعة.

بعد تجربة هذا، أصبحت تحويلة إلى استخدام use...only متى أمكن. لقد بدأت أيضا في التقاط بيثون، وعرضها بنفس الطريقة from modulename import *. وبعد هناك الكثير من الأشياء العظيمة التي تعطيك الوحدات، لكنني أفضل الحفاظ على مساحة اسمي العالمية التي تسيطر عليها بإحكام.

Answer 3

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

إذا كان هناك بعض التجمع المنطقي للمتغيرات، فيمكنك إنشاء نوع مشتق بنفسك لكل مجموعة، وتخزين مثيل من هذا النوع في الوحدة النمطية ثم يمكنك استيراد المجموعة التي تحدثها فقط.

مثال صغير: لدينا الكثير من البيانات بعضها مدخلات المستخدم والبعض الآخر هو نتيجة تهيئة متنوعة.

module basicdata
   implicit none
   ! First the data types...
   type input_data
      integer :: a, b
   end type input_data
   type init_data
      integer :: b, c
   end type init_data

   ! ... then declare the data
   type(input_data) :: input
   type(init_data) :: init
end module basicdata

الآن إذا كان الروتين الفرعي يستخدم فقط البيانات من init, ، يمكنك استيراد ذلك:

subroutine doesstuff
   use basicdata, only : init
   ...
   q = init%b
end subroutine doesstuff

هذا بالتأكيد ليس حل قابل للتطبيق عالميا، يمكنك الحصول على بعض حمولة إضافية من بناء جملة النوع المشتق ثم سيكون بالطبع بالطبع بالكاد ما إذا كانت الوحدة النمطية ليست هي basicdata فرز أعلاه، ولكن بدلا من ذلك allthestuffivebeenmeaningtosortoutتشكيلة. على أي حال، كان لدي بعض الحظ في الحصول على رمز يناسب الدماغ بهذه الطريقة.

Answer 4

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

Answer 5

متفق عليها مع معظم الإجابات التي سبق معين، use ..., only: ... هي الطريقة للذهاب، واستخدام أنواع عندما يكون منطقي، تطبيق فكر بايثون بقدر المستطاع. اقتراح آخر هو استخدام اتفاقيات التسمية المناسبة في الوحدة النمطية المستوردة، إلى جانب private / public صياغات.

على سبيل المثال، netcdf استخدامات المكتبة nf90_<some name>, ، الذي يحد من تلوث مساحة الاسم على جانب المستورد.

use netcdf  ! imported names are prefixed with "nf90_"

nf90_open(...)
nf90_create(...)
nf90_get_var(...)
nf90_close(...)

وبالمثل، ncio. المجمع لاستخدام هذه المكتبة nc_<some name> (nc_read, nc_write...).

الأهم من ذلك، مع مثل هذه التصاميم حيث use: ..., only: ... أصبح أقل أهمية، من الأفضل التحكم في مساحة اسم الوحدة المستوردة من خلال الإعداد المناسب private / public السمات في الرأس، بحيث تكون نظرة سريعة عليها كافية للقراء لتقييم مستوى "التلوث" الذي يواجهونه. هذا هو أساسا نفس use ..., only: ..., ، ولكن على جانب الوحدة المستوردة - وبالتالي ستكون مكتوبة مرة واحدة فقط، وليس في كل استيراد).

شيء آخر: فيما يتعلق بتوجيه الكائنات والثاني، فإن الفرق في رأيي هو أن FORTRAN لا يشجع بالفعل الإجراءات المحددة للنظام، جزئيا لأنها معيار جديد نسبيا (على سبيل المثال غير متوافق مع عدد من الأدوات ، وأقل بعقلانية، فمن غير المعتاد) ولأنه يكسر سلوك مفيد مثل نسخة نوع مشتق خالية من الإجراءات (type(mytype) :: t1, t2 و t2 = t1). هذا يعني أنك غالبا ما تضطر إلى استيراد النوع والإجراءات التي سيتم ربطها جميعها، بدلا من الفصل فقط. هذا وحده يجعل رمز FORTRAN أكبر Verbose مقارنة مع Python، وقد تأتي الحلول العملية مثل اتفاقية تسمية البادئة في متناول اليدين.

IMO، خلاصة القول هو: اختر أسلوب الترميز الخاص بك للأشخاص الذين سيقرأونه (يتضمن ذلك بنفسك لاحقا)، كما يدرسه بيثون. الأفضل هو أكثر سرعة use ..., only: ... في كل استيراد، ولكن في بعض الحالات، ستفعل ذلك اتفاقية تسمية بسيطة (إذا كنت منضبطا بما فيه الكفاية ...).

Answer 6

نعم، يرجى استخدام use module, only: .... وبعد بالنسبة لقواعد التعليمات البرمجية الكبيرة مع العديد من المبرمجين، فإنه يجعل الرمز أسهل لمتابعة الجميع (أو مجرد استخدام grep).

يرجى عدم استخدامها، استخدم وحدة نمطية أصغر لذلك بدلا من ذلك. قم بتضمين عبارة عن رسالة نصية من التعليمات البرمجية المصدر والتي لم يتم التحقق منها من قبل المحول البرمجي في نفس المستوى مثل استخدام الوحدة النمطية، انظر: Fortran: الفرق بين تشمل وحدات. Include عموما يجعل من الصعب على كل من البشر والكمبيوتر استخدام التعليمات البرمجية مما يعني عدم استخدامه. السابق. من المنتدى MPI: "استخدام ملف MPIF.H يشمل بشدة يمكن إحباطه بشدة وقد يتم إهماله في إصدار مستقبلي من MPI." فيhttp://mpi-forum.org/docs/mpi-3.1/mpi31-report/node411.htm.).

Answer 7

أعلم أنني متأخرة قليلا إلى الحفلة، ولكن إذا كنت فقط بعد مجموعة من الثوابت وليس القيم المحسوبة بالضرورة، فيمكنك أن تفعل مثل C وإنشاء ملف تضمين:

داخل ملف، على سبيل المثال، الثوابت.

real, parameter :: pi = 3.14
real, parameter :: g = 6.67384e-11
...


program main
    use module1, only : func1, subroutine1, func2 
    implicit none

    include 'constants.for'
    ...
end program main

تم تحريره لإزالة "الحقيقي (4)" كما يعتقد البعض أنها ممارسة سيئة.