after Sept 16th, the thicknesses do look on a par with what you would expect this year - before that date, thicknesses are not trustworthy.
No, it's just a scaling visualization issue. Here the ESRL program is experimental, PanoplyCL is in beta, and I am making novel forum-adapted graphics out of raw data files like RASM-ESRL_2017-09-28-00_t048.nc rather than using 'official' ESRL web products (from which glitches may have vanished in their better-informed processing). There's no methods paper out yet.
Here's how scaling works: the ice thickness numbers modeled for a given day fall within a certain range. If PanoplyCL uses the default 'fit to data' setting, the palette colors will be assigned evenly over the
full range of data values, even if some are sparsely occupied or altogether unrepresented.
However maybe 0.5% are artifactual outliers due to some internal problem in the calculation, for example near the coastline. These outliers can fluctuate wildly from day to day. If they are not filtered out somehow, because palette color assignments
follow the range in 'fit to data' mode, the colors of the map won't be consistent from day to day (ie frame to frame in the animation).
Outlying thicknesses will get palette colors on the far right, intermediate colors won't be used at all, and core range thicknesses will be crammed into what's still available in the palette.
Meanwhile, the core range that ice thicknesses take on is much smaller and varies seasonally but very little from day to day. After skimming through the files, I replaced 'fit to data' with a fixed 3.6 m for the outer limit of thickness for all 49 days to get consistent coloration. Ice at higher thickness, some reasonable like 3.65 m and some obviously erroneous but rare outliers like 17.5 m get collapsed into the final palette color, just like in WorldView.
Around 16 Sept, ESRL seems to have refined the internal algorithmic glitch that was creating the outliers. From that date on, the ranges varied little and 'fit to data' barely differed from 'fit to 3.6'. That doesn't imply that the earlier data was wrong, only that 'fit to 3.6' wasn't the right scale for synching the palette scale to actual thicknesses or for smooth color transitions over the change.
Since the early parts of the animation were well synched to each other up until the glitch, they likely just need a constant rescale, say 5.0 instead of 3.6 m, to make the whole series harmonious. To determine that rescale, reload the the 15th and 16th in Panoply's linear grayscale and divide in Combine Arrays.
Some computer mishap seems to have occurred on Sept 10th. There are data gaps on 8th and then again for the 11th and 12th which have not been filled. On the 13th (and subsequently) when the archive resumed, they dropped the t024.nc time slot, going right to forecast day two t048.nc. Elsewhere a file would be described by its start and stop hours, eg t000 to t024.
These mishaps occur in all the archives. Yesterday, on another forum, a pacman data gap in AMSR2 drew comment. That's not been fixed and cannot be fixed if the responsible satellite or receiving ground station had a glitch.
In the bigger picture of netCDF climate files, pre-calculated statistical properties of the data distribution should be part of the file, not sit implicit in machine-readable binary. That would allow consistent automated definition of outliers as well as 'histogram equalization', both discussed at length over at Dev Corner. Panoply does provide thicknesses averaged over latitude (with land masked out) which is a start.
RASM-ESRL ice thickness has commonality with sparsely gridded Hycom. Both of these are in serious conflict with the less-nuanced ringed display of Piomas. A round of Cryosat2 flight lines takes a month to get close to full coverage; it's challenging to compare experiment with model.
The only thickness reset available is new ice forming each fall from open water. The older ice will wander off farther and farther into uncertainty as time goes on, whatever the modeling system. Ice thickness is a derived product in RASM-ESRL; they have 49 outputs overall.
From the perspective of differential equations, where did the initial conditions come from on the start date? It's time evolution won't be any better than that. Daily satellite inputs might reset attributes like ice boundary or melt pond fraction but thickness is known only on the open water (zero).
The model is initialized with the NOAA Global Forecast System (GFS) analyses and the Advanced Microwave Scanning Radiometer 2 (AMSR2) sea ice concentrations. The model is forced at the lateral boundaries by 3-hourly GFS forecasts of winds, temperature, and water vapor. Weather Research and Forecasting (WRF3.5.1; run with 40 vertical levels) atmospheric model; the Parallel Ocean Program (POP2) model; the Los Alamos Community Ice Model (CICE5.1; and the NCAR Community Land Model (CLM4.5). All components, run at 10 km horizontal resolution, are coupled using a regionalized version of the CESM flux coupler (CPL7), which includes modifications (Roberts et al. 2014) important for resolving the sea ice pack response to weather events. Other model optimizations include: a bulk double-moment cloud microphysics scheme for droplets and frozen hydrometeors, running ensemble forecasts initialized with GEFS ensemble members, and extending the model domain to include the Bering Strait and Svalbard.
The most striking feature in RASM-ESRL thickness animation (passing over glitch) is how little the ice has moved about this summer (or grown or shrunk). The patches of enhanced thickness jostle about indecisively. There's no indication of textbook Transpolar Drift or Beaufort Gyre. If that persists, the plan for the frozen-in Polarstern might need serious revision.
The animation below shows the dramatic effects in map coloration using a fixed palette to display the same data in core vs outlier range settings. Scientific visualization has a great many issues; we can explore them only when the data archiving site provides the underlying netCDF file. Many do, but others just post their favorite depiction (which may use an awful palette and bury data under text and grid lines).