Pecan: BrownDog/NARR sipnet.clim-Dateien werden nicht korrekt generiert

Interessanterweise wird der erstellte Treiber als Option angezeigt, wenn Sie zur gleichen Site/Modell-Kombination zurückkehren

Ich bin mir auch nicht sicher, ob dies geschehen soll, aber ein sipnet.clim-Ordner wurde auf der obersten Ebene des Pekannuss-Workflow-Ordners erstellt, wie hier zu sehen:

[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

Aber der Ordner ist leer

So sieht ein Ausführungsordner aus:

[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

Basierend auf einem Kommentar von @robkooper auf Slack sieht es so aus, als ob die zurückgegebene Datei eine ZIP-Datei ohne die richtige Erweiterung ist. Wenn ich die Datei umbenenne, kann ich die Datendatei, die eine richtig formatierte sipnet.clim-Datei ist, erfolgreich extrahieren.

[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 ...

Führen Sie es erneut aus und sehen Sie, dass sich jetzt zwei verschiedene BD-clim-Dateien in der falsch benannten .zip-Datei befinden

[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

Ein weiteres Problem ist, dass der in job.sh verwendete Sym-Link nicht mit den Dateinamen übereinstimmt:

[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
...

Ein kurzer Check, wie es meiner Meinung nach eingerichtet sein sollte:

[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 hatten Sie die Möglichkeit, die BD-Probleme mit NARR zu untersuchen?

Ich denke, dies wurde möglicherweise mit # 2039 behoben. Ich muss dies testen.

welches jahr wählst du?
ein Jahr oder mehrere?

@robkooper hat es gerade noch einmal versucht und folgendes bekommen:

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

Hier ist das Verzeichnis, das diesmal tatsächlich besser aussieht:

[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

Aber nichts in der Datei??

[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]$

Aus dem 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] : 
   --------------------------------------------------------- 

Hier sind meine Laufinfos

  <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>

Ich glaube, dies ist im Entwicklungszweig behoben, aber noch nicht bereitgestellt. Ich werde mit @yan130 zusammenarbeiten , um zu testen, ob es auf dem

@robkooper OK danke. Ich verwende den Develop Branch für diese Läufe, habe die Änderungen nur noch nicht für einen lokalen Branch gepusht?

Wir haben den Entwicklungszweig hier nicht bereitgestellt. diese spezielle Instanz folgt dem Master-Zweig. Ich hatte gehofft, die neue Version dort bereitzustellen. Ich werde bei @tonygardella nachfragen, wann die neue Veröffentlichung erscheint.

@robkooper Ich bin mir nicht sicher, ob ich folge ... Ich bin mir auch immer noch nicht sicher, an welchem ​​Ende dieser Fehler liegt. Ich gehe davon aus, dass wir sicherstellen werden, dass es sowohl für Master als auch für Entwickler funktioniert?

Haben wir dafür schon irgendwelche Fixes? @para2x Irgendwann in Ihrem Multi-Site-SDA werden wir denke ich, dass wir mit NARR-Treibern über Sites hinweg laufen wollen, oder zumindest war das der ursprüngliche Plan. Aber wir haben auf eine Lösung gewartet.

Stoßen. Konnte jemand anderes BrownDog NARR in letzter Zeit mit sipnet verwenden? Wenn ja, lassen Sie es mich bitte wissen, vielleicht wurde es behoben und funktioniert wieder....unklar.

Wenn es Probleme mit BrownDog NARR gibt, würde ich in der Zwischenzeit die THREDDS-basierte NARR_site verwenden

@robkooper Ich

<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, Szenario=NULL, ensemble_member=NULL, überschreiben =FALSE, outfolder='/home/polyglot/cache/PEcAn/NARR_site_1-25731/', start_date='1990-01-01', end_date='2014-12-31')}
remoteout <- remotefunc()

Anhängendes Paket: 'PEcAn.utils'

Das folgende Objekt wird von ' package:utils ' maskiert:
Download-Datei

2019-01-23 11:18:33 DEBUG [PEcAn.data.atmosphere::download.NARR] :
Datei ' /home/polyglot/cache/PEcAn/NARR_site_1-25731//pres.sfc.2014.nc '
bereits vorhanden, Springen zur nächsten Datei.
2019-01-23 11:18:33 DEBUG [PEcAn.data.atmosphere::download.NARR] :
Datei ' /home/polyglot/cache/PEcAn/NARR_site_1-25731//pres.sfc.2013.nc '
bereits vorhanden, Springen zur nächsten Datei.
2019-01-23 11:18:33 DEBUG [PEcAn.data.atmosphere::download.NARR] :
Herunterladen von:
ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc an:
/home/polyglot/cache/PEcAn/NARR_site_1-25731//pres.sfc.2012.nc
Versuch URL 'ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc'
Fehler in utils::download.file(url, filename, method):
URL 'ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc' kann nicht geöffnet werden
Aufrufe: remotefuc ->->->
Außerdem: Warnmeldung:
In utils::download.file(url, filename, method) :
URL 'ftp://ftp.cdc.noaa.gov/Datasets/NARR/monolevel/pres.sfc.2012.nc': Status war 'Verbindung zum Server nicht möglich'
Ausführung gestoppt
[1] 1
2019-01-23 11:20:41 INFO [PEcAn.utils::convert.input] :
ERGEBNISSE: 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] :
Fehler in Datei != "" :Vergleich (2) ist nur für Atom- und Listentypen möglich
Aufrufe: met.process ... .download.raw.met.module ->-> Teilmenge -> Teilmenge.Standard
23.01.2019 11:20:41 WARN [db.close] :
Verbindung außerhalb des PEcAn.DB-Pakets erstellt
Ausführung gestoppt

PS: Ich weiß nicht, warum es ab 2014 heruntergeladen wird, ich habe einfach den Anfang als 1990 und das Ende als 1991 festgelegt.

Willkommen zum Shutdown der Regierung vielleicht?

@yan130 Ich habe gerade diesen FTP-Link getestet und er

Ich habe das gerade ausgeführt und es scheint Daten herunterzuladen

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 Ich angezeigt wird.

Danke @yan130 Testen Sie den grundlegenden NARR-Code oder die BrownDog-Version?

Ich muss zuerst den grundlegenden NARR-Code auf dem BrownDog-Server ausführen.
Wenn das, was ich ausführe, fertig ist, können Sie die BrownDog-Version von Ihrem Computer ausführen.

Ah, okay, das macht Sinn. Danke schön!

Seltsam, ich habe Pekannuss auf die neueste Entwicklung aktualisiert und erhalte jetzt diesen Fehler:

> 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()

Der ähnliche Befehl oben funktioniert jedoch immer noch, ich muss herausfinden, warum es jetzt einen Unterschied gibt

Aha, das Problem mit dem neueren Befehl in PEcAn ist, dass "method" standardmäßig auf NULL gesetzt wird, was für mich Fehler darstellt. Aber wenn ich laufe als:

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()

es läuft prima.

Ich kann hier nicht finden: https://github.com/PecanProject/pecan/blob/develop/modules/data.atmosphere/R/download.NARR.R

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

wo "Methode" standardmäßig auf NULL gesetzt wird? Das passiert hier auch nicht, soweit ich das beurteilen kann? https://github.com/PecanProject/pecan/blob/develop/web/03a-narr.php . Aber dieses "method=NULL" unterbricht NARR für mich auf Modex, weil das aus unserem R-Profil geholt werden muss.

aktuelles Fehlerprotokoll:

Beginnen Sie mit der modellspezifischen Konvertierung
[1] "In Modellformat konvertieren"
Kein GeonamesUsername festgelegt. Siehe http://geonames.wordpress.com/2010/03/16/ddos-part-ii/ und stellen Sie einen mit options(geonamesUsername="foo") ein, damit einige Dienste funktionieren
Fehler in url(url, open = "r") :
kann die Verbindung zu 'http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya' nicht öffnen
Aufrufe: met.process ... site.lst -> GNtimezone -> as.data.frame -> getJson -> url
Außerdem: Warnmeldung:
In url(url, open = "r") :
URL ' http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya ': Status war 'Hostname konnte nicht aufgelöst werden'
31.01.2019 15:28:05 WARN [db.close] :
Verbindung außerhalb des PEcAn.DB-Pakets erstellt
Ausführung gestoppt

@yan130 Ich bekomme diese Fehlermeldung an meinem Ende:

```> # Konvertierungen durchführen

Einstellungen <- PEcAn.workflow::do_conversions(Einstellungen)
2019-02-01 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] : VERARBEITUNG: met
2019-02-01 08:33:22 INFO [PEcAn.workflow::do_conversions] :
Aufruf von met.process:
2019-02-01 08:33:25 INFO [browndog.met] :
Browndog-Download-URL:
http://dap.ncsa.illinois.edu :8184/file/20318176_pecan.clim
Fehler in basename(downloadedfile): ein Zeichenvektorargument erwartet
Anrufe:->-> browndog.met -> Basisname
Vorgangszeit()
Benutzersystem abgelaufen
11.513 1.215 662.677
```.

Vielleicht ist Ihre Arbeit, alle NARR herunterzufahren, gescheitert? Dieser Fehler trat nach einer langen Wartezeit auf, daher gehe ich davon aus, dass er bei der Extraktion funktioniert hat und bei der Übertragung fehlgeschlagen ist. @robkooper habt ihr protokolle an diesem ende, die dieses

aktuelles Fehlerprotokoll:

Beginnen Sie mit der modellspezifischen Konvertierung
[1] "In Modellformat konvertieren"
Kein GeonamesUsername festgelegt. Siehe http://geonames.wordpress.com/2010/03/16/ddos-part-ii/ und stellen Sie einen mit options(geonamesUsername="foo") ein, damit einige Dienste funktionieren
Fehler in url(url, open = "r") :
kann die Verbindung zu 'http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya' nicht öffnen
Aufrufe: met.process ... site.lst -> GNtimezone -> as.data.frame -> getJson -> url
Außerdem: Warnmeldung:
In url(url, open = "r") :
URL ' http://ws.geonames.org/timezoneJSON?lat=40.6658&lng=-77.9041&radius=0&username=carya ': Status war 'Hostname konnte nicht aufgelöst werden'
31.01.2019 15:28:05 WARN [db.close] :
Verbindung außerhalb des PEcAn.DB-Pakets erstellt
Ausführung gestoppt

Dies kann durch Hinzufügen einer neuen API-URL behoben werden:
options(geonamesHost = "api.geonames.org")

zu allen geonames::GNtimezone-Anrufen.

@robkooper
Ich kann diese Zeile zu PEcAn_convert.R in browndog hinzufügen,
oder module/data.atmosphere/R/site.lst.R in pecanproject.
welchen Weg bevorzugen Sie?

@serbinsh es sollte jetzt funktionieren, bitte hinterlassen Sie einen Kommentar, wenn Sie immer noch Probleme haben.

Überprüfen Sie, welche Version von Geonames installiert ist. Dies könnte in einem Update behoben werden.

neueste, kein Update seit 2014.
https://cran.r-project.org/web/packages/geonames/index.html

Können Sie Rscript -e "devtools::install_github('ropensci/geonames')" versuchen und sehen, ob das das Problem löst. Dies wird derzeit in PEcAn verwendet.

funktioniert nicht. habe den Hostnamen im Quellcode von 'ropensci/geonames' nicht gefunden

Gibt es im Anschluss daran irgendwelche Fortschritte, den NARR-Prozess über BD wieder zum Laufen zu bringen?

Ich habe es gerade am Morgen erneut versucht und festgestellt, dass eine Datei sipnet.clim erstellt wird, ABER sie ist leer

Dieses Problem ist veraltet, da es 365 Tage ohne Aktivität geöffnet war.