search

metno / emep-ctm

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

Question on running EMEP local fraction #72

Open baihuiqian opened 4 years ago

baihuiqian commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

The problem might be connected to a bug in the NetCDF library (not the emep-mscw library): https://github.com/Unidata/netcdf-c/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

baihuiqian commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Thank you for doing those tests. They all confirm my suspicion that https://github.com/Unidata/netcdf-c/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

gitpeterwind commented 4 years ago

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

uEMEP_mod.f90.txt

baihuiqian commented 4 years ago

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? image

gitpeterwind commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Thanks Peter!

baihuiqian commented 4 years ago

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

avaldebe commented 4 years ago

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 commented 4 years ago

Yes thanks

baihuiqian commented 3 years ago

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 commented 3 years ago

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