[BUG/ISSUE] Buffer zone cells in nested grid not properly re-adjusting to boundary conditions

[lfreese]

Description of the problem

The buffer zone cells of GEOS-Chem should adjust every three hours to match the value of the boundary conditions in the cell (from the GC wiki: "In any case, the tracer concentrations in the “buffer zone” will get overwritten by the 2° x 2.5° or 4° x 5° boundary conditions at the specified time (usually every 3h)"). I am finding that this is not happening, and instead the buffer cells seem to have a pattern where the concentration adjusts to the value at the beginning of the month, every day. This was noticed because of large anomalous values in the buffer zone for ozone and PM2.5 for simulations, but the values were shockingly high (even without advection).

There is a chance the way the buffer zone responds to the boundary condition cells has been changed and that the wiki page with that information (saying that it should adjust every 3 hours) is no longer accurate, but based on my current understanding, these values are quite off what they should be. What this is doing instead is taking the instantaneous value at the beginning of a month (which can be high or low compared to the average), and setting a buffer cell's concentration to go through diurnal cycles based on that. This could have downstream impacts by creating inaccurate gradients, unless this type of pattern is on purpose.

Description of troubleshooting performed

I have tried modifying the CRE for reading in the boundary conditions to 'RF' rather than the suggested 'EY', and the results of that can be seen here:

It looks like the 'RF' is somewhat closer to the boundary conditions, but it is unclear if it is re-adjusting every 3 hours as it should be.

GEOS-Chem version

v12.9.3

Description of modifications

I've modified the code to use emissions inputs from my own inventories; I also modified it so that negative values (I was getting a lot of small negative values from the nested grid) are made into extremely small positive values or zeros.

I've attached two figures showing what is happening below-- it is a comparison of the values in a buffer cell for the boundary condition values vs. the nested grid values. I've done a similar thing for multiple different buffer cells and this pattern where it drops and repeats itself for the whole month is pretty consistent.

I was told to tag @msulprizio since this is a nested grid issue! Thanks in advance for the help.

[yantosca]

Thanks for writing @lfreese. There was a similar issue reported in #700. The fix for that was to change the time cycle flag for boundary conditions to "CRE". Let us know if that works in your case.

[yantosca]

Oops, instead of "CRE", try "EFY". My bad. The "EY" flag only reads once but "EFY" will keep reading.

The behavior of the time-cycle flags was updated in 13.1.0, I believe.

[yantosca]

Just to confirm, in the 13.1.* and later versions, the time flags are now:

                ! Set time cycling behaviour. Possible values are:
                ! - "C"   : cycling <-- DEFAULT
                ! - "CS"  : cycling, skip if not exist
                ! - "CY"  : cycling, always use simulation year
                ! - "CYS" : cycling, always use simulation yr, skip if not exist
                ! - "R"   : range
                ! - "RA"  : range, average outside
                ! - "RF"  : range, forced (error if not in range)
                ! - "RFY" : range, forced, always use simulation year
                ! - "RFY3 : range, forced, always use simulation year, 3-hourly
                ! - "RY"  : range, always use simulation year
                ! - "E"   : exact, read/query once
                ! - "EF"  : exact, forced (error if not exist), read/query once
                ! - "EFY" : exact, forced, always use sim year
                ! - "EFYO": exact, forced, always use sim year, read once
                ! - "EC"  : exact, read/query continuously (e.g. for ESMF interface)
                ! - "ECF" : exact, forced, read/query continuously
                ! - "EY"  : exact, always use simulation year, read/query once
                ! - "A"   : average
                ! - "I"   : interpolate
                ! - "ID"  : interpolate, discontinuous dataset

[yantosca]

You can also keep 12.9.3 and just update HEMCO to version 3.0.0 by getting the latest updates in the "main" branch. Then the EFY flag mentioned above should work.

[lfreese]

Thank you! I'll switch to the 'EFY' and check that it works properly.

[lfreese]

It might be worth updating this wiki page: http://wiki.seas.harvard.edu/geos-chem/index.php/Setting_up_GEOS-Chem_nested_grid_simulations to show 'EFY' as well

[yantosca]

Thanks @lfreese. That page is a bit stale. We are in the process of moving the GC manual to geos-chem.readthedocs.io as time allows. I will update the wiki page in the meantime.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days it will be closed. You can add the "never stale" tag to prevent the Stale bot from closing this issue.

[stale]

Closing due to inactivity

[lfreese]

Hi @yantosca -- I'm hoping to re-open this issue as it seems that it is more than just an error caused by the change to 'CRE'. Using CRE instead of EFY fixes spiking values in the most exterior of the buffer grid cells, but not in the second layer. I'm wondering if this has anything to do with the hard-coding of value 1 in lines 2500-2531 of hco_utilities_gc_mod.F90? It looks like the I,J,L are set to be values of 1 (or I may be misunderstanding that). Another location I have been looking into is the tp_core_window_mod.F90, where I see much of the ghost cell setup is made, but am unclear if this is the right place to look. If it is not in either of these, it does seem to me that the 3-hour reset of buffer/ghost cells to boundary conditions is only working for 1 layer of the buffer/ghost cells rather than whatever number a user sets them to (in the case of nested grid, it is pre-set to 3).

[lfreese]

So I've gone in to run hourly simulations and check out the different ghost cells. Here are figures from

1. 45, -40

2. 45, -41.25

3. 45, -42.5

Where the orange is the nearest buffer cell value and the blue is the nested grid value at that lat/lon These should be three buffer/ghost cells. It does look like the values are technically coming back down to what they should be from the boundary conditions in all three ghost cells every three hours, but they are spiking extremely high in between those three hours in the middle ghost cell (45, -41.25). The main concern is that those spikes could then be read into the main part of the grid, so I am hoping to clarify if these high values can be advected into the rest of the nested grid during the in-between time period, or if this is harmless as the buildup is washed out every few hours. It is also surprising that both the 1st and 2rd ghost cell have similar output, but the 2nd has such large differences.

[stale]

Closing due to inactivity

[msulprizio]

Hi @lfreese. Were you ever able to resolve this issue? If not, we may need further guidance from the nested model community.

[lfreese]

I wasn't able to fully solve this, no! Would be great to bring this to the nested model community. The middle ghost cell does not return to the boundary condition value every 3 hours, while the other two ghost cells do. It doesn't make a large difference when you compare the output of a nested run to the global run (re-gridding the nested to a 4x5), but it still seems worth while to fix as this shouldn't be happening. The code for the ghost cells is just repeated across all of them, so it isn't clear why one cell isn't working properly-- if someone more familiar with this part of the code has thoughts I'd be happy to discuss. I also have trying a simulation with 4-5 ghost cells on my to-do list to see where the error propagates with that.

[yantosca]

This should now be solved in GEOS-Chem 14.2.1, where we now force refresh of the boundary condition arrays every hour. See this PR:

• Impose boundary conditions at every timestep in GC-Classic nested-grid simulations #1895