__group__ ticket summary component milestone type created _changetime _description _reporter anphi 297 gridcheck_ecmwf.f90: fix of small bug and improvements FP coding/compilation FLEXPART 10 Defect 2021-03-20T16:43:22Z 2023-02-07T21:59:41Z "1. check on field dimensions uses undefined variable `nx` 2. If ECMWF grib files contain only GRIB2 formatted fields, FLEXPART stops with an error message due to missing parameters from GRIB1 messages. `***ERROR: input file needs to contain GRiB1 formatted messages` '''Update 2022-02-09:''' In v10.4 the problem is not that a GRIB1 field is required, but that this messages is emitted if no T2 field is found (which is used to extract certain parameters). Rewriting the error message is probably good enough as a solution." anphi anphi 114 FLEXPART-WRF of v3.2 cannot read in more than 96 met files? FP other Defect 2015-03-07T15:37:58Z 2017-06-20T16:46:36Z "The latest version of FLEXPART-WRF seems to work smoothly if I run it less than 96 hours, however, when I try to run it more than 96 hours (one met file for each hour), the model crashes with the following error message: error doing nf_close in flxwrf_nf_open_for_reading: /home/lsu/flexpart/met/wrfout_d01_2011-03-27_21:00:00 Is it a bug or there is something wrong in my setting? FYI, My flexpart.input is attached." sulinust anphi 134 Issue using *.grb and *.grib2 FP input data FLEXPART 9.2 Defect 2016-01-08T09:40:47Z 2020-12-01T18:12:20Z "We have started working recently in the field of air pollution modelling. FLEXPART is a software we found apt for our application. There's an enquiry that we have regarding usage of input data set, kindly help us to resolve. We have run the model for 20100109 date using both *.grb and *.grib2 formats (bothFNL data). The following are the two changes done in the files for making it run for the *.grb files. 1. For using the *.grb format, we had commented the line no. 290 [ if (xaux.eq.0.) xaux=-179.0 ] in readwind_gfs.f90. 2. We had also changed the value of OUTLONLEFT (GEOGRAFICAL LONGITUDE OF LOWER LEFT CORNER OF OUTPUT GRID ) in OUTGRID to 0.0 (default was -179.0). I am hereby attaching the plots generated from pflexible for your reference. The files ""AIRTRACER_fp_grib1.png"" and ""AIRTRACER_tc_grib1.png"" have been generated using *.grb format input files and the files ""AIRTRACER_fp_grib2.png"" and ""AIRTRACER_tc_grib2.png"" have been generated using *.grib2 input files. We were expecting similar sensitivity output plots, whereas the course of travel in the plots also looks different in addition to the max. values plotted. We would like to know if there is any other change required for making the run using *.grb format input files. Since we are just beginners in this area of study, could you please help us to understand if this is acceptable and why the difference." tjaya anphi 232 Warnings about undefined GRiB2 messages FP input data FLEXPART 10 Defect 2019-03-11T11:03:17Z 2023-05-08T09:34:48Z "I'm filing this against flex_extract, but am not 100% sure if this is correct. I'm using flex_extract to download ERA5 data. I'm using the `release-10` branch from git (up to date as of today). When running FLEXPART, I get errors like this when the model initializes: {{{ parId 3063 isec1(6) 143 parId 3066 isec1(6) 141 ***ERROR: undefined GRiB2 message found! 192 128 186 1 parId 186 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 187 1 parId 187 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 188 1 parId 188 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 0 0 17 1 parId 235 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 139 106 parId 139 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 39 106 parId 39 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 27 1 parId 27 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 28 1 parId 28 isec1(6) -1 ***ERROR: undefined GRiB2 message found! 192 128 244 1 parId 244 isec1(6) -1 }}} and warnings like this in every time step: {{{ ***WARNING: undefined GRiB2 message found! 192 128 186 1 parId 186 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 187 1 parId 187 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 188 1 parId 188 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 0 0 17 1 parId 235 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 139 106 parId 139 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 39 106 parId 39 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 27 1 parId 27 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 28 1 parId 28 isec1(6) -1 ***WARNING: undefined GRiB2 message found! 192 128 244 1 }}} The FLEXPART run seems to complete without problems. This is confusing for the user, because the ERROR suggest that something is wrong. Some of the paramers that FLEXPART complains about are defined in `CONTROL_EA5.highres` as `ADDPAR`: {{{ ADDPAR /186/187/188/235/139/39 }}} The others are parameters 17 (whatever that might be), 27, 28 (cvl and cvh), and 244 (fsr). If FLEXPART doesn't need these fields, then I suggest that flex_extract doesn't download them by default. New users will just try CONTROL files that are in the repository, and will get confused by all the warnings. If FLEXPART does need these fields, then there should be something done in FLEXPART in order to not issue these warnings." ahilboll anphi 301 Bug in flex_extract due to python3 upgrade at ECMWF ecgate env flex_extract flex_extract_v7.1.3 Defect 2021-05-14T18:23:10Z 2022-02-09T17:26:24Z "After the ECMWF announced a couple of software upgrades and change to new default versions (https://confluence.ecmwf.int/display/UDOC/2021/03/10/Change+of+default+versions+of+ECMWF+and+third-party+software+packages+-+May+2021), the software runs into an error when retrieving ERA5 data: {{{ $HOME/flex_extract_v7.1.2_ctbto/Source/Python/Mods/checks.py:94: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma? raise ValueError('GRID parameter contains two ' $HOME/flex_extract_v7.1.2_ctbto/Source/Python/Mods/checks.py:819: SyntaxWarning: ""is not"" with a literal. Did you mean ""!=""? parlist = [p for p in parlist if p is not ''] Retrieving ECMWF data and printing MARS request! start date 20140617 end date 20140621 Traceback (most recent call last): File ""$HOME/flex_extract_v7.1.2_ctbto/Source/Python/submit.py"", line 268, in main() File ""$HOME/flex_extract_v7.1.2_ctbto/Source/Python/submit.py"", line 107, in main get_mars_data(c) File ""$HOME/flex_extract_v7.1.2_ctbto/Source/Python/Mods/get_mars_data.py"", line 150, in get_mars_data server = mk_server(c) File ""$HOME/flex_extract_v7.1.2_ctbto/Source/Python/Mods/get_mars_data.py"", line 211, in mk_server server = cdsapi.Client() File ""/usr/local/apps/cdsapi/0.5.1/lib/python3.8/site-packages/cdsapi/api.py"", line 301, in __init__ raise Exception(""Missing/incomplete configuration file: %s"" % (dotrc)) Exception: Missing/incomplete configuration file: $HOME/.cdsapirc }}} " anphi anphi 311 flex_extract 7.1.2 local extraction no flux data flex_extract Defect 2021-12-20T10:33:02Z 2023-04-03T10:29:21Z "Dear all, When I download ERA5 data with flex_extract 7.1.2 using the attached control files, the program finishes (FLEX EXTRACT IS DONE) and the files EA* are created in GRIB1 format. When I run with FLEXPART, I get the message: {{{ WARNING: No flux data contained in GRIB file /mnt/Disk1/Flexpart_9.02/winds_RA5/2019/03/EA19030421 }}} My ECMWF access has the following rights: {{{ level of access: 0 roles: authenticated user, cms_secrep_view, cms_comprep_view policies: gr_files group_member_state greece public group_mars_access }}} I have applied the #286 accepted Defect fix, but the result is the same. Could you be so kind and direct me to a solution to this problem? Best regards,[[BR]] Stergios Vratolis" vratolis anphi 328 GRIB2 CONVERSION FAILED! error in flex_extract flex_extract flex_extract_v7.1.3 Defect 2023-02-15T16:08:53Z 2023-04-03T09:16:30Z "I am facing this error intermittently while downloading ERA5 data. This does not happen to all jobs that get submitted for a particular interval of data download. So, I am not sure what is causing this behaviour. I am using the flex_extract_v7.1.3 dev branch on the ECMWF Bologna server. The met files are downloaded successfully but this errors comes while converting the files into GRIB2 format." sannadate anphi 330 error in flex_extract-7.1.3 flex_extract Defect 2023-03-03T10:19:54Z 2023-03-30T07:14:25Z "dear FLEXPART technical support, I try to use the flex_extract version 7.1.3 on the new ECMWF machin Atos. I succeeded to launch the job but I have an error in the middle of the process: MARS retrieve done ... Prepare 20201106/to/20201106 Traceback (most recent call last): File ""../Source/Python/submit.py"", line 268, in main() File ""../Source/Python/submit.py"", line 109, in main prepare_flexpart(ppid, c) File ""/home/sof0/flex_extract_v7.1.3/Source/Python/Mods/prepare_flexpart.py"", line 160, in prepare_flexpart flexpart.write_namelist(c) File ""/home/sof0/flex_extract_v7.1.3/Source/Python/Classes/EcFlexpart.py"", line 852, in write_namelist from genshi.template.text import NewTextTemplate ModuleNotFoundError: No module named 'genshi' Thank you in advance for your response. Sincerely Gisèle" gtong anphi 333 CDS download for ERA5 sdor,cvh,cvl,fsor sometimes fails flex_extract flex_extract_v7.1.3 Defect 2023-03-31T09:01:25Z 2023-04-03T13:30:01Z "I ran into the issue, that flex_extract downloads for ERA5 would sometimes fail for the sdor, cvh, cvl and fsor files with a data availability error. After reaching out to the ECMWF support I was told that the retrieval with either the codes or short names can lead to unpredictable results and that the retrieval with the long parameter names as per the tables on the ERA 5 documentation (https://confluence.ecmwf.int/display/CKB/ERA5%3A+data+documentation) was the only supported way. For now I have just disable the conversion to codes for this retrieval and it seems to be okay, at least for the data that I am still missing. I have attached a simple script that illustrates the problem outside of flex_extract " terhardt anphi 286 Bug for local public ERA5 data / flex_extract v7.1.2 flex_extract flex_extract_v7.1.3 Defect 2020-11-29T21:25:37Z 2022-02-09T17:23:45Z "When working with flex_extract v7.1.2 locally to retrieve ERA5 data from the CS3 website with CDSAPI the requests, a user had problems to use the retrieved files with FLEXPART v10.4. An example result file and CONTROL file are attached. " anphi anphi 304 INSTALLDIR not passed to the installation flex_extract flex_extract_v7.1.3 Defect 2021-07-02T11:01:50Z 2021-07-21T08:57:10Z "Dear Anne / all, this is to report a really minor bug. In {{{ setup.sh }}} the INSTALLDIR is not added to the list of arguments that are passed to the installation script. Thus the installation directory is always the default one. Simply adding {{{ if [ -n ""$INSTALLDIR"" ]; then # not empty parameterlist+="" --installdir=$INSTALLDIR"" fi }}} does the trick for me. I use flex_extract_v7.1.2. Kind regards, Jessica" jkeune anphi 313 No flux file for the second member with ENDA ERA5 data flex_extract flex_extract_v7.1.3 Defect 2022-01-24T09:00:43Z 2023-04-03T10:29:35Z "Hello, I tried to retrieve ensemble ERA5 data for 2020/01/01. The control file that I used is attached. The Flexpart input files are correctly created for the first member (''EN200101*.N000''). But for the second member, I get an error : `FileNotFoundError: [Errno 2] No such file or directory: '~/era5_compare/EXTRACTIONS_DEV/era5_20200101_ensembles/input/flux2020010100.N001'` Indeed, the `flux2020010100.N001` file is not produced, as you can see in the attached ''listoffiles.txt'' which gives the list of the files in the processing directory when the error arises. You can also observe that strange flux files are produced (e.g. `flux2018123118.N000`). The attached file ''submit_out.log'' show the entire output from the flex_extract process. I'm using the ''dev'' branch of flex_extract. " tcarion dearn 33 Precipitation treatment FP physics/numerics FLEXPART 9.2 Defect 2013-09-12T17:40:12Z 2015-07-03T14:53:19Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) In the GFS and WRF versions of FLEXPART, the treatment of precipitation needs to be investigated as well (NILU). Cf. ticket:31" pesei ignacio 276 Problems creating NetCDf output with many output levels FP coding/compilation FLEXPART 10 Defect 2020-06-25T09:19:22Z 2020-06-25T18:25:01Z "When doing some FLEXPART test runs with many output levels, the jobs would fail quite quickly when creating the NetCDF output file, e.g.: {{{ NetCDF: Invalid argument Stopped }}} When testing, this error seemed to occur with more than 20 output levels, or thereabouts. I had a look at the NetCDF writing / creation code, and the attached patch seems to have fixed things for us, which mostly just removes the specific values for the chunk sizes, so default values are used. I'm sure other approaches/ fixes would be possible as well. I thought it might be of interest, and was worth letting you know. Thanks and all the best, Richard " rrigby jbrioude 110 Warm start crashes FLEXPART-WRF FP other FLEXPART_WRF_3.4_FPbase_9 Defect 2014-12-15T11:55:28Z 2017-07-06T16:26:50Z "FLEXPART-WRF crashes with the following cryptic error if trying to run with option IPOUT=1: {{{ At line 46 of file skplin.f90 (unit = 1, file = 'flex_nyiragongo_main.input') Fortran runtime error: End of file }}} I think the problem is in subroutine readinput in this block of code: {{{ ... if (iouttype .eq. 0 .or. iouttype .eq.2) then read(unitpartin,end=99) itimein,numpart_in, & iomode_xycoord_in else read(unitpartin,*,end=99) itimein,numpart_in, & iomode_xycoord_in endif ... }}} After jumping back to 99, readinput will repeat code that has already been run. WRF input files will be read a second time, followed by the gridcheck routines. After that, readinput will try to read OUTGRID setting a second time, but since this has already been done, the initial call to skplin will reach the end of file(?). This much I'm sure about. I'm not sure if I got the rest right since this subroutine is a bit hard to follow but hopefully this will help solve the problem. I tried solving the problem by skipping forward instead: {{{ ... if (iouttype .eq. 0 .or. iouttype .eq.2) then read(unitpartin,end=101) itimein,numpart_in, & iomode_xycoord_in else read(unitpartin,*,end=101) itimein,numpart_in, & iomode_xycoord_in endif 101 nparttot2=maxpart+numpart_in ... }}} The model will now run without any errors, however, the ""old"" particles aren't properly loaded. Plotting the particle positions before and after the attempted warm start clearly shows that the model started from scratch. So, is the warm start feature currently broken or not yet implemented?" adingwell mduetsch 296 "Compiling fails on Mac OS 10.15 with ""unable to execute command: Illegal instruction"" error" FP coding/compilation Defect 2021-02-06T07:06:48Z 2021-05-12T14:16:33Z "I am trying to compile Flexpart for the first time and would greatly appreciate some help. I've gotten nearly to the end of the process (having installed the necessary libraries, etc.) but am now quite stuck. My set-up is as follows: Mac OS 10.15.7 gcc10.2 (this version is also used to build mpicc) `ulimit -n 1000` `ulimit -s 16383` `LIBRARY_PATH`, `LD_LIBRARY_PATH`, and various FLAGS are set to (I believe) the appropriate directories. I then try to compile with {{{ make -f makefile gcc=10.2 FC=gfortran ncf=yes -I/dir/of/eccodes/build/include/grib_api.mod }}} which results in the error {{{ clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang integrated assembler command failed due to signal (use -v to see invocation) Apple clang version 12.0.0 (clang-1200.0.32.29) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. make: *** [com_mod.o] Error 1 }}} Experimenting with various flags and compilers (i.e. gcc, gfortran, mpicc, mpif90) has not helped so far, and the answers found from Google are either too complex for me to understand, or too specific to seem applicable. What I can tell is it has something to do with wrong compiler options and/or Mac compatibility with 32-bit operations, but what these are exactly I can't determine. I'm hoping someone else has had this issue (or a similar one) as well and can advise! Thank you, Colin Raymond" craymond pasko 233 Error: NetCDF: Invalid dimension ID or name FP coding/compilation Defect 2019-03-15T03:19:06Z 2019-11-14T09:05:52Z "Dear all, I'm trying to run flexpart-wrf-3.3 on LINUX (INTEL) but I try running it, it crashes with WARNING: No (or incomplete) flux data contained in WRF output file wrfout_d01_2015-04-27_18:00:00 WARNING: No (or incomplete) flux data contained in WRF output file wrfout_d01_2015-04-27_19:00:00 WARNING: No (or incomplete) flux data contained in WRF output file wrfout_d01_2015-04-27_20:00:00 readwind 0.2240000 calcpar 0.1655000 verttran 0.1810000 '''Error: NetCDF: Invalid dimension ID or name''' following is my setup files =====================FORMER COMMAND FILE===================== {{{ 1 LDIRECT: 1 for forward simulation, -1 for backward simulation 20150427 180000 YYYYMMDD HHMISS beginning date of simulation 20150504 180000 YYYYMMDD HHMISS ending date of simulation 3600 SSSSS (int) output every SSSSS seconds 3600 SSSSS (int) time average of output (in SSSSS seconds) 180 SSSSS (int) sampling rate of output (in SSSSS seconds) 999999999 SSSSS (int) time constant for particle splitting (in seconds) 180 SSSSS (int) synchronisation interval of flexpart (in seconds) 10. CTL (real) factor by which time step must be smaller than tl 10 IFINE (int) decrease of time step for vertical motion by factor ifine 5 IOUT 1 concentration, 2 mixing ratio, 3 both, 4 plume traject, 5=1+4 1 IPOUT particle dump: 0 no, 1 every output interval, 2 only at end 0 LSUBGRID subgrid terrain effect parameterization: 1 yes, 0 no 0 LCONVECTION convection: 3 yes, 0 no 3600. DT_CONV (real) time interval to call convection, seconds 0 LAGESPECTRA age spectra: 1 yes, 0 no 0 IPIN continue simulation with dumped particle data: 1 yes, 0 no 1 IFLUX calculate fluxes: 1 yes, 0 no 1 IOUTPUTFOREACHREL CREATE AN OUPUT FILE FOR EACH RELEASE LOCATION: 1 YES, 0 NO 0 MDOMAINFILL domain-filling trajectory option: 1 yes, 0 no, 2 strat. o3 tracer 1 IND_SOURCE 1=mass unit , 2=mass mixing ratio unit 2 IND_RECEPTOR 1=mass unit , 2=mass mixing ratio unit 0 NESTED_OUTPUT shall nested output be used? 1 yes, 0 no 0 LINIT_COND INITIAL COND. FOR BW RUNS: 0=NO,1=MASS UNIT,2=MASS MIXING RATIO UNIT 1 TURB_OPTION 0=no turbulence; 1=diagnosed as in flexpart_ecmwf; 2 and 3=from tke. 1 LU_OPTION 0=old landuse (IGBP.dat); 1=landuse from WRF 1 CBL SCHEME 0=no, 1=yes. works if TURB_OPTION=1 0 SFC_OPTION 0=default computation of u*, hflux, pblh, 1=from wrf 0 WIND_OPTION 0=snapshot winds, 1=mean winds,2=snapshot eta-dot,-1=w based on divergence 0 TIME_OPTION 1=correction of time validity for time-average wind, 0=no need 1 OUTGRID_COORD 0=wrf grid(meters), 1=regular lat/lon grid 1 RELEASE_COORD 0=wrf grid(meters), 1=regular lat/lon grid 2 IOUTTYPE 0=default binary, 1=ascii (for particle dump only),2=netcdf 1 NCTIMEREC (int) Time frames per output file, only used for netcdf 0 VERBOSE VERBOSE MODE,0=minimum, 100=maximum }}} " lchong pesei 31 Wet deposition - problems with in-cloud/below-cloud scheme FP physics/numerics FLEXPART 10 Defect 2013-09-12T17:34:02Z 2021-01-09T21:33:32Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Petra reports that in the project FLEXRISK, the new cloud deposition scheme has, at least partly, lead to results that look unrealistic. Petra has developed a “quick fix”, that will be included in the next version " pesei pesei 34 Wet deposition - washout coefficients FP physics/numerics FLEXPART 9.2 Defect 2013-09-12T17:42:31Z 2014-03-27T10:54:48Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) From the experience gained with Fukushima, it was agreed that the washout coefficients in FLEXPART need to be re-evaluated. " pesei pesei 204 namelist input for RELEASES needs more checking FP coding/compilation FLEXPART 10 Defect 2018-08-31T13:49:45Z 2020-08-21T18:57:28Z "If a RELEASES file in namelist format does not contain MASS for all species, it will not be properly initalised (compiler may set it to 0.). This is different from standard RELEASES files where a read error would occur. Therefore, this conditions should be identified and a WARNING should be produced (maybe even an ERROR, as one would not normally want to use zero mass)." pesei pesei 205 Output format for trajectories.txt FP post-processing FLEXPART 10 Defect 2018-09-06T15:41:25Z 2020-08-21T19:21:27Z "We noticed that the output format in the trajectories.txt file is not optimal. We had the situation that, in backward mode with long simulation times, the -NNNNNNN was so long that there was no space separating the first and second columns any more (for late time steps). It would be good if the output format could be changed to accomodate long simulations. I believe that the necessary change is in plumetraj.f90, in line 235., by applying this change: {{{#!fortran modified src/plumetraj.f90 @@ -232,7 +232,7 @@ subroutine plumetraj(itime) ! Write out results in trajectory data file !****************************************** - write(unitouttraj,'(i5,i8,2f9.4,4f8.1,f8.2,4f8.1,3f6.1,& + write(unitouttraj,'(i5,i9,2f9.4,4f8.1,f8.2,4f8.1,3f6.1,& &5(2f8.3,f7.0,f6.1,f8.1))')& &j,itime-(ireleasestart(j)+ireleaseend(j))/2, & xcenter,ycenter,zcenter,topocenter,hmixcenter,tropocenter, & }}} I'm happy to solve this myself - how should I contribute back? Via a patch against git master? Or should I create (am I allowed to do that?) my own branch in Git and you do the merging? Or do you just want to implement that one-character change yourself? This seems to still be in git master. However, I cannot choose git master as ""Version"" when reporting this issue. What would be the most convenient thing to do to make it easy for you?" ahilboll pesei 305 FLEXTRA fails with NCEP GFS data after 2021-03-22 FLEXTRA FLEXTRA 6 Defect 2021-07-09T07:04:56Z 2023-02-02T10:01:55Z "FLEXTRA fails when used with NCEP GFS data for dates after (approximately) 2021-03-22. The error message is typically {{{ TEMP: 0.00000000 STOP SORRY: T NOT IN [K] }}} This is a known issue with FLEXPART and has been discussed in the '''mailing list''' (initial post from Richard Damoah dated '''2021-05-09''' with subject line ""'''FLEXPART 10.4 Error with GFS met fields'''""). I believe there is a fix in development versions of FLEXPART. I am only creating this ticket to ensure that FLEXTRA gets the fix too. I have set the priority to critical, but that is only true for dates after 2021-03-22. For dates before that, there is no problem." hcpxvi pesei 115 Bug in readspecies.f90 FP coding/compilation FLEXPART 9.2 Defect 2015-03-10T16:43:56Z 2015-06-11T20:44:35Z "I found a bug in `readspecies.f90`, probably introduced with the modulation of releases as a function of day of week and hour of day, and more with intro of namelists. '''1. Wrong address for premature end of SPECIES''' In the lines {{{ #!python read(unitspecies,'(a10)',end=22) species(id_pos) ! write(*,*) species(id_pos) }}} etc., the place to jump to must be '''`20`''', otherwise `area_hour, point_hour, area_dow, point_dow` are not intialised. '''2. Attempt to read modulation factors''' If we are already at EOF, we can't use `end=` anymore, so use `err=22`. '''3. Assignment to namelist''' (maybe that should go into #94) {{{ pspecies=species(id_pos) pdecay=decay(id_pos) pweta=weta(id_pos) pwetb=wetb(id_pos) pweta_in=weta_in(id_pos) pwetb_in=wetb_in(id_pos) pwetc_in=wetc_in(id_pos) pwetd_in=wetd_in(id_pos) preldiff=reldiff(id_pos) phenry=henry(id_pos) pf0=f0(id_pos) pdensity=density(id_pos) pdquer=dquer(id_pos) pdsigma=dsigma(id_pos) pdryvel=dryvel(id_pos) pweightmolar=weightmolar(id_pos) pohreact=ohreact(id_pos) pspec_ass=spec_ass(id_pos) pkao=kao(id_pos) }}} has to be split and each line to be put below the corresponding read statement. There is more stuff that should be cleaned up even if it does not give bugs. I started to do so in my wet depo work. " pesei pesei 140 vertransform.f90 occasionally fails to initialize FP other FLEXPART 10 Defect 2016-03-14T12:34:56Z 2021-01-29T11:03:04Z "When running with smaller domains verttransform might fail to initialize ixm and jym. At initialization the following block is run in verttransform.f90: {{{#!fortran ! Search for a point with high surface pressure (i.e. not above significant topography) ! Then, use this point to construct a reference z profile, to be used at all times !************************************************************************************** do jy=0,nymin1 do ix=0,nxmin1 if (ps(ix,jy,1,n).gt.100000.) then ixm=ix jym=jy goto 3 endif end do end do 3 continue }}} In order to work, there has to be a grid point within the domain with a surface pressure above 1000 hPa. Such a point might not be present in smaller domains, where there is only a small number of grid points over sea surface. It would be good if this block at least produces an error if no reference point is found. " adingwell pesei 143 readwind_gfs() not reading total cloud cover from GRIB2 FP input data FLEXPART 9.2 Defect 2016-03-22T01:34:33Z 2016-03-23T15:58:39Z "In trying to resolve wet deposition differences between FP9.02 and our Vtable version of FP, I stumbled with GRIB parameter codes for total cloud cover. As I see it, the codes used in ''readwind_gfs()'' are incorrect for GRIB2 inputs. My initial debugging consisted of printing '''SUM(tcc)''' at each timestep, and it was always 0.0. So then I looked at the code, and it never even checks GRIB2 parameters for TCC. It only checks for GRIB1 parameters of 071 with level type of 244. I even put print statements in all the ""if"" blocks that deal with TCC, and not one of them printed. We have created Vtable code which resolves this kind of problem, but if anybody wants to resolve the issue in existing FP9.02 code, I recommend adding the following in ''readwind_gfs()'', in the section of code that converts GRIB2 codes to GRIB1 codes (for use further down in the routine). {{{ elseif ((parCat.eq.6).and.(parNum.eq.1).and.(typSurf.eq.244)) then ! TCC isec1(6)=71 ! indicatorOfParameter isec1(7)=244 ! indicatorOfTypeOfLevel }}} After doing this, I am finding identical output between our FP with Vtables and the original FP9.02. " donaldjmorton pesei 173 "Variables ""settling"" and ""idummy"" not properly initialized in advance.f" FP coding/compilation Defect 2017-04-28T13:11:15Z 2017-04-28T13:26:49Z "Statements: data idummy/-7/ data settling/0./ do not properly initialize the variables during subsequent calls of the subroutine. Should be replaced by : idummy=-7 settling=0.0 Already solved in versions 9 and 10. " chrmau pesei 175 FpWrf header_nest dxoutn, dyoutn always in metre FP coding/compilation FLEXPART_WRF_3.4_FPbase_9 Defect 2017-07-06T16:28:55Z 2017-09-18T20:04:06Z "The file `header_nest` contains the grid distance in metre even in the case that outgrid is in lat-lon system. The same problem holds for the release coordinates (`xpoint, ypoint`) in bother `header` and `header_nest`" pesei pesei 193 Wrong date format in output filename FP coding/compilation Defect 2018-05-07T13:51:41Z 2018-05-08T16:39:21Z "While using FLEPXARTv8.2.3 I found a wrong date format in some of the output files. I ran FLEXPART in backward mode and mostly the output filenames were named as expected such as {{{ grid_time_20170405000000_001 grid_time_20170402000000_001 }}} However, in some simulations I found problems with the date format during transition of dates so that it shows the hour '24' instead of '00', e.g. {{{ grid_time_20170331240000_001 grid_time_20170401240000_001 }}} This seems to be a bug in function `caldate` due to rounding errors. === Suggestion for solution: === The hour in `caldate` should be checked as it is already done for seconds and minutes. == Reproducability == Additionally, it should be checked if this behavior can be reproduced with other FLEXPART versions. I used `ifort` and the ECCODES library version `2.6.0` for compilation of FLEXPART with the following setting of FLAGS: {{{ FFLAGS = -O3 -mcmodel=medium -unroll -inline -heap-arrays 32 -I$(INCPATH) LDFLAGS = $(FFLAGS) -L$(LIBPATH1) -Bstatic -leccodes_f90 -leccodes -Bdynamic -lm -ljasper -openmp }}} ==== COMMAND file ==== Relevant parameter of the COMMAND file are: {{{ -1 LDIRECT 20170331 040000 20170405 050000 3600 OUTPUT EVERY 3600 TIME AVERAGE OF OUTPUT 120 SAMPLING RATE OF OUTPUT 999999999 TIME CONSTANT FOR PARTICLE SPLITTING 60 SYNCHRONISATION INTERVAL 1.0 CTL }}} " anphi pesei 214 global OUTGRID is rejected FP coding/compilation FLEXPART 10 Defect 2018-11-16T16:34:11Z 2020-08-21T19:01:54Z "`readoutgrid.f90` checks whether the outgrid falls within the boundaries of the meteo domain. However, a global meteo domain is a special case which is not considered here. For example, with 0.75 deg meteo resolution (ERA-Interim), the first grid point has a longitude of -179.25 deg. For a global OUTGRID, outlon0 has to be set to -180. This is rejected by {{{#!fortran if ((outlon0+eps.lt.xlon0).or.(outlat0+eps.lt.ylat0) & .or.(xr.gt.xr1+eps).or.(yr.gt.yr1+eps)) then }}} " pesei pesei 269 Compilation without netCDF not properly implemented, grib_api -> eccodes FP coding/compilation FLEXPART 10.4.1 Defect 2020-05-06T13:53:41Z 2023-03-29T17:42:36Z The makefile distributed with FLEXPART 10.4 contains netcdf-related objects without enclosing them in a proper if block. Therefore, it is not possible to compile the code using this makefile on a machine where netcdf is not available (or not available in the expected place / version). pesei pesei 270 readreceptors.f90: bug in namelist version FP coding/compilation FLEXPART 11 Defect 2020-05-28T16:38:05Z 2023-03-30T18:07:04Z The reading of the namelist version of RECEPTORS is not properly implemented. The first record is read to test whether the file is namelist. If it is, this record is discarded, thus the first receptor is not used. pesei pesei 307 Flexpart-WRF crashes due to array boundary violation in outgrid_init_reg.f90 FP coding/compilation Defect 2021-08-17T10:11:50Z 2023-03-29T16:03:31Z "Deal All, I am using Flexpart-wrf version 3.3.2, compiled for mpi (version cray-mpich/7.6.3) using gnu compilers (version 7.2.0) on cray architecture. The model has run successfully for 2 simulations, but on the next simulation, I am getting segmentation fault: {{{ ---------------------------- Running Flexwrf ---------------------------------- CPU: n180 N9 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x2aaaac8b693f in ??? #1 0x44baaf in ??? #2 0x4a830f in ??? #0 0x2aaaac8b693f in ??? #1 0x44baaf in ??? #2 0x4a830f in ??? #3 0x2aaaaace5aad in gomp_thread_start at ../../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/libgomp/team.c:120 #4 0x2aaaab17c723 in ??? #5 0x2aaaac96bc9c in ??? #6 0xffffffffffffffff in ??? _pmiu_daemon(SIGCHLD): [NID 00069] [c0-0c1s1n1] [Fri Aug 13 12:56:57 2021] PE RANK 0 exit signal Segmentation fault [NID 00069] 2021-08-13 12:56:57 Apid 182238106: initiated application termination. -------------------------------------------------------------------------- }}} These are my flags for compilation: {{{ GNU_FFLAGS = -O2 -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check -fbacktrace GNU_LDFLAGS = -O2 -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -lnetcdff -fno-range-check }}} ---------------------------------------------------- I have used: {{{ ulimit -s unlimited ulimit -c unlimited }}} before running the model. Any idea how I can fix this problem?" srakesh pesei 139 Bad do-loop in richardson.f90 FP coding/compilation FLEXPART 9.2 Defect 2016-03-08T19:42:52Z 2018-06-01T20:22:50Z "When determining the levels to use for the Richardson number, the following loop is executed: {{{ ! Integrate z up to one level above zt !************************************* do k=2,nuvz ... if (ri.gt.ric .and. thetaold.lt.theta) goto 20 ... end do 20 continue }}} The final k-value is then used for the main calculation in a second loop: {{{ do i=1,20 zl=zold+real(i)/20.*(z-zold) ul=ulev(k-1)+real(i)/20.*(ulev(k)-ulev(k-1)) vl=vlev(k-1)+real(i)/20.*(vlev(k)-vlev(k-1)) thetal=thetaold+real(i)/20.*(theta-thetaold) rhl=rhold+real(i)/20.*(rh-rhold) ril=ga/thetaref*(thetal-thetaref)*(zl-zref)/ & max(((ul-ulev(2))**2+(vl-vlev(2))**2+b*ust**2),0.1) zl2=zl theta2=thetal if (ril.gt.ric) goto 25 zl1=zl theta1=thetal end do }}} When a level is caught by the if-statement in the first loop, everything works as expected. However, if the expression in that if-statement is never satisfied, the loop exits by reaching the upper limit (k=nuvz). In standard Fortran this means that the final value will be k=nuvz+1, which means that ulev and vlev will exceed their bounds in the second loop! This problem might go undetected without strict compiler flags, but it's probably causing some strange behaviour even when the error is not raised. A quick work-around to this problem is to add ""k=k-1"" between ""end do"" and ""20 continue"". I'm not sure if this is a ''good'' solution from a physical point of view..." adingwell pesei 176 No error issued if insufficient number of SPECIES (FpWrf) FP coding/compilation FLEXPART_WRF_3.4_FPbase_9 Defect 2017-07-06T16:33:37Z 2017-08-23T13:18:19Z "If there are not as many species listed in the SPECIES section as required by the RELEASE section, no error is triggered, but the output files seem to be empty. I suggest that this condition should be treated as ERROR (stop run) as output will not be useful." pesei pesei 274 Non-ascii characters in FLEXTRA output FLEXTRA FLEXTRA 6 Defect 2020-06-16T13:18:32Z 2020-06-16T14:13:34Z "A problem that occurs with FLEXTRA is that the output file can contain non-ascii characters. This happens because the variable `datestring(1:24)` is written out, but the non-standard call which would have filled it with today's date is commented out, meaning that the variable is never initialised. The simplest fix is to edit `opencetoutput.f`, `openflightoutput.f` and `openoutput.f` . In each case, find the comment {{{ C call fdate(datestring) }}} and immediately after it insert the line {{{ datestring=""----- Not Available ----"" }}} One could just remove the print statements that print out `datestring(1:24)` but the above suggestion keeps the layout of the output file identical to how it was before, while ensuring that it is pure ascii. The non-ascii characters are benign to some users, but can cause trouble for anyone trying to read the FLEXTRA output into python 3. " hcpxvi pesei 138 FLEXPART.f90 should not call readpaths with an argument FP coding/compilation FLEXPART 9.2 Defect 2016-03-08T18:51:00Z 2018-05-28T17:52:34Z "'''readpaths()''' no longer accept an argument since '''pathfile''' now resides in '''com_mod.f90'''. However, '''FLEXPART.f90''' still attempt to make the call with '''pathfile''' as argument; this results in an error when using more strict compiler options. (This also applies to FLEXPART10)" adingwell saeck 248 Inconsistency between Pisso et al paper and model behavior FP other Defect 2019-09-09T13:21:34Z 2019-09-19T08:47:22Z "In the Pisso et al. paper, it is said that > In simulations where a particle represents several species, all species are transported with the settling velocity of the first species. If this is undesired, simulations for the different species must be run separately. However, when running the model with two species per release point, I get the following: {{{ WARNING: more than 1 species per release point, settling disabled }}} This seems to be contradicting. What is actually the case? Given that the paper describes v10.3, I believe that either the model code (specifically, the exact words of the warning) or the paper should be updated." ahilboll anphi 25 Dynamic memory allocation FP coding/compilation FLEXPART 10 Enhancement 2013-09-12T17:17:21Z 2020-08-21T18:09:40Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Introduce dynamic memory allocation at least for all variables related to meteorological input data" pesei anphi 59 Improve error messages FP coding/compilation Enhancement 2014-01-10T21:21:16Z 2015-03-06T09:36:01Z Many of the FLEXPART error messages don't contain enough or appropriate content, for example they say that some variable is outside the expected range but don't give its actual value or the value of the expected range. pesei jbrioude 50 FLEXPART can crash with some GFS data FP coding/compilation FLEXPART 9.2 Enhancement 2013-10-03T00:09:54Z 2020-09-24T12:42:09Z "Ticket #48 reminded me that for GFS files obtained from the NCEP ftp server, I had to fix gridcheck_gfs.f90 and readwind_gfs.f90 for GRIB1 and GRIB2 files because 1) the vertical levels are not sorted 2) additional 2D fields might be wrongly detected as temperature or humidity 2D fields by FLEXPART. I will had a fix to the new version of FLEXPART. " jbrioude pesei 122 Improve MQUASILAG option FP physics/numerics FLEXPART 10.4.1 Enhancement 2015-06-03T13:42:55Z 2022-04-26T09:24:56Z "Quasi-Lagrangian output, i.e. particle IDs and positions, is not well implemented yet. In `readcommand.f90`: {{{ ! For quasilag output for each release is forbidden ! For quasilag backward is forbidden }}} In `partoutput_short.f90`: {{{ ! Convert positions to integer*2 variables (from -32768 to 32767) ! Do this only for region of main interest, i.e. extended North Atlantic region, ! and for the tracer of interest, i.e. the North American one !***************************************************************************** if (xlon.gt.180.) xlon=xlon-360. if (xlon.lt.-180.) xlon=xlon+360. numshortall=numshortall+1 if ((xlon.gt.-140).and.(xlon.lt.60).and.(ylat.gt.10).and. & (xmass1(i,1).gt.0.)) then numshortout=numshortout+1 idump(1,numshortout)=nint(xlon*180.) idump(2,numshortout)=nint(ylat*360.) zlim=min(ztra1(i)+topo,32766.) idump(3,numshortout)=nint(zlim) i4dump(numshortout)=npoint(i) endif endif end do }}} I don't see the reasons for these limitations, and in any case, they are not desirable (cf. recent FLEXPART discussion list posting, Subject: Particle tracking). " pesei pesei 77 Speeding up FLEXPART FP input data FLEXPART 9.2 Enhancement 2014-05-07T15:55:39Z 2018-06-25T20:17:52Z "Using 1-h meteorological input, CTBTO/PTS/IDC has found that calculation times increased over the sustainable limit for their operational application and asked for support. With their specific setup and 119 levels, they found the following distribution of CPU time per subroutine '''for 3-h data''': {{{ % cumulative self self total time seconds seconds calls Ks/call Ks/call name 24.25 9198.93 9198.93 2983679872 0.00 0.00 advance_ 14.62 14743.46 5544.53 1976235129 0.00 0.00 interpol_wind_ 12.12 19339.47 4596.02 1009684743 0.00 0.00 interpol_all_ 10.84 23453.55 4114.08 2983414505 0.00 0.00 interpol_wind_short_ 9.23 26954.62 3501.07 119 0.03 0.03 verttransform_ 8.08 30021.38 3066.76 119 0.03 0.03 calcpv_ 3.81 31466.55 1445.17 1 1.45 35.87 timemanager_ 3.62 32840.83 1374.28 119 0.01 0.01 readwind_ 2.98 33971.49 1130.66 469 0.00 0.00 conccalc_ 1.67 34606.72 635.24 119 0.01 0.03 calcpar_ ... }}} '''whereas with 1-h data it is''' {{{ % cumulative self self total time seconds seconds calls Ks/call Ks/call name 21.00 8774.93 8774.93 359 0.02 0.03 verttransform_ 16.29 15581.52 6806.59 3573265152 0.00 0.00 advance_ 12.84 20947.59 5366.07 359 0.01 0.01 calcpv_ 9.18 24786.27 3838.68 889791459 0.00 0.00 interpol_all_ 7.70 28002.91 3216.65 359 0.01 0.01 readwind_ 7.34 31071.00 3068.08 3572065979 0.00 0.00 interpol_wind_short_ 6.84 33931.05 2860.06 2692433693 0.00 0.00 interpol_wind_ 4.13 35655.92 1724.86 1 1.72 40.23 timemanager_ 3.64 37177.09 1521.17 359 0.00 0.02 calcpar_ 3.48 38630.15 1453.06 715 0.00 0.00 conccalc_ 0.96 39033.10 402.94 grib_jasper_decode }}} " pesei pesei 275 FLEXTRA not compilable against eccodes FLEXTRA FLEXTRA 6 Enhancement 2020-06-16T14:07:33Z 2020-08-05T16:46:04Z "FLEXTRA as supplied can not be compiled against [https://confluence.ecmwf.int/display/ECC/ecCodes+Home eccodes]. This is because when ECMWF retired ''libgrib_api'' and told everyone to move to ''eccodes'', they also retired the Fortran 77 interface (which FLEXTRA uses). (This is not an issue for Flexpart which is in Fortran 9x, used the Fortran 9x interface to libgrib_api, and already compiles against eccodes.) I am aware that the forthcoming FLEXTRA 6 will work with eccodes, so this problem should go away once FLEXTRA 6 is released --- I am happy to wait until that happens. I am putting in a ticket partly so that the enhancement request is on record and partly to document an approach to compiling FLEXTRA 5 with eccodes that didn't work for me, in case that information is of any help to the developers. What I did was to delete the files `gridcheck_gfs.f` and `readwind_gfs.f`, then replace them with the versions at https://sources.debian.org/patches/flextra/5.0-12/ With the usual sort of changes to the makefile, FLEXTRA will compile and the FLEXTRA_GFS executable will run to the extent of telling you that you need to set up a pathnames file. I next set up a pathnames file and an options directory for a short test run. I checked that the setup was correct by running a FLEXTRA executable linked against `libgrib_api`, obtaining the expected trajectory file. When I ran the executable compiled against eccodes with the same pathnames file and options directory it crashed with the error message {{{ TEMP: 0.00000000 STOP SORRY: T NOT IN [K] }}} A different test case that worked as expected with the executable linked against `libgrib_api` failed with the executable linked against `eccodes`, but with a different error: {{{ #### TRAJECTORY MODEL SUBROUTINE READPOINTS: #### #### ERROR - TOO MANY STARTING POINTS #### [...] }}} I set the priority on this ticket to ""major"". It could be regarded only as minor while it is still possible to keep a working copy of `libgrib_api` around. But it might escalate itself to critical once `libgrib_api` became difficult to use. " hcpxvi pesei 281 problem with caldate FP other FLEXPART 10 Enhancement 2020-07-22T18:16:02Z 2020-11-11T11:53:18Z "was reported for FLEXTRA, see #280 should be fixed in FLEXPART as well" pesei pesei 36 Convection - don't call every time step FP physics/numerics FLEXPART 9.2 Enhancement 2013-09-12T17:50:50Z 2016-08-23T15:09:27Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Since the scheme is computationally costly, it should be investigated whether it could be called not every time step, but less frequently. " pesei pesei 85 Input file templates FP input data Long-term tasks Enhancement 2014-06-27T17:21:22Z 2018-06-25T20:20:41Z The templates for FLEXPART input files (COMMAND etc.) can be improved, so that the manual needs to be consulted less. Let's collect here what we want to do. pesei pesei 124 Suggest easing of restriction on number of releases in readpartpositions.f90 FP other FLEXPART 9.2 Enhancement 2015-06-20T23:33:38Z 2015-06-28T17:46:41Z "Given another very bad fire year in Alaska, I am running FLEXPART operationally, warm starting from one run to the next. Because of the dynamic nature of releases (new fires, some fires suppressed), it is normal that the number of releases saved from a previous run to warm start a new run will not be the same as the number of releases in the new run. In readpartpositions.f90, I have found it necessary to comment out the following code (in the vicinity of Line 78) in order to allow for different number of releases from one run to the next. {{{ read(unitpartin) numpointin !!!!!!!!!!!!!! MODIFICATION DJM 2015-06-20 - comment out the !!!!!!!!!!!!!! following restriction ! if (numpointin.ne.numpoint) goto 995 }}} I understand there may be very good reason to have this restriction, but at least in my case it gets in the way. " donaldjmorton pesei 198 Unsorted trajectories in FLEXTRA flightmode with constant initialization time FLEXTRA Enhancement 2018-06-08T12:21:51Z 2018-06-08T12:23:37Z "For a project we did some simulations in flight mode with FLEXTRA. The specific characteristic was, that we hold the time and horizontal coordinates constant and just varied the vertical coordinate. This lead to the following STARTFLIGHT file: {{{#!fortran ... header ... ********************************************************************** alife 1 !kind 1 !unit ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20170422 060000 !time begin 32.97000 !lon 35.43000 !lat 1121.0 !height ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20170422 060000 !time begin 32.97000 !lon 35.43000 !lat 896.0 !height ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20170422 060000 !time begin 32.97000 !lon 35.43000 !lat 671.0 !height ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20170422 060000 !time begin 32.97000 !lon 35.43000 !lat 446.0 !height ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20170422 060000 !time begin 32.97000 !lon 35.43000 !lat 221.0 !height ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20170422 060000 !time begin 32.97000 !lon 35.43000 !lat 131.0 !height ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ }}} Reading of the first trajectory starting point from this file is done in FLEXTRA.f line 99. Afterwards, the rest is read in the following timemanager.f section (l. 114 - 162): {{{#!fortran C Check whether new trajectories have to be started C 1nd if: check if time within modeling period C 2nd if: check if the interval interv has passed by (for NORMAL C trajectories) or if a FLIGHT traj. is due to be started ***************************************************************** if (abs(itime).le.abs(ideltas-lentra)) then if (modecet.eq.3) then ! FLIGHT mode 41 continue if ((nextflight.eq.itime).and.(numtra.lt.maxtra)) then do 43 i=numtra,1,-1 ! shift pointers 43 numb(i+1)=numb(i) numtra=numtra+1 ! increase number of traj. j=1 ! initialize FLIGHT traj. 42 continue if (nttra(j).eq.0) then numb(1)=j npoint(j)=1 levmem(j)=zpoint(1) xtra(j,1)=xpoint(1) ytra(j,1)=ypoint(1) ztra(j,1)=zpoint(1) ittra(j,1)=itime nttra(j)=1 kind(j)=kind(1) kindz(j)=kindz(1) else j=j+1 if (j.gt.maxtra) stop 'timemanager: too many trajectorie +s. Increase parameter maxtra and re-start' goto 42 endif C Read the next FLIGHT traj. **************************** read(unitpoin,*,err=15,end=15) ldat,ltim read(unitpoin,*,err=15,end=15) xpoint(1) read(unitpoin,*,err=15,end=15) ypoint(1) read(unitpoin,*,err=15,end=15) zpoint(1) read(unitpoin,*,err=15,end=15) nextflight=nint(sngl(juldate(ldat,ltim)-bdate)*86400.) call coordtrafo(error) if (error) stop call subtractoro() if (kindz(1).eq.3) zpoint(1)=zpoint(1)*100. goto 41 endif }}} The problem in this section is, that the vertical order isn't maintained. The new trajectory is stored in the next free memory which is found. It might not be a problem if the time is increasing, but seems to have a problem with a constant time. This unordered storage of trajectories are then written out to the output file in this wrong order. This might not be a problem for most cases. But it matters in our case where the output trajectories are processed one by one, assuming the correct order of trajectories regaring the height. " anphi pesei 280 Trajectory time 240000 instead of 000000 next day FLEXTRA FLEXTRA 6 Enhancement 2020-07-22T08:13:04Z 2020-07-27T11:02:45Z "This is a bit of a corner case. When running FLEXTRA in STARTFLIGHT mode, one of my start points happened by pure chance to be {{{ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20200103 000000 -142.8289 -53.1970 215.4435 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ }}} (FWIW, the vertical unit here is 3 : pressure in hPa) In the output file, the trajectory header line comes out as {{{ DATE: 20200102 TIME: 240000 STOP INDEX: 4 # OF POINTS: 383 }}} It would be preferable if this were to be written out as {{{ DATE: 20200103 TIME: 0 STOP INDEX: 4 # OF POINTS: 383 }}} " hcpxvi anphi 38 Testing environment FP other Long-term tasks New feature 2013-09-12T17:57:31Z 2015-12-11T13:46:10Z "It was generally agreed that standardized and automated test cases and model/measurement comparison metrics are urgently needed to test new model versions, validate model improvements and inter-compare FLEXPART with other models. Performance benchmarks are also desirable, not only to evaluate hardware but also to quantify the impact of code modifications on performance. Consistency checks between forward and backward simulations would be useful as well; to reach full consistency, sources need to be defined as grid cell sources on the output grid. " pesei anphi 67 Support for removing levels from EN files FP input data New feature 2014-03-24T20:28:22Z 2017-07-12T10:43:04Z "For tropospheric dispersion problems, atmospheric layers higher than ca. 100 hPa are rarely needed. However, they may have been extracted from ECMWF MARS into the EN files (some versions of the extraction routines haven't offered the option to take only a part of the levels). This causes the EN files to be unnecessarily large, and it creates additional overhead in `verttransform.f90` and `calcpv.f90`. As recent experiences have shown, with 1-h temporal resolution, these two subroutines can form a bottleneck. It is therefore worthwhile to offer fixes for this problem. Options: 1. A script using the GRIB_API to remove certain layers 2. An option in FLEXPART to not ingest certain layers. Probably implementing both solutions would be best." pesei anphi 226 flex_extract WRF data flex_extract flex_extract_v7.2 New feature 2019-01-17T18:10:27Z 2021-07-21T08:41:15Z " __Message by ahilboll: I noticed that when downloading data with GAUSS=1 and ETA=0 (which is, if I understand the comments in flexpartTools.py correctly, the recommended setting for ERA-Interim), the U and V parameters are downloaded in SH grid, not on GG - which means that it probably cannot be ingested by WRF's ungrib.exe. Or am I missing something here? Furthermore, D is contained in the WRF files twice, once in GG and once in SH. That's because it explicitly gets added to the GG list in the {{{if c.wrf=='1': }}} block even though it's already part of SH. So maybe, the way would be to do {{{ if c.wrf=='1': self.params['OG__ML'][0]+='/Z/VO' for var_ in ['/D', '/U', '/V']: if var_ not in self.params['OG__ML'][0]: self.params['OG__ML'][0]+=var_ }}} to add the GG U and V fields to the download list, and then (~line 1188) {{{ if c.wrf=='1' and gridtype=='regular_ll': if levtype=='hybrid': if paramId in [129,130,131,132,133,138,155]: grib_write(gid,fwrf) else: if paramId in wrfpars: grib_write(gid,fwrf) }}} " anphi anphi 295 New interpolation scheme for precipitation FP physics/numerics FLEXPART 10 New feature 2021-01-10T20:16:04Z 2021-01-10T20:18:28Z "Implement the new precipitation interpolation method using fields at 2 additional times as introduced in ''A conservative reconstruction scheme for the interpolation of extensive quantities in the Lagrangian particle dispersion model FLEXPART'' by Sabine Hittmeir, Anne Philipp, and Petra Seibert, https://gmd.copernicus.org/articles/11/2503/2018/ Note that these fields can be produced in `flex_extract` v7.1.2+ (see https://www.flexpart.eu/flex_extract/)" pesei anphi 302 Create flex_extract_precip flex_extract flex_extract_v7.2 New feature 2021-05-21T13:35:29Z 2021-07-21T08:55:46Z "The new precipitation disaggregation with two additional fields per step (e.g., hourly in case of 3-h data) has been implemented in flex_extract, but many data, esp. ERA5, have already been extracted with the old scheme. Therefore we need a tool to extract and process only the precip fields with the new method, and optionally replace the fields in the EN-files." pesei anphi 315 flex_extract templates with reduced level number flex_extract flex_extract_v7.1.3 New feature 2022-02-10T22:40:09Z 2023-04-03T10:29:51Z "For most applications, it is not necessary to extral al of ECMWF's IFS model levels. Usually levels covering troposphere and lower stratosphere are sufficient. Benefits: -- less data to transfer and store -- FLEXPART runs will require less memory -- FLEXPART runs will require less CPU time Therefore, suitable standard templates should be distributed with `flex_extract`" pesei pesei 318 reading receptor output FP post-processing New feature 2022-06-21T11:56:47Z 2022-07-18T14:10:08Z "Hi all, When adding receptors to forward flexpart runs with netcdf enabled, I can't see the desired output in the .nc output file. Could the receptors output be added to the netcdf file? And meanwhile, what is the easiest option to read the receptor_**** binary files? Thanks in advance! " tcarion pesei 113 Option for incremental wet deposition output FP physics/numerics New feature 2015-01-27T14:02:41Z 2015-02-16T18:28:41Z "I'll plan to 1. Introduce a switch to reset deposition fields after output like in flexRISK versions 2. Implement & test option for using loutstep,loutaver,loutsample not only in concentration output but also in deposition output Justification: We use feature (1) in flexRISK and follow-up projects to reduce the size of the deposition output. I don't want to backfit this feature to any new FLEXPART version, and I think it's useful for everyone. Feature (2) is a generalisation, and it will be useful for testing of wet deposition, possibly also other contexts. We can decide whether it should be kept in mainstream Fp, but I thought I let everyone know about it, so they can make suggestions." pesei anphi 298 Running preprocessing with previously loaded grib files flex_extract flex_extract_v7.1.3 Support 2021-04-09T09:00:17Z 2023-04-03T10:28:54Z "Hello, When I'm running flex_extract, I sometimes get an error at etadot calculation : {{{ #!div style=""font-size: 80%"" Flex_extract error: {{{#!python Command '['{fe_path}/flex_extract_v7.1.2/Source/Fortran/calc_etadot']' died with . }}} }}} I don't know where it comes from, and for debugging purposes, I would like to rerun flex_extract without re-downloading the grib files through mars request, since these files are already available. Unfortunately, reading the (very good) documentation, I didn't see any way of running only the pre-processing phase of the raw grib files given by mars. So I wanted to know if this feature could be added (or if it already exists but I'm not aware). Thank you very much in advance. Tristan Carion" tcarion pesei 210 RECEPTOR syntax error FP other Support 2018-11-03T21:11:44Z 2018-12-20T12:01:53Z I was having an issue with my OUTGRID section (see ticket:209). I think I resolved it. However, now I keep getting a syntax error for the RECEPTOR section of my flexwrf.input file. I have not made any changes to this section so I really don't know what is wrong. mitchekc pesei 271 SFC_OPTION = 1 not working FP input data Support 2020-05-30T13:16:36Z 2023-03-29T16:14:36Z "Hi, I am trying to run flexwrf_v3.3.2. When I tried to input SFC from WRF output, it is showing no longer supported. Does anyone have idea of why is this happening? Error message: #### FLEXPART MODEL ERROR! SFC_OPTION = 1 #### FLEXPART MODEL ERROR! SFC_OPTION = 1 #### Reading from WRF no longer supported. #### --------------------------------- Attaching input and log files " srakesh anphi 56 Parameter numbers in GRIB1/GRIB2 FP input data FLEXPART 9.2 Task 2013-11-22T12:31:32Z 2022-03-02T17:20:18Z "FLEXPART identifies different fields through ''parameter category'', ''parameter number'' and ''level type''. These are not always the same and have changed from GRIB1 to GRIB2, thus creating problems for reading sfc parameters in GRIB2. Using ''shortName'' as identifier instead would (almost) solve this problem. Furthermore, precipitation units have changed from m in GRIB1 to mm in GRIB2. Adaption of `gridcheck.f90` and `gridcheck_nests.f90` would be desirable. (based on input from Leo Haimberger)" pesei anphi 312 EMOSLIB to disappear on new HPC in Bologna flex_extract flex_extract_v7.1.3 Task 2022-01-16T20:22:28Z 2022-02-10T20:50:57Z "[https://confluence.ecmwf.int/display/EMOS/Emoslib EMOSLIB] has been retired by ECMWF and it will [https://confluence.ecmwf.int/display/UDOC/Bologna+-+New+Data+Centre not be provided on the new HPC system in Bologna], which should become operational around March or April 2022. Emoslib is used in the Fortran code of flex_extract. It should be checked what exactly is used and necessary changes should be implemented. " pesei anphi 266 FIX: Remove flex_extract v7.1 from ECMWF server before new installation flex_extract flex_extract_v7.2 Task 2020-02-28T09:54:47Z 2021-07-21T08:44:05Z "Currently, flex_extract overwrites current files within a new installation. This does not remove old files which are not needed anymore. This may leed to errors sometimes. Therefore, during the installation process, search for an existing installation and remove it before the new installation is done." anphi hasod 30 Documentation for domain-filling runs FP other Task 2013-09-12T17:31:55Z 2013-11-19T08:37:16Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Harald presented his work related to domain filling runs; it was agreed that existing FLEXPART options should be documented better, and that examples should be provided to document what can be done with the existing code (Harald to look into that) " pesei ignacio 44 Cittycat interface FP post-processing Long-term tasks Task 2013-09-12T18:07:19Z 2013-09-20T15:50:43Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) An existing interface of FLEXPART with Cittycat (chemistry box model) will be provided by Ignacio (post-processing tool) " pesei pesei 28 Trivial parallelisation FP input data Task 2013-09-12T17:29:12Z 2013-09-12T18:48:41Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Trivial parallelization does not need code modifications. Petra agreed to document and write down the approach used in the FLEXRISK project. Contributing scripts for efficient application of trivial parallelisation strategies are welcome. " pesei pesei 43 Library for reading output FP post-processing Task 2013-09-12T18:06:31Z 2014-03-20T15:23:19Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) To facilitate the interfacing between FLEXPART and other models, standardized code to read FLEXPART output would be needed (Library); Petra will provide an improved version of the existing one to NILU. ZAMG/Matthias will also look into that. " pesei pesei 51 Wet deposition - other models FP physics/numerics Long-term tasks Task 2013-10-15T09:41:44Z 2014-02-17T11:50:50Z "In a small meeting (Delia, Anne, Petra) we agreed that we should systematically research the algorithms and parameters for wet deposition used in other large-scale dispersion models, including chemistry-transport models. We may want to look at dry deposition as well while doing this. Base should be literature and model descriptions as well as - where possible - code and/or direct contact with developers of those models. This work should be divided between a number of people. For coordination, a wiki page ResearchDepo is created. All who want to contribute should enter there what they do. I'll try to coordinate and then summarise." pesei pesei 94 Code review for changeset 27 / hasod FP coding/compilation FLEXPART 9.2 Task 2014-07-04T13:35:12Z 2015-07-06T10:44:46Z "'''Namelist input''' changeset:27 by hasod contains: - Implemented optional namelist input for COMMAND, RELEASES, SPECIES, AGECLASSES,OUTGRID,OUTGRID_NEST,RECEPTORS - Implemented `com_mod` switch `nmlout` to write input files as namelist to the output directory (`.true.` by default) - Proposed updated startup and runtime output (may change back to previous info if desired) This ticket is also a place to discuss the proposed new standard output of a run. " pesei pesei 101 Code review for changeset 31 / hasod FP coding/compilation FLEXPART 9.2 Task 2014-10-21T08:19:52Z 2016-03-03T14:37:36Z "New feature netcdf output added. Affected routines are FLEXPART.f90, com_mod.f90, netcdf_output_mod.f90, readcommand.f90, timemanager.f90. Someone should test compilation and output on another system setup in addition to hasod." hasod pesei 27 ETEX1 data as part of FLEXPART distribution FP input data FLEXPART 9.2 Task 2013-09-12T17:25:42Z 2015-12-03T11:39:37Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) It was agreed that test data and performance benchmarks shall be included (optionally) into the FLEXPART distribution (ETEX 1 case); NILU to look into packaging EXTEX 1 test configuration; Matthias (Langer) to look into permissions to use/redistribute ECMWF data; " pesei