MICS to CMAQ

MICS.ipynb

I've solved the problem by adding a option options = '-f nc',

cdoo.gridarea( f'-O -remapnn,{dom}.grid -stdatm,0', options = '-f nc', output=areapath, returnCdf=True )

How about?

Great. I made the update.

Dear Barron,

I have obtained too big value of emissions (CO : 100 times).
But I found that MICS.ipynb deal with units very seriously.
I don't know why the emissions have too big value.

Best regards,
Gwang-Jin

Dear Barron,

I found why the emissions have too big value.
When converting gram [g] to mole, should the emissions be divided by some fraction?
For example,

1 moles CO to grams = 28.0101 grams.

In case of CO, MICS has unit of mass Mg/month originally

$ ncdump -h MICS_Asia_CO_2010_0.25x0.25.nc
float CO_RESIDENTIAL(time, lat, lon) ;
CO_RESIDENTIAL:long_name = "CO_RESIDENTIAL" ;
CO_RESIDENTIAL:short_name = "MICS_Asia_CO_RES" ;
CO_RESIDENTIAL:units = "Mg/month" ;

MICS.ipynb is likely to need consideration of mole-mass conversion by each chemical species.
Fortunately, only five species (CO, CO2, NOx, SO2, and NH3) need to be converted.

CO : 1 moles = 28.0101 grams
CO2 : 1 moles = 44.0095 grams
NO : 1 moles = 30.0061 grams
NO2 : 1 moles = 46.00550 grams
SO2 : 1 moles = 64.0638 grams
NH3 : 1 moles = 17.03052 grams

Best regards,
Gwang-Jin

I found that MICS.ipynb has already considered mole-mass conversion regarding NH3.
How about modifying [17] :

splitfactors = {
'NOx': [e2g('NO', 0.9/30.0061), e2g('NO2', 0.1/46.00550)],
'CO': [e2g('CO', 1./28.0101)],
'SO2': [e2g('SO2', 0.97/64.0638), e2p('PSO4', 0.03)],
'NH3': [e2g('NH3', 1./17.03052)],
}

?

I am not sure that PSO4 need no mole-mass conversion. Or

'SO2': [e2g('SO2', 0.97/64.0638), e2p('PSO4', 0.03/64.0638 * 96.)],

?

After changing, I've got a reasonable CO emission [moles/s].

Thank you.

@Gwang-Jin

You're right. My code incorrectly assumed the units for gases (CO, NOx, and SO2) were in Mmol/month like the VOCs. I agree with all of your updates except for NOx. For NOx, the file emissions units are probably in "Mg/month as NO2." This is similar to using TgN instead of TgNOx. The benefit is that the mass does not depend on what the speciation split. This is very common.

So, the conversion for both NO and NO2 would use the Mw of NO2.

You're also correct that PSO4 does not need the adjustment because CMAQ uses g/s for aerosols.

I'll update the gist.

I got it regarding NOx. Thank you.

@barronh Hi Barron! Just wondering do you have any tools or suggestions if I need to reproject gridded emission files from one Lambert Conformal Conic (LCC) projection to another LCC project with the total emissions conserved? Say I need to reproject a 27kmx27km gridded emissions into 36kmx36km grids. Cdos' remapycon seems not working and remapbil gives me close numbers (off by 0.5%). Thanks!

The best choice is using remapycon. The results still won't be perfect, but there are three basic steps to make sure it works right.

1. Convert emissions from CMAQ-ready mass/rates and mole/rates files to flux files (moles/s to moles/m2/s).
2. Set the flux file to the projected space using cdo's grid definition file
3. Run remapycon

Steps 2 and 3 can be combined.

It would be better to ask this type of question thru the CMAS Center forum since it is more general than this gist.

A quick remind
If you are using different machines beyond google colab, different installation methods or versions of CDO could make "cdoo.remapycon" or "cdoo.gridarea" not working. The CDO version on Ubuntu with Colab is 1.9.3 and python3-CDO 1.3.5 here.

If you can't install old-version CDO like 1.9.3, the recent version of CDO I have tested is CDO 2.0.3 using conda.
Several changes to match original code with CDO 2.0.3

1. install cdo bundle:
   I suggest to create a new conda env for cdo so it won't have unexpected bugs happening for conda
   conda create -n cdo
   conda install -c conda-forge cdo python-cdo xarray

2. make sure you also install other required packages for running this gist.
   Pseudonetcdf
   pyproj

3. Now you don't have to use python-cdo interface, you can comment out like
   #import cdo
   #cdoo = cdo.Cdo(cdopath)

4. Change cdoo code
   change
   cdoo.remapycon(f'{dom}.grid', input=fluxpath, output=regridpath, returnCdf=False)
   to
   os.system(f'cdo remapycon,grid.{domain} {fluxpath} {regridpath}')

change
cdoo.gridarea(f'-O -remapnn,{dom}.grid -stdatm,0', options='-f nc', output=areapath, returnCdf=True)
to
os.system(f'cdo -O -f nc -gridarea -remapnn,grid.{domain} -stdatm,0 ../outputs/{domain}/flux_regrid/area.nc')

5. Instead of creating "Projection" variable in remapped files, newer version CDO like CDO 2.0.3 here will output "crs". You also need to change code
   if k in ('time', 'lat', 'lon', 'x', 'y', 'Projection')
   to
   if k in ('time', 'lat', 'lon', 'x', 'y', 'crs')

Dear @barronh ,

I'm using eta_levels in WRF :

1.000, 0.995, 0.985, 0.979, 0.973,
0.967, 0.960, 0.954, 0.949, 0.941,
0.934, 0.925, 0.917, 0.907, 0.897,
0.887, 0.878, 0.866, 0.855, 0.844,
0.832, 0.806, 0.778, 0.764, 0.749,
0.718, 0.687, 0.654, 0.623, 0.590,
0.559, 0.526, 0.495, 0.462, 0.431,
0.398, 0.367, 0.334, 0.304, 0.272,
0.244, 0.213, 0.187, 0.155, 0.120,
0.090, 0.065, 0.040, 0.015, 0.000

And I would like to make 17 vertically allocated emissions. Is it possible to allocate emissions on different vertical grid?

I know I should not simply interpolate the vertical fractions to my eta_levels. But, I don't know a mathematical keyword to obtain new fractions on the new vertical grid.

I've obtained the new fractions on my eta_levels by replacing layerfractions with :

layerfractions = pd.read_csv(io.StringIO("""L,SigmaTop,PPCB,PROT
1,0.995,0.00,0.06
2,0.985,0.066,0.26
3,0.979,0.067,0.34
4,0.973,0.067,0.34
5,0.967,0.1,0.0
6,0.960,0.1,0.0
7,0.954,0.1,0.0
8,0.949,0.05,0.0
9,0.941,0.05,0.0
10,0.934,0.05,0.0
11,0.925,0.05,0.0
12,0.917,0.05,0.0
13,0.907,0.05,0.0
14,0.897,0.05,0.0
15,0.887,0.05,0.0
16,0.878,0.05,0.0
17,0.866,0.05,0.0
"""), comment='#')

I distributed original fraction to new level properly, and the sum of fractions is 1.

I have one question regarding the area source of MICS-Asia RESIDENTIAL, TRANSPORT, and AGRICULTURE.
In [23], the area sources are allocated on the second vertical grids. But, the first vertical grid has also height (35m). So should be the area sources allocated on the first vertical grids?
Thank you.

I'm glad you figured it out.

You're right about the layers. When it was first made, I think that L was the index. In this version, however, the index is a zero-based value. You should change all of those to layerfractions.loc[0, '...'] = 1. I updated the notebook.

Thank you for response.