FXDR


Original: http://meteora.ucsd.edu/~pierce/fxdr_home_page.html

David W. Pierce
Instititution Scripps d’océanographie

Qu’est-ce que c’est?

FXDR est une bibliothèque qui vous permet d’effectuer des appels aux routines XDR (représentation externe des données) de Fortran. Vous avez certainement déjà les routines XDR sur votre poste de travail–avec FXDR vous pouvez facilement les appeler de Fortran. Concrètement, cela signifie que vous pouvez lire et écrire des fichiers binaires non formatés dans votre code Fortran qui sont portables entre différentes plates-formes. Écrire votre binaire sur un Cray, le lire sur un DEC, écrivez-le sur un SIG, lire sur un HP–il n’est pas grave.

  • Télécharger la source pour FXDR version 2. 1 b. Je l’ai testé sur DEC Alphas et PMAX, Crays, SIG et HPs. Version 2,1 c sortie le 25 janvier 2002.

NOTE spéciale pour les utilisateurs de la VERSION 1.x

(Journal des modifications).

Plus d’informations sur FXDR
Table des matières

  1. Ce qui est FXDR ?
  2. Pourquoi voudrais-je utiliser les routines XDR via la bibliothèque FXDR ?mment utiliser FXDR ?
  3. Plus de détails sur l’utilisation de la bibliothèque FXDR
  4. Une remarque importante sur la précision
  5. Encore une autre note sur la précision
  6. Interprétation des résultats du programme de test
  7. Informations plus complètes
  8. Droit d’auteur

Ce qui est FXDR ?

La bibliothèque FXDR est un ensemble de routines Fortran qui fournissent une interface pour les routines XDR qui existent déjà (presque certainement) sur votre poste de travail ou mainframe. C’est-à-dire, il fournit un moyen facile et pratique d’utiliser la capacité XDR de votre ordinateur à partir de Fortran.

Pourquoi voudrais-je utiliser les routines XDR via la bibliothèque FXDR ?

En une seule phrase : Si vous utilisez les routines FXDR dans vos codes de Fortran pour écrire vos fichiers de données binaires, puis vous pouvez déplacer ces fichiers de données à l’une des différentes machines utilisez-vous, et les données seront lus dans correctement ! Plus de traduire entre les différentes plateformes ! Pas plus gros fichiers de ASCII s’occuper ! OK, c’était plus qu’une seule phrase, mais je suis enthousiaste.

La bibliothèque XDR est ce que les ordinateurs utilisent pour parler les uns aux autres pour les appels RPC (Remote ProCedure) sur le réseau. Lorsque le RPC a été conçu tout d’abord, les fabricants s’est rendu compte qu’ordinateurs différents du vendeur ne pouvait pas facilement communiquent entre eux via un réseau en raison des différences de classement et de précision octets. Par exemple, des données binaires, écrites sur un soleil ne peut pas être lire directement sur un DEC parce que l’ordre d’octet est opposé sur les deux ; et Cray flottante point données binaires ne peut facilement être lu sur n’importe quoi d’autre Cray utilise leur propre format, pas de IEEE (comme plus tout le monde utilise). Ainsi, les concepteurs RPC standardisés une façon particulière de représenter des données (la représentation de données externe, ou XDR).

Si vous écrivez les données en utilisant les bibliothèques XDR, ensuite le lire en utilisant les bibliothèques XDR, alors peu importe ce que vous a écrit sur ou lire sur la plate-forme. Vous pouvez écrire sur le soleil et le lire sur le DEC, ou écrire sur un Cray et le lire sur un SIG. Tant que vous passez par la bibliothèque XDR, le format de bas niveau des données sera compris correctement. (Il faut toujours savoir le format des données de haut niveau. C’est à dire, si vous avez écrit un nombre à virgule flottante en simple précision, vous devez demander les routines de lire dans un numéro et pas quelque chose de différent tel qu’une chaîne en entier ou caractère à virgule flottante en simple précision.)

Comment utiliser FXDR ?

Il vous suffit de remplacer votre Fortran binaire non formaté écrire des déclarations par des appels à la routine de bibliothèque FXDR appropriée.

Exemple :

parameter (nx=80,ny=100)
real    coeffs(nx,ny)
open(ilun, file=’testdata’, form=’unformatted’)
write(ilun) coeffs

Avec

parameter (nx=80,ny=100)
real    coeffs(nx,ny)
ixdrs = initxdr(‘testdata.xdr’, ‘w’, .FALSE.)
ierr  = ixdrrmat( ixdrs, nx*ny, coeffs )

Assez facile, hein ? À lire dans ces mêmes données :

Remplacer

open(ilun, file=’testdata’, form=’unformatted’)
read(ilun) coeffs

Avec

ixdrs = initxdr(‘testdata.xdr’, ‘r’, .FALSE.)
ierr = ixdrrmat( ixdrs, nx*ny, coeffs )

Notez que l’appel à la routine FXDR est exactement la même que vous soyez de lecture ou d’écriture ; Si vous en fait lire, écrivez ou ajoutez dépend de si vous avez appelé la routine de « initxdr » avec un « r », « w » ou « a » as le second argument. C’est une amélioration de Fortran, où l’appel pour ouvrir le fichier est exactement le même si vous êtes lecture ou écriture, mais vous appelez différentes routines (« lu » ou « écrire ») pour atteindre celui que vous voulez. Le troisième argument d’initxdr contrôle la gestion de l’erreur ; pour le comportement plus comme Fortran, affectez-lui. FAUX., auquel cas les routines XDR vont imprimer un message d’erreur et arrêter si elles rencontrent une erreur (cela ressemble à ce que fait Fortran). Si le troisième argument a la valeur. VRAI., puis les routines XDR retournera une valeur inférieure à zéro, si elles rencontrent une erreur, ce qui permet à votre code appelant spécifiquement dans cette cause.

Plus de détails sur l’utilisation de la bibliothèque FXDR

Pour utiliser la bibliothèque FXDR vous ouvrez d’abord le fichier au format XDR à l’aide de la routine « initxdr ». Cette routine retourne un entier qui représente le numéro d’identification avec que toutes les routines XDR utilisera pour indiquer quel fichier XDR vous voulez travailler. Le premier argument de « initxdr » est le nom du fichier ; le second argument est ‘r’, ‘w’, ou « a » pour la lecture, écriture ou à ajouter ; le troisième argument est. LA VALEUR FALSE. Si vous voulez les routines d’imprimer un message d’erreur et arrêter si elles rencontrent une erreur (comme Fortran), et. LA VALEUR TRUE. Si vous souhaitez que les routines pour renvoyer un code d’erreur est inférieure à zéro si elles rencontrent une erreur :

character*(*) filename
character*1   mode
integer       id
logical       return_on_error
id = initxdr( filename, mode, return_on_error )

Puis, vous remplacez votre « lecture » et « écrire » appels par un appel à l’une des fonctions entières suivantes :

Name      Bits  Fortran type of argument
——— —-  ——————————————————–
ixdrdouble 64    double precision floating point number
ixdrdmat   64    array of double precision floating point numbers
ixdrint    32    integer
ixdrimat   32    array of integers
ixdrreal   32    single precision floating point number
ixdrrmat   32    array of single precision floating point numbers
ixdrreal64 64    single precision floating point number
ixdrrmat64 64    array of single precision floating point numbers
ixdrstring n/a   character*(*)

La colonne « Bits » indique le nombre de bits significatif est enregistré dans le fichier XDR.

Retourner des valeurs pour toutes les routines : si initxdr a été appelée à l’origine de ce fichier avec le troisième argument. FAUX., puis une erreur provoque la routine d’imprimer un message d’erreur et arrêter. Si initxdr a été appelée avec le troisième argument. VRAI., puis ces routines retournent n’importe quoi, et la valeur retournée est inférieur à 0 si une erreur a été rencontrée.

Les routines de scalaire (c’est-à-dire une valeur unique, pas de tableau) tous les prennent exactement deux Paramètres :

  • l’ID du fichier xdr, qui était l’entier retourné par l’appel « initxdr ».
    la variable ni lire ni écrire.

Les routines de tableau tous les prennent exactement trois paramètres :

  • l’ID du fichier xdr, qui était l’entier retourné par l’appel « initxdr ».
  • le nombre TOTAL d’éléments dans le tableau.
  • Tableau pour lire ou écrire.

Une remarque importante sur la précision

Il est IMPORTANT de comprendre que la précision mentionnée ci-dessus (par exemple, la précision « simple » de routine « ixdrreal ») ou la précision ‘double’ de routine ‘ixdrdouble’ est la valeur de votre compilateur, pas par la bibliothèque FXDR. C’est important, parce que les différents compilateurs ont des précisions par défaut différente (comme, en nombre de bits) associées aux noms ‘simples’, ‘double’, etc.. Au moment d’écrire ces, cela rend la plus grande différence lorsque vous déplacez des fichiers XDR entre Crays et postes de travail tels que les soleils, HPs ou DECs, car par defalt le compilateur Cray Fortran utilise une ‘simple’ précision de 64 bits et une précision « double » de 128 bits, tandis que le soleil, HP et DEC utiliser une ‘simple’ précision de 32 bits et une ‘double’ précision de 64 bits. (Vous risquez d’obtenir un effet similaire sur un poste de travail si vous compilez avec un drapeau comme ‘-r8’, qui indique au compilateur de faire tout par défaut les variables « simple précision » à 8 octets [64 bits] de précision).

Le résultat, c’est que si vous utilisez un Cray pour écrire une précision unique de Fortran, nombre à virgule flottante dans un fichier XDR à l’aide de la routine « ixdrreal », seulement 32 bits 64 bits original sera écrit. Mais, vous ne pouvez pas utiliser routine « ixdrdouble » d’écrire tous les 64 bits correctement, car cette routine s’attend à passer une variable de point flottante Fortran double précision, pas une variable simple précision.

Pour contourner ce problème, il y a un ensemble de routines spéciales qui tiennent les variables « simple précision » telle que définie par le compilateur Fortran et écrivez-les 64 bits (ce sont les routines « ixdrreal64 » et « ixdrrmat64 »). Pour lire ces dans un poste de travail où un véritable est uniquement 32 bits, vous devez utiliser les routines de « ixdrdouble » ou « ixdrdmat » et fournir une * double * précision flottante point variable pour recevoir les 64 bits de données valides. (Pour lire ces dans sur un Cray, vous utilisez juste la même routine qui a écrit les données en premier lieu–« ixdrreal64 » ou « ixdrrmat64 »).
Pour résumer pour précision 64-bit :

Écrire des valeurs de précision unique sur un Cray (ou workstation avec reals Fortran 64bits) avec « ixdrreal64 » ou « ixdrrmat64 », puis lire dans valeurs double précision sur une station de travail régulier avec un appel à « ixdrdouble » ou « ixdrdmat ».

Écrire des valeurs double précision sur une station de travail avec le « ixdrdouble » ou « ixdrdmat », puis lire dans valeurs de simple précision sur un Cray (ou workstation avec reals Fortran 64bits) avec un appel à « ixdrreal64 » ou « ixdrrmat64 ».

Notez que vous n’avez pas à utiliser la précision 64 bits ; vous pouvez utiliser précision 32 bits si vous voulez (je fais souvent, les fichiers sont à moitié aussi grand). C’est facile à faire ; Il suffit d’écrire à réel * 4 Inscrivez les numéros sur le Cray et le poste de travail et utiliser les appels de 32 bits tels qu’ixdrrmat et ixdrreal.

Encore une autre remarque importante sur la précision

Malheureusement, ce n’est pas tout, que vous devez savoir sur la précision. Il y a aussi le problème que Crays (pour le moment–nouveau Crays pourrait changer cela) utilisent un système complètement différent pour représenter les nombres en interne que de faire des postes de travail. Crays utiliser « Cray format de point flottant » (duh) tandis que les stations de travail utilisent « IEEE floating point format ». Eh bien, les bibliothèques XDR sous-jacentes que FXDR appelle toujours utilisation format IEEE flottant point, donc si vous travaillez toujours sur un poste de travail puis tout est très bien et s’il vous plaît ignorer ce paragraphe malgré le fait que vous avez déjà lu beaucoup de lui. Si vous travaillez sur les Crays, cependant, vous devrez sachez que mettre des données dans un fichier XDR et puis immédiatement la lecture en sera ne pas vous laisseront avec exactement le même nombre à virgule flottante que vous avez commencé avec. Il sera probablement différent dans la dernière position de bit ou plus. Il s’agit d’une légère différence, et pour mettre en perspective, le compilateur Cray va se faire les choses à votre code (et vous avertir qu’il leur fait) qui peut changer votre résultats autant, dans un souci de rendre le code plus rapide. Cependant si vous juste ne peut pas vivre avec perdre un peu de précision dans vos numéros alors s’il vous plaît effacer votre exemplaire de cette bibliothèque et par l’amour de Dieu commencer à boire de café décaféiné !

Cependant, le genre d’endroit où cela peut faire une différence est sérieusement, si vous avez une simulation numérique longtemps courir et écrivez un fichier de redémarrage mi-chemin à travers, mais encore l’intention de courir sur une seule plate-forme. Dans ce cas, vous seriez probablement mieux ne pas utiliser FXDR pour écrire le fichier de redémarrage, car vous ne serez pas en mesure d’obtenir peu reproductibilité entre une exécution dans dont le modèle a été relancé à mi-chemin à travers et une course dans laquelle le modèle a jamais redémarré. Mais il s’agit d’un cas pathologique d’une manière ; Si vous utilisez FXDR, c’est parce que vous souhaitez déplacer des résultats entre les plates-formes. Si vous déplacez votre modèle circulent entre plates-formes, vous n’obtiendrez pas de reproductibilité peu n’importe quoi, donc à l’aide de FXDR ne vous coûte rien de toute façon. À mon avis, la meilleure utilisation pour FXDR est pour le modèle d’initialisation et exportez des fichiers, pas les fichiers de redémarrage ; avoir vos fichiers d’initialisation dans FXDR est très pratique, car vous pouvez les déplacer en toute transparence à toutes les plateformes à exécuter et avoir la sortie en FXDR est grand, parce que vous pouvez analyser les résultats sur quelle que soit la machine est plus pratique. Si vous êtes déjà déplacement des fichiers de redémarrage entre plates-formes et continue s’exécute sur des ordinateurs différents, vous avez déjà perdu bit reproductibilité de toute façon, donc vous pouvez aussi bien utiliser FXDR pour les fichiers de redémarrage, mais en général, je déconseille cette approche pour les fichiers de redémarrage.

Interprétation des résultats du programme de test

Il y a un programme de test fourni avec la distribution. Lorsque vous « faites tester » puis le programme (appelé–si vous pouvez croire TI–“test. F”) est compilé et fonctionne, test de la bibliothèque FXDR. Elle:

  • Écrit un fichier .xdr, appelé « test.xdr »
  • Lit dans ce fichier qu’il vient de créer (“test.xdr”) et vérifie pour voir si elle a les valeurs attendues.
  • Lit un fichier .xdr que j’ai généré sur un DEC alpha (“test.orig.xdr”) pour voir si elle a les valeurs attendues.

Maintenant ce qui arrive souvent, c’est qu’il y a une perte de précision quelque part le long de la voie, habituellement dans le dernier morceau. La première partie du test, qui crée un fichier .xdr et puis le lit en, rarement montre aucune perte de précision sur une machine que lui utilise IEEE floating point format (la plupart postes de travail y compris DEC, Sun, HP et SGI). Si fréquemment partie passera sans avertissement de perte de précision. En revanche, si vous l’exécutez sur un Cray (qui n’utilise pas de IEEE floating point format) puis vous verrez un certain manque de précision à ce stade. Pour les valeurs des points de flottante en simple précision, 1 partie à 10 ** 7 est sur le dernier morceau ; pour double précision flottante des valeurs point, 1 partie en 10 ** 14 est le dernier morceau. Donc, si vous voyez des pertes de précision inférieure ou égale à ce montant (et vous presque certainement sera) alors cela signifie simplement que le dernier morceau se déteriorés. Vous devez décider par vous-même si il s’agit d’un problème ou si vous pouvez vivre avec elle. N’oubliez pas, les paramètres des indicateurs de compilateur affectant le niveau d’optimisation fréquemment modifient vos résultats à ce niveau de précision. Comme indiqué plus haut, je vois ce surtout comme un problème de redémarrage fichiers par rapport aux fichiers d’initialisation ou de sortie.

La deuxième partie du test lit un fichier .xdr que j’ai généré sur un DEC alpha et il vérifie les valeurs correctes. Sauf si vous vous avérez justement être en cours d’exécution sur un DEC alpha vous-même, puis vous obtiendrez presque certainement quelques avertissements de perte de précision à ce stade.

Toutes les infos
Il y a des informations plus complètes sur la façon de construire, installer et configurer la bibliothèque FXDR dans le fichier README, donc n’oubliez pas de regarder à travers qui après avoir téléchargé la source. Aussi, n’oubliez pas de regarder les pages de manuel (man fxdr).

Informations de version
2.1 c: 25 janvier 2002. AIX ajouté aux plate-formes supportées par « configure ».
2. 1 b: 27 septembre 1999. Corrections mineures pour les valeurs d’erreur en retour. Linux ajouté aux plate-formes supportées par « configure ».
2. 1 a: 2 septembre 1999. Difficulté pour la mal nommée variable lors de la compilation sur un HP. Merci à Aldo Bonfiglioli pour cela.
2.1 : 31 août 1999. Ajout du support pour les Crays plus récents qui utilisent des pointeurs chaîne de caractères Fortran deux mots.
2.0 : 10 août 1999. A totalement changé l’interface pour prendre en charge la gestion des erreurs. Routines ne sont plus vers l’arrière compatible avec le code de la version 1.x.
1.4 à 1. 4 a: 13 novembre 1998. Des modifications mineures au système « unicos » définit pour les compilateurs plus récents de Cray.
1.3 à 1.4 : 14 novembre 1997. Ajout du support de type « court ». Ajout d’informations pour les utilisateurs de HP, Linux et systèmes solaires.
1.2 à 1.3 : 213 juillet, 1996. Contrôle additionnel « mode » transmis à routine « initxdr ».
1.1 à 1.2 : 18 mars 1996. Correction d’un bug dans le fichier makefile. Ajouté « local_filename » à « cxdrinit.c » pour le faire fonctionner sous UNICOS 9.0.1 sur le C90 de routine.
1.0 à 1.1 : 28 novembre 1995. Routine ajoutée « xdrrewind ».

Droit d’auteur
Copyright (c) 1995 les régents de l’Université de Californie. Tous droits réservés.
Redistribution et l’utilisation sous forme source et binaire sont autorisées sous réserve que (1) source distrubutions conserver cette notice de copyright ensemble et commentaire, et (2) les distributions telles que binaires affichent la confirmation suivante: ” ce produit comprend un logiciel développé par l’Université de Californie, San Diego et ses contributeurs ” dans la documentation ou autres matériels fournis avec la distribution et à tous les supports publicitaires mentionnant les fonctions ou l’utilisation de ce logiciel. Ni le nom de l’Université, ni les noms de ses contributeurs peuvent servir à endosser ou promouvoir des produits dérivés du présent logiciel sans autorisation écrite spécifique.
CE LOGICIEL EST FOURNI « EN L’ÉTAT » ET SANS AUCUNE EXPRESS OU IMPLICITES, Y COMPRIS, SANS S’Y LIMITER, LES GARANTIES IMPLICITES DE QUALITÉ MARCHANDE ET D’ADEQUATION A UN USAGE PARTICULIER.
Retour à la page d’accueil de David Pierce.
Modifié le Sep 2, 1999

 

Comments are closed.