metno / emep-ctm

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

Error in VOC splits when using own sector definition #80

Closed janamol closed 1 year ago

janamol commented 3 years ago

Hi, We are trying to run EMEP with CAMS emissions and with STEAM shipping emissions (monthly emisions); the shipping VOC emissions are given in 4 different classes and 2 altitudes. To not exceed the maximum number of ‘sources’ the CAMS emissions were reformatted to separate files with 1 emitted species for all sectors per file; the sectors for land emissions are mapped to SNAP sectors 1-11 in the config_emep.nml. The shipping emissions are then mapped to additional 8 sectors 12-19. We are then using our own sector definition TEST.

!TEST to try own defintions
   integer, public, parameter:: &
          NSECTORS_TEST  = 19 ! Number of sectors defined. Must match the sizes of the maps below  
   integer, save, target, dimension(NSECTORS_TEST), public :: &
      ! mapping of sector to time factor class. values must be <= N_TFAC 12: 
        TEST_sec2tfac_map  = [1,2,3,4,5,6,7,8,9,10,11,11,11,11,11,11,11,11,11] &
      ! mapping of sector to height distribution class. vals must be <= N_HFAC
       ,TEST_sec2hfac_map  = [1,2,3,4,5,6,7,8,9,10,11,12,13,12,13,12,13,12,13] & 
      ! mapping of sector to height distribution class ! must be<=N_SPLIT S: Should be mapping emission split class
       ,TEST_sec2split_map = [1,2,3,4,5,6,7,8,9,10,11,12,12,13,13,14,14,15,15]
The STEAM species are partly translated to EMEP emission variables (voc, nox, co) and partly directly to EMEP species (SO2, SO4, PM species).
The problem that we have run into is that we don’t seem to get the VOC splits correctly for some of the sectors in TEST. As far as we can tell something seems to go wrong when the values in the "special" split files are stored in the emisfrac matrix. 
In EmisGet_mod, subroutine EmisSplit, we have added a small loop to show some of the values of the fractions for some splits, and when they are being looped through at the end of the subroutine EmisSplit, just before it terminates, we see that they have been read correctly - in the specials file splits are defined for splits 12-15 and those are in their correct places, and for the splits 10-11 we find the values for those splits from the default file, just as expected. 
We put this loop just before the row "end subroutine EmisSplit" (row 1654): 
if(MasterProc) then
    do xsplit=10,15
        do xidx=7,20
            write(*,"(a,i0,a,i0,a,i0,a,f9.7)")"emisfrac(", xidx, ", ",xsplit,", ", 153,") = ",emisfrac(xidx,xsplit,153)
        end do
    end do
end if

However, if we put the same debug printout loop on the row directly after the call to EmisSplit that is made in Emissions_mod (row 1139), we get a completely different result. The splits 10-11 are still the defaults as expected, but now the splits for 12-15 have been replaced with the default splits 1-4, in that order (default 1 has overwritten special 12, default 2 has overwritten special 13, etc). So emisfrac is no longer correct. We are not sure how this happened or how to solve this or if there is something we have missed when preparing the input files. We have some debug printouts of the splits before and after if you think these could be helpful.

gitpeterwind commented 3 years ago

It is difficult to say without access to all the files. Could you send me:

gitpeterwind commented 3 years ago

Hi @janamol , I got a sample of your input data, and the error comes from the files emissplit.default that you use. They must have one entry per split, i.e. in your case 15 entries. This is because the default files are used to define the total number of splits. This was not clear from the documentation, and no error message was produced. It will be improved in next version. Thanks for the feedback, and sorry for the inconveniences, Peter

mifads commented 1 year ago

Solved in 2021 it seems.