Closed czender closed 6 years ago
@czender
The below command is working for me with the latest repo version of NCO
ncks -v spectral_channel_quality -m s5p.n
With the below command I am getting
ncks -m s5p.nc
nco_err_exit(): ERROR Short NCO-generated message (usually name of function that triggered error): nco_inq_varid() nco_err_exit(): ERROR Error code is -59. Translation into English with nc_strerror(-59) is "NetCDF: Name contains illegal characters" nco_err_exit(): ERROR NCO will now exit with system call exit(EXIT_FAILURE)
This fails for me on MacOS, yet works on Linux:
ncks -v spectral_channel_quality -m s5p.nc
This fails on both:
ncks -m s5p.nc
Please continue investigation into second command failure on Linux.
@czender have done a fix to nco_prn_cdl_trd() so that COMPOUND/ENUM/VLEN/OPAQUE types are ignored and NOT marked for extraction. Maybe the traversal table should NOT be picking up these types. Let me think some more on this. Anyways my fix is in the branch hmb_fix_cdl
The command ncks -m s5p.nc
now works
Great! Please propagate the fix to XML and JSON printing if you have not already. We want to keep each output type working for all input classes. Also take time and think how this should be done with an eye towards allowing the easiest non-atomic types (enum and vlen?) to work with certain NCO features, starting with extraction and printing. 4.7.4 should include the fixes that allow printing of as much of the S5P datasets as possible with the minimal hassle.
@czender OK I have a more thematic one line fix - will add fix to XML & JSON and then commit in branch hmb_fix_cdl
ok json, xml, trd, cdl all fixed in branch hmb_fix_cdl
Please merge to master then close issue. If you have ideas on extracting/printing non-atomic types, please open a new issue to discuss. This S5P dataset is a good one to use to prioritize changes that are useful to the community.
merged
This S5P L1B file breaks
ncks
, and the question is why. If the answer is fixable, then we'll do that later, for now we just need to know why:The warning clearly says there are non-atomic type (NAT, i.e., vlen_t) variables. Is that what breaks it?
ncks
was designed to ignore NAT variables, but maybe in some cases it does not. Or maybe it's a fixable bug in thencks
print or extraction code. Please run this through a debugger and see why it fails. I got this stacktrace but do not have time to follow through:Thanks!