Aquaplanet cases should not require ndep

[jedwards4b]

What happened?

When running a high-resolution aquaplanet case we found that the NTASK count was limited by the resolution of the ndep file. In this case we were running 3.75Km MPAS QPC6, the namelist default ndep file is fndep_clm_hist_b.e21.BWHIST.f09_g17.CMIP6-historical-WACCM.ensmean_1849-2015_monthly_0.9x1.25_c180926.nc We tried to run on 57344 tasks, which should be allowed by mpasa 3.75km but we were limited by the ndep file which causes an error: ESMCI_mesh_create_from_ESMFMesh_ Value unrecognized or out of range - Can't create a Mesh from a file in a VM when that VM contains more PETs than elements in the file.

We need to generate some high resolution ndep files but also aquaplanet should not require ndep to run.

What are the steps to reproduce the bug?

Explained above.

What CAM tag were you using?

cam6_3_119

What machine were you running CAM on?

CISL machine (e.g. cheyenne)

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

No

Extra info

No response

[cacraigucar]

@jedwards4b - Who will be creating the high resolution ndep files, if needed? We can turn off ndep for aquaplanet runs.

[briandobbins]

I don't think we know who'll be creating them yet, if anyone. Per discussion with Erik, they get NDEP from running a WACCM ensemble and calculate averages. Since running high-res WACCM ensembles is cost-prohibitive, it's not clear yet if or when this'll happen.

I'll see if it comes up at the ESPP discussion today, though, and update this discussion afterwards, since it's more of a science issue than a technical one, I think.

[brianpm]

Did @jedwards4b 's changes for this issue ever get incorporated? I think I just encountered it with an error "ERROR: No default value found for drydep_srf_file" in a recent CAM tag.

[cacraigucar]

I saw that I did not have @brian-eaton assigned to the PR #910, so I just did that. He is working through the "misc tag" PRs.

[brian-eaton]

@brianpm, I'm starting to look at this. From the current namelist (atm_in) constructed for an aquaplanet run it's not clear what deposition and emission processes are supposed to be active. Could you provide some guidance on this issue? Thanks.

[brianpm]

I'd like the aquaplanet to be flexible regarding emissions. In the default case, the aquaplanet uses namelist settings to short-circuit aerosol-cloud interactions by specifying a constant drop and ice concentration. That pairs well with the default behavior to skip emissions by just giving no emissions files. Along with the regular diagnostic sea salt flux based on wind speed, which can be controlled with a multiplicative factor that is also a namelist parameter. There are use cases for the aquaplanet with aerosol and even with full chemistry, so I don't want to make it difficult to get back to that.

I've always totally ignored deposition considerations. I guess there should be deposition that matches whatever happens over the open ocean. The nitrogen deposition over the ocean should only matter at all if the biogeochemistry is on (right?); I suppose someone will eventually want to run a coupled aquaplanet with marine biogeochemistry, but I haven't heard of anyone wanting to do that yet. I'm not sure how dry deposition is handled over the ocean, but I guess it must be doing the same in the aquaplanet as in realistic configurations. Same for wet deposition, which I supposed doesn't care about the surface at all (?).

[brian-eaton]

Thanks @brianpm, that's really helpful. Regarding the emissions, I'll leave everything as it is. Then there are the 2 separate deposition issues.

The nitrogen deposition doesn't impact aquaplanet or simple model configurations. In those cases it's just passing data to the coupler that isn't used by DOCN or SOCN components. In PR #910 Jim provided a fix that is aquaplanet specific and doesn't remove the ndep datasets from the namelist. I am going to attempt a fix that works for both aquaplanet and simple models, and removes the ndep datasets from the namelist so that these runs don't depend on having very large files that are not needed.

The dry deposition is different in that it does impact surface layer concentrations in CAM configurations with chemistry in addition to passing fluxes to the coupler (which are not used). I've looked into the drydep_srf_file problem that you just ran into and see that that file is needed for all unstructured grids. In the rectangular grid case the data is interpolated on the fly from a fixed 1 deg dataset, eitheratm/cam/chem/trop_mozart/dvel/regrid_vegetation.nc for non-aquaplanet runs or atm/cam/chem/trop_mozart/dvel/regrid_vegetation_all_zero_aquaplanet_1deg_regularGrid_c20170421.nc for aquaplanet (this latter file was created by you). So FV aquaplanet runs are getting a consistent drydep treatment with no land type variation. On the other hand aquaplanets with unstructured grids are using the same datasets that have been constructed for CAM/CLM runs. The tool used to construct the drydep_srf_file datasets for unstructured grids (tools/mkatmsrffile.F90) could use the all_zero_aquaplanet version of regrid_vegetation to create aquaplanet versions of the drydep_srf_file datasets. But since the file is basically full of zeros I think a better approach will be to modify the drydep_inti routine to just set fraction_landuse to zero directly when running in aquaplanet mode. I will implement this.