ERA5 meteo data and EDGAR emissions.

[lorenzobruno00]

Hello, I'm trying to use the EMEP model to estimate concentrations of PM2.5 in Denmark using EDGAR emissions. Ideally, I would like to cover the entire 1970-2018 period for which EDGAR emissions are available. Since I'm an economist, I'm not an expert of this kind of models and it would be great if you could clarify some of my doubts. 1) Meteo data: I was thinking to use the ERA5 dataset, but I'm not sure whether it contains all the variables I need to run the model. In case it does, are the variables in the "Popular" category enough or should I add other specific variables? For the time dimension, is a 3 hour periodicity (starting at 0:00) okay? 2) EDGAR emissions: this dataset has annual emissions by sector. Can I use it to estimate also daily concentrations or just annual? Thank you in advance! Lorenzo

[gitpeterwind]

Hi Lorenzo, I don't know what kind of information you really try to get, but making realistic pm2.5 data for this entire period is a heavy task. To answer your direct questions: 1) the ERA5 dataset is not directly readable by the emep model. Most external users make they own meteorological data using WRF (which can use the ERA5 data as initial and boundary conditions). The emep model can directly read the wrf output data. 2) Yes, the model will be able to output daily concentrations. Best wishes, Peter

[lorenzobruno00]

Hi Peter, thank you so much for your answer! Everything is clear. Best, Lorenzo

[lorenzobruno00]

Hello, sorry for reopening this topic but I'm facing some problems in running emepctm to produce my output. I used ERA5 surface and pressure data to run the WRF model. After producing the wrfout files, I tried to use those files as the meteorological input of my simulation. However, I receive the following error "STOP-ALL ERROR: Projection not recognized" (I attach the slurm output with the full log). I believe the reason why I'm getting this error is that, in order to make the raw meteorological files easier to manage (and since I was only interested in Europe), I restricted the ERA5 input to the grid made of longitude -30:60 and latitude 30:80. Furtermore, I restricted the WRF domain to fit that area (I also attach the namelist.wps file from my WRF configuration). I also attach my config_emep.nml file. P.S. I'm using the gfortran compiler. Thank you in advance and sorry for reopening the issue! Lorenzo namelist.txt config_emep.txt slurm-11269969.txt

[gitpeterwind]

Hi Lorenzo, I am afraid the mercator projection is not supported by the emep model. There exist a document with recommendations for use of wrf for the emep model, but I do not actually know where this is published. @mvieno may be able to answer most questions related to this.

[lorenzobruno00]

Hi Peter, it worked! Thanks a lot. The model is now running but I have a little problem the reading the meteorological files. In particular, for each day, I have four files in the following format: wrfout_d01_YYYY-MM-DD_00:00:00, wrfout_d01_YYYY-MM-DD_06:00:00, wrfout_d01_YYYY-MM-DD_12:00:00 and wrfout_d01_YYYY-MM-DD_18:00:00. Is there a way to instruct the model to read the first file for the first 6 hours, then the second file and so on? Otherwise, I can simply create a unique file, so it shouldn't be a big problem. Thank you again! Lorenzo

[gitpeterwind]

Congratulations Lorenzo, I am impressed! You should be able to set meteo = '/scratch/lbruno/ERA5/out/wrfout_d01_YYYY-MM-DD_hh:00:00', Although I haven't tried, so cannot guarantee that it actually works. (I am also quite sure that it is possible to make wrf output daily files).

(Edit, this should work automatically for wrf meteo: You probably have found out by now, you should set:--- USES%DEGREEDAY_FACTORS = F, ---(because you do not have the required input file for your meteorology). )

[lorenzobruno00]

Thanks a lot Peter! I solved this problem too. Everything looks under control for now, so I can close the issue I guess :) Thank you again!!! Lorenzo

[lorenzobruno00]

Hello, sorry for reopening the issue. The model runs and it produces the final output. However, apparently, it's not reading the emissions because the estimated concentrations are too low. This should be the same problem faced in #60, which involved EDGAR emissions too. That issue was solved but it was not specified how. I attached my config_emep.nml file. I'm using 5 source files: one for each substance. In each dataset, I have a variable for each EDGAR sector, which was manually mapped into the corresponding GNFR sector. Since the emissions are in kg/m2/s, I'm multiplying it by the number of seconds in a year and by the number of squared meters in a cell grid (0.1x0.1 degrees), hence the final unit should be "kg per cell grid". One last thing: does the grid resolution of the final output depend on the resolution of the meteorological files? Because I'm getting few observations, but I'm also using a large meteorological grid (50km x 50km). Thank you so much in advance!!! Lorenzo config_emep.txt

[gitpeterwind]

Hi Lorenzo,

1. (kg/m2/s are recognized by the model as a valid unit; so you do not have to change that.)
2. in the netcdf outputs, you have fields that show the total emission used per sector for the period. Are those correct?
3. The grid used for output is identical as the meteorological grid. (I am not sure of what it is you call "observations").
4. If your entire grid is only 50km x 50km, then it is normal that concentrations will appear low: The concentrations reflect only the emissions included in the grid. For small grids pollutants are rapidly "washed out" of the grid. It is possible (through nesting) to include boundary conditions that include incoming pollutant, but then you must have some way to create those (through another run for example). For realistic values you should at least cover most of Europe in the grid.
5. Also you should define countries (as a first approximation you could set everything as Danish) for the emissions; otherwise there will be only default timefactors (mostly constant, 1.0)

Best wishes, Peter

[lorenzobruno00]

Hello Peter, thanks a lot for your answer! 1) I initially tried to use it (units='kg/m2/s') but it wasn't recognized. Maybe it has to do with the yearly periodicity? I may have read something about that. 2) I'm sorry, do you mean the variables "Sec_Emis_mgm2_sox", "Sec_Emis_mgm2_pm25" etc? In that case, the totals are apparently zero! I guess they are not being read properly, as in #60? I may also try asking the user who opened that thread to see how he solved it. If, instead, you mean the sourcefiles, in those files I also have the total emissions by sector, which look realistic. 3) Got it! Thanks a lot! 4) I'm sorry, I meant that the grid resolution is 50km x 50km, while the total grid covers almost the entire Europe. 5) Thank you! I will do that. Best, Lorenzo

[gitpeterwind]

1. ? I don't know what happened. But if you are happy with your solution, that is fine for now.
2. Yes, that are the fields. If they are zero, then as you say, something is wrong with the reading. The reference #60 was followed up by direct mail. Their problem was simply that they did not have any source defined in the config. Your config looks right. Could you send me the "standard output" ( starting with "Found 512 MPI processes available" or similar); maybe I see something unusual. Otherwise you can send me one of the Edgar file, and I could try with your config (I can send you an upload link if you prefer). If you contact me by mail (peter.wind@met.no), I can give you the mail from the people who used Edgar emissions, as I know they are still using the emep model.
3. You could also check that the coordinates in the netcdf output file and the lat and lon variables in the emission files are all correct.

[mvieno]

Hi. Sorry I was away and just saw this. We use the global EDGAR and seems to work ok. float EDGARv6_Other(time, lat, lon) ; EDGARv6_Other:units = "tonnes month-1" ; EDGARv6_Other:_FillValue = 9.96921e+36f ; EDGARv6_Other:long_name = "Other" ; EDGARv6_Other:description = "Other" ; EDGARv6_Other:sector = 13s ; EDGARv6_Other:species = "voc" ;

We did omit the countries code, as we use monthly emissions and the hourly split is country independent.

[lorenzobruno00]

Hello Peter and Massimo, thank you so much for your answers!

Peter: I attached the output from the simulation that I tried to run from 1990-01-02 to 1990-01-08. Let me know if you don't find any error and I'll send you one of the nc inputs that I'm using.

Massimo: actually, I'm using annual data because I want a time series that starts in 1970. For a given pollutant, say PM2.5, I download data from all the sectors (for example, here is where I downloaded data for power industry) and then I put them together in a unique file using: cdo merge EDGARv6.1_PM2.51990.0.1x0.1.nc PM2.5_1990.nc (EDGARv6.1_PM2.51990.0.1x0.1.nc captures all the sector specific files). I also attached the ncdump of one of my input files.

Thank you again! Lorenzo emepout.txt edgar_ncdump.txt

[gitpeterwind]

Hi Lorenzo, I do not understand what is wrong. Could you send me one of the Edgar emission files you are using?

[lorenzobruno00]

Hi Peter, I think I found the problem! Something went wrong with "cdo merge". In fact, the resulting file has only 0 values (although the original files have normal values). I'm now trying to find a new way to merge all the sectors into a single file. Thank you again! I'll keep you posted! Lorenzo

[gitpeterwind]

Good! I also thought of another potential problem that we have encountered earlier. Some tools like nco will write strings with an invisible character at the end (char(0), to indicate the end of the string); this is not used by fortran and interpreted as an extra character (there is no string type in fortran, only character arrays). This may have caused the units no being recognized for example. I will have to upgrade the code to take this into account in the future.

[lorenzobruno00]

Hello Peter, I fixed the input files and now it seems to work!!! The model is finally outputting reasonable values of PM2.5 concentrations. Regarding the countries in the config_emep.nml file: if I'm using a grid that covers almost all the Europe, is it enough to put a list of the countries covered? Furthermore, if I'm only interested in Danish concentrations, is it enough to put just Denmark's code or it's still better to use all the countries in the grid? Anyway, this point is not an emergency because I saw there is some documentation explaining how to handle these cases. Thank you again for all your help! Lorenzo

[gitpeterwind]

Excellent! The best is to have all countries, but that is a lot of work since you have to extract their contributions and make a new variable for each. The simplest is to put something like: Emis_sourceFiles(1)%ountry_ISO = 'DK',