metno / emep-ctm

Open Source EMEP/MSC-W model
GNU General Public License v3.0
27 stars 18 forks source link

Changes input EMEP v5.0 vs rv4.45 #120

Closed SebastiaanHazelhorst closed 4 months ago

SebastiaanHazelhorst commented 5 months ago

Dear EMEP modellers,

This week I downloaded the EMEP msc-W model (version 5.00) and the input data from github, using the python tool. I compared the input data with the input data from version 4.45 and read the changes in the EMEP status report. There are some things I would like to check. Could you answer the following questions?

  1. The Monthly time factors are in a folder ‘MonthlyFacs_eclipse_V6b_snap_xJun2012’. Two questions. a. Are the data correct? The folder says ‘xJun2012’ and the files themselves are from February 2021. The input data downloaded with 4.45 says ‘MonthlyFacs_eclipse_V6b_snap_may2021’ and has data from may 2021. In the msc report (p.164), it is said that the Monthly time profiles are updated. Do I have the right version? b. Secondly, the emissions are in GNFR sectors, 13 in total. I think the monthly time factors are in SNAP, 11 sectors in total. How does this work? Are the GNFR sectors coupled to SNAP sectors?
  2. In the report, it is said that a mask is added for Desert areas. Could you elaborate on how this works and how it affects PM emissions? Does it only affect emissions in Desert areas, or also in the Netherlands (we have some dune areas which I recall are also classified as desert in EMEP)

I look forward to your reply. Thanks in advance

Kind regards Sebastiaan

avaldebe commented 5 months ago
  1. The Monthly time factors are in a folder ‘MonthlyFacs_eclipse_V6b_snap_xJun2012’. Two questions. a. Are the data correct? The folder says ‘xJun2012’ and the files themselves are from February 2021. The input data downloaded with 4.45 says ‘MonthlyFacs_eclipse_V6b_snap_may2021’ and has data from may 2021. In the msc report (p.164), it is said that the Monthly time profiles are updated. Do I have the right version?

Yes, the files are correct. I created the input tar file from the files we regularly use. Since the rv4.45 release we found that the older MonthlyFacs dataset produced better results.

We have had good results with v5.0 and the CAMS TEMPO v3.2/v4.1 simplified climatological temporal profiles. Alas, we are not able to re-distribute them at the moment.

b. Secondly, the emissions are in GNFR sectors, 13 in total. I think the monthly time factors are in SNAP, 11 sectors in total. How does this work? Are the GNFR sectors coupled to SNAP sectors?

The SNAP to GNFR sectors are mapped internally, but I do not know the dertails. @gitpeterwind do you know how this is done on the model?

In any case, the following lines on the configuration are necessary to read the ‘MonthlyFacs_eclipse_V6b_snap_xJun2012’ temporal profiles: https://github.com/metno/emep-ctm/blob/78abe584a7534e6bd79d325765472156d9c146bd/config_emep.nml#L13-L14

The model checks for the xJun2012 on the path name https://github.com/metno/emep-ctm/blob/78abe584a7534e6bd79d325765472156d9c146bd/Timefactors_mod.f90#L267-L269

2. In the report, it is said that a mask is added for Desert areas. Could you elaborate on how this works and how it affects PM emissions? Does it only affect emissions in Desert areas, or also in the Netherlands (we have some dune areas which I recall are also classified as desert in EMEP)

I do not know the details. @mifads can you answer this part?

gitpeterwind commented 5 months ago
   b. Secondly, the emissions are in GNFR sectors, 13 in total. I think the monthly time factors are in SNAP, 11 sectors in total. How does this work? Are the GNFR sectors coupled to SNAP sectors?

Yes, the time factors are mapped: 11 time factors are defined (they are still the one from SNAP, until we will get new ones). The 13 GNFR sectors are then using the 11 time factors defined.

mifads commented 5 months ago

Yes, these MonthylFacs are confusing. I hope we will have a cleaner system for the next release, but for now xJune2012 is fine.

Peter and Alvaro have answered about the factors, so I just comment on the deserts here. First, here's the quick-n-dirty ncview of the raw polar-stereographic landcover of areas classified as "desert" (EMEP code DE): desertsfromPS

You can see that there are small patches of DE along coastlines, but also in some odd places - e.g. Scottish highlands or the Alps. These likely stem from "bare-soil" or "barren" being counted as DE at some stage. The patch here near Almeria in Spain was causing big problems with PM predictions - being far too high as the model produced dust from this area. As an interim fix for this issue we implemented the "Olson" desert mask. If you run the model with DEBUG%DUST = T you will get a netcdf file PRINTCDF_Deserts_Olson.nc which shows the areas which are retained as desert (red below) and those which are reclassified as "bare" in green. Sadly, this has removed e.g. the Dutch sand-dunes, but it has also removed the problematic Alermia deserts. In future I would hope to use much more modern land-cover maps, with more unity between the European and global land-cover, but this also needs a reconsideration of biogenic VOC emssions, and will not be done in the next months.

Users can of course create their own land-cover maps to use in place of the default ones, or one could omit the Olson mask entirely if interested in the NL.

deserts4emep e.

SebastiaanHazelhorst commented 5 months ago

Thank you all for the fast and clear response! It is good to know that the monthly factors are as intended and that the dune area's in the Netherlands are regarded as Bare soil, probably resulting in smallerParticulate matter concentrations. We will test some of the changes as well in order to see what the effects are on the results with the EMEP4NL configuration. Kind regards Sebastiaan