Non-uniform PassiveTracer in 14.7.0

[yuanjianz]

Your name

Yuanjian Zhang

Your affiliation

WashU

What happened? What did you expect to happen?

PassiveTracer in the TransportTracer simulation is meant to test mass and monotonicity conservation. The monotonicity is tested as the uniform distribution of this spatially uniform tracer upon transport.

https://geos-chem-1yr-benchmarks.s3.amazonaws.com/14.7.0-rc.0/GCHP/TransportTracers/BenchmarkResults/GCHP_version_comparison/TransportTracers/AnnualMean/TransportTracers_FullColumn_ZonalMean_AnnualMean.pdf

In the latest benchmark, the PassiveTracer is no longer unform.

A possible reason is the restart pressure scaling introduced in geoschem/FVdycoreCubed_GridComp#11. The tracer mixing ratio is scaled based on the difference between the pressure depth in the restart file and the meteorological input to ensure mass conservation upon restart. However, for PassiveTracer, which is meant to have uniform mixing ratio of 100ppb anyway, this scaling introduces non-uniformity the first timestep.

To solve this issue, I propose for PassiveTracer:

1. we do not store it in the restart file and rely on bootstrapping to 100ppb whenever the simulation start, and skip the pressure scaling. But this could be a problem for restarting a TransportTracer simulation in the middle of the run.

or

2. manually skip scaling of PassiveTracer, which can be done through

if (fieldname == 'SPC_PassiveTracer')

I prefer the second solution.

What are the steps to reproduce the bug?

Transport Tracer simulation with PassiveTracer

Please attach any relevant configuration and log files.

No response

What GCHP version were you using?

14.7.0

What environment were you running GCHP on?

Other (please explain below)

What compiler and version were you using?

none

What MPI library and version were you using?

none

Will you be addressing this bug yourself?

Yes

Additional information

No response

[yuanjianz]

@lizziel

[yantosca]

Thanks for this issue @yuanjianz. Also tagging @lizziel and @mcdon1718-h for reference.

One problem I foresee is that not storing PassiveTracer in the restart file will mess up the TransportTracers benchmark. The species mass tables are computed from the instantaneous concentrations in the SpeciesRst collection.

[lizziel]

This is a tricky issue. As an aside, we might want to consider having a configuration logical for whether to apply mass conservation scaling if restart met does not match run-time met, applied to all species. I think sometimes users would want to use unmodified ppb values in the restart upon startup, rather than conserve the mass in the restart. You can do this by removing the met from the restart, but that might not be obvious to users. @sdeastham, do you agree with that?

There is also another angle to this not yet mentioned: our transport restart file is the result of a 10-year spinup. The initial values for the passive tracer, therefore, would be not uniform 100 ppb even if we remove the scaling. Any drift from a previous version propagates to the next benchmark. This has come up in the past and I believe we never changed that. @yantosca, is that right? The values seen in the 14.7.0 benchmark, which I guess no one saw before (thank you @yuanjianz for finding this!) might include drift during those years.

I suggest:

1. Adding the logical I mentioned above. I may be misremembering, but I think it only affects if the restart met does not match the run-time met, and that only might happen in the very first of a series of consecutive runs. This avoids the need to remove the met from the restart to just use the ppb values without modification.

2. Remove the passive tracer from the transport tracer restarts we use for benchmarking and provide to the community. When absent, the model will initialize it to 100 ppb everywhere, which is what we want for the first run. When in the restart, it will be used, which is what we want if breaking up the run in time. This update requires only changing our restarts, not modifying the code.

We may need to update GC-Classic to also initialize the passive tracer to 100 ppb at the start of the benchmark, rather than use the 10-year spun up values. @yantosca, correct me if I am wrong that the benchmark still uses use those spun up values.

Does all this make sense?

[yantosca]

@lizziel @yuanjianz, yes I do believe the 10-year TransportTracers benchmark is initialized w/ from the previous 10-year benchmark. I don't recall resetting the PassiveTracer to a uniform value before I ran the 14.7.0 TransportTracers benchmark. We will need to add this into our benchmarking instructions.

[lizziel]

I checked our 14.7.0 restarts that we are providing in ExtData/GEOSCHEM_RESTARTS/GC_14.7.0. Users are initializing passive tracer simulations with this. The upper plots are surface. I think we should definitely remove these variables from those files.

[yuanjianz]

I agree with having a config option but we should make sure it is described clearly in the documentation. And it would be good to remove PassiveTracer from community-oriented restart file.

[lizziel]

@yantosca, are we doing a transport tracer benchmark with 14.8.0? If yes, I think we should make this change before that benchmark.

[yantosca]

@lizziel we can do a transport tracer benchmark.