Pecan: Les fichiers BrownDog/NARR sipnet.clim ne sont pas générés correctement

Fait intéressant, le pilote créé apparaît en option si vous revenez au même combo site/modèle

De plus, je ne sais pas si c'est ce qui est censé se produire, mais un dossier sipnet.clim a été créé au niveau supérieur du dossier de flux de travail de noix de pécan, comme indiqué ici :

[sserbin<strong i="6">@modex</strong> PEcAn_2000000991]$ ll
total 932
-rw-r--r--. 1 apache test    100 Aug 17 11:44 ensemble.output.2000001031.NPP.2002.2004.Rdata
-rw-r--r--. 1 apache test    785 Aug 17 11:43 ensemble.samples.2000001031.Rdata
drwxr-sr-x. 3 apache test     31 Aug 17 11:43 out
-rw-r--r--. 1 apache test   2957 Aug 17 11:41 pecan.CHECKED.xml
-rw-r--r--. 1 apache test   3195 Aug 17 11:43 pecan.CONFIGS.xml
-rw-r--r--. 1 apache test   3114 Aug 17 11:42 pecan.METProcess.xml
-rw-r--r--. 1 apache test   3155 Aug 17 11:42 pecan.TRAIT.xml
-rw-rw-r--. 1 apache test   2151 Aug 17 11:41 pecan.xml
drwxr-sr-x. 3 apache test     51 Aug 17 11:41 pft
drwxr-sr-x. 3 apache test     50 Aug 17 11:43 run
-rw-r--r--. 1 apache test 871702 Aug 17 11:43 samples.Rdata
drwxr-sr-x. 2 apache test     10 Aug 17 11:41 sipnet.clim
-rw-r--r--. 1 apache test    371 Aug 17 11:44 STATUS
-rw-rw-r--. 1 apache test   6320 Aug 17 11:41 workflow.R
-rw-r--r--. 1 apache test  39635 Aug 17 11:44 workflow.Rout

Mais le dossier est vide

Voici à quoi ressemble un dossier d'exécution :

[sserbin<strong i="6">@modex</strong> 2000075070]$ ll
total 20
-rwxr-xr-x. 1 apache test 1767 Aug 17 11:43 job.sh
-rw-r--r--. 1 apache test  664 Aug 17 11:43 README.txt
lrwxrwxrwx. 1 apache test   67 Aug 17 11:43 sipnet.clim -> /data/Model_Output/pecan.output/dbfiles/BD-10704043b8b7/sipnet.clim
-rw-r--r--. 1 apache test 2750 Aug 17 11:43 sipnet.in
-rw-r--r--. 1 apache test 2767 Aug 17 11:43 sipnet.param
-rw-r--r--. 1 apache test    1 Aug 17 11:43 sipnet.param-spatial

D'après un commentaire de @robkooper sur Slack, il semble que le fichier renvoyé soit un fichier .zip sans l'extension correcte. Si je renomme le fichier, je peux extraire avec succès le fichier de données qui est un fichier sipnet.clim correctement formaté.

[sserbin<strong i="7">@modex</strong> BD-10704043b8b7]$ sudo mv sipnet.clim sipnet.clim.zip
[sudo] password for sserbin:
[sserbin<strong i="8">@modex</strong> BD-10704043b8b7]$ ll
total 500
-rw-r--r--. 1 apache test 508617 Aug 17 11:42 sipnet.clim.zip

[sserbin<strong i="9">@modex</strong> BD-10704043b8b7]$ sudo unzip sipnet.clim.zip
Archive:  sipnet.clim.zip
  inflating: NARR.2002-01-01.2004-12-31.clim
[sserbin<strong i="10">@modex</strong> BD-10704043b8b7]$ ll
total 1780
-rw-r--r--. 1 root   test 1309045 Aug 17 10:42 NARR.2002-01-01.2004-12-31.clim
-rw-r--r--. 1 apache test  508617 Aug 17 11:42 sipnet.clim.zip

0       2002    1       0       0.125   -7.9094299316406        -2.44315996314612       0       0.000804662704467773    106.125279746456        279.20088185235 231.658948408484        5.31823073993271        0.6
0       2002    1       3       0.125   -9.32294311523435       -2.39741738404251       0       -0.0412188470363617     75.1397549593781        285.159348289328        227.559947202096        5.60749023697066        0.6
0       2002    1       6       0.125   -10.5312866210937       -2.33946353060725       0       -0.0244013965129852     55.1456123301122        294.838635604529        220.208121240694        5.00348134365326        0.6
0       2002    1       9       0.125   -11.3368286132812       -2.27091310812966       0       -0.0244013965129852     35.953950127431 295.342434940375        222.430670123902        5.07081553376126        0.6
0       2002    1       12      0.125   -12.4007629394531       -2.19504814728271       628398.237304688        0.0848717987537384      19.7246218935274        303.128231282344        217.696640681874        4.52785957682463        0.6
0       2002    1       15      0.125   -8.40720214843748       -2.10964517251597       1622754.71191406        0.000804662704467773    67.3028051574853        265.95481312816 257.728592667697        6.00752887354068        0.6
0       2002    1       18      0.125   -5.53836669921873       -2.05694625720645       1374894.71191406        0.00921338796615601     109.890647291759        230.4657112397  295.058308799463        6.37520017434981        0.6
0       2002    1       21      0.125   -4.0488342285156        -2.02781320104941       58806.474609375 0.0176221132278442      132.242433885207        205.770433990006        320.831082348398        5.77486085931632        0.6
0       2002    2       0       0.125   -5.8043273925781        -2.01090098947708       0       0.00921338796615601     68.1552254424385        198.632733047786        328.702943023655        5.63152559393685        0.6
0       2002    2       3       0.125   -6.48831787109373       -1.97915701994827       0       0.000804662704467773    57.8740762854741        209.776452022241        318.84142518764 4.74670963477183        0.6 ...

Exécutez-le à nouveau et voyez qu'il y a maintenant deux fichiers BD clim différents dans le fichier .zip mal nommé

[sserbin<strong i="6">@modex</strong> BD-650a29c32afa]$ ll
total 3556
-rw-r--r--. 1 root   test 2191869 Aug 17 11:37 NARR.2000-01-01.2004-12-31.clim
-rw-r--r--. 1 root   test  439523 Aug 17 09:57 NARR.2004-01-01.2004-12-31.clim
-rw-r--r--. 1 apache test 1003128 Aug 17 12:37 sipnet.clim.zip

Un autre problème est que le lien symbolique utilisé dans job.sh ne correspond pas aux noms de fichiers :

[sserbin<strong i="10">@modex</strong> 2000075302]$ ll
total 20
-rwxr-xr-x. 1 apache test 1768 Aug 17 12:37 job.sh
-rw-r--r--. 1 apache test  673 Aug 17 12:37 README.txt
lrwxrwxrwx. 1 apache test   67 Aug 17 12:37 sipnet.clim -> /data/Model_Output/pecan.output/dbfiles/BD-650a29c32afa/sipnet.clim
-rw-r--r--. 1 apache test 2750 Aug 17 12:37 sipnet.in
-rw-r--r--. 1 apache test 2771 Aug 17 12:37 sipnet.param
-rw-r--r--. 1 apache test    1 Aug 17 12:37 sipnet.param-spatial

# see if application needs running
if [ ! -e "/data/Model_Output/pecan.output/PEcAn_2000000994/out/2000075302/sipnet.out" ]; then
  cd "/data/Model_Output/pecan.output/PEcAn_2000000994/run/2000075302"
  ln -s "/data/Model_Output/pecan.output/dbfiles/BD-650a29c32afa/sipnet.clim" sipnet.clim
...

Une vérification rapide de ce que je pense devrait être la façon dont il est configuré:

[sserbin<strong i="6">@modex</strong> 2000075302]$ sudo ln -s /data/Model_Output/pecan.output/dbfiles/BD-650a29c32afa/NARR.2000-01-01.2004-12-31.clim sipnet.clim
[sserbin<strong i="7">@modex</strong> 2000075302]$ ll
total 20
-rwxr-xr-x. 1 apache test 1768 Aug 17 12:37 job.sh
-rw-r--r--. 1 apache test  673 Aug 17 12:37 README.txt
lrwxrwxrwx. 1 root   test   87 Aug 17 12:42 sipnet.clim -> /data/Model_Output/pecan.output/dbfiles/BD-650a29c32afa/NARR.2000-01-01.2004-12-31.clim
-rw-r--r--. 1 apache test 2750 Aug 17 12:37 sipnet.in
-rw-r--r--. 1 apache test 2771 Aug 17 12:37 sipnet.param
-rw-r--r--. 1 apache test    1 Aug 17 12:37 sipnet.param-spatial

[sserbin<strong i="8">@modex</strong> 2000075302]$ sudo ./job.sh

[sserbin<strong i="9">@modex</strong> out]$ cd 2000075302
[sserbin<strong i="10">@modex</strong> 2000075302]$ ll
total 3456
-rw-r--r--. 1 apache test      1293 Aug 17 12:43 logfile.txt
-rw-r--r--. 1 root   test       673 Aug 17 12:43 README.txt
-rw-r--r--. 1 root   test   3523496 Aug 17 12:43 sipnet.out
-rw-------. 1 apache apache       0 Aug 17 12:37 stderr.log
-rw-------. 1 apache apache     119 Aug 17 12:37 stdout.log

[sserbin<strong i="11">@modex</strong> 2000075302]$ ll
total 5956
-rw-rw-r--. 1 sserbin test    507576 Aug 17 12:48 2000.nc
-rw-rw-r--. 1 sserbin test       743 Aug 17 12:48 2000.nc.var
-rw-rw-r--. 1 sserbin test    506200 Aug 17 12:48 2001.nc
-rw-rw-r--. 1 sserbin test       743 Aug 17 12:48 2001.nc.var
-rw-rw-r--. 1 sserbin test    506200 Aug 17 12:48 2002.nc
-rw-rw-r--. 1 sserbin test       743 Aug 17 12:48 2002.nc.var
-rw-rw-r--. 1 sserbin test    506200 Aug 17 12:48 2003.nc
-rw-rw-r--. 1 sserbin test       743 Aug 17 12:48 2003.nc.var
-rw-rw-r--. 1 sserbin test    507576 Aug 17 12:48 2004.nc
-rw-rw-r--. 1 sserbin test       743 Aug 17 12:48 2004.nc.var
-rwxrwxrwx. 1 apache  test        16 Aug 17 12:46 logfile.txt
-rwxrwxrwx. 1 root    test       673 Aug 17 12:46 README.txt
-rwxrwxrwx. 1 root    test   3523496 Aug 17 12:43 sipnet.out
-rwxrwxrwx. 1 apache  apache       0 Aug 17 12:37 stderr.log
-rwxrwxrwx. 1 apache  apache     119 Aug 17 12:37 stdout.log

@robkooper avez-vous eu le temps d'examiner les problèmes de BD avec NARR ?

Je pense que cela a peut-être été corrigé avec #2039, je vais devoir tester cela.

tu choisis quelle année?
un an ou plusieurs ?

@robkooper vient de réessayer et a obtenu ceci :

prerun
Error: no climate data in sipnet.clim
mv: cannot stat `/data/Model_Output/pecan.output/PEcAn_2000001054/run/2000079623/sipnet.out': No such file or directory

Voici le répertoire, qui semble en fait mieux cette fois :

[sserbin<strong i="10">@modex</strong> run]$ cd 2000079623/
[sserbin<strong i="11">@modex</strong> 2000079623]$ ll
total 20
-rwxr-xr-x. 1 apache test 1767 Sep 14 08:09 job.sh
-rw-r--r--. 1 apache test  663 Sep 14 08:09 README.txt
lrwxrwxrwx. 1 apache test   67 Sep 14 08:10 sipnet.clim -> /data/Model_Output/pecan.output/dbfiles/BD-9ac83554512c/sipnet.clim
-rw-r--r--. 1 apache test 2750 Sep 14 08:09 sipnet.in
-rw-r--r--. 1 apache test 2757 Sep 14 08:09 sipnet.param
-rw-r--r--. 1 apache test    1 Sep 14 08:09 sipnet.param-spatial

Mais rien dans le fichier ??

[sserbin<strong i="15">@modex</strong> 2000079623]$ cd /data/Model_Output/pecan.output/dbfiles/BD-9ac83554512c/
[sserbin<strong i="16">@modex</strong> BD-9ac83554512c]$ ll
total 0
-rw-r--r--. 1 apache test 0 Sep 14 08:08 sipnet.clim
[sserbin<strong i="17">@modex</strong> BD-9ac83554512c]$

À partir du workflow.log

> 
> # Do conversions
> settings <- PEcAn.utils::do_conversions(settings)
2018-09-14 08:06:24 DEBUG  [PEcAn.utils::do_conversions] : 
   do.conversion outdir /data/Model_Output/pecan.output/dbfiles 
2018-09-14 08:06:24 INFO   [PEcAn.utils::do_conversions] : PROCESSING:  met 
2018-09-14 08:06:24 INFO   [PEcAn.utils::do_conversions] : 
   calling met.process: 
2018-09-14 08:06:28 INFO   [browndog.met] : 
   browndog download url : 
   http://dap.ncsa.illinois.edu:8184/file/20285355_pecan.clim 
2018-09-14 08:08:29 WARN   [PEcAn.DB::db.close] : 
   Connection created outside of PEcAn.DB package 
2018-09-14 08:08:29 DEBUG  [PEcAn.utils::do_conversions] : 
   updated met path: 
   /data/Model_Output/pecan.output/dbfiles/BD-9ac83554512c/sipnet.clim 
> 
> # Query the trait database for data and priors
> if (PEcAn.utils::status.check("TRAIT") == 0){
+   PEcAn.utils::status.start("TRAIT")
+   settings <- PEcAn.workflow::runModule.get.trait.data(settings)
+   PEcAn.settings::write.settings(settings, outputfile='pecan.TRAIT.xml')
+   PEcAn.utils::status.end()
+ } else if (file.exists(file.path(settings$outdir, 'pecan.TRAIT.xml'))) {
+   settings <- PEcAn.settings::read.settings(file.path(settings$outdir, 'pecan.TRAIT.xml'))
+ }
2018-09-14 08:08:31 INFO   [query.trait.data] : 
   --------------------------------------------------------- 

Voici mes infos sur la course

  <run>
    <site>
      <id>1000025731</id>
      <met.start>1990/01/01</met.start>
      <met.end>1991/12/31</met.end>
    </site>
    <inputs>
      <met>
        <source>NARR</source>
        <output>SIPNET</output>
      </met>
    </inputs>
    <start.date>1990/01/01</start.date>
    <end.date>1991/12/31</end.date>
  </run>

Je crois que cela est corrigé sur la branche de développement mais pas encore déployé. Je travaillerai avec @yan130 pour tester et voir si cela fonctionne sur le serveur de développement avec ce fichier spécifique.

@robkooper OK merci. J'utilise la branche develop pour ces exécutions, mais je n'ai pas encore poussé les modifications pour une branche locale ?

la branche develop n'est pas déployée ici. cette instance particulière suit la branche master. J'espérais y déployer la nouvelle version. Je vérifierai auprès de @tonygardella quand la nouvelle version arrivera.

@robkooper Je ne suis pas sûr de suivre ...... Je ne suis toujours pas certain de la fin de ce bogue. Je suppose que nous allons nous assurer que cela peut fonctionner à la fois pour le maître et le développeur ?

Avons-nous encore des correctifs pour cela? @para2x à un moment donné dans votre SDA multi-sites, je pense que nous allons vouloir fonctionner avec les pilotes NARR sur tous les sites, ou du moins c'était le plan d'origine. Mais nous attendons un correctif.

Cogner. Est-ce que quelqu'un d'autre a récemment pu utiliser BrownDog NARR avec sipnet ? Si c'est le cas, faites-le moi savoir, peut-être qu'il a été résolu et qu'il fonctionne à nouveau... pas clair.

S'il y a des problèmes avec BrownDog NARR, j'utiliserais le site NARR basé sur THREDDS dans l'intervalle

@robkooper Je teste ce cas sur prod et l'erreur est un mauvais lien ftp :

<input> <type>NARR</type> <site>US-SSH</site> <lat>40.6658</lat> <lon>-77.9041</lon> <start_date>1990-01-01 00:00:00</start_date> <end_date>1991-12-31 23:59:59</end_date> </input>

remotefunc <- function() {PEcAn.data.atmosphere::download.NARR(site_id='1135', lat.in=40.6658, lon.in=-77.9041, model=NULL, scenario=NULL, ensemble_member=NULL, écraser =FALSE, outfolder='/home/polyglot/cache/PEcAn/NARR_site_1-25731/', start_date='1990-01-01', end_date='2014-12-31')}
remoteout <- remotefunc()

Fichier joint : 'PEcAn.utils'

L'objet suivant est masqué dans ' package:utils ' :
télécharger un fichier

2019-01-23 11:18:33 DEBUG [PEcAn.data.atmosphere::download.NARR] :
Fichier ' /home/polyglot/cache/PEcAn/NARR_site_1-25731//pres.sfc.2014.nc '
existe déjà, en passant au fichier suivant.
2019-01-23 11:18:33 DEBUG [PEcAn.data.atmosphere::download.NARR] :
Fichier ' /home/polyglot/cache/PEcAn/NARR_site_1-25731//pres.sfc.2013.nc '
existe déjà, en passant au fichier suivant.
2019-01-23 11:18:33 DEBUG [PEcAn.data.atmosphere::download.NARR] :
Téléchargement depuis :
ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc à :
/home/polyglot/cache/PEcAn/NARR_site_1-25731//pres.sfc.2012.nc
essayer l'URL 'ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc'
Erreur dans utils::download.file(url, filename, method) :
impossible d'ouvrir l'URL 'ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc'
Appels : remotefunc ->->->
En plus : Message d'avertissement :
Dans utils::download.file(url, nom de fichier, méthode) :
URL 'ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc' : l'état était 'Impossible de se connecter au serveur'
Exécution interrompue
[1] 1
2019-01-23 11:20:41 INFO [PEcAn.utils::convert.input] :
RÉSULTATS : Convert.Input
2019-01-23 11:20:41 INFO [PEcAn.utils::convert.input] : 1
2019-01-23 11:20:41 INFO [PEcAn.utils::convert.input] :
Erreur dans le fichier != "" :la comparaison (2) n'est possible que pour les types atomique et liste
Appels : met.process ... .download.raw.met.module ->-> sous-ensemble -> sous-ensemble.default
2019-01-23 11:20:41 AVERTIR [db.close] :
Connexion créée en dehors du package PEcAn.DB
Exécution interrompue

PS : Je ne sais pas pourquoi il est téléchargé à partir de 2014, je viens de définir le début en 1990 et la fin en 1991.

Bienvenue à la fermeture du gouvernement peut-être?

@ yan130 Je viens de tester ce lien FTP et il semble être de retour

Je viens de lancer ceci et il semble retirer des données

remotefunc <- function() {PEcAn.data.atmosphere::download.NARR(site_id='1135', lat.in=40.6658, lon.in=-77.9041, model=NULL, scenario=NULL, 
                                                               ensemble_member=NULL, overwrite=FALSE, outfolder='~/scratch', 
                                                               start_date='1990-01-01', end_date='2014-12-31')}
remoteout <- remotefunc()

@serbinsh Je l'exécute, prend un certain temps (peut-être un jour), je vous

Merci @ yan130 Testez -vous le code NARR de base ou la version BrownDog ?

Je dois d'abord exécuter le code NARR de base sur le serveur BrownDog.
lorsque ce que j'exécute est terminé, vous pouvez exécuter la version BrownDog à partir de votre machine.

Ah, d'accord, c'est logique. Merci!

Étrange, j'ai mis à jour la noix de pécan vers le dernier dev et j'obtiens maintenant cette erreur :

> remotefunc <- function() {PEcAn.data.atmosphere::download.NARR(site_id='1135', lat.in=40.6658, lon.in=-77.9041, model=NULL, scenario=NULL, ensemble_member=NULL, method=NULL, overwrite=FALSE, outfolder='/data/Model_Output/pecan.output/dbfiles/NARR_site_1135/', start_date='1990-01-01', end_date='2014-12-31')}

> remoteout <- remotefunc()

2019-01-28 15:10:40 DEBUG  [#1: PEcAn.data.atmosphere::download.NARR] :
   Downloading from:
   ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2014.nc to:
   /data/Model_Output/pecan.output/dbfiles/NARR_site_1135//pres.sfc.2014.nc
Error in if (method == "ncftpget") { : argument is of length zero
> traceback()
3: PEcAn.utils::download.file(url, new.file, method)
2: PEcAn.data.atmosphere::download.NARR(site_id = "1135", lat.in = 40.6658,
       lon.in = -77.9041, model = NULL, scenario = NULL, ensemble_member = NULL,
       method = NULL, overwrite = FALSE, outfolder = "/data/Model_Output/pecan.output/dbfiles/NARR_site_1135/",
       start_date = "1990-01-01", end_date = "2014-12-31") at #1
1: remotefunc()

Pourtant, la commande similaire ci-dessus fonctionne toujours, il faut déterminer pourquoi il y a une différence maintenant

Aha, le problème avec la nouvelle commande dans PEcAn est qu'elle définit la "méthode" sur NULL par défaut, ce qui est une erreur pour moi. Mais si je lance comme :

remotefunc <- function() {PEcAn.data.atmosphere::download.NARR(site_id='1135', lat.in=40.6658, lon.in=-77.9041, model=NULL, scenario=NULL, ensemble_member=NULL, overwrite=FALSE, 
                                                               outfolder='~/scratch', start_date='1990-01-01', end_date='1990-02-01')}
remoteout <- remotefunc()

ça marche bien.

Je ne trouve pas ici : https://github.com/PecanProject/pecan/blob/develop/modules/data.atmosphere/R/download.NARR.R

OU ici : https://github.com/PecanProject/pecan/blob/develop/modules/data.atmosphere/R/download.NARR_site.R

où la "méthode" est définie sur NULL par défaut ? Cela ne se produit pas non plus ici, pour autant que je sache ? https://github.com/PecanProject/pecan/blob/develop/web/03a-narr.php . Mais cette "méthode = NULL " casse NARR pour moi sur modex car cela doit être extrait de notre profil R.

journal des erreurs actuel :

Commencer la conversion spécifique au modèle
[1] "Convertir au format modèle"
Aucun geonamesUsername défini. Voir http://geonames.wordpress.com/2010/03/16/ddos-part-ii/ et définissez-en un avec options(geonamesUsername="foo") pour que certains services fonctionnent
Erreur dans l'url(url, open = "r") :
impossible d'ouvrir la connexion à 'http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya'
Appels : met.process ... site.lst -> GNtimezone -> as.data.frame -> getJson -> url
En plus : Message d'avertissement :
Dans url(url, open = "r") :
URL ' http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya ': le statut était 'Impossible de résoudre le nom d'hôte'
2019-01-31 15:28:05 AVERTIR [db.close] :
Connexion créée en dehors du package PEcAn.DB
Exécution interrompue

@ yan130 Je reçois ce message d'erreur de mon côté :

```> # Faire des conversions

paramètres <- PEcAn.workflow::do_conversions(settings)
01-02-2019 08:33:22 DEBUG [PEcAn.workflow::do_conversions] :
do.conversion outdir /data/Model_Output/pecan.output/dbfiles
2019-02-01 08:33:22 INFO [PEcAn.workflow::do_conversions] : TRAITEMENT : rencontré
2019-02-01 08:33:22 INFO [PEcAn.workflow::do_conversions] :
appelant met.process :
2019-02-01 08:33:25 INFO [browndog.met] :
URL de téléchargement de browndog :
http://dap.ncsa.illinois.edu :8184/file/20318176_pecan.clim
Erreur dans le nom de base (fichier téléchargé) : un argument de vecteur de caractère attendu
Appels:->-> browndog.met -> nom de base
proc.temps()
système utilisateur écoulé
11.513 1.215 662.677
``` .

peut-être que votre travail pour abattre tout le NARR a échoué ? Cette erreur est survenue après une longue attente, donc je suppose qu'elle fonctionnait sur l'extraction et a échoué lors du transfert ? @robkooper avez-vous des journaux à cette fin qui peuvent éclairer ce problème ?

journal des erreurs actuel :

Commencer la conversion spécifique au modèle
[1] "Convertir au format modèle"
Aucun geonamesUsername défini. Voir http://geonames.wordpress.com/2010/03/16/ddos-part-ii/ et définissez-en un avec options(geonamesUsername="foo") pour que certains services fonctionnent
Erreur dans l'url(url, open = "r") :
impossible d'ouvrir la connexion à 'http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya'
Appels : met.process ... site.lst -> GNtimezone -> as.data.frame -> getJson -> url
En plus : Message d'avertissement :
Dans url(url, open = "r") :
URL ' http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya ': le statut était 'Impossible de résoudre le nom d'hôte'
2019-01-31 15:28:05 AVERTIR [db.close] :
Connexion créée en dehors du package PEcAn.DB
Exécution interrompue

cela peut être corrigé en ajoutant une nouvelle URL d'API :
options(geonamesHost = "api.geonames.org")

à tous les appels geonames::GNtimezone.

@robkooper
Je peux ajouter cette ligne à PEcAn_convert.R dans browndog,
ou modules/data.atmosphere/R/site.lst.R dans pecanproject.
tu préfères quel chemin ?

@serbinsh cela devrait fonctionner maintenant, veuillez laisser un commentaire si vous avez toujours des problèmes.

Vérifiez quelle version de geonames est installée. Cela pourrait être corrigé dans une mise à jour.

le dernier, pas de mise à jour depuis 2014.
https://cran.r-project.org/web/packages/geonames/index.html

Pouvez-vous essayer Rscript -e "devtools::install_github('ropensci/geonames')" et voir si cela résout le problème. C'est ce qui est actuellement utilisé dans PEcAn.

Ca ne fonctionne pas. n'a pas trouvé le nom d'hôte dans le code source de 'ropensci/geonames'

Juste pour donner suite à cela, des progrès ont-ils été réalisés pour que le processus NARR s'exécute à nouveau via BD ?

Je viens d'essayer à nouveau ce matin et j'ai constaté qu'il crée un fichier sipnet.clim, MAIS il est vide

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