Naser Mahfouz

But what if we get field X into the diag and then do some ops on it (like say X_at_model_top). Assuming X is masked at that instance, then X_at_model_top will...

That's a good question. I assumed we had some fields like that. I now think we actually don't ... [see this search query](https://github.com/search?q=repo%3AE3SM-Project%2FE3SM%20DefaultFillValue&type=code) of our codebase

This code in COSP should be replaced with a proper masked value treatment: [link](https://github.com/E3SM-Project/E3SM/blob/f0aef174f94b228aee26bd2e6d269a65ac8bb22b/components/eamxx/src/physics/cosp/eamxx_cosp.cpp#L218-L248). That would be the first application of it I guess ...

@meng630 + @TaufiqHassan please note that this issue is on our radar for masked fields in diagnostics. AODVIS (in EAMxx, it can be requested as `AerosolOpticalDepth550nm`, and it is implemented...

> Hi [@mahf708](https://github.com/mahf708) , would you be able to revisit this issue soon? We'll need to AOD diagnostic output to be ready soon for evaluation of the ne256 simulations. Yeah,...

@bartgol, let's prioritize fixing this? I am not sure where your thinking is, but we are reaching a point where we likely want any solution. Either brute force or cutesy,...

I think you should make optional diagnostics optional in a way that doesn't increase memory. Here, you could simply hide away the diagnostics behind an extra_diags flag ```diff // ......

> The tests are passing, so I am planning to merge this PR. > > > > There are some outstanding issues (e.g., hide diagnostics using a namelist flag), and...

> > Why not expose 3D fields now? > > > > This PR has a lot of other changes from the MAM4xx submodule and the HAERO submodule (e.g., cmake...

@jsbamboo what's your conclusion on this? Any updates? Does this introduce scientifically invalid output in your cases?