Giter VIP home page Giter VIP logo

Comments (18)

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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.

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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). )

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024
  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 ([email protected]), 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.

from emep-ctm.

mvieno avatar mvieno commented on September 14, 2024

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.

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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.5_1990_.0.1x0.1.nc PM2.5_1990.nc (EDGARv6.1_PM2.5_1990_.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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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.

from emep-ctm.

lorenzobruno00 avatar lorenzobruno00 commented on September 14, 2024

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

from emep-ctm.

gitpeterwind avatar gitpeterwind commented on September 14, 2024

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',

from emep-ctm.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.