Threading with regrid_data_plane

[robdarvell]

I'm testing out regridding our global data before running gridstat rather than within the gridstat job to try and improve runtime performance. Since the introduction of the threading to the regrid code if I forget to specify this variable in my job the scheduler I am using resets the value to the number of cpus, in my case 256 (this is running on our new Cray EX supercomputer). The job still runs through fine, but it is coming out with some strange values in the output (regridding value outside of the range in the initial file eg: max pressure values of 103450 then when regridded max value 109375), and if I run the same job more than once I get different answers. The output netcdf files can also look 'blurry' when visualised. If I specify a value in the job (eg: 1, 4, 8, not tried too high) then all looks good.
This discussion is more a question on the different answers being seen when running the same setup (with the large thread number).
netcdf file and config to be sent for your own testing.

Rob

[JohnHalleyGotway]

Thanks for raising this issue @robdarvell. Using the command you sent via email, I was able to replicate this undesirable behavior on our Linux project machine. And the key is that the inconsistent output occurs when regridding using the Area-Weighted regridding method (-method AW_MEAN). So now I know where to look.

I documented this problem in this dtcenter/MET#3206 bugfix issue. I'll go try to debug/fix this for the upcoming MET-12.1.0 release. And I'll go ahead and mark this discussion as being answered/closed.

Please feel free to comment on dtcenter/MET#3206 with any other details related to this problem.

Thanks for finding this bug!