This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Dcmetar is 1) routinely dropping metars from bulletins which implement the PIL id in line 2 of the bulletin and 2) crashes on bad 5appp group in the RMK section: 1) I noticed dcmetr dropping a number of reports which start with the new MTRxxx on the first line of the bulletin following the WMO header (see Fred Branksi's info on PILs being implemented in bulletins). The METAR and SPECI lines still exist in S(A/P)US70 & 80 bulletins, but individual reports now carry the PIL line. I see that the MTR (AFOS) check was removed from MT_FIND in 4/98, but probably need to reimplement this check. 491 SAUS45 KMSO 191403 RTD MTRHMM METAR KHMM 191350Z 00000KT 20SM SKC M07/M10 RMK NOSPECI 4/001 T10721100 647 SAUS41 KOKX 191403 MTRLGA SPECI KLGA 191402Z 04008KT 1SM -FZRA BR OVC004 M01/M01 A2991 RMK AO2 SFC VIS 1 1/2 FZDZE1359FZRAB1359 R04/P6000FT $ Resulting decoder logs: [25920] 000222/1358 [DCMETR 2] MTRHMM METAR KHMM 191350Z 00000KT 20SM SKC M07/M10 RMK NOSPECI 4/001 T10721100 [25920] 000222/1358 [DCMETR 5] No valid station found in report: MTRHMM METAR KHMM 191350Z 00000KT 20SM SKC M07/M10 RMK NOSPECI 4/001 [25920] 000222/1358 [DCMETR 2] MTRLGA SPECI KLGA 191402Z 04008KT 1SM -FZRA BR OVC004 M01/M01 A2991 RMK AO2 SFC VIS 1 1/2 FZDZE1359FZRA [25920] 000222/1358 [DCMETR 5] No valid station found in report: MTRLGA SPECI KLGA 191402Z 04008KT 1SM -FZRA BR OVC004 M01/M01 A2991 2) I found an occasion for dcmetr to segment fault on our Solaris x86 machine this weekend. The problem was a miscoded metar from KRWI in the 14Z observation from Feb 19, 2000. The remarks section is being inappropriately interpreted as a pressure tendency group. KRWI 191350Z 22012G18KT 7SM FEW060 FEW090 SCT100 OVC130 17/14 A2996 RMK RB 57E15= It should probably have been RAB57RAE15. Instead, since the RB is separated from the 57E15 group, the decoder is interpreting the group as 5appp. When this group gets passed to mt_pten, the appp group gets stored in the pressure tendency as 7x10E15 (the pr_p03d routine only checks to make sure the ppp is not 999). Later in the storage routine, PR_P03C is called and the program segment faults: Feb 22 19:58:47 DCMETR[25201]: Starting Up signal SEGV (no mapping at the fault address) in pr_p03c at line 35 in file "prp03c.f" 35 PR_P03C = psign ( itendc + 1 ) * ptend =>[1] pr_p03c(p03d = 7e+15), line 35 in "prp03c.f" [2] mt_gemp(lunf = 1, ihhmm = 1350, nparm = 29, parms = ARRAY, cprms = ARRAY, imnem = ARRAY, numprm = 29, saoflg = false, iret = 0), line 90 in "mtgemp.f" dbx: out of memory to allocate 1177590784 bytes of expression value [3] mt_dcod(curtim = , line 390 in "mtdcod.f" I placed a check in the mt_pten routine to ensure appp is all numeric: <clip> C------------------------------------------------------------------------ iret = 0 C do i=2,5 CALL ST_ALNM(stpten(i:i),ityp,ier) if(ityp.ne.1) then iret = 22 return endif end do pten = PR_P03D ( stpten ( 2:5 ) ) <clip> Steve Chiswell Unidata User Support