Pecan: Possível bug: saída PEcAn às vezes se repete primeira / última data / hora entre anos ou começa em -1
Descreva o bug
Ao trabalhar na execução de alguns testes de ED2 por meio de ILAMB, descobrimos que, pelo menos em minha saída, a última data do ano na variável de tempo é a primeira data da saída dos próximos anos
Se olharmos para os tempos de minha produção de 2001-2002, por exemplo
0 55115.0104173 55480.0104173 17520
1 55480.0104173 55845.0104173 17520
você pode ver que o tempo é o mesmo aqui também ... isso pode nos causar problemas para o processamento que tenta encadear a saída, como com ILAMB atualmente
Além disso, enquanto brincava com a saída SIPNET, percebi que em minhas execuções o primeiro valor da variável de tempo é -1!
data:
time = -1, -0.958333333333333, -0.916666666666667, -0.875,
-0.833333333333333, -0.791666666666667, -0.75, -0.708333333333333,
-0.666666666666667, -0.625, -0.583333333333333, -0.541666666666667, -0.5,
-0.458333333333333, -0.416666666666667, -0.375, -0.333333333333333,
-0.291666666666667, -0.25, -0.208333333333333,
time = UNLIMITED ; // (8760 currently)
...
double time(time) ;
time:units = "days since 2000-01-01 00:00:00" ;
time:long_name = "time" ;
time:calendar = "standard" ;
Comportamento esperado
Eu acho que não queremos a saída fornecida dessa forma e, em vez disso, apenas a variável de tempo inclui os dados de anos / intervalo de datas. Por exemplo, terminando em tempo fracionário, como: 364.895833333333, 364.916666666667, 364.9375,
364.958333333333, 364.979166666667 ;
E começando com 0.04166667 por exemplo, se por hora (ou seja, SIPNET).
Preciso verificar se isso está vindo de met ou de model2netcdf .... Eu suspeito que passo m2n
Máquina (preencha as seguintes informações):
- Modex de servidor
- SO: linux
- Navegador (se aplicável) NA
- Versão NA
serbinsh
Todos 30 comentários
Aqui está um exemplo de saída SIPNET bruta
Notes: (PlantWoodC, PlantLeafC, Soil and Litter in g C/m^2; Water and Snow in cm; SoilWetness is fraction of WHC;
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
0 2000 0 0.00 17998.95 0.00 10001.44 5.00 5999.96 5999.59 280.00 0.500 6.00 0.500 1.00 -0.02 0.06 0.06 0.00 0.019 0.041 0.005 0.024 0.036 0.059 0.00323719 0.0000 0.0000
0 2000 0 1.00 17997.91 0.00 10002.85 5.00 5999.91 5999.17 280.00 0.500 6.00 0.500 0.99 -0.02 0.09 0.15 0.00 0.018 0.072 0.005 0.023 0.068 0.090 0.00283669 0.0000 0.0000
0 2000 0 2.00 17996.86 0.00 10004.27 5.00 5999.87 5998.76 280.00 0.500 6.00 0.500 0.99 -0.02 0.09 0.24 0.00 0.017 0.070 0.005 0.022 0.066 0.087 0.00275556 0.0000 0.0000
0 2000 0 3.00 17995.82 0.00 10005.71
e o final daquele ano
0 2000 364 23.00 10911.18 178.24 18025.82 5.00 5591.78 3376.22 280.00 0.500 6.47 0.539 0.04 -0.02 0.10 1951.40 0.00 0.014 0.084 0.005 0.019 0.079 0.097 0.00636472 0.0000 0.3524
0 2001 0 0.00 10910.54 178.23 18026.64 5.00 5591.74 3375.98 280.00 0.500 6.47 0.539 0.03 -0.02 0.10 1951.50 0.00 0.012 0.084 0.005 0.017 0.078 0.095 0.00632517 0.0000 0.3524
0 2001 0 1.00 10909.91 178.23 18027.46 5.00 5591.70 3375.75 280.00 0.500 6.47 0.539 0.02 -0.02 0.10 1951.60 0.00 0.011 0.084 0.005 0.016 0.079 0.095 0.00691700 0.0000 0.3524
0 2001 0 2.00 10909.28 178.22 18028.28 5.00 5591.66 3375.52 280.00 0.500
então isso parece ok
serbinsh
em 5 set. 2018
WRT SIPNET o problema está aqui
t <- ncdf4::ncdim_def(name = "time",
units = paste0("days since ", y, "-01-01 00:00:00"),
vals = sub.sipnet.output$day - 1 + (sub.sipnet.output$time/24),
calendar = "standard",
unlim = TRUE)
e eu não tenho certeza porque temos o -1 lá
> vals = sub.sipnet.output$day - 1 + (sub.sipnet.output$time/24)
> head(vals)
[1] -1.0000000 -0.9583333 -0.9166667 -0.8750000 -0.8333333 -0.7916667
contra
> vals = sub.sipnet.output$day + (sub.sipnet.output$time/24)
> head(vals)
[1] 0.00000000 0.04166667 0.08333333 0.12500000 0.16666667 0.20833333
onde o segundo terminaria como
> tail(vals)
[1] 363.7500 363.7917 363.8333 363.8750 363.9167 363.9583
Com ED2 é um pouco complicado porque em python (ILAMB):
from netCDF4 import num2date,date2num
print num2date(365.,"days since 2001-01-01 00:00:00")
print num2date( 0.,"days since 2002-01-01 00:00:00")
dá
2002-01-01 00:00:00
2002-01-01 00:00:00
e atualmente fornecemos tempo de saída ED2, como:
time = 0, 0.0208345225184086, 0.0416690450368172, 0.0625035675552258,
0.0833380900736343, 0.104172612592043, 0.125007135110452,
0.14584165762886, 0.166676180147269, 0.187510702665677,
0.208345225184086, 0.229179747702494, 0.250014270220903,
...
364.333295279411, 364.354129801929, 364.374964324448, 364.395798846966,
364.416633369485, 364.437467892003, 364.458302414521, 364.47913693704,
364.499971459558, 364.520805982077, 364.541640504595, 364.562475027113,
364.583309549632, 364.60414407215, 364.624978594669, 364.645813117187,
364.666647639705, 364.687482162224, 364.708316684742, 364.729151207261,
364.749985729779, 364.770820252297, 364.791654774816, 364.812489297334,
364.833323819853, 364.854158342371, 364.87499286489, 364.895827387408,
364.916661909926, 364.937496432445, 364.958330954963, 364.979165477482,
365 ;
então parece que precisamos terminar na 364. parte para non leap e 365. para leap, por exemplo
>>> from netCDF4 import num2date,date2num
>>> print num2date(365.,"days since 2004-01-01 00:00:00")
2004-12-31 00:00:00
por um ano bissexto onde
>>> print num2date(366.,"days since 2004-01-01 00:00:00")
2005-01-01 00:00:00
resulta no mesmo problema que levantei acima
serbinsh
em 5 set. 2018
Para ED2, proponho que mudemos para:
> days <- seq(0,364,0.02083333)
> head(days)
[1] 0.00000000 0.02083333 0.04166666 0.06249999 0.08333332 0.10416665
> tail(days)
[1] 363.8958 363.9166 363.9374 363.9583 363.9791 363.9999
e
> days <- seq(0,365,0.02083333)
> head(days)
[1] 0.00000000 0.02083333 0.04166666 0.06249999 0.08333332 0.10416665
> tail(days)
[1] 364.8958 364.9166 364.9374 364.9583 364.9791 364.9999
que ainda seria traduzido para datas corretas, por exemplo
> head(as.Date(days, origin=as.Date("2001-01-01")))
[1] "2001-01-01" "2001-01-01" "2001-01-01" "2001-01-01" "2001-01-01" "2001-01-01"
> tail(as.Date(days, origin=as.Date("2001-01-01")))
[1] "2001-12-31" "2001-12-31" "2001-12-31" "2001-12-31" "2001-12-31" "2001-12-31"
por anos bissextos. @istfer @tonygardella @ashiklom pensamentos? Obviamente, definiríamos o timestep dinamicamente com base na frequência de saída em vez de codificação permanente, mas acho que só precisamos alterar a data de término de 365 para 364 ou 365 de 366 dependendo.
serbinsh
em 5 set. 2018
@serbinsh Eu não vi o problema do SIPNET antes. Acabei de verificar uma saída SIPNET e começa no dia 1, poderia ser uma coisa de versão?
> head(sipnet.output)
loc year day time plantWoodC plantLeafC soil microbeC coarseRootC fineRootC
1 0 2005 1 0.0 8819.99 0 1600.18 0.8 2519.93 1259.91
2 0 2005 1 0.5 8819.97 0 1600.36 0.8 2519.85 1259.81
3 0 2005 1 1.0 8819.96 0 1600.54 0.8 2519.78 1259.72
portanto:
> vals = sub.sipnet.output$day - 1 + (sub.sipnet.output$time/24)
> head(vals)
[1] 0.00000000 0.02083333 0.04166667 0.06250000 0.08333333 0.10416667
> tail(vals)
[1] 364.8750 364.8958 364.9167 364.9375 364.9583 364.9792
> t <- ncvar_get(nc, "time")
> head(t)
[1] 0.00000000 0.02083333 0.04166667 0.06250000 0.08333333 0.10416667
> tail(t)
[1] 364.8750 364.8958 364.9167 364.9375 364.9583 364.9792
ou poderia ser algo relacionado ao met2model? Acho que o SIPNET leva o tempo do arquivo sipnet.clim em consideração. Os arquivos de clim que estou usando foram gerados há algum tempo, talvez as mudanças mais recentes tenham afetado esses
istfer
em 5 set. 2018
@istfer qual versão do sipnet você está usando que dá o dia 1? Eu estava executando o r136 ou qualquer outra coisa que NÃO "unk", mas sim, parece um problema de versão! e isso pode nos causar problemas, a menos que determinemos 0 vs 1
serbinsh
em 5 set. 2018
Estou usando r136 também
istfer
em 5 set. 2018
@istfer OK, então estreitando, aqui está meu arquivo de entrada sipnet.clim
0 2000 0 0 0.04166667 -0.433 0.376 0.000 0.000 100.433 136.257 491.841 3.572 0.291
0 2000 0 1 0.04166667 -1.022 -0.128 0.000 0.000 68.020 106.262 499.302 3.362 0.291
0 2000 0 2 0.04166667 -1.606 -0.421 0.000 0.000 43.585 92.809 499.950 3.287 0.291
0 2000 0 3 0.04166667 -2.558 0.153 0.000 0.000 19.511 130.896 487.128 2.770 0.291
0 2000 0 4 0.04166667 -3.706 0.204 0.000 0.000 4.198 159.356 460.947 2.457 0.291
0 2000 0 5 0.04166667 -4.769 0.110 0.000 0.000 5.600 192.289 423.814 2.641 0.291
0 2000 0 6 0.04166667 -5.526 -0.282 0.000 0.000 8.120 201.453 397.363 2.653 0.291
0 2000 0 7 0.04166667 -5.961 -0.044 0.000 0.000 5.246 222.228 387.034 2.306 0.291
0 2000 0 8 0.04166667 -5.873 -0.396 0.199 0.000 4.868 203.824 390.057 2.721 0.291
0 2000 0 9 0.04166667 -5.133 0.130 0.401 0.000 11.418 210.657 406.345 2.904 0.291
0 2000 0 10 0.04166667 -4.606 -0.012 0.574 0.000 26.797 202.741 407.945 2.638 0.291
0 2000 0 11 0.04166667 -4.362 0.211 0.638 0.000 39.046 216.858 403.749 2.025 0.291
0 2000 0 12 0.04166667 -4.048 -0.200 0.739 0.000 49.391 198.420 403.986 2.063 0.291
0 2000 0 13 0.04166667 -3.649 -0.253 0.607 0.000 55.847 188.786 411.273 1.289 0.291
0 2000 0 14 0.04166667 -3.626 0.131 0.437 0.000 59.100 208.189 408.843 1.734 0.291
0 2000 0 15 0.04166667 -3.930 -0.080 0.157 0.000 60.933 211.205 396.469 1.616 0.291
0 2000 0 16 0.04166667 -4.145 -0.644 0.012 0.000 62.895 196.041 387.170 1.496 0.291
0 2000 0 17 0.04166667 -4.443 0.105 0.000 0.000 61.198 236.942 378.919 1.808 0.291
0 2000 0 18 0.04166667 -4.518 0.050 0.000 0.000 60.600 236.412 377.020 2.160 0.291
0 2000 0 19 0.04166667 -4.623 -0.135 0.000 0.000 51.999 223.087 382.171 2.078 0.291
0 2000 0 20 0.04166667 -4.592 -0.074 0.000 0.000 51.546 224.259 383.645 2.273 0.291
0 2000 0 21 0.04166667 -4.431 -0.966 0.000 0.000 48.845 177.983 391.666 2.294 0.291
0 2000 0 22 0.04166667 -4.274 0.152 0.000 0.000 42.899 215.100 402.855 2.563 0.291
0 2000 0 23 0.04166667 -4.235 -0.533 0.000 0.000 30.999 171.920 416.050 2.832 0.291
0 2000 1 0 0.04166667 -4.553 -0.300 0.000 0.000 5.512 167.050 430.972 2.746 0.291
0 2000 1 1 0.04166667 -5.150 0.217 0.000 0.000 0.000 203.668 417.228 2.489 0.291
0 2000 1 2 0.04166667 -5.506 0.100 0.000 0.621 0.000 209.524 406.124 2.560 0.291
0 2000 1 3 0.04166667 -5.688 0.146 0.000 1.863 0.000 217.156 400.534 2.391 0.291
0 2000 1 4 0.04166667 -5.837 0.080 0.000 1.087 0.000 218.738 396.020 2.705 0.291
0 2000 1 5 0.04166667 -5.902 -0.194 0.000 0.932 0.000 208.559 394.068 2.522 0.291
0 2000 1 6 0.04166667 -5.878 -0.203 0.000 0.621 0.000 207.457 394.789 2.543 0.291
0 2000 1 7 0.04166667 -5.763 0.370 0.000 2.174 0.000 229.550 398.248 2.425 0.291
0 2000 1 8 0.04166667 -5.337 -0.092 0.122 2.018 0.000 195.760 411.378 2.577 0.291
0 2000 1 9 0.04166667 -4.868 -0.526 0.259 0.932 0.000 162.046 426.224 3.651 0.291
0 2000 1 10 0.04166667 -4.800 0.038 0.332 0.466 0.000 184.481 428.415 3.601 0.291
0 2000 1 11 0.04166667 -4.206 0.666 0.402 0.621 0.000 193.298 448.059 3.630 0.291
0 2000 1 12 0.04166667 -3.661 -0.022 0.839 0.776 0.000 143.512 466.706 4.431 0.291
0 2000 1 13 0.04166667 -3.334 -0.717 1.134 0.466 12.835 114.715 465.410 4.670 0.291
0 2000 1 14 0.04166667 -3.183 -0.172 0.858 0.311 42.649 162.607 441.002 4.792 0.291
0 2000 1 15 0.04166667 -3.339 -0.469 0.267 0.311 39.049 151.700 439.005 4.519 0.291
0 2000 1 16 0.04166667 -3.630 0.845 0.024 0.000 24.439 206.330 443.367 4.987 0.291
0 2000 1 17 0.04166667 -4.063 0.541 0.000 0.000 28.848 211.587 424.012 4.044 0.291
0 2000 1 18 0.04166667 -4.466 0.473 0.000 0.000 27.139 220.310 412.203 3.689 0.291
0 2000 1 19 0.04166667 -4.892 0.257 0.000 0.000 28.478 225.690 396.983 3.625 0.291
0 2000 1 20 0.04166667 -5.524 -0.287 0.000 0.000 30.128 223.151 375.420 2.896 0.291
0 2000 1 21 0.04166667 -6.071 -0.317 0.000 0.000 30.071 238.344 358.946 2.453 0.291
0 2000 1 22 0.04166667 -6.380 -0.827 0.000 0.000 26.396 221.945 353.545 2.264 0.291
0 2000 1 23 0.04166667 -6.704 -0.480 0.000 0.000 31.298 250.912 339.312 2.532 0.291
então você pode ver começa com 0
e
0 2001 363 0 0.04166667 -13.042 1.509 0.000 0.000 46.950 503.577 177.913 3.800 0.312
0 2001 363 1 0.04166667 -12.941 1.504 0.000 0.000 45.600 500.112 181.100 4.200 0.312
0 2001 363 2 0.04166667 -12.740 1.513 0.000 0.000 44.600 495.852 185.813 4.400 0.312
0 2001 363 3 0.04166667 -12.539 1.504 0.000 0.000 45.400 492.436 188.783 3.900 0.312
0 2001 363 4 0.04166667 -12.439 1.504 0.000 0.000 47.400 492.533 188.686 4.100 0.312
0 2001 363 5 0.04166667 -12.338 1.512 0.000 0.000 57.550 501.142 180.455 4.700 0.312
0 2001 363 6 0.04166667 -12.539 1.499 0.000 0.000 63.100 509.912 171.083 4.800 0.312
0 2001 363 7 0.04166667 -12.740 1.479 0.000 0.000 52.500 502.086 177.913 4.200 0.312
0 2001 363 8 0.04166667 -13.042 1.499 0.206 0.000 59.450 515.589 165.413 4.200 0.312
0 2001 363 9 0.04166667 -13.243 1.494 0.691 0.000 62.000 521.530 159.228 4.800 0.312
0 2001 363 10 0.04166667 -13.343 1.484 1.532 0.000 66.550 527.344 152.882 5.600 0.312
0 2001 363 11 0.04166667 -12.841 1.491 2.401 0.000 79.700 531.757 148.849 5.600 0.312
0 2001 363 12 0.04166667 -12.037 1.490 2.606 0.000 96.200 532.887 147.644 5.200 0.312
0 2001 363 13 0.04166667 -11.132 1.474 2.302 0.311 119.050 536.689 143.088 4.800 0.312
0 2001 363 14 0.04166667 -10.530 1.490 1.501 0.466 137.650 543.210 137.355 5.200 0.312
0 2001 363 15 0.04166667 -10.530 1.484 0.598 0.000 139.250 544.520 135.755 4.800 0.312
0 2001 363 16 0.04166667 -11.434 1.475 0.044 0.000 115.600 539.515 140.309 4.200 0.312
0 2001 363 17 0.04166667 -12.539 1.489 0.000 0.000 95.500 541.824 138.683 3.900 0.312
0 2001 363 18 0.04166667 -13.443 1.489 0.000 0.000 87.500 550.330 130.147 4.000 0.312
0 2001 363 19 0.04166667 -14.147 1.477 0.000 0.000 79.300 553.688 126.216 4.100 0.312
0 2001 363 20 0.04166667 -14.649 1.472 0.000 0.000 80.200 562.654 117.024 4.400 0.312
0 2001 363 21 0.04166667 -15.252 1.475 0.000 0.000 74.850 566.990 112.819 4.500 0.312
0 2001 363 22 0.04166667 -15.754 1.482 0.000 0.000 69.950 570.086 110.076 4.300 0.312
0 2001 363 23 0.04166667 -16.056 1.468 0.000 0.000 68.400 572.311 107.174 4.000 0.312
0 2001 364 0 0.04166667 -16.458 1.473 0.000 0.000 67.050 576.955 102.742 4.600 0.312
0 2001 364 1 0.04166667 -17.060 1.465 0.000 0.000 62.900 580.796 98.538 4.300 0.312
0 2001 364 2 0.04166667 -17.462 1.471 0.000 0.000 62.000 585.566 94.075 3.800 0.312
0 2001 364 3 0.04166667 -17.965 1.469 0.000 0.000 59.900 589.826 89.696 3.100 0.312
0 2001 364 4 0.04166667 -18.568 1.462 0.000 0.000 58.400 595.426 83.740 2.800 0.312
0 2001 364 5 0.04166667 -18.969 1.466 0.000 0.000 56.500 598.520 80.855 2.500 0.312
0 2001 364 6 0.04166667 -19.472 1.466 0.000 0.000 53.500 601.281 78.078 3.100 0.312
0 2001 364 7 0.04166667 -19.170 1.455 0.000 0.000 52.200 596.011 82.817 2.100 0.312
0 2001 364 8 0.04166667 -18.869 1.457 0.320 0.000 51.050 591.428 87.487 2.900 0.312
0 2001 364 9 0.04166667 -17.563 1.451 1.287 0.000 62.000 585.859 92.759 2.800 0.312
0 2001 364 10 0.04166667 -15.352 1.449 2.086 0.000 72.900 565.308 113.218 2.800 0.312
0 2001 364 11 0.04166667 -13.443 1.452 2.564 0.000 88.950 550.002 128.697 2.800 0.312
0 2001 364 12 0.04166667 -11.836 1.444 2.678 0.000 114.950 545.463 132.859 2.100 0.312
0 2001 364 13 0.04166667 -10.831 1.440 2.293 0.000 130.700 540.313 137.802 3.000 0.312
0 2001 364 14 0.04166667 -11.333 1.433 1.492 0.155 121.000 540.789 136.971 3.200 0.312
0 2001 364 15 0.04166667 -12.740 1.432 0.512 0.000 92.950 540.250 137.463 3.600 0.312
0 2001 364 16 0.04166667 -13.443 1.424 0.029 0.000 80.850 540.538 136.797 3.200 0.312
0 2001 364 17 0.04166667 -13.544 1.425 0.000 0.000 77.200 538.698 138.675 2.700 0.312
0 2001 364 18 0.04166667 -12.303 1.425 0.000 0.000 52.600 491.271 186.088 3.166 0.312
0 2001 364 19 0.04166667 -12.374 1.421 0.000 0.000 44.149 484.044 193.164 2.871 0.312
0 2001 364 20 0.04166667 -13.032 1.416 0.000 0.000 39.277 491.198 185.761 2.769 0.312
0 2001 364 21 0.04166667 -14.262 1.412 0.000 0.000 34.911 508.061 168.674 3.102 0.312
0 2001 364 22 0.04166667 -14.844 1.404 0.000 0.000 30.150 512.417 163.932 3.406 0.312
0 2001 364 23 0.04166667 -15.402 1.403 0.000 0.000 27.243 518.203 158.108 2.669 0.312
e termina em 364. O seu termina com 365 por acaso para um salto não?
serbinsh
em 5 set. 2018
Estranhamente, parece que minhas corridas não foram cumpridas
0 2004 363 23 0.04166667 -8.001 1.312 0.000 0.000 2.650 339.257 332.666 1.706 0.308
0 2004 364 0 0.04166667 -8.102 1.282 0.000 0.000 2.798 340.570 329.895 1.882 0.308
0 2004 364 1 0.04166667 -8.179 0.948 0.000 0.000 2.600 326.437 328.132 1.858 0.308
0 2004 364 2 0.04166667 -8.185 1.356 0.000 0.000 3.499 346.979 327.062 1.994 0.308
0 2004 364 3 0.04166667 -8.279 1.454 0.000 0.000 3.650 354.288 324.500 2.441 0.308
0 2004 364 4 0.04166667 -8.084 1.436 0.000 0.000 3.144 347.881 330.015 2.747 0.308
0 2004 364 5 0.04166667 -7.790 1.409 0.000 0.000 2.794 338.550 338.059 2.575 0.308
0 2004 364 6 0.04166667 -7.425 1.382 0.000 0.000 1.942 326.654 348.660 2.749 0.308
0 2004 364 7 0.04166667 -6.757 1.374 0.000 0.000 0.116 305.884 368.999 3.290 0.308
0 2004 364 8 0.04166667 -5.497 1.369 0.052 0.000 0.000 267.967 406.701 3.472 0.308
0 2004 364 9 0.04166667 -3.161 1.353 0.067 0.000 0.000 188.884 484.994 4.810 0.308
0 2004 364 10 0.04166667 -1.557 1.341 0.145 0.466 0.000 127.691 545.617 5.119 0.308
0 2004 364 11 0.04166667 -0.740 1.330 0.138 1.087 0.000 93.617 579.172 2.841 0.308
0 2004 364 12 0.04166667 -0.388 1.283 0.155 1.863 0.000 76.253 594.238 2.865 0.308
0 2004 364 13 0.04166667 0.049 0.950 0.138 1.242 0.000 41.232 613.402 6.940 0.308
0 2004 364 14 0.04166667 0.994 1.338 0.119 2.951 0.000 16.352 656.804 6.072 0.308
0 2004 364 15 0.04166667 2.087 1.468 0.053 0.932 0.000 -30.885 710.365 5.627 0.308
0 2004 364 16 0.04166667 2.681 1.463 0.001 0.621 0.000 -61.660 740.909 4.882 0.308
0 2004 364 17 0.04166667 2.867 1.445 0.000 0.776 0.000 -72.437 750.800 4.829 0.308
0 2004 364 18 0.04166667 3.600 1.435 0.000 0.776 0.000 -112.841 790.720 2.381 0.308
0 2004 364 19 0.04166667 4.299 1.430 0.000 0.466 0.000 -152.990 830.614 2.522 0.308
0 2004 364 20 0.04166667 5.669 1.433 0.000 0.466 0.000 -235.950 913.729 2.470 0.309
0 2004 364 21 0.04166667 6.689 1.424 0.000 0.310 5.008 -298.007 975.312 6.086 0.309
0 2004 364 22 0.04166667 6.645 1.409 0.000 0.155 13.670 -287.069 963.670 4.143 0.310
0 2004 364 23 0.04166667 6.032 1.435 0.000 0.155 53.540 -205.478 883.343 4.816 0.311
sim, por um ano não bissexto, meu clim começa com 1 e termina com 365
> head(clim)
V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 V14
1 0 2005 1 0.0 0.02083333 9.981012 -0.1449951 0 0 336 0 895.1882 1 0.6
2 0 2005 1 0.5 0.02083333 10.042993 -0.1409973 0 0 347 0 889.3658 1 0.6
> tail(clim)
V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 V14
122683 0 2011 365 21.0 0.02083333 5.499994 0.4399963 0 0 89 0 815.5093 1 0.6
122684 0 2011 365 21.5 0.02083333 5.480005 0.4500061 0 0 98 0 805.2459 1 0.6
122685 0 2011 365 22.0 0.02083333 5.260004 0.4599854 0 0 83 0 806.4457 1 0.6
122686 0 2011 365 22.5 0.02083333 5.059991 0.4699951 0 0 69 0 808.0639 1 0.6
122687 0 2011 365 23.0 0.02083333 5.219995 0.4699951 0 0 79 0 807.9565 1 0.6
122688 0 2011 365 23.5 0.02083333 5.390009 0.4500061 0 0 92 0 805.5776 1 0.6
@istfer , você quis dizer começa com 1 e termina com 365?
serbinsh
em 5 set. 2018
ugh sim
istfer
em 5 set. 2018
@istfer e se implementarmos algo como:
if (tail(unique(sipnet.output$day), n=1)==365) {
tvals <- sub.sipnet.output$day-1 + (sub.sipnet.output$time/out.day)
} else {
tvals <- sub.sipnet.output$day + (sub.sipnet.output$time/out.day)
}
t <- ncdf4::ncdim_def(name = "time",
units = paste0("days since ", y, "-01-01 00:00:00"),
vals = tvals,
calendar = "standard",
unlim = TRUE)
o ponto deve ser consistente com 0-364 / 365 dependendo do não / salto em vez de alguns sendo 1-365 / 366
mas então como lidar com corre menos de um ano ....
serbinsh
em 5 set. 2018
arrggh que não vai funcionar se houver um ano bissexto.
serbinsh
em 5 set. 2018
Isso também não funcionará para tiragens mais curtas. Não se esqueça de que agora temos previsões SIPNET de 16 dias em execução diariamente em Willow Creek
mdietze
em 5 set. 2018
é mais difícil do que deveria ser porque somos inconsistentes com a forma como os dias atendidos são especificados para a SIPNET? Isso às vezes é atendido como 0 de início e às vezes é indexado com base em um dia de início de 1? Podemos escolher apenas um? Dito isso, não tenho certeza da melhor forma de tornar esta parte traseira compatível ... mas como é, eu não acho que queremos ter as duas. Suponho que poderíamos olhar para o arquivo met, mas, novamente, pode não ter datas de início / fim do ano se apenas algumas semanas de drivers de met. Não sei a solução agora ....
serbinsh
em 5 set. 2018
Se o problema for a diferença entre runk e r136 (e avançar), então estou bem em quebrar a compatibilidade com versões anteriores do runk, retirando-o da VM e rotulando-o como obsoleto. Não há realmente nenhuma diferença na coragem do modelo entre os dois e o r136 tem algumas correções de bug de E / S.
mdietze
em 5 set. 2018
O dia do ano deve começar com 1 para representar 1 de janeiro. Observe também as mudanças de fuso horário. Mudar de UTC para CST ou EST ou vice-versa é outra fonte de erro em termos de quando os dias de início / término não são analisados corretamente em drivers de entrada ou saídas. Os arquivos Ameriflux estão no horário local, então as coisas mudam durante as conversões. Isso leva a dias sendo adicionados ou removidos.
ankurdesai
em 5 set. 2018
@mdietze Não acho que seja um problema de versão, pelo menos para SIPNET, parece mais um problema de como os drivers met são especificados.
serbinsh
em 5 set. 2018
O problema do https://github.com/PecanProject/pecan/issues/2094#issuecomment -418801635
serbinsh
em 5 set. 2018
O que precisamos é uma maneira padrão de definir o tempo em netCDF, que inclui dias desde, tipo de calendário e como os valores de tempo são especificados, de modo a evitar o problema 0/365/366 como sendo lido como a mesma data e, portanto, duplicado. Obviamente, quando usamos salto, precisamos especificar um salto cal e, se não, provavelmente, especificar um no_leap cal, mas também devemos ser consistentes de que os valores devem ser de 1.x a 364.x (ou 365.x se salto) para todos os modelos saída
esta é novamente outra toca de coelho que eu não previ ao iniciar esta discussão ... Eu pensei que talvez fosse uma solução bastante rápida, mas parece que na verdade não é
serbinsh
em 5 set. 2018
Parece que realmente queremos primeiro determinar a data posix e, em seguida, gerar os tvals DOY a partir disso .... e também que precisamos começar com 0, por exemplo
> as.Date(300, origin="2001-01-01")
[1] "2001-10-28"
> as.Date(364, origin="2001-01-01")
[1] "2001-12-31"
> as.Date(1, origin="2001-01-01")
[1] "2001-01-02"
> as.Date(0, origin="2001-01-01")
[1] "2001-01-01"
> as.Date(365, origin="2001-01-01")
[1] "2002-01-01"
... ou talvez comecemos a usar limites de tempo, por exemplo
double time(time) ;
time:units = "days since 1850-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:axis = "T" ;
time:long_name = "time" ;
time:standard_name = "time" ;
time:bounds = "time_bounds" ;
double time_bounds(time, nv) ;
time_bounds:long_name = "time_bounds" ;
time_bounds:standard_name = "time_bounds" ;
Parece que concluímos que os anos começam em 0. Existem outras coisas para resolver aqui? (além de algumas correções de código e testes para garantir que met2CF, met2model e model2netcdf estejam fazendo isso corretamente)
mdietze
em 6 set. 2018
bpbond
em 6 set. 2018
@mdietze dê uma olhada em https://github.com/PecanProject/pecan/pull/2095 Provavelmente ainda alguma limpeza, mas eu testei no modex (comando e via web) e ele não quebra PEcAn, mas fornece os "time_bounds" adicionais que é comum na saída global do ESM e, portanto, algo que programas como ILAMB procuram. Fornece pontos de tempo de início / fim para cada etapa de tempo, o que significa que usamos time ou time_bounds para definir a comparação com os dados, etc. Onde time_bounds podem ser usados agregar dados de frequência mais alta em bins de saída do modelo exato..etc. E, como sugeriu Nate, nossos resultados não são instantâneos e, como tal, os limites fornecem limites explícitos para cada etapa.
de qualquer forma, eu esperava que pudéssemos adicionar à saída, uma vez que não afeta as funções existentes, mas poderia adicionar funcionalidade no futuro e fornecer uma conexão mais fácil com ILAMB em vez de ter que encontrar uma solução alternativa para ler "tempo" e fazer suposições em a comparação com benchmarks ..... feliz em explicar mais amanhã
serbinsh
em 6 set. 2018
Por exemplo, saída CLMCN global
netcdf rsds_Amon_CLM40cn_historical_r1i1p1_185001-201012 {
dimensions:
time = UNLIMITED ; // (1932 currently)
lat = 192 ;
lon = 288 ;
levgrnd = 15 ;
levlak = 10 ;
hist_interval = 2 ;
variables:
float lat(lat) ;
lat:long_name = "coordinate latitude" ;
lat:units = "degrees_north" ;
lat:_FillValue = 1.e+36f ;
lat:missing_value = 1.e+36f ;
float levgrnd(levgrnd) ;
levgrnd:long_name = "coordinate soil levels" ;
levgrnd:units = "m" ;
float levlak(levlak) ;
levlak:long_name = "coordinate lake levels" ;
levlak:units = "m" ;
float lon(lon) ;
lon:long_name = "coordinate longitude" ;
lon:units = "degrees_east" ;
lon:_FillValue = 1.e+36f ;
lon:missing_value = 1.e+36f ;
float time(time) ;
time:long_name = "time" ;
time:units = "days since 1850-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:bounds = "time_bounds" ;
double time_bounds(time, hist_interval) ;
time_bounds:long_name = "history time interval endpoints" ;
Uma coisa que eu preferiria é se pudéssemos remover a variável int da saída e ter apenas a variável dimensional.
é assim que SIPNET está escrito em meu PR
[sserbin<strong i="10">@modex</strong> 2000078549]$ ncdump -h 2001.nc
netcdf \2001 {
dimensions:
time_interval = 2 ;
time = UNLIMITED ; // (8760 currently)
lon = 1 ;
lat = 1 ;
variables:
int time_interval(time_interval) ;
time_interval:long_name = "output time interval endpoints" ;
double time(time) ;
time:units = "days since 2001-01-01 00:00:00" ;
time:long_name = "time" ;
time:calendar = "standard" ;
time:bounds = "time_bounds" ;
double time_bounds(time, time_interval) ;
time_bounds:units = "days since 2001-01-01 00:00:00" ;
time_bounds:long_name = "output time bounds" ;
e aqui está a saída CLM-FATES
float time(time) ;
time:long_name = "time" ;
time:units = "days since 1900-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:bounds = "time_bounds" ;
int mcdate(time) ;
mcdate:long_name = "current date (YYYYMMDD)" ;
int mcsec(time) ;
mcsec:long_name = "current seconds of current date" ;
mcsec:units = "s" ;
int mdcur(time) ;
mdcur:long_name = "current day (from base day)" ;
int mscur(time) ;
mscur:long_name = "current seconds of current day" ;
int nstep(time) ;
nstep:long_name = "time step" ;
double time_bounds(time, hist_interval) ;
time_bounds:long_name = "history time interval endpoints" ;
Então eu acho que as perguntas são 1) estamos felizes com a inclusão de uma variável de limites, 2) em caso afirmativo, como devemos chamá-la (parece que para CLM é comum chamá-lo de "hist_interval" de tamanho 2) com um nome longo de "history time interval endpoints" e nenhuma unidade; 3) se mantivermos essa variável, evitamos obter o
int time_interval(time_interval) ;
time_interval:long_name = "output time interval endpoints" ;
aparecer? .... e tudo o mais que eu possa estar perdendo / esquecendo.
serbinsh
em 6 set. 2018
Este problema está desatualizado porque esteve aberto 365 dias sem atividades.
![github-actions[bot] picture](https://avatars.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
em 11 abr. 2020
Questões relacionadas
infotroph
·
9Comentários
serbinsh
·
39Comentários
ashiklom
·
9Comentários
istfer
·
6Comentários
tonygardella
·
5Comentários
Comentários muito úteis