Pecan: problèmes d'espaces dans sipnet.out

Sûrement, quelqu'un d'autre a rencontré cela? J'ai touché ceci, jusqu'à présent, UNIQUEMENT à US-Me2...... quelqu'un d'autre?

mon "correctif" actuel est de passer de l'utilisation de PFT "boreal.coniferous" à "
temperate.needleleaf.evergreen" ce qui est plus précis de toute façon, mais c'est probablement un bogue SIPNET

Je me souviens avoir rencontré cette erreur. Cela fait un moment donc je ne me souviens pas bien des détails mais je pense que ma solution était de changer le code sipnet lui-même permettant plus de chiffres dans fprinf

@istfer Merci ! @para2x essayant d'exécuter le code SDA et cela ne se produit que pendant la configuration de mes exécutions sipnet, en particulier lors de l'utilisation du PFT boreal.coniferous. Avez-vous pu gérer des sites avec ce PFT ? Il semble que chaque fois que j'essaie d'utiliser ce PFT, cela échoue avec ce problème. Peut-être que vous utilisez le modèle binaire que @istfer a créé après avoir mis à jour le code comme elle le mentionne.

On dirait que le problème est comme vous l'avez dit avec roughRootC spécifiquement avec la valeur 5.0010000.62 . Il s'agit de la concaténation de 5.00 et 10000.62. Quelle peut être la taille de roughRootC ? À l'heure actuelle, il suppose un maximum de 9999,99. Comme @serbinsh l'a dit, nous pourrions simplement vouloir y ajouter des espaces supplémentaires pour lui permettre de s'adapter correctement. Cela ne devrait pas casser les fichiers existants.

@robkooper Je soupçonne que le problème est le paramétrage de ce PFT par pecan car j'ai trouvé de très gros paramètres résultants dans SIPNET pour les racines avec certains pfts, ce qui crée probablement ensuite de grands pools de racines dans sipnet. J'aime l'idée d'augmenter simplement le maximum... bien que cela puisse simplement permettre à plus de nombres absurdes de cracher.

Peut-être que vous utilisez le modèle binaire que @istfer a créé après avoir mis à jour le code comme elle le mentionne.

Oui. J'ai fait mes xmls basés sur Istems dont nous avons explicitement une balise dans xml qui pointe vers une version de SIPNET.

Oui, c'est un problème en général puisque maintenant je rencontre ce problème avec mes tests SDA... qui dans ce cas n'est pas lié à boreal.coniferous pft sauf, peut-être, parce que le fichier de paramètres pour IC est basé sur Bartlet qui EST-ce qu'un BC pft, @para2x? les pensées?

> require (PEcAn.SIPNET)
Loading required package: PEcAn.SIPNET
Loading required package: PEcAn.data.atmosphere
>     model2netcdf.SIPNET('/data/sserbin/Modeling/sipnet/NASA_CMS/SDA/out/ENS-00013-1000025731', 40.6658, -77.904, '1980/01/01', '2010/12/31', FALSE, 'r136')
Error in scan(file = file, what = what, sep = sep, quote = quote, dec = dec,  :
  line 11126 did not have 28 elements
Calls: model2netcdf.SIPNET -> read.table -> scan
Execution halted

Je ne connais vraiment pas assez le code SIPNET lui-même pour faire une suggestion ici.

Pas de soucis, @para2x my Q était plus sur la façon dont vous utilisez le fichier https://github.com/PecanProject/pecan/blob/develop/modules/assim.sequential/inst/MultiSite-Exs/SDA/Bartlett.param qui peut avoir une valeur param l'influence rootC qui provoque des valeurs vraiment grandes

La seule raison pour laquelle j'utilise Bartlett.param est de spécifier le bois initial de la plante qui est la première rangée. Vous pouvez essayer deux choses ici : l'une consiste à ne pas utiliser ce fichier ou à simplement conserver la première ligne.

Quelqu'un à BU, pourriez-vous me dire à quoi ressemble votre fichier sipnet.c aux lignes 782-785 et 813 ? C'est pour le numéro d'identification du modèle BETY 1000000014. Je veux voir s'il s'agit d'une version où la sortie a été modifiée

Je pense que c'est ça

le dernier nom de variable dans l'en-tête après LAI est en quelque sorte coupé, mais il devrait s'agir d'une création en bois (et notez que cela pourrait ne pas être dans d'autres fichiers sipnet.c, c'était un autre tracker que j'ai créé (j'aurais dû le déplacer sous un autre sipnet version)

void outputHeader(FILE *out) {
  fprintf(out, "Notes: (PlantWoodC, PlantLeafC, Soil and Litter in g C/m^2; Water and Snow in cm; SoilWetness is fraction of WHC;\n");
  fprintf(out, "loc year day time plantWoodC plantLeafC ");

        #if SOIL_MULTIPOOL
            int counter;

            for(counter=0; counter<NUMBER_SOIL_CARBON_POOLS; counter++) {
                fprintf(out, "soil(%8.2f) ",envi.soil[counter]);
            }
                fprintf(out,"totSoilC ");

        #else
            fprintf(out, "soil ");
        #endif

            fprintf(out, "microbeC ");
            fprintf(out, "coarseRootC fineRootC ");
  fprintf(out, "litter litterWater soilWater soilWetnessFrac snow ");
  fprintf(out, "npp nee cumNEE gpp rAboveground rSoil rRoot ra rh rtot evapotranspiration fluxestranspiration fPAR LAI ation\n");
}

// pre: out is open for writing
// print current state to output file
void outputState(FILE *out, int loc, int year, int day, double time) {


        fprintf(out,"%8d %4d %3d %5.2f %8.2f %8.2f ",loc,year,day,time,envi.plantWoodC,envi.plantLeafC);


        #if SOIL_MULTIPOOL
            int counter;

            for(counter=0; counter<NUMBER_SOIL_CARBON_POOLS; counter++) {
                fprintf(out, "%8.2f ",envi.soil[counter]);
            }
                fprintf(out,"%8.2f ",trackers.totSoilC);



        #else
            fprintf(out, "%8.2f ",envi.soil);
        #endif



            fprintf(out, "%8.2f ", envi.microbeC);

            fprintf(out, "%8.2f %8.2f", envi.coarseRootC,envi.fineRootC);

    fprintf(out, " %8.2f %8.3f %8.2f %8.3f %8.2f ",
         envi.litter, envi.litterWater, envi.soilWater, trackers.soilWetnessFrac, envi.snow);
    fprintf(out,"%8.2f %8.2f %8.2f %8.8f %8.3f %8.3f %8.3f %8.3f %8.3f %8.3f %8.8f %8.4f %8.4f %8.4f %8.4f\n", trackers.npp, trackers.nee, trackers.totNee, trackers.gpp, trackers.rAboveground,
           trackers.rSoil, trackers.rRoot, trackers.ra, trackers.rh, trackers.rtot, trackers.evapotranspiration, fluxes.transpiration, trackers.fpar, trackers.LAI, trackers.wcr);

//note without modeling root dynamics

//trackers.fa, trackers.fr, fluxes.rLeaf*climate->length,trackers.evapotranspiration

}

Ouais, pas la même chose dans mon sipnet.c, qui est la base r136

lignes 787-840

// pre: out is open for writing
// print current state to output file
void outputState(FILE *out, int loc, int year, int day, double time) {


                fprintf(out,"%8d %4d %3d %5.2f %8.2f %8.2f ",loc,year,day,time,envi.plantWoodC,envi.plantLeafC);


                #if SOIL_MULTIPOOL
                        int counter;

                        for(counter=0; counter<NUMBER_SOIL_CARBON_POOLS; counter++) {
                                fprintf(out, "%8.2f ",envi.soil[counter]);
                        }
                                fprintf(out,"%8.2f ",trackers.totSoilC);



                #else
                        fprintf(out, "%8.2f ",envi.soil);
                #endif



                        fprintf(out, "%8.2f", envi.microbeC);

                        fprintf(out, "%8.2f %8.2f", envi.coarseRootC,envi.fineRootC);

        fprintf(out, " %8.2f %8.3f %8.2f %8.3f %8.2f ",
                 envi.litter, envi.litterWater, envi.soilWater, trackers.soilWetnessFrac, envi.snow);
        fprintf(out,"%8.2f %8.2f %8.2f %8.2f %8.3f %8.3f %8.3f %8.3f %8.3f %8.3f %8.8f %8.4f %8.4f\n", trackers.npp, trackers.nee, trackers.totNee, trackers.gpp, trackers.rAboveground,
           trackers.rSoil, trackers.rRoot, trackers.ra, trackers.rh, trackers.rtot, trackers.evapotranspiration, fluxes.transpiration, trackers.fpar);

//note without modeling root dynamics

//trackers.fa, trackers.fr, fluxes.rLeaf*climate->length,trackers.evapotranspiration
}

void outputStatecsv(FILE *out, int loc, int year, int day, double time) {
  fprintf(out, "%8d , %4d , %3d , %5.2f , %8.2f , %8.2f , ", loc, year, day, time,
                envi.plantWoodC, envi.plantLeafC);

        #if SOIL_MULTIPOOL
                fprintf(out, "%8.2f ,", trackers.totSoilC);
        #else
                fprintf(out, "%8.2f ,", envi.soil);
        #endif

        fprintf(out, "%8.2f , %8.3f, %8.2f , %8.3f , %8.2f , %8.2f , %8.2f , %8.2f , %8.2f , %8.3f , %8.3f , %8.3f, %8.3f , %8.3f , %8.3f %8.8f %8.4f %8.4f\n",
          envi.litter, envi.litterWater, envi.soilWater, trackers.soilWetnessFrac, envi.snow,
          trackers.npp, trackers.nee, trackers.totNee, trackers.gpp, trackers.rAboveground, trackers.rSoil, trackers.rRoot, trackers.ra, trackers.rh, trackers.rtot, trackers.evapotranspiration, fluxes.transpiration, trackers.fpar);

}

Je vais d'abord essayer d'augmenter la taille de sortie de roughRootC dans sipnet.C à quelque chose comme 9.2f; pas sûr que nous devrions l'augmenter plus grand que cela

Mon intuition est que le write.table a un format spécifique pour un nombre à virgule flottante (4,2%f est ce qu'il semble) et il en résulte un fichier invalide (encore en train d'expérimenter avec cela).

@robkooper pas sûr de comprendre... voulez-vous dire read.table? J'ai changé pour 9.4f et jusqu'à présent, je n'ai pas encore rencontré l'erreur pour le même combo site/pft

c'est-à-dire dans le fichier sipnet.C pour la variable de sortie roughRootC

Oui . n'a pas aidé. Je suppose que nous avons juste besoin d'augmenter les espaces blancs

J'essaie de comprendre comment le fichier que vous avez collé a été créé. Est-ce que cela a été créé par PEcAn ? J'ai essayé d'exécuter la même exécution et généré le fichier d'entrée (https://pecan-docker.ncsa.illinois.edu/minio/dbfiles/CRUNCEP_SIPNET_site_0-763/) Je ne vois pas ce problème dans le fichier là-bas. Les chiffres doivent être séparés par des tabulations, pas d'espace.

@bailsofhay FYI - cela pourrait être la cause de vos mystérieux plantages SIPNET. Nous devrions enquêter davantage

Tenter de résoudre ce problème en mettant à jour sipnet.C

        fprintf(out,"%8.2f %8.2f %8.2f %8.8f %8.3f %8.3f %8.3f %8.3f %8.3f %8.3f %8.8f %8.4f %8.4f %8.4f\n", trackers.npp, trackers.nee, trackers.totNee, trackers.gpp, trackers.rAboveground,
           trackers.rSoil, trackers.rRoot, trackers.ra, trackers.rh, trackers.rtot, trackers.evapotranspiration, fluxes.transpiration, trackers.fpar, trackers.LAI);

changé 4 à 8.8

également ajouté trackers.LAI basé sur l'exemple @istfer

J'ai mis à jour l'en-tête :

void outputHeader(FILE *out) {
  fprintf(out, "Notes: (PlantWoodC, PlantLeafC, Soil and Litter in g C/m^2; Water and Snow in cm; SoilWetness is fraction of WHC);\n");
  fprintf(out, "loc year day time plantWoodC plantLeafC ");

        #if SOIL_MULTIPOOL
                        int counter;

                        for(counter=0; counter<NUMBER_SOIL_CARBON_POOLS; counter++) {
                                fprintf(out, "soil(%8.2f) ",envi.soil[counter]);
                        }
                                fprintf(out,"totSoilC ");

                #else
                        fprintf(out, "soil ");
                #endif

                        fprintf(out, "microbeC ");
                        fprintf(out, "coarseRootC fineRootC ");
  fprintf(out, "litter litterWater soilWater soilWetnessFrac snow ");
  fprintf(out, "npp nee cumNEE gpp rAboveground rSoil rRoot ra rh rtot evapotranspiration fluxestranspiration fPAR LAI\n");
}

OK, donc cela a fonctionné, sauf que je trouve un décalage entre ce que PEcAn fournit pour LAI dans les fichiers nc et ce qui est dans la colonne LAI de la sortie SIPNET. Je sais que c'est un problème que @istfer et @mdietze ont déjà signalé, mais j'oublie comment nous devrions y remédier. Donc 1) où PEcAn obtient-il LAI, calcule-t-il plutôt après coup en utilisant d'autres données de sortie au lieu de supposer que LAI est sorti de SIPNET? 2) devrions-nous utiliser le LAI calculé ou le LAI craché de SIPNET après avoir ajouté le trackers.LAI ? 3) Pour SDA, que devrions-nous utiliser car cela peut être une raison de l'étrangeté des exécutions SIPNET

Donc par exemple, voici la sortie LAI 2010 en SIPET (depuis sipnet.out), entre 0,2 et ~23 m2/m2 MAIS voici la sortie PEcAN LAI

@istfer avez-vous utilisé SIPNET LAI ou PEcAn LAI calculé ?

OK, hmmm... aussi SIPNET LAI ne va pas à 0... oscille souvent autour de 0,1 ou 0,2, mais parfois jusqu'à 0,5 en hiver ?! Pour un site à feuilles larges

Je parlerai à @istem aujourd'hui pour voir si elle se souvient du correctif pour les valeurs LAI signet vs pecan

Voici un nouveau problème qui, je pense, est lié à cela depuis que nous avons modifié le fichier signet.c

loc year day time plantWoodC plantLeafC soil microbeC coarseRootC fineRootC litter litterWater soilWater soilWetnessFrac snow npp nee cumNEE gpp rAboveground rSoil rRoot ra rh rtot evapotranspiration fluxestranspiration fPAR LAI
       0 2002 197  0.00 15311.11     0.00 143942.45    71.97 911070.92 23093.15   280.00    0.500     6.89    0.537     0.08   -17.83    64.48    64.48 0.00000000    0.128   64.356   17.699   17.827   46.657   64.484 0.00697267   0.0000   0.0000   0.0000
       0 2002 197  6.00 15310.95     0.00 143943.92    71.97 911018.37 23072.85   280.00    0.500     6.96    0.577     0.00   -17.85    71.53   136.02 0.00000000    0.126   71.408   17.721   17.846   53.687   71.533 0.00000001   0.0000   0.0000   0.0000
       0 2002 197 12.00 15310.74     0.00 143944.66    71.97 910965.80 23052.57   280.00    0.500     6.92    0.578     0.00   -17.92    72.31   208.33 -0.00000000    0.165   72.148   17.752   17.917   54.396   72.313 0.03588458   0.0000   0.0000   0.0000
       0 2002 197 18.00 15310.55     0.00 143946.14    71.97 910913.31 23032.32   280.00    0.500     6.89    0.575     0.00   -17.82    71.45   279.78 -0.00000000    0.156   71.297   17.661   17.816   53.637   71.453 0.03566278   0.0000   0.0000   0.0000
       0 2002 198  0.00 15310.39     0.00 143948.22    71.97 910860.90 23012.08   280.00    0.500     6.85    0.572     0.00   -17.72    70.74   350.53 0.00000000    0.128   70.616   17.596   17.723   53.020   70.743 0.03615626   0.0000   0.0000   0.0000
       0 2002 198  6.00 15310.23     0.00 143950.43    71.97 910808.46 22991.85   280.00    0.500     6.81    0.569     0.00   -17.74    70.61   421.14 0.00000000    0.125   70.483   17.618   17.743   52.866   70.609 0.03677418   0.0000   0.0000   0.0000
       0 2002 198 12.00 15310.01     0.00 143952.75    71.97 910755.99 22971.65   280.00    0.500     6.79    0.567     0.00   -17.82    70.57   491.71 -0.00000000    0.176   70.393   17.647   17.824   52.746   70.569 0.02752184   0.0000   0.0000   0.0000
       0 2002 198 18.00 15309.82     0.00 143955.88    71.97 910703.65 22951.46   280.00    0.500     6.76    0.564     0.00   -17.69    69.60   561.30 -0.00000000    0.160   69.436   17.527   17.687   51.909   69.596 0.02520775   0.0000   0.0000   0.0000
       0 2002 199  0.00 15309.65     0.00 143959.58    71.97 910651.39 22931.30   280.00    0.500     6.73    0.562     0.00   -17.58    68.90   630.20 0.00000000    0.135   68.762   17.449   17.584   51.314   68.897 0.02564393   0.0000   0.0000   0.0000
       0 2002 199  6.00 15309.48     0.00 143963.49    71.97 910599.13 22911.15   280.00    0.500     6.71    0.560     0.00   -17.58    68.67   698.87 0.00000000    0.134   68.540   17.443   17.577   51.097   68.674 0.02672652   0.0000   0.0000   0.0000
       0 2002 199 12.00 15309.28     0.00 143967.57    71.97 910546.87 22891.02   280.00    0.500     6.87    0.566     0.00   -17.60    68.50   767.37 0.00000000    0.159   68.341   17.441   17.600   50.900   68.501 0.03973389   0.0000   0.0000   0.0000
       0 2002 199 18.00 15309.10     0.00 143970.78    71.97 910494.70 22870.90   280.00    0.500     6.99    0.578     0.00   -17.51    69.26   836.63 0.00000000    0.145   69.112   17.363   17.508   51.748   69.256 0.03744034   0.0000   0.0000   0.0000

Pourquoi obtenons-nous des valeurs de -0,000 pour AGB ????

C'est l'arrondi. La valeur réelle est négative mais > -0.0000000005. Et les en-têtes de colonnes sont délimités, non alignés, donc je ne pense pas que ce soit en fait AGB

Changer cela pour être la notation sci maintenant. Sera mis à jour une fois corrigé

changer la colonne 19 (gpp) en : %8.3e

OK, donc en fait j'ai fait une erreur avant. Ce que je dois faire, c'est corriger deux colonnes différentes.

Le premier pour résoudre le problème initial, que les cols 8 et 9 fusionnent parfois car il n'y a pas assez d'espace et le second est la notation pour GPP (col 19).

@serbinsh Il semble que nous devions penser un peu plus à la GPP en plus du problème de la notation scientifique. Je cherchais dans mon fichier signet.out l'ensemble qui a échoué, et il n'y a pas de points négatifs dans cette exécution, mais l'espacement des colonnes est perturbé plus tard dans l'année lorsque les valeurs GPP sont passées du chiffre 1 au chiffre 10. Voici un exemple (les colonnes sont les mêmes que l'exemple que j'ai posté ci-dessus :
0 2000 221 18.00 14575.71 113.85 56661.11 17.39 0.00 285788.90 280.00 0.500 10.78 0.898 0.00 4.43 18.77 1947.13 7.93938489 2.561 24.148 0.951 3.512 23.197 26.709 0.17197340 0.6069 0.5578 3.8823 0 2000 222 0.00 14579.71 114.58 56875.78 17.39 0.00 285551.70 280.00 0.500 10.69 0.894 0.00 5.23 17.92 1965.05 8.50201393 2.330 24.090 0.941 3.271 23.149 26.420 0.09273126 0.3709 0.5594 3.9070 0 2000 222 6.00 14583.60 115.44 57090.45 17.39 0.00 285314.87 280.00 0.500 10.59 0.887 0.00 5.41 17.54 1982.59 8.63300350 2.283 23.893 0.935 3.218 22.957 26.176 0.09346984 0.3566 0.5613 3.9363 0 2000 222 12.00 14585.45 116.43 57305.10 17.39 0.00 285078.41 280.00 0.500 10.68 0.886 0.00 3.68 19.10 2001.69 7.51178589 2.897 23.716 0.931 3.828 22.785 26.612 0.20875203 0.7065 0.5635 3.9701 0 2000 222 18.00 14588.05 117.52 57519.55 17.39 0.00 284842.29 280.00 0.500 10.78 0.894 0.00 4.67 18.13 2019.82 8.21516699 2.635 23.712 0.915 3.550 22.797 26.347 0.17083126 0.5641 0.5660 4.0074 0 2000 223 0.00 14591.06 118.73 57733.69 17.39 0.00 284606.53 280.00 0.500 10.68 0.894 0.00 5.36 17.57 2037.39 8.70971254 2.447 23.830 0.904 3.351 22.926 26.277 0.10070652 0.4028 0.5688 4.0487 0 2000 223 6.00 14594.25 120.08 57947.87 17.39 0.00 284371.14 280.00 0.500 10.59 0.886 0.00 5.84 16.85 2054.24 9.03531674 2.297 23.590 0.898 3.195 22.693 25.888 0.08617136 0.3222 0.5718 4.0945 0 2000 223 12.00 14595.80 121.57 58162.01 17.39 0.00 284136.13 280.00 0.500 10.74 0.889 0.00 4.53 18.02 2072.27 8.22739039 2.807 23.443 0.894 3.702 22.549 26.251 0.20809168 0.6766 0.5752 4.1453 0 2000 223 18.00 14597.85 123.17 58375.78 17.39 0.00 283901.48 280.00 0.500 10.96 0.904 0.00 5.29 17.45 2089.72 8.77340379 2.601 23.622 0.882 3.483 22.741 26.223 0.19588011 0.5974 0.5788 4.2000 0 2000 224 0.00 14600.46 124.91 58588.93 17.39 0.00 283667.19 280.00 0.500 11.04 0.917 0.00 6.16 17.01 2106.73 9.39612713 2.366 24.045 0.873 3.239 23.171 26.411 0.10046154 0.3110 0.5827 4.2592 0 2000 224 6.00 14603.09 126.79 58801.70 17.39 0.00 283433.30 280.00 0.500 10.96 0.916 0.00 6.52 16.85 2123.58 9.65203856 2.265 24.233 0.870 3.135 23.363 26.497 0.08316609 0.2768 0.5868 4.3235 0 2000 224 12.00 14604.52 128.70 59014.36 17.39 0.00 283199.63 280.00 0.500 11.10 0.919 0.00 5.37 17.92 2141.49 9.03953546 2.803 24.153 0.869 3.672 23.284 26.956 0.18632810 0.6005 0.5912 4.3884 0 2000 224 18.00 14606.58 130.63 59226.61 17.39 0.00 282966.20 280.00 0.500 11.23 0.930 0.00 6.07 17.43 2158.92 9.52919823 2.598 24.361 0.859 3.457 23.502 26.959 0.17821633 0.5664 0.5956 4.4545 0 2000 225 0.00 14609.44 132.61 59438.41 17.39 0.00 282733.02 280.00 0.500 11.21 0.935 0.00 6.95 16.80 2175.73 10.11249382 2.305 24.612 0.853 3.158 23.759 26.917 0.12228206 0.3314 0.6000 4.5217 0 2000 225 6.00 14612.64 134.62 59649.97 17.39 0.00 282500.08 280.00 0.500 11.09 0.929 0.00 7.40 16.42 2192.15 10.36770066 2.118 24.668 0.854 2.972 23.814 26.786 0.11599917 0.2490 0.6044 4.5903 0 2000 225 12.00 14614.56 136.67 59861.39 17.39 0.00 282267.39 280.00 0.500 10.89 0.916 0.00 6.20 17.55 2209.70 9.75227886 2.691 24.614 0.859 3.549 23.756 27.305 0.23872529 0.8320 0.6088 4.6604 0 2000 225 18.00 14617.15 138.80 60073.06 17.39 0.00 282035.00 280.00 0.500 10.74 0.901 0.00 7.05 16.27 2225.97 10.32246739 2.422 24.175 0.853 3.275 23.322 26.597 0.23678459 0.7050 0.6132 4.7330 0 2000 226 0.00 14620.34 140.99 60284.78 17.39 0.00 281802.87 280.00 0.500 10.61 0.889 0.00 7.78 15.30 2241.28 10.81901992 2.186 23.938 0.853 3.039 23.085 26.124 0.14153777 0.3429 0.6176 4.8077 0 2000 226 6.00 14623.66 143.24 60496.39 17.39 0.00 281571.01 280.00 0.500 10.47 0.879 0.00 8.03 14.98 2256.26 10.99722667 2.109 23.865 0.858 2.968 23.007 25.975 0.13726935 0.2748 0.6221 4.8842 0 2000 226 12.00 14623.64 145.53 60707.87 17.39 0.00 281339.40 280.00 0.500 10.35 0.868 0.00 4.81 18.13 2274.39 8.49493616 2.818 23.811 0.866 3.685 22.944 26.629 0.28877915 0.9217 0.6267 4.9626 0 2000 226 18.00 14625.66 147.86 60919.42 17.39 0.00 281108.02 280.00 0.500 10.26 0.859 0.00 6.91 15.78 2290.17 10.38533933 2.612 23.551 0.862 3.474 22.690 26.164 0.29844127 0.9112 0.6312 5.0419 0 2000 227 0.00 14628.99 150.24 61130.90 17.39 0.00 280876.90 280.00 0.500 10.19 0.852 0.00 8.34 14.22 2304.39 11.49566120 2.293 23.421 0.861 3.154 22.560 25.714 0.16840103 0.4209 0.6357 5.1229 0 2000 227 6.00 14632.40 152.68 61342.16 17.39 0.00 280646.05 280.00 0.500 10.03 0.842 0.00 8.56 14.04 2318.43 11.70045859 2.271 23.474 0.867 3.139 22.607 25.745 0.15826026 0.3612 0.6403 5.2061 0 2000 227 12.00 14629.28 155.18 61553.35 17.39 0.00 280415.47 280.00 0.500 9.89 0.830 0.00 2.16 20.32 2338.75 6.26260256 3.230 23.352 0.875 4.105 22.477 26.582 0.27769493 0.8826 0.6448 5.2914 0 2000 227 18.00 14626.96 157.65 61764.71 17.39 0.00 280185.05 280.00 0.500 9.65 0.815 0.00 2.90 19.22 2357.97 6.84262945 3.074 22.989 0.867 3.941 22.122 26.063 0.26190036 0.8707 0.6494 5.3757 0 2000 228 0.00 14630.43 160.08 61976.42 17.39 0.00 279954.77 280.00 0.500 9.43 0.795 0.00 8.61 12.97 2370.94 12.07581213 2.600 22.446 0.862 3.462 21.585 25.046 0.22249240 0.7077 0.6538 5.4586 0 2000 228 6.00 14634.17 162.58 62188.30 17.39 0.00 279724.77 280.00 0.500 9.27 0.779 0.00 9.03 12.19 2383.14 12.42523436 2.528 22.092 0.865 3.393 21.227 24.619 0.16641807 0.5000 0.6580 5.5438 0 2000 228 12.00 14627.63 165.14 62400.19 17.39 0.00 279495.04 280.00 0.500 9.05 0.763 0.00 -1.10 22.13 2405.26 3.72972367 3.961 21.894 0.870 4.831 21.024 25.855 0.22022551 0.8153 0.6623 5.6311 0 2000 228 18.00 14622.48 167.59 62612.55 17.39 0.00 279265.37 280.00 0.500 8.82 0.744 0.00 0.03 20.34 2425.60 4.51935059 3.632 21.223 0.856 4.488 20.367 24.855 0.22887585 0.7960 0.6666 5.7145 0 2000 229 0.00 14625.24 169.92 62825.31 17.39 0.00 279035.75 280.00 0.500 8.60 0.725 0.00 7.72 12.05 2437.65 11.61133388 3.047 20.616 0.846 3.893 19.771 23.663 0.22073243 0.7758 0.6706 5.7941 0 2000 229 6.00 14629.30 172.29 63038.32 17.39 0.00 278806.37 280.00 0.500 8.40 0.708 0.00 9.10 10.23 2447.88 12.96732463 3.023 20.172 0.844 3.867 19.328 23.195 0.19535639 0.6865 0.6743 5.8748 0 2000 229 12.00 14621.47 174.70 63251.53 17.39 0.00 278577.25 280.00 0.500 8.20 0.692 0.00 -2.68 21.64 2469.51 2.74794197 4.588 19.798 0.843 5.432 18.954 24.386 0.20192009 0.7392 0.6781 5.9572 0 2000 229 18.00 14616.93 176.95 63465.20 17.39 0.00 278348.13 280.00 0.500 8.38 0.691 0.00 0.26 18.03 2487.54 4.97890595 3.889 19.115 0.825 4.714 18.290 23.004 0.23649558 0.7214 0.6818 6.0340 0 2000 230 0.00 14622.07 179.08 63678.37 17.39 0.00 278119.05 280.00 0.500 8.22 0.691 0.00 9.69 8.91 2496.45 13.60916949 3.107 19.411 0.814 3.921 18.598 22.519 0.16278224 0.5916 0.6852 6.1066 0 2000 230 6.00 14627.67 181.27 63891.65 17.39 0.00 277890.24 280.00 0.500 8.13 0.681 0.00 10.26 8.04 2504.49 13.96623695 2.889 19.113 0.813 3.703 18.300 22.003 0.12493134 0.4129 0.6884 6.1811 0 2000 230 12.00 14620.98 183.51 64104.82 17.39 0.00 277661.68 280.00 0.500 7.94 0.670 0.00 -1.88 20.11 2524.60 3.22887897 4.295 19.047 0.816 5.112 18.230 23.342 0.18911457 0.7155 0.6916 6.2575

@bailsofhay ce n'est pas vraiment un problème et cela arrive assez souvent. Les problèmes que j'ai postés sont plus sérieux, 1) pas assez d'espacement entre les colonnes de sorte que deux colonnes fusionnent et alors PEcAN ne peut pas trouver le bon nombre de colonnes. L'autre problème est l'erreur d'arrondi possible pour GPP. Ce que vous montrez ci-dessus est extrêmement courant pour sipnet et jusqu'à présent, je l'ai ignoré, mais c'est peut-être un problème? J'ai supposé que non. Autres?

@serbinsh Je pense que c'est un peu faux. Si vous regardez certaines des autres colonnes où le nombre de chiffres avant la virgule augmente, les nombres décimaux restent alignés et les nombres à gauche de la décimale se déplacent. GPP est le contraire, où les chiffres à gauche de la virgule sont alignés, mais les nombres à droite de la virgule ne sont plus alignés. Vous avez peut-être raison de dire que ce n'est pas vraiment un problème, mais il est possible que ce soit le problème qui fait planter certaines courses. Je vais regarder certaines des exécutions réussies et voir s'ils ont le changement avec les chiffres alignés, et s'ils existent dans d'autres fichiers, alors ce n'est probablement pas un problème

@bailsofhay, la raison pour laquelle je ne pense pas que ce soit un problème est que PEcAn échouerait si le nombre de colonnes n'atteignait pas 28 ou ne s'alignait pas. Recherchez donc cette erreur dans les journaux, si vous ne la trouvez pas, ce n'est pas un problème

De plus, je viens de mettre à jour sipnet pour utiliser la notation sci pour GPP, cela peut également résoudre ce problème, veuillez essayer de réexécuter votre SDA

kk fera l'affaire. J'ai également vérifié certaines des autres exécutions et les chiffres ont changé comme un échec, mais tous les espaces sont là, donc vous avez raison. ce n'est pas un problème.

Ce numéro est périmé car il a été ouvert 365 jours sans activité.