libaec fails with pgi compiler

We encounter a proplem on daint, when we compile with pgcc and use libaec inside of eccodes within cdi inside iconleading we get wrong results. However, we still can unpack the file, but it is ridicouslly small and the values are incorrect.

In a first step we replace libaec by a gcc compiled one, to see, if that fixes the problem. @k202009 its just to keep you informed.

Just checked with pgi on mistral and checks pass. Does make test/check for libaec work on daint?

pgi doesn't seem to support the gcc __builtin_clzll() intrinsic so decoding is a little slower and it uses the C code path. Results should be correct in any case, though.

Well, it is not on daint with pgi-20.1.1. As results are fine with all other compilers, I have been testing and put eccodes are fine ... I'm further investigating and will update here the findings.

Maybe it is the interface between eccodes and libaec ...? Thanks for testing.

The eccodes interface is very simple. I would be surprised if that code triggers a compiler error. If you can boil something down to reproduce the error on mistral, I will have a look.

Full icon code in r2b9 with GPU :-(

Some more news on this:

Hi Luis,

We have been battling with an issue for a couple of days while trying to run on Summit, involving PGI compiler, libaec and eccodes. Meanwhile we saw your report in #1 Sorry I don’t have a login there to post a reply, which seems a missed opportunity — why not use GitHub?

Carrying on … we seem to have the same issue. We can encode and we get some results but the message sizes are very small and the values are not quite correct. The minimum was clipped and the number of different values was 10x less than with grib_simple.

Anyway, we found a work around, which is to prepare a template where the grib_ccsds is already set and bitsPerValue is set to 16. During the run, we only set the arrays, we don’t call eccodes to set packing parameters. Then all the fields seem compressed correctly without any clipping.

We still haven’t found what really is the cause. My suspicion is how we interpret the bits_per_value and block_size in the aec_stream struct (as it goes in). Shahram and I will continue to dig and see if eccodes needs a fix or simply how we use it...

Hope this helps you find a workaround for Pitz Daint,

Tiago

Okay, if eccodes somehow screws up bitsPerValue then it's no wonder data gets lost during compression. I'll look into eccodes next week to see if anything goes wrong with option setting. I think I was involved with that code but that had been ages ago.

I guess I need more information here. Simply overriding default values from the template with eccodes grib_set works here. bits_per_value is just taken from the object to pack so it doesn't make sense to change that. Ideally, Tiago or Shahram would give me an example .grib file and a grib_set -r -s packingType=grid_ccsds,... command which corrupts the data.