¿Cómo se usan los datos del módulo 90 Fortran

https://stackoverflow.com/questions/1240510

11-09-2019
|

Pregunta

Supongamos que tiene un módulo de Fortran 90 que contiene lotes de variables, funciones y subrutinas. En su estado de cuenta USE, que la convención usted sigue:

declarar explícitamente qué variables / funciones / subrutinas que está utilizando con la sintaxis , only :, como USE [module_name], only : variable1, variable2, ...?
Inserte una USE [module_name] manta?

Por un lado, la cláusula only hace que el código un poco más detallado. Sin embargo, te obliga a repetir a sí mismo en el código y si su módulo contiene lotes de variables / funciones / subrutinas, las cosas comienzan a mirar ingobernable.

Este es un ejemplo:

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

Actualizar Esperemos que alguien dice algo así como "Fortran? Sólo recodificar en C #!" de modo que pueda bajar voto ti.

Actualizar

Tim Whitcomb respuesta , que se compara con USE modulename de Fortran from modulename import * de Python. Un tema que ha estado en desbordamiento de pila antes:

'módulo de importación' o 'de importación de módulo'
- En una respuesta , Mark Roddy mencionó:
  
  No utilice 'del módulo de importación *'. por cualquier gran conjunto razonable de código, si que 'importación *' su probable que se cementación en el módulo, no puede ser eliminado. Esto se debe a que es difícil determinar qué elementos utilizar en el código vienen de 'módulo', por lo que es este para llegar al punto donde cree que no utiliza el importar más, pero su extremadamente difícil estar seguro.
¿Cuáles son las buenas reglas de oro para Python importaciones?
- de DBR respuesta contiene
  
  no lo hacen desde x importación * - que hace su código muy difícil de entender, como no se puede ver fácilmente en un método Vino desde (desde x importación *; de y importación *; mi_func () - donde es mi_func definido?)

Por lo tanto, me estoy inclinando hacia un consenso de establecer explícitamente todos los artículos que estoy usando en un módulo a través de

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

Y como Stefano Borini menciona ,

[si] tiene un módulo tan grande que se sienten obligados a agregar sólo, significa que su módulo es demasiado grande. Dividirlo.

Solución

Es una cuestión de equilibrio.

Si utiliza sólo unas pocas cosas del módulo, tiene sentido si se agrega SOLAMENTE, para especificar claramente lo que usted está utilizando.

Si utiliza una gran cantidad de cosas desde el módulo, especificando sólo será seguido por un montón de cosas, por lo que tiene menos sentido. Que son básicamente cherry-picking lo que se utiliza, pero el hecho cierto es que son dependientes de ese módulo en su conjunto.

Sin embargo, al final la mejor filosofía es la siguiente: si están preocupados por la contaminación del espacio de nombres, y tiene un módulo tan grande que se siente obligado a agregar sólo, significa que el módulo es demasiado grande. Dividirlo.

Actualización: Fortran? simplemente recodificar en Python;)

Otros consejos

Yo solía simplemente hacer use modulename - entonces, como mi solicitud crecía, me pareció más y más difícil de encontrar la fuente de funciones (sin volver a grep) - algunos de los otros códigos flotando alrededor de la oficina todavía utiliza un uno -subroutine-por-archivo, que tiene su propio conjunto de problemas, pero lo hace mucho más fácil de usar un editor de texto para desplazarse por el código y rápidamente rastrear lo que necesita.

Después de experimentar esto, me he convertido en un convertido al uso de use ... only siempre que sea posible. También he comenzado recogiendo Python, y verlo de la misma manera como from modulename import *. Hay un montón de grandes cosas que le dan los módulos, pero prefiero mantener mi espacio de nombres global estrechamente controlada.

No es exactamente responder a la pregunta aquí, simplemente tirar en otra solución que he encontrado útil en algunas circunstancias, si por cualquier razón usted no desea dividir su módulo y empezar a tener enfrentamientos de espacio de nombres. Puede utilizar los tipos derivados de almacenar varios espacios de nombres en un solo módulo.

Si hay alguna agrupación lógica de las variables, puede crear su propio tipo derivado para cada grupo, almacenar una instancia de este tipo en el módulo y luego se puede importar sólo el grupo que le sucede a necesitar.

Pequeño ejemplo: Tenemos una gran cantidad de datos de algunas de las cuales es la entrada del usuario y algunos que es el resultado de diversos inicializaciones

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

Ahora bien, si una subrutina sólo utiliza datos de init, se importa más que eso:

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

Esto definitivamente no es una solución de aplicación universal, se obtiene algún nivel de detalle adicional de la sintaxis tipo derivado y luego, por supuesto, apenas ayuda si su módulo no es el basicdata tipo anterior, pero en lugar de más de un allthestuffivebeenmeaningtosortoutvariety. De todos modos, he tenido un poco de suerte en conseguir el código que se ajuste más fácil en el cerebro de esta manera.

La principal ventaja de USO, sólo para mí, es que evita contaminar mi espacio de nombres global con cosas que no necesito.

acuerdo con la mayoría respuestas dadas anteriormente, use ..., only: ... es el camino a seguir, tipos de uso cuando tiene sentido, aplicar pitón pensar tanto como sea posible. Otra sugerencia es usar convenciones de nombres apropiados en su módulo importado, junto con las declaraciones private / public.

Por ejemplo, la biblioteca netcdf utiliza nf90_<some name>, lo que limita la contaminación del espacio de nombres en el lado importador.

use netcdf  ! imported names are prefixed with "nf90_"

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

Del mismo modo, el ncio envoltorio a esta biblioteca utiliza nc_<some name> (nc_read, nc_write ...) .

Es importante destacar que con este tipo de diseños en los que use: ..., only: ... se hace menos relevante, que le controlar mejor el espacio de nombres del módulo importado mediante el establecimiento de private apropiado / public atributos en la cabecera, de modo que un rápido vistazo será suficiente para que los lectores evaluar qué nivel de "contaminación" que se enfrentan. Este es básicamente el mismo que use ..., only: ..., pero en el lado módulo importado -. Tanto a escribir solamente una vez, no en cada importación)

Una cosa más: en lo que se refiere a la orientación a objetos y pitón, una diferencia en mi opinión es que FORTRAN en realidad no se animar a los procedimientos de tipo fijo, en parte porque es un estándar relativamente nuevo (por ejemplo, no es compatible con una número de herramientas, y menos racional, es sólo inusual) y porque rompe el comportamiento práctico como copia gratuita del procedimiento derivado de tipo (type(mytype) :: t1, t2 y t2 = t1). Eso significa que a menudo tienen que importar el tipo y todos los procedimientos de tipo fijo, aspirantes a, en lugar de la clase. Esto por sí solo hace que el código FORTRAN más detallado en comparación con el pitón, y soluciones prácticas, como un prefijo convención de nombres puede ser útil.

OMI, la conclusión es: elegir su estilo de codificación para las personas que van a leer (esto incluye su auto después), según lo enseñado por pitón. Lo mejor es la use ..., only: ... más detallado en cada importación, pero en algunos casos un simple convención de nomenclatura lo hará (si es lo suficientemente disciplinado ...).

Sí, por favor utilice use module, only: .... Para las grandes bases de código con varios programadores, hace que el código sea más fácil de seguir por todo el mundo (o simplemente utilizar grep).

Por favor, no usar incluyen, utilizar un módulo más pequeño para que en su lugar. Incluir es una inserción de texto de código fuente que no está controlada por el compilador al mismo nivel que el módulo de uso, véase: FORTRAN: Diferencia entre INCLUYEN y módulos . Include general hace que sea más difícil para los seres humanos y equipo para utilizar el código que significa que no se debe utilizar. Ex. de MPI-foro: "El uso de la mpif.h archivo de inclusión se desaconseja encarecidamente y puede ser obsoleto en una versión futura de MPI." ( http://mpi-forum.org/docs/mpi -3.1 / mpi31-informe / node411.htm ).

Yo sé que soy un poco tarde a la fiesta, pero si estás sólo después de un conjunto de constantes y no necesariamente los valores calculados, se puede hacer como C y crear un archivo de inclusión:

dentro de un archivo, por ejemplo, constants.for

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

Editado para eliminar "real (4)", como algunos piensan que es una mala práctica.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow