Review Comments For GMD-2022-35: Checkerboard Patterns in E3SMv2 and E3SM-MMFv2

This work identifies checkerboard patterns in the E3SMv2 and E3SM-MMF simulations. The pattern is mostly prominent in the precipitation and liquid water path and shows persistence in various timescales. The authors identified the DCAPE convection trigger as the primary cause of such a pattern in E2SMv2 by showing a diminished pattern when turning off the trigger. They also provided an hypothesis that the pattern in E3SM-MMF is caused by the fluctuation trapping. Satellite data are used as a validation reference. Potential solutions for both model configurations are discussed at the end. 

This paper is well written. It brings up the non-negligible persistent and non-physical patterns in the model results, and logically tracks down the causes for the patterns. It points out the potential problems with the physical parameterization (i.e., convection trigger) and the design of CRM configurations of E3SMv2. I recommend acceptance with minor revision.

A general question for curiocity: Have you performed any sensitivity tests on various resolution setups? It would be interesting to see whether the patterns occurs at all or whether they are more/less frequent under different resolutions.

Minor comments:

1. Lines 182 - 186 and Figs 4-5: As the authors pointed out, the E3SMv2 shows less obvious patterns. It will be better to show 1) a map of difference between with/without DCAPE, and 2) maps of the differences between simulations and satellite regrided results.
2. Line 196: I believe the author meant to refer to Figure 6b,d here.
3. Figure 6: Is there an explanation why the simulation without DCAPE is even smoother than satellite results?

This article describes the checkerboard pattern that occurs in the E3SM atmospheric component in some of the cloud components (e.g., precipitation and liquid water path). This phenomenon only occurs over water and in the vertical levels where shallow clouds are present. Moreover, this phenomenon occurs in both E3SMv2 (which uses standard subgrid-scale (SGS) parameterizations) and E3SM-MMFv2 (which replaces the standard SGS parameterization with what had been previously referred to as “super-parameterization”). This phenomenon can be essentially removed in E3SMv2 when the DCAPE trigger is disabled; this is quite puzzling to me but, without understanding the mechanism of their DCAPE it is difficult to conjecture why this would happen.  To capture this checkerboard pattern the authors develop an interesting technique whereby they divide the domain into groups of element (9), compute the mean and then mark the 8 elements (excluding the center element) with either a 0 or a 1 depending on whether the local mean is below or above the group mean.  Using this approach, they can now easily identify the checkerboard noise signal.

The article is well-written (with only a few grammatical errors), and it does a good job of explaining what they did although they can do better (see Minor Comments below).  The authors identify some possible fixes so am wondering why they didn’t address the fixes in this paper. Why wait for another paper? I would find that paper a far more interesting paper since it (1) identifies an issue in moist models, (2) presents a means to capture this signal, and (3) fixes the issue.  The current paper only addresses the first two items but it’s up to the authors what they want to include in this paper.

The current version of the paper would have a stronger impact on the community if more details were included that would allow for more easily understand reproducibility. I am referring specifically to their MMF setup. Even though it has been described elsewhere, it would be best to give more details here (see Minor Comments below).

My recommendation is to accept with minor revision since none of my suggestions require running code or performing additional analysis. 

Minor Comments

Below, I will go through minor points in sequential order. When I write “fix” this means there is a grammatical error”

Line 30:  Why would the fact that the derivatives are discontinuous at element edges be problematic for the MMF model. The DSS operator takes care of this “discontinuity”.

Line 35: If each spectral element is decomposed into 4 finite volume cells then you will have 4N_e MMF models (where N_e are the number of spectral elements). Is this correct?

Line 80: Section 2.1 needs more details. This is where your new algorithm is described but I had a difficult time following it.  E.g., are you doing this analysis to the spectral element (SE) cells, where you compute the dynamics,  or to the finite volume (FV) cells, where you compute the physics?  A picture here would go a long way to better explaining this. 

Line 82: Fix near “between”

Line 83: Fix near “northernmost”

Table 1: A figure showing what these look like would be awesome.

Line 92: Fix near “equal”

Line 93: Why ignore the center cell?

Line 127: A clear description of the CRM is essential here. E.g., how wide is the horizontal, what are its dimensions, etc? Is it too small so that the periodicity keeps things localized and moist components remain captured? Is the MMF domain 2D, 3D?  A brief, but clear, description of your setup is imperative.

Line 143: Sec. 2.4 contains your model simulations. More details would be helpful here. E.g., do you only use MPI? MPI with OpenMP for multi-threading on KNL hardware?

Line 198: fix near “occurrence”

Line 285: fix near “balance”

Line 304: is the rest of the physics the same? Is this why you think it is the dynamical core?  Doesn't E3SM-atmos use nonhydrostatic equations while CAM uses hydrostatic? Any other big differences you can identify?

Line 311: Regarding your conjecture that the “scale gap” is a design flaw of the MMF approach.  Perhaps the issue is that the GCM is not imposing as big an influence on the CRM and, therefore, the CRM dynamics remain trapped (but I suppose this will always be the case when the CRM is allowed to evolve independently, no? Perhaps this is what you are saying). So the fix is to let these processes out - your variance transport.  Would be very interested in hearing about how this is applied and could very well save the MMF idea.

Figure 1 Caption: fix near “scale”