geoschem / integrated_methane_inversion

Integrated Methane Inversion workflow repository.
https://imi.readthedocs.org
MIT License
25 stars 19 forks source link

Global native resolution state vector creation issue #181

Closed eastjames closed 6 months ago

eastjames commented 7 months ago

Name and Institution (Required)

Name: James East Institution: Harvard ACMG

Description of your issue or question

I'm using the feature/global_inversion branch. When creating a native resolution state vector on the 2x2.5° grid, IMI creates a state vector element for all grid cells north of 60°S, totaling 10,800 state vector elements. A map looks like this:

import xarray as xr
import matplotlib.pyplot as plt
import pycno

with xr.open_dataset('StateVector_orig.nc') as ds:
    sv_orig = ds['StateVector']

cno = pycno.cno(xlim=(-180,180),ylim=(-90,90))

sv_orig.plot()
cno.draw()
Screenshot 2023-12-28 at 11 26 39 AM

This happens in src/utilities/make_state_vector_file.py. The latitude of the HEMCO file used to filter for offshore O&G emissions gets manually adjusted, probably for regional applications. Also, the check for a land threshold always evaluates to false probably not intentionally.

Adding a check for mismatched longitudes at line 88-90 and changing the land_threshold check at line 139 seems to work:

    # Require hemco diags on same global grid as land cover map
    if np.abs(lc.lon.values - hd.lon.values).max() != 0: #JDE add a check
        hd["lon"] = hd["lon"] - 0.03125  # initially offset by 0.03125 degrees
    #if land_threshold: #old
    if land_threshold > 0: #JDE change

New state vector file:

Screenshot 2023-12-28 at 11 26 50 AM
nicholasbalasus commented 7 months ago

Hey James, the offset issue you describe was due to an issue in HEMCO that we fixed. See this IMI issue. The solution is to update the HEMCO standalone outputs used for this check using the updated version of HEMCO, which we should probably do before IMI 2.0 anyway given the emissions that have changed recently.

eastjames commented 7 months ago

Thanks, Nick. I think this is slightly different -- the latitude adjustment was being applied regardless of what grid resolution is being used, so in global applications it was incorrectly shifting the latitude. I added a check so that it won't apply the adjustment if there is no misalignment. It sounds like updating the HEMCO standalone outputs and getting ride of the latitude adjustment will take care of it, but I needed to do this for now.

nicholasbalasus commented 7 months ago

Thanks, James - my bad, I just meant that the HEMCO bug was why the adjustment has to exist at all (though it is only applicable for the 0.25° x 0.3125° case as you point out)!