JAVA et NETCDF

Version imprimable

14/08/2009, 17h39
HammerK

JAVA et NETCDF

Bonjour,

Je travail sous éclipse ou je développe un modèle mathématique qui prend en entré des données de type precipitation/Température/.. répartie temporellement et par pixel.

ces données étant en très grand nombre (11GO par variables (il y en a 6)), elles sont stockées dans 6 fichier (1 par variable) de type NETCDF.

Je me suis donc servis des de la bibliothèques NETCDF JAVA library (NJL)

http://www.unidata.ucar.edu/software/netcdf-java/

Le problème est que la lecture des donnée est parfois tres longue. Je m'explique, je calcul pour chaque pixel les sortie du modèle, et pour chaque pixel, je dois donc aller chercher les valeur journalière de donnée comme la température, les precipitations etc... Pour certain pixel, cette lecture devient bizarrement longue (1 minute pour lire mes 8 données (fois 365*nb année simulé)) alors que pour la plupart des pixel, cette lecture prend a peine 1 seconde. Je precise bien sur que pour chaque pixel la taille des donnée à lire est toujours similaire.....

Je ne comprend pas cette irrégularité dans le temps de lecture? je pense que la NJL traffic des truc avec la mémoire.

N'etant pas expert en Java, est ce qu'il existe des moyens de voir ce qui se passe au niveau du Garbage collector ? si celui travaille, a quelle fréquence??

Est il possible d'avoir une fuite mémoire en JAVA qui sature la mémoire utile du process dans lequel s'exécute mon modèle???

Est ce qu'un utilisateur pourrait me renseigner sur une bonne façon d'utiliser la NJL dans le cas ou je m'en sert mal.

D'autant plus que depuis cet après midi, alors que j'ai juste modifié très légèrement le code (j'ai remplacé un coef multiplicateur par un autre) le ralentissement ce fait maintenant a tout les pixels.

Ha oui, il se passe autre chose d'étrange. si depuis éclipse, je lance le run sur par exemple les 4 premiers pixel. J'arrete le run et je relance alors là, comme par magie, pour ces 4 pixel, le temps d'accès en lecture au variable et de nouveaux rapide (comme si des chose en mémoire avait été stocké)..... Bref, j'ai un peu de mal a comprendre le pourquoi du comment

Merci pour votre aide.
14/08/2009, 18h00
HammerK

J'oubliais de precisier :

Je travail sous XP.

Et lorsque le ralentissement a la lecture est en cour si je regarde le taux d'utilisation du CPU il est a zero % (ainsi que l'acces noyaux) du coup mon programme va a deux à l'heure alors et le CPU ne travail pas ....

Je ne comprend pas???
14/08/2009, 19h42
msami

Est ce que c'est possible de voir une portion de code ?
16/08/2009, 23h29
bouye

Vi parceque la bon...

Je n'ai jamais eut de reel probleme avec la lib Netcdf mais les volumes de donnees que le manipule sont beaucoup moins important.

Comment-lis-tu tes donnees ? Pixel par pixel ? Ou plan par plan ? Ou caches-tu un sous-partie (tile) d'un plan, etc... Bref des optimisations sont possibles en changeant de strategie de lecture.

Et puis 11 Go (x6 en plus !) c'est quand meme enorme... est-ce que l'OS sous-jacent peut cacher et correctement manipuler des fichiers aussi gros ?
17/08/2009, 00h30
tchize_

C'est toujours pour les mêmes données? Est-ce possible que ce soit lié à leur position dans le fichier? Un support de stockage endommagé pourrais expliquer ce problème, la zone concernée prendrait alors plusieurs essais à l'OS pour être lue correctement.

je vais détillé avec du code ma "stratégie" de lecture :

dans un premier temps j'ouvre mes fichiers :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
		temperature_min=NetcdfFile.open(nc_tmin);
		temperature_max=NetcdfFile.open(nc_tmax);
		precipitation=NetcdfFile.open(nc_precip);
		humidite=NetcdfFile.open(nc_hum);
		rayonnement=NetcdfFile.open(nc_ray);
		vent=NetcdfFile.open(nc_vent);
 
		var_tmin = temperature_min.findVariable("Temperature_min");
		var_tmax = temperature_max.findVariable("Temperature_max");
		var_precip = precipitation.findVariable("Total_Precipitation");
		var_hum = humidite.findVariable("Relative_humidity");
		var_vent = vent.findVariable("U_wind_component");
		var_ray = rayonnement.findVariable("Incoming_Short_Wave_Radiation");

puis je lis mes variable de cette façon:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
System.out.println("1.1");
		int[] origin = new int[] {dStart-1, indexLatitude-1, indexLongitude-1 };
		int[] size = new int[] {tStop, 1, 1};
 
		data3D = var_tmin.read(origin, size);
		listTAirMin = data3D.reduce();		
 
		data3D = var_tmax.read(origin, size);
		listTAirMax = data3D.reduce();
 
 
		data3D = var_precip.read(origin, size);
		listPrecipTemp = data3D.reduce();
		listPrecip=listPrecipTemp.copy();
		listET0=listPrecipTemp.copy();		
 
		data3D = var_hum.read(origin, size);
		listHum = data3D.reduce();	
 
		data3D = var_vent.read(origin, size);
		listWind = data3D.reduce();			
 
		data3D = var_ray.read(origin, size);
		listRay = data3D.reduce();	
 
		System.out.println("1.6");

c'est entre les deux println que le code ralentie énormément.

Comme vous le remarquez le lis les données pixel/pixel mais sur la durée de ma simulation.

Code:

int[] size = new int[] {tStop, 1, 1};

mon tstop vaut 7300.

Peux-tu remplacer le code par ceci, afin de voir si c'est bien la lecture qui foire et, si oui, laquelle

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
System.out.println("1.1");
		int[] origin = new int[] {dStart-1, indexLatitude-1, indexLongitude-1 };
		int[] size = new int[] {tStop, 1, 1};
 
		data3D = var_tmin.read(origin, size);
		System.out.printf("lu tmin(%d,%d)",origin,size);
		data3D = var_tmax.read(origin, size);
		System.out.printf("lu tmax(%d,%d)",origin,size);
		data3D = var_precip.read(origin, size);
		System.out.printf("lu precip(%d,%d)",origin,size);
		data3D = var_hum.read(origin, size);
		System.out.printf("lu hum(%d,%d)",origin,size);
		data3D = var_vent.read(origin, size);
		System.out.printf("lu vent(%d,%d)",origin,size);
		data3D = var_ray.read(origin, size);
		System.out.printf("lu ray(%d,%d)",origin,size);
		listTAirMin = data3D.reduce();		
 
		listTAirMax = data3D.reduce();
 
 
		listPrecipTemp = data3D.reduce();
		listPrecip=listPrecipTemp.copy();
		listET0=listPrecipTemp.copy();		
 
		listHum = data3D.reduce();	
 
		listWind = data3D.reduce();			
 
		listRay = data3D.reduce();	
 
		System.out.println("cacul fait 1.6");

Peux-tu faire aussi un petit code qui test la vitesse de lecture des fichiers afin de voir si le filesystem peut être en cause?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
 
 
public class TestSpeed {
	public static void main(String[] argv) throws IOException{
		File f = new File(argv[0]);
		long read = 0;
		long bigBlockRead =0;
		byte[] MegBuffer = new byte[1024*1024];
		FileInputStream fis = new FileInputStream(f);
		int current ;
		long previous = System.currentTimeMillis();
		while ((current = fis.read(MegBuffer)) >=0){
			read+=current;
			if (read/(1024*1024*100)!=bigBlockRead){
				long now = System.currentTimeMillis();
				System.out.printf("Read 100M block n° %3d in %d milliseconds\n", bigBlockRead+1,now-previous);
				previous=now;
				bigBlockRead++;
			}
		}
	}
 
}

17/08/2009, 10h00
HammerK

le printf plant.

(Exception in thread "main" java.util.IllegalFormatConversionException: d != [I
at java.util.Formatter$FormatSpecifier.failConversion(Unknown Source)
at java.util.Formatter$FormatSpecifier.printInteger(Unknown Source)
at java.util.Formatter$FormatSpecifier.print(Unknown Source)
at java.util.Formatter.format(Unknown Source)
at java.io.PrintStream.format(Unknown Source)
at java.io.PrintStream.printf(Unknown Source)
at fr.InputData.fillWithNetcdfFile(InputData.java:421)
at fr.Main.main(Main.java:63)
17/08/2009, 10h02
tchize_

oops, pas vu que c'était des tableaur, remplace origin et size par start et stop, ce sont les valeurs qui sont intéressantes à connaitre lors du ralentissement ;) Et n'oublie pas le test de vitesse de mon post ;)
17/08/2009, 10h26
HammerK

En fait tstart et tstop valent toujours : 1, 7300 pour toute les lectures.

et lorsque j'ai un ralentissement, ça el fait pour toute les lectures.

Je vais faire le test d'accés fichier. Je poste la réponse des que je l'ai fait... (peut pas le faire dans l'immédiat).
17/08/2009, 10h29
tchize_

C'est bien les lectures et pas le calcul en dessous qui posent problème?
17/08/2009, 10h41
HammerK

oui oui ça c'est sur...

J'ai criblé mon code de println et c'etait entre les prints des lectures que j'avais un ralentissement, le reste se faisait assez vite.
17/08/2009, 11h13
bouye

Et ça ne serait pas justement le fait de lire une colonne entière de données plutot qu'un plan qui soit lent compte tenu des multiples sauts et décallages que cela va engendrer dans la lecture d'un fichier de cette taille (en supposant que le NetCDF stocke ses données de manière contigue bien sur) ?
20/08/2009, 10h37
HammerK

Bonjour,

Apres quelques tests, je pense que cela vient en effet de la lecture par colonne. Les données doivent etre rangé par lattitude/Longitude ainsi les saut dans la mémoire prennent plus de temps.

Malheureusement, tout le code a été pensé pour etre lu temporellement et pas spatialement... Tant pis. ce sera pour la prochaine fois..

Merci pour votre aide, mais j'aurai une dernière question (avant de flagué RESOLU), comme j'ai vu qu'il y a vait des utilisateur :

J'ecris mes resultats en NETCDF egalement : Je n'ai pa trouvé le moyen de renseigner la valeur par default des pixels non calculé. commetn peut on fixer la "default Value" ? j'aimerai la mettre à Nan si possible...
20/08/2009, 10h55
bouye

Suivant les normes, tu peux renseigner un attribu dans la variable :

http://www.unidata.ucar.edu/software...nventions.html

Citation:

valid_min
A scalar specifying the minimum valid value for this variable.

valid_max
A scalar specifying the maximum valid value for this variable.

_FillValue
The _FillValue attribute specifies the fill value used to pre-fill disk space allocated to the variable. Such pre-fill occurs unless no-fill mode is set using nc_set_fill in C (see nc_set_fill) or NF_SET_FILL in Fortran (see NF_SET_FILL). The fill value is returned when reading values that were never written. If _FillValue is defined then it should be scalar and of the same type as the variable. It is not necessary to define your own _FillValue attribute for a variable if the default fill value for the type of the variable is adequate. However, use of the default fill value for data type byte is not recommended. Note that if you change the value of this attribute, the changed value applies only to subsequent writes; previously written data are not changed.
Generic applications often need to write a value to represent undefined or missing values. The fill value provides an appropriate value for this purpose because it is normally outside the valid range and therefore treated as missing when read by generic applications. It is legal (but not recommended) for the fill value to be within the valid range.

For more information for C programmers see Fill Values. For more information for Fortran programmers see Fill Values.

missing_value
This attribute is not treated in any special way by the library or conforming generic applications, but is often useful documentation and may be used by specific applications. The missing_value attribute can be a scalar or vector containing values indicating missing data. These values should all be outside the valid range so that generic applications will treat them as missing.

Mais NaN en soit n'est pas vraiment une bonne valeur, tu ne peux pas utiliser (ici j'ai mis Float mais tu peux mettre Double à la place) -Float.MAX_VALUE ou Float.MAX_VALUE (note : Float.MIN_VALUE est la plus petite valeur POSITIVE) ou si tu utilises des données packed Short.MIN_VALUE ou Short.MAX_VALUE (idem avec Integer).

A voir d'ailleurs s'il n'y a pas une constante déjà définie dans l'API Java Netcdf pour ça...
20/08/2009, 11h01
HammerK

ok j'avais renseigner missing_value mais visiblement c'est _FillValue qu'il faut renseigner dans mon cas...