UF File Writing about pyart HOT 14 CLOSED

@josephhardinee Very cool, would this also include the ability to read UF files without RSL? I have the beginnings of a module that can read UF files. I'll post it somewhere if it helps.

from pyart.

I'd just planned on writing UF, though I have a UF reader written also(RSL doesn't work with NCAR format UF files a lot of the time). I can push it into another branch and we can compare and merge the codes.

from pyart.

I'll start a UF branch in the next few days for the codes I have and add a link here.

from pyart.

@josephhardinee Any updates on this work?

from pyart.

It kind of got strangled by dissertation writing. Hopefully I should be able to revisit it very soon.

from pyart.

Is some one working in this issue? Responding from a request from Simepar, I would like to get to it.

from pyart.

@josephhardinee mentioned he had some code for this at the AMS radar meeting.

Since I added support for reading UF and am now well versed in the format I can try to code something up this afternoon.

from pyart.

In progress work on a UF writing appears in the jjhelmus/pyart/uf_write branch. This branch will rebased when complete.

from pyart.

Closed with the merging of #388

from pyart.

Nice work @jjhelmus

@TulipaSilva can you please confirm that TITAN is recognizing this UF-files. If you don't have the time, ask someone else, Beneti is aware of that.

from pyart.

Let me know if there are any issue with UF writing that you find. Code coverage is 100% but it could still use some testing with real world files. Two other things to keep in mind are:

• Py-ART is writing UF files with 2-byte padding around each record, this is consistent with the files RSL creates but may not be supported by all software. If you need 1-byte or no padding files open an issue and I should be able to add support for these files without too much work.
• UF writing in Py-ART relatively slow, probably no good way around this without some serious optimization.

from pyart.

BUG: in line 265 it should be / 1000 and not * 1000, this is causing overflow and consequent error while packing. Also in line 266 I believe 'range_start_m' is just the decimal part of the range, otherwise a start range of 33 km will overflow and I don't see a reason for repeating the information. Sorry it took so long for reporting this bug.

Also I would have found more comfortable, fields not present in uf_field_names to be excluded from writing, and not causing an KeyError: in line 150. But you probably have your reasons for not doing so.

from pyart.

Thanks @gamaanderson for catching these. All three of these are bugs, I will have a fix for them shortly.

from pyart.

PR #400 fixes all three of these bugs.

from pyart.