Question on running EMEP local fraction

[baihuiqian]

Hi, I managed to run EMEP local fraction for a day and a month, but I use the same config file and data to run local for a year, it crashed after a month. Could you please give me some suggestions? (log and error files attached.)

Another question related to EMEP local fraction is:

I want to run uEMEP for Edinburgh only and therefore I only need local fraction and EMEP output for Edinburgh, but my EMEP set up is to run EMEP for Europ and then EMEP for UK. Is it possible to set up EMEP so that I only get output for Edinburgh rather than the whole UK?

Thanks!
emep_pbs_EU_UK_LF_2017e.txt
emep_pbs_EU_UK_LF_2017o.txt

Vera

[gitpeterwind]

Hi Vera,

The easy first: yes you can limit the size of the output by setting uEMEP%DOMAIN (see https://emep-ctm.readthedocs.io/en/latest/Subrun.html#local-fractions-under-development ).

About the "HDF5" error, that is not easy. It shows an error while reading or writing a netcdf file. It happens at some apparently random place in the run, so might be that some limitation on your system is reached. We have never run uEMEP hourly output for such long periods afaik.

Could you run again with the limited uEMEP%DOMAIN , and see if the code crashes at the same point?
You could also try to run the identical setup, but with start date at 2017-02-26 00:00:00 , to know if it is a problem associated with that date, or a problem with the length/size of the run.

Best wishes,
Peter

[baihuiqian]

Hi Peter,

Thanks a lot! I did manage to run with different start date including 2017-02-26 00:00:00 and it worked fine. I will try to set up a smaller domain first.

Vera

[gitpeterwind]

The problem might be connected to a bug in the NetCDF library (not the emep-mscw library):
Unidata/netcdf-c#350
In this case it will not help with a smaller region. If the code stops at the same date it maybe the reason. In such a case it would be necessary to rethink the way the data is written out in order to avoid this situation.

[baihuiqian]

Hi Peter,

I did change the domain to uEMEP%DOMAIN = 133,138,133,135, but it crashed (log and error files attached.) I am not sure if I set domain correctly (config file attached.). I put the Edinburgh domain roughly at lon ( -3.069 - -3.34) lat ( 55.89 - 55.98) and the UK results roughly at : lon (-10.72 - 2.55) lat (48.52, 61.80).

Thanks!
Vera
config_emep.txt
emep_pbs_EU_UK_EDI_LFe.txt
emep_pbs_EU_UK_EDI_LFo.txt

[gitpeterwind]

The "DOMAIN" is in units of the meteo grid. Your meteo grid is of size 149 x 84 , that means that the DOMAIN numbers must be within that range. something like:
uEMEP%DOMAIN = 133,138,11,15
would give you a uemep output that has 6x5 gridcells and the lower left gridcell has indices (133,11) in the meteo grid.

[mvieno]

@gitpeterwind the domain size is 240x240. In our setup the EU domain (149x84) is calculated first to create the nest file and then the nested UK. If you look at Vera's .o file at line 6557 is where the UK domain starts.

The error messages Vera uploaded are not related to the uEMEP domain issue, but we notice that on earlier runs. Vera is going to setup a new run to try to reproduce the error.

I refer to these:
emep_pbs_EU_UK_EDI_LFe.txt
emep_pbs_EU_UK_EDI_LFo.txt

[gitpeterwind]

Ah, yes, I did not noticed that. This last test failed for another reason. Somewhat the nesting went wrong. Your nesting file EMEP_IN.nc seems empty:
Nest: dimensions external grid 149 84 21 0
means that there are no records in the file.Maybe it is related to the first part of the nesting which shows:
STOP-ALL ERROR: Nest: Refuse to overwrite. Remove this file: EMEP_OUT.nc

[baihuiqian]

Thanks @gitpeterwind . I removed EMEP_OUT.nc file and rerun this. It crashed again. I have attached log files and error files here.
emep_pbs_EU_UK_EDI_LFe.txt
emep_pbs_EU_UK_EDI_LFo.txt

[gitpeterwind]

Trying new things, you get new type of errors... Sorry for that. uEMEP is still under active development, so not everything is fully tested. For such small uEMEP%DOMAIN, we have to modify the code. In uEMEP_mod.f90, about line 322, the values for dimSizes(3) dimSizes(4) and dimSizes_tot(1) dimSizes_tot(2), must be replaced with:

  dimSizes(1)=2*uEMEP%dist+1
  dimNames(1)='x_dist'
  dimSizes(2)=2*uEMEP%dist+1
  dimNames(2)='y_dist'

  uEMEP%DOMAIN(1) = max(RUNDOMAIN(1),uEMEP%DOMAIN(1))
  uEMEP%DOMAIN(2) = min(RUNDOMAIN(2),uEMEP%DOMAIN(2))
  uEMEP%DOMAIN(3) = max(RUNDOMAIN(3),uEMEP%DOMAIN(3))
  uEMEP%DOMAIN(4) = min(RUNDOMAIN(4),uEMEP%DOMAIN(4))

  dimSizes(3)=min(LIMAX,uEMEP%DOMAIN(2)-uEMEP%DOMAIN(1)+1)
  dimSizes(4)=min(LJMAX,uEMEP%DOMAIN(4)-uEMEP%DOMAIN(3)+1)

  dimSizes_tot(1)=min(LIMAX,uEMEP%DOMAIN(2)-uEMEP%DOMAIN(1)+1)
  dimSizes_tot(2)=min(LJMAX,uEMEP%DOMAIN(4)-uEMEP%DOMAIN(3)+1)

I am afraid this is not related to the first problem you had.

[baihuiqian]

Thanks, Peter! I will try to modify the codes and rerun it.

[baihuiqian]

Hi @gitpeterwind , after modifying the codes, I can get uEMEP results only at Edinburgh domain, but it still crashed at 2017-02-26 22:00:00. Could you please have a look at the log file?

Thanks!
Vera
emep_pbs_EU_UK_EDI_LFo.txt

[baihuiqian]

Another question I'd like to ask is about uEMEP%dist parameter. uEMEP%dist = 5 is at the user guide. Is there any rule or minimum requirement for uEMEP%dist value?

[gitpeterwind]

Is there any rule or minimum requirement for uEMEP%dist value?

The "local fractions" from the emep model can be used for many things. the dist value should be chosen according to what you want to do with the results. For downscaling using @brucerd 's uEMEP, I think dist=3 is more than enough, but he should confirm that.

[gitpeterwind]

Thank you for doing those tests. They all confirm my suspicion that Unidata/netcdf-c#350 is the problem.
(if you wish you could do a last test by starting at a later date, and check that the time of crash is shifted by the same amount).
This is not so easy to correct, and it might take some time before it is done.
For a temporary solution, you could run one month at a time?

[baihuiqian]

Thanks @gitpeterwind , I will try to run it monthly and check if the time of crash is shifted and will let you know the results.

[baihuiqian]

Hi @gitpeterwind , I tried to shift the date one day so start with 02 Jan 2017 instead of 01 Jan 2017, and it crashed at 2017-02-27 22:00:00 whereas the last crash was 2017-02-26 22:00:00. I assume this confirms your above suspicion. Hope it can be fixed soon. Let me know if you want me to run other tests.

[gitpeterwind]

I have made a fix that should solve this problem. Could you try:
NetCDF_mod.f90.txt
uEMEP_mod.f90.txt

It should be compatible with rv4_33 (just remove the .txt endings).

(this version keep the uEMEP files open instead of opening and closing them each time).
I have tested that it works, but in another version.

[baihuiqian]

Thanks a lot, Peter! I will test it and let you know how it works.

[gitpeterwind]

I think there was an error in the previous version of uEMEP_mod.f90, here is a corrected one:

uEMEP_mod.f90.txt

[baihuiqian]

Hi @gitpeterwind , the full year run was finished. The EMEP hourly and monthly results are fine and log file does not show any error. But uEMEP_hour.nc and uEMEP_month.nc only writes the first hour and month. Could you please have a look?

[gitpeterwind]

And you are sure you used the second version of uEMEP_mod.f90.txt (the one just above you comment)? This is the kind of things that would happen with the first version...

[baihuiqian]

Thanks @gitpeterwind . I updated the uEMEP with the new file, but it crashed when writing netcdf to to 2017-01-01 02:00:00. Log file is attached.
emep_pbs_EU_UK_LF.o14205.txt

[gitpeterwind]

Sorry about that! I tried and found a bug in my corrections in NetCDF_mod.f90. Here is a better one (tested on rv4_33 this time...)
NetCDF_mod.f90.txt

[baihuiqian]

Thanks Peter!

[baihuiqian]

Hi @gitpeterwind, it works now. Thanks a lot!

[avaldebe]

Hi @baihuiqian and @gitpeterwind

Looks like this question was answered and the model was patched.
Can we mark this issue as solved and close it?

[mvieno]

Yes thanks

[baihuiqian]

Hi @gitpeterwind ,

I am running EMEP4.34 for local fraction calculation. I have updated the NetCDF_mod.f90 (attached), but it still gave me the same error message as before (attached). Could you please give me some suggestions?
NetCDF_mod.f90.txt
emep_pbs_UKSCAPE.o15299.txt

Thanks!
Vera

[gitpeterwind]

Hi @baihuiqian ,

Sorry for late response.
The latest release (rv4_36) should be corrected for this problem. If you are using rv4_34, you should adapt also uEMEP_mod.f90 with the changes in the file given above.
Best wishes,
Peter