Jak korzystać z danych modułu Fortran 90

Kiedyś po prostu robiłem use modulename - potem, gdy moja aplikacja się rozrastała, coraz trudniej było znaleźć źródło funkcji (bez włączania grepa) - niektóre z innych kodów unoszących się po biurze nadal używają jednego podprogramu na plik, który ma swój własny zestaw problemów, ale znacznie ułatwia korzystanie z edytora tekstu, aby poruszać się po kodzie i szybko znaleźć to, czego potrzebujesz.

Po doświadczeniu tego, stałem się konwerterem na użycie use...only w miarę możliwości. Zacząłem też odbierać Pythona i oglądać go w ten sam sposób co from modulename import *. Jest wiele wspaniałych rzeczy, które dają Ci Moduły, ale wolę, aby moja globalna przestrzeń nazw była ściśle kontrolowana.

Nie do końca odpowiadam na to pytanie, po prostu wprowadzam inne rozwiązanie, które uznałem za przydatne w pewnych okolicznościach, jeśli z jakiegoś powodu nie chcesz podzielić modułu i zacząć otrzymywać starć przestrzeni nazw. Możesz używać typów pochodnych do przechowywania kilku przestrzeni nazw w jednym module.

Jeśli istnieje logiczne grupowanie zmiennych, możesz utworzyć własny typ Pochodny dla każdej grupy, zapisać instancję tego typu w module, a następnie zaimportować tylko grupę, która tak się składa, że potrzebujesz.

Mały przykład: mamy dużo danych, z których część jest wprowadzana przez użytkownika, a część jest wynikiem różnych inicjalizacji.

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

Teraz, jeśli podprogram używa tylko danych z init, importujesz tylko to:

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

To zdecydowanie nie jest uniwersalne rozwiązanie, otrzymujesz dodatkową szczegółowość ze składni typu pochodnego, a to oczywiście nie pomoże, jeśli twój moduł nie jest typem basicdata powyżej, ale zamiast tego bardziej odmianą allthestuffivebeenmeaningtosortout. W każdym razie, miałem trochę szczęścia w uzyskaniu kodu, który łatwiej pasuje do mózgu w ten sposób.

Główną zaletą użycia, tylko dla mnie, jest to, że unika zanieczyszczania mojej globalnej przestrzeni nazw rzeczami, których nie potrzebuję.

Zgadzam się z większością wcześniej udzielonych odpowiedzi, use ..., only: ... jest droga do zrobienia, użyj typów, gdy ma to sens, zastosuj myślenie Pythona jak najwięcej. Kolejną sugestią jest użycie odpowiednich konwencji nazewnictwa w importowanym module, wraz z private / public Oświadczenia.

Na przykład Biblioteka netcdf używa nf90_<some name>, co ogranicza zanieczyszczenie przestrzeni nazw po stronie importera.

use netcdf  ! imported names are prefixed with "nf90_"

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

Podobnie, ncio wrapper do tej biblioteki używa nc_<some name> (nc_read, nc_write...).

Co ważne, przy takich projektach, gdzie use: ..., only: ... jest mniej istotne, lepiej kontrolować przestrzeń nazw importowanego modułu, ustawiając odpowiednie private / public atrybutów w nagłówku, tak aby szybkie jego obejrzenie wystarczyło czytelnikom do oceny z jakim poziomem "zanieczyszczenia" się borykają. Jest to w zasadzie to samo co use ..., only: ..., ale po stronie importowanego modułu-tak więc może być napisane tylko raz, nie przy każdym imporcie).

Jeszcze jedno: o ile orientacja obiektowa i python są zaniepokojone, różnica w moim przekonaniu jest taka, że fortran nie zachęca do procedur związanych z typami, po części dlatego, że jest to stosunkowo nowy standard (np. nie kompatybilny z wieloma narzędziami, a mniej racjonalnie, jest to po prostu niezwykłe) i ponieważ łamie poręczne zachowanie, takie jak wolna od procedur pochodna Kopia typu (type(mytype) :: t1, t2 i t2 = t1). Oznacza to, że często musisz zaimportować typ i wszystkie możliwe procedury związane z typem, zamiast tylko klasy. To samo sprawia, że kod fortran jest bardziej zwięzły w porównaniu z Pythonem, a praktyczne rozwiązania, takie jak konwencja nazewnictwa prefiksów, mogą się przydać.

IMO, najważniejsze jest to: wybierz swój styl kodowania dla osób, które go przeczytają (dotyczy to również twojego późniejszego ja), zgodnie z nauczaniem Pythona. Najlepsze jest bardziej wyraziste use ..., only: ... przy każdym imporcie, ale w niektórych przypadkach wystarczy zwykła konwencja nazewnictwa (jeśli jesteś wystarczająco zdyscyplinowany...).

Tak, proszę użyć use module, only: .... W przypadku dużych baz kodu z wieloma programistami, kod jest łatwiejszy do naśladowania przez wszystkich (lub po prostu użyj grep).

Proszę nie używać include, zamiast tego użyj mniejszego modułu. Include jest tekstową wstawką kodu źródłowego, która nie jest sprawdzana przez kompilator na tym samym poziomie co use module, patrz: FORTRAN: Difference between INCLUDE and modules . Ogólnie utrudnia zarówno ludziom, jak i komputerowi użycie kodu, co oznacza, że powinien nie stosować. Ex. z mpi-forum: "korzystanie z mpif.H plik nagłówkowy jest zdecydowanie odradzany i może być przestarzały w przyszłej wersji MPI."( http://mpi-forum.org/docs/mpi-3.1/mpi31-report/node411.htm).

Wiem, że jestem trochę spóźniony na imprezę, ale jeśli chodzi Ci tylko o zbiór stałych i niekoniecznie obliczonych wartości, możesz zrobić jak C i utworzyć plik nagłówkowy:

Wewnątrz pliku, np. stałe.dla

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

Edytowano, aby usunąć " real (4)", ponieważ niektórzy uważają, że jest to zła praktyka.