ticket summary component type owner status created modified _description reporter 335 No data is available for ERA5 in Oct 2018 flex_extract Support new 2023-04-11T14:30:14Z 2024-02-02T05:29:42Z "Dear FLEXPART community, I recently used flex_extract (v7.1.2) to download ERA5 data, and I ran into an error below. This error is strange as my data-downloading job ran perfectly fine for all years and months '''except for Oct 2018 only'''. The variables (param: 160.128/027.128/028.128/244.128) for Oct 2018 somehow appear missing from the CDS database. I wonder if anyone else has encountered a similar error before. I just sent a support request to C3S reporting the issue and am now awaiting their response. I also appreciate any help/solution from you about this issue. Many thanks for your attention. Best, Fandy {{{ MARS retrieve done ... ... retrieve 20181001/to/20181002 in dir /disk/r059/tfchengac/flex_extract/farmer_test/Run/Workspace/EA_temp marsclass: EA dataset: ERA5 type: AN levtype: SFC levelist: 1 repres: date: 20181001 resol: 255 stream: OPER area: 90.0/-179.0/-90.0/180.0 time: 00 step: 000 expver: 1 number: OFF accuracy: 24 grid: 1.0/1.0 gaussian: target: /disk/r059/tfchengac/flex_extract/farmer_test/Run/Workspace/EA_temp/OG_OROLSM__SL.20181001.1677928.1677929.grb param: 160.128/027.128/028.128/244.128 target: /disk/r059/tfchengac/flex_extract/farmer_test/Run/Workspace/EA_temp/OG_OROLSM__SL.20181001.1677928.1677929.grb RETRIEVE ERA5 WITH CDS API! 2023-04-11 18:53:06,316 INFO Welcome to the CDS 2023-04-11 18:53:06,316 INFO Sending request to https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-single-levels 2023-04-11 18:53:06,642 INFO Request is queued 2023-04-11 18:53:29,388 INFO Request is failed 2023-04-11 18:53:29,388 ERROR Message: no data is available within your requested subset 2023-04-11 18:53:29,388 ERROR Reason: Request returned no data 2023-04-11 18:53:29,389 ERROR Traceback (most recent call last): 2023-04-11 18:53:29,389 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/cdshandlers/services/handler.py"", line 59, in handle_request 2023-04-11 18:53:29,389 ERROR result = cached(context.method, proc, context, context.args, context.kwargs) 2023-04-11 18:53:29,389 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/caching.py"", line 108, in cached 2023-04-11 18:53:29,389 ERROR result = proc(context, *context.args, **context.kwargs) 2023-04-11 18:53:29,389 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/services.py"", line 124, in __call__ 2023-04-11 18:53:29,389 ERROR return p(*args, **kwargs) 2023-04-11 18:53:29,389 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/services.py"", line 60, in __call__ 2023-04-11 18:53:29,389 ERROR return self.proc(context, *args, **kwargs) 2023-04-11 18:53:29,389 ERROR File ""/home/cds/cdsservices/services/mars/mars.py"", line 48, in internal 2023-04-11 18:53:29,389 ERROR return mars(context, request, **kwargs) 2023-04-11 18:53:29,389 ERROR File ""/home/cds/cdsservices/services/mars/mars.py"", line 20, in mars 2023-04-11 18:53:29,389 ERROR execute_mars(context, requests, info) 2023-04-11 18:53:29,389 ERROR File ""/home/cds/cdsservices/services/mars/execute_mars.py"", line 33, in execute_mars 2023-04-11 18:53:29,389 ERROR raise NoDataException(""Request returned no data"", '') 2023-04-11 18:53:29,389 ERROR cdsinf.exceptions.NoDataException: Request returned no data MARS Request failed! no data is available within your requested subset. Request returned no data. Traceback (most recent call last): File ""/disk/r059/tfchengac/flex_extract/farmer_test/Source/Python/Classes/MarsRetrieval.py"", line 587, in data_retrieve self.server.retrieve(dataset, File ""/disk/r059/tfchengac/anaconda3/lib/python3.8/site-packages/cdsapi/api.py"", line 317, in retrieve result = self._api('%s/resources/%s' % (self.url, name), request, 'POST') File ""/disk/r059/tfchengac/anaconda3/lib/python3.8/site-packages/cdsapi/api.py"", line 458, in _api raise Exception(""%s. %s."" % (reply['error'].get('message'), reply['error'].get('reason'))) Exception: no data is available within your requested subset. Request returned no data. }}}" fcheng 343 flex_extract: TypeError: an integer is required FP other Defect new 2024-02-01T20:39:10Z 2024-02-02T05:03:14Z "Dear developers, I recently used the developer version of flex_extract from Github to download ERA5. Due to the data size, I downloaded the data day by day. It ran well and successfully produced the files for the FLEXPART model for 2022-09-01 and 2022-09-02, until it ran into an error [[span(style=color: #FF0000, TypeError: an integer is required )]] for 2022-09-03 after the MARS retrieve was done. I'm pasting the error message below. Any help is much appreciated. Thank you very much, Franklin '''Error message:''' {{{ ... marsclass: EA dataset: ERA5 type: AN levtype: ML levelist: 1 repres: date: 20220903/to/20220903 resol: 399 stream: OPER area: 90.0/-179.5/-90.0/180.0 time: 00/03/06/09/12/15/18/21 step: 00 expver: 1 number: OFF accuracy: 24 grid: OFF gaussian: target: /disk/r059/tfchengac/flex_extract_github_dev/Run/Workspace/EA_temp/ANSH__SL.20220903.834135.834136.grb param: 152.128 target: /disk/r059/tfchengac/flex_extract_github_dev/Run/Workspace/EA_temp/ANSH__SL.20220903.834135.834136.grb RETRIEVE ERA5 WITH CDS API! 2024-02-01 22:06:44,492 INFO Welcome to the CDS 2024-02-01 22:06:44,492 INFO Sending request to https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-complete 2024-02-01 22:06:44,823 INFO Request is queued 2024-02-01 23:13:34,739 INFO Request is completed 2024-02-01 23:13:34,739 INFO Downloading https://download-0016.copernicus-climate.eu/cache-compute-0016/cache/data4/adaptor.mars.external-1706800396.2392218-9882-14-77ff4c23-b955-4ad3-8531-f0e19a7ef648.grib to /disk/r059/tfchengac/flex_extract_github_dev/Run/Workspace/EA_temp/ANSH__SL.20220903.834135.834136.grb (3.7M) 0%| | 0.00/3.68M 2024-02-01 23:13:38,210 INFO Download rate 1.1M/s MARS retrieve done ... Prepare 20220903/to/20220903 ... index will be done ... index done Traceback (most recent call last): File ""/disk/r059/tfchengac/flex_extract_github_dev/Source/Python/submit.py"", line 272, in main() File ""/disk/r059/tfchengac/flex_extract_github_dev/Source/Python/submit.py"", line 110, in main prepare_flexpart(ppid, c) File ""/disk/r059/tfchengac/flex_extract_github_dev/Source/Python/Mods/prepare_flexpart.py"", line 161, in prepare_flexpart flexpart.deacc_fluxes(inputfiles, c) File ""/disk/r059/tfchengac/flex_extract_github_dev/Source/Python/Classes/EcFlexpart.py"", line 1009, in deacc_fluxes iid, index_vals = self._mk_index_values(c.inputdir, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/disk/r059/tfchengac/flex_extract_github_dev/Source/Python/Classes/EcFlexpart.py"", line 602, in _mk_index_values key_vals = codes_index_get(iid, key) ^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/disk/r059/tfchengac/anaconda3/lib/python3.11/site-packages/gribapi/gribapi.py"", line 2202, in grib_index_get result = grib_index_get_string(indexid, key) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/disk/r059/tfchengac/anaconda3/lib/python3.11/site-packages/gribapi/gribapi.py"", line 1482, in grib_index_get_string nval = grib_index_get_size(indexid, key) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/disk/r059/tfchengac/anaconda3/lib/python3.11/site-packages/gribapi/gribapi.py"", line 1433, in grib_index_get_size ih = get_index(indexid) ^^^^^^^^^^^^^^^^^^ File ""/disk/r059/tfchengac/anaconda3/lib/python3.11/site-packages/gribapi/gribapi.py"", line 184, in get_index return ffi.cast(""grib_index*"", indexid) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/disk/r059/tfchengac/anaconda3/lib/python3.11/site-packages/cffi/api.py"", line 300, in cast return self._backend.cast(cdecl, source) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: an integer is required }}}" fcheng 342 the cdo sinfo time of ERA5 is strange FP other Defect new 2023-11-28T20:57:16Z 2023-11-28T20:57:16Z "Hi, everyone, I download ERA5 data using the below code, i download for August,2022, i submite the job for 3 times, 1 for 0801-0810, 2 for 0811-0820, 3 for 0821-0831, {{{ START_DATE 20220817 END_DATE 20220825 DTIME 3 TYPE AN AN AN AN AN AN AN AN TIME 00 03 06 09 12 15 18 21 STEP 00 00 00 00 00 00 00 00 ACCTYPE FC ACCTIME 06/18 ACCMAXSTEP 12 CLASS EA STREAM OPER GRID 0.5 LEFT -179. LOWER -90. UPPER 90. RIGHT 180. LEVELIST 1/to/137 RESOL 159 ETA 1 CWC 1 PREFIX EA ECTRANS 1 FORMAT GRIB2 }}} when i checked the output using cdo sinfo, the result of EA22082218 is: {{{ Time coordinate : time : unlimited steps RefTime = 2022-08-22 18:00:00 Units = hours Calendar = proleptic_gregorian YYYY-MM-DD hh:mm:ss YYYY-MM-DD hh:mm:ss YYYY-MM-DD hh:mm:ss YYYY-MM-DD hh:mm:ss 2022-08-22 18:00:00 2022-08-20 03:00:00 2022-08-20 06:00:00 2022-08-20 09:00:00 2022-08-20 12:00:00 2022-08-20 15:00:00 2022-08-20 18:00:00 2022-08-20 21:00:00 }}} the time stamp with 2022-08-22 18:00:00 is acceptable, but other time stamp is strange. Why there exist the 2022-08-20 time stamp. " xu_ru 336 ERA5 flux data scaling at >1h temporal resolution flex_extract Support new 2023-04-20T06:14:59Z 2023-09-21T15:26:59Z "When downloading ERA5 data with flex_extract at lower than 1h resolution it seems that the flux data is scaled with a wrong time step. If i download the data with DTIME=6 to get 6 hourly output data the flux data is divided by DTIME instead of the correct 1h that is the actually accumulation time. At least if I understand the code correctly. This is the relevant section of the CONTROL file that I am using {{{ DTIME 6 TYPE AN AN AN AN TIME 00 06 12 18 STEP 00 00 00 00 }}} Maybe I have not understood the different parameters correctly yet. Thanks for your support! Best Tobias " terhardt 340 Deposition and particle reflection FP coding/compilation Support new 2023-06-21T12:10:43Z 2023-06-21T12:10:43Z "Referencing closed ticket #245 on particle reflection, we are simulating agricultural spray drift with FLEXPART-WRF. For large droplets (e.g. 2500 micrometers) with significant terminal velocity, most all of them should not reflect when they hit the ground or the vegetation canopy. We are releasing a distribution of small and large droplets at 0.5 m above the ground. The large droplets should all settle out in a few seconds close to the release point and very few if any should reflect back into the air. That aspect of reflection is simply not realistic for this application. We also note that there does not appear to be any deposition, perhaps given the settings we used. If the FLEXPART/FLEXPART-WRF physics are not really designed for this type application, we can choose alternate packages. We would also be curious if there are similar studies looking at this application." jmanobianco 339 Segmentation fault FP other Defect new 2023-06-14T06:03:38Z 2023-06-15T02:14:46Z "Hello, My flex_extract has terminated during running calc_etadot: {{{ /work09/am/flex_extract/Source/Python $ ./submit.py --start_date 20220619 --controlfile CONTROL_EA5_202206 --public=1 Retrieving ECMWF data! start date 20220619 end date 20220619 Using ECMWF WebAPI: False Using CDS API: True ... removing old files in /work09/am/flex_extract/Run/Workspace ... retrieve 20220618/to/20220620 in dir /work09/am/flex_extract/Run/Workspace ........... Inputfile: /work09/am/flex_extract/Run/Workspace/ANOG__ML.20220619.262134.290194.grb Inputfile: /work09/am/flex_extract/Run/Workspace/ANOG__SL.20220619.262134.290194.grb Inputfile: /work09/am/flex_extract/Run/Workspace/ANSH__SL.20220619.262134.290194.grb ... index done current product: ('20220619', '0', '0') Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F84B73B06D7 #1 0x7F84B73B0D1E #2 0x7F84B64693FF #3 0x7F84B6581630 #4 0x7F84B7491D3A #5 0x403725 in __rwgrib2_MOD_readlatlon #6 0x405134 in MAIN__ at calc_etadot.f90:? ... ERROR CODE: -11 ... ERROR MESSAGE: Command '['/work09/am/flex_extract/Source/Fortran/calc_etadot']' died with . ... FORTRAN PROGRAM FAILED! }}} Do I have to modifiy the array sizes somewhere in the source files? I have compiled flex_extract v7.1.3, following the instruction described in https://www.flexpart.eu/ticket/297 . Thank you." amanda 338 FLEXPART failing on eccodes v2.30.0 FP other Defect new 2023-06-12T07:34:39Z 2023-06-12T07:34:39Z "When using eccodes v2.30.0, FLEXPART fails with the following output: {{{ Welcome to FLEXPART Version 10.4 (2019-11-12) FLEXPART is free software released under the GNU General Public License. ---------------- INFORMATION: SUBGRIDSCALE TERRAIN EFFECT IS NOT PARAMETERIZED DURING THIS SIMULATION. ---------------- ECMWF metdata detected ECCODES ERROR : Cannot unpack as pv ECCODES ERROR : Hint: Try unpacking as double ECCODES ERROR : gridcheck: Error reading grib file Function not yet implemented }}} When I try with v2.27.1, everything works properly." tcarion 334 Error when downloading 2023 ERA5 data with dev branch of flex_extract flex_extract Defect new 2023-04-04T14:42:01Z 2023-06-08T08:07:46Z "Hi all, I tried to download ERA5 data for January 2023 using dev branch of flex_extract : {{{ git clone https://www.flexpart.eu/gitmob/flex_extract cd flex_extract git checkout dev }}} and I have this error : {{{ marsclass: EA dataset: None type: AN levtype: ML levelist: 90/to/137 repres: date: 20230111/to/20230111 resol: 255 stream: OPER area: -10.125/0.0/-70.3125/100.125 time: 00/01/02/03/04/05/06/07/08/09/10/11/12/13/14/15/16/17/18/19/20/21/22/23 step: 00 expver: 1 number: OFF accuracy: 24 grid: 0.28125/0.28125 gaussian: target: /home/piaj/03_workdir/2F_devel_FLEXPART/test_flex_extract/flex_extract/Run/Workspace/EA5_MAPIO_20230111_20230116/ANOG__ML.20230111.12834.12835.grb param: 130.128/133.128/131.128/132.128/077.128/246.128/247.128 target: /home/piaj/03_workdir/2F_devel_FLEXPART/test_flex_extract/flex_extract/Run/Workspace/EA5_MAPIO_20230111_20230116/ANOG__ML.20230111.12834.12835.grb RETRIEVE ERA5 WITH CDS API! 2023-04-04 16:18:57,268 INFO Welcome to the CDS 2023-04-04 16:18:57,268 INFO Sending request to https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-complete 2023-04-04 16:18:57,306 INFO Request is queued ll 2023-04-04 16:21:48,674 INFO Request is running 2023-04-04 16:25:15,525 INFO Request is failed 2023-04-04 16:25:15,525 ERROR Message: the request you have submitted is not valid 2023-04-04 16:25:15,525 ERROR Reason: Last error is -43; Expected 8064, got 5760.; Request failed; Some errors reported (last error -1) 2023-04-04 16:25:15,525 ERROR Traceback (most recent call last): 2023-04-04 16:25:15,525 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/cdshandlers/services/handler.py"", line 59, in handle_request 2023-04-04 16:25:15,525 ERROR result = cached(context.method, proc, context, context.args, context.kwargs) 2023-04-04 16:25:15,525 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/caching.py"", line 108, in cached 2023-04-04 16:25:15,525 ERROR result = proc(context, *context.args, **context.kwargs) 2023-04-04 16:25:15,525 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/services.py"", line 124, in __call__ 2023-04-04 16:25:15,525 ERROR return p(*args, **kwargs) 2023-04-04 16:25:15,525 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/services.py"", line 60, in __call__ 2023-04-04 16:25:15,526 ERROR return self.proc(context, *args, **kwargs) 2023-04-04 16:25:15,526 ERROR File ""/home/cds/cdsservices/services/mars/mars.py"", line 53, in external 2023-04-04 16:25:15,526 ERROR return mars(context, request, **kwargs) 2023-04-04 16:25:15,526 ERROR File ""/home/cds/cdsservices/services/mars/mars.py"", line 20, in mars 2023-04-04 16:25:15,526 ERROR execute_mars(context, requests, info) 2023-04-04 16:25:15,526 ERROR File ""/home/cds/cdsservices/services/mars/execute_mars.py"", line 20, in execute_mars 2023-04-04 16:25:15,526 ERROR exception=MarsException) 2023-04-04 16:25:15,526 ERROR File ""/opt/cdstoolbox/cdscompute/cdscompute/context.py"", line 209, in run_command 2023-04-04 16:25:15,526 ERROR raise exception(call, proc.returncode, output) 2023-04-04 16:25:15,526 ERROR home.cds.cdsservices.services.mars.__init__.py.exceptions.MarsException: Last error is -43; Expected 8064, got 5760.; Request failed; Some errors reported (last error -1) }}} Previous extractions for OG_OROLSM_SL.20230111.12834.12835.grb and FCOG_acc_SL.20230110.12834.12835.grb are ok. It's only for the model levels that the extraction crashes ... Is the flex_extract tool is not yet adapted for recent (2023) ERA5 data ? I managed to retrieve the ERA5 data for this date using a classic CDS API query successfully. Thanks in advance for your help. " jpianezze 337 flex_extract7.1.2 download ERA5 (20220701-20220705) parameter 77 (etadoc) is missing flex_extract Support new 2023-05-24T06:46:17Z 2023-06-06T08:36:00Z "Hi,everyone I use flex_extract7.1.2 to download ERA5 (20220701-20220705), the error appears as ""parameter 77 is missing,most likely it is not available for this type or date/time, check parameters CLASS, TYPE, STREAM,START_DATE.fort.21 is empty while parameter eta is set to 1 in CONTROL file"", but my code work well if i only download data at 20220701, when i extend my date to 20230705, it report an error. " xu_ru 232 Warnings about undefined GRiB2 messages FP input data Defect anphi accepted 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 292 Problem reading TKE_PBL - Flexpart-WRF FP input data Support new 2020-12-17T08:33:16Z 2023-04-17T15:45:18Z "Dear all, I have been running flexwrf_v3.3.2 for a few weeks. It was running successfully with the attached file flexwrf.input.forward.test2.notke with : TURB_OPTION = 0 (no turbulence) But when I set TURB_OPTION = 2 (or 3) in flexwrf.input.forward.test2, I get the following error message : {{{ file = /ccc/scratch/cont002/dam/polinebr/flexpart-wrf_brune/Wrfdata_test2/wrfout_d02_2020-11-25_00.nc NO TKE_PBL available. Try QKE instead NO TKE_PBL available. Try QKE instead read_ncwrfout_1realfield -- var lendim mismatch for TKE_PBL 3 32 33 }}} I don’t understand why it can’t find TKE_PBL since there is this variable set in my wrfout file. I have check in the file readwind.f90 and read_ncwrfout.f90 for answers but it looks like it might be a problem reading TKE_PBL. I have attached : - flexwrf.input.forward.test2 (input file) - log.test2 (with the error message at the end) Thank you in advance! Brune. " bpoline 333 CDS download for ERA5 sdor,cvh,cvl,fsor sometimes fails flex_extract Defect anphi accepted 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 315 flex_extract templates with reduced level number flex_extract New feature anphi accepted 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 313 No flux file for the second member with ENDA ERA5 data flex_extract Defect anphi accepted 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 311 flex_extract 7.1.2 local extraction no flux data flex_extract Defect anphi accepted 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 298 Running preprocessing with previously loaded grib files flex_extract Support anphi accepted 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 328 GRIB2 CONVERSION FAILED! error in flex_extract flex_extract Defect anphi accepted 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 270 readreceptors.f90: bug in namelist version FP coding/compilation Defect pesei accepted 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 330 error in flex_extract-7.1.3 flex_extract Defect anphi accepted 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 269 Compilation without netCDF not properly implemented, grib_api -> eccodes FP coding/compilation Defect pesei accepted 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 119 random numbers with fixed seeds in convective scheme FP physics/numerics Defect igpis assigned 2015-05-07T18:07:00Z 2023-03-29T16:28:56Z "In subroutine redist_kf() there are many calls to the random number generator function ran3(). Most of these calls, however, are made using a fixed seed to ran3, which means you always get the same answer back. For instance, the code below is around line 126. It clearly says it is choosing a random position within the cloud, but the number is drawn as rn=ran3(88)... and the result is compared with the threshold ""if (rn.le.fmix) then...."". By the way it is written it is definitely not random. Moreover, the code for the ran3() function, inside of the file random.f90 does not look ok. Parameters are not defined with clear intent(in) or intent(out) declarations, and optional arguments are not identified. Hence, what the function will do when called with just 1 parameter, is compiler dependent (other parameters are automatically saved between calls? what about the call order from different computing nodes??)! I also don't know why redist_kf() calls the random number generator directly, since a pile of random number are pre-generated by the MPI_ID==0 processor once the program starts. If each MPI node calls independently the random number generator, the result will depend on how fast the code runs in each node (order of calls to ran3() among all nodes). I don't know how to fix this, but it seems to be a serious bug in the code. Best regards, Henrique ========= Sample code, redist_kf.f90, around line 126. ! Simply mix all particles by assigning a random position within cloud ! In this case, backward run is not wroking since this reposition process is not ! reversible. IF (mix_option .eq. well_mix) then ! Well-mixed !! only consider updraft (usually >> downdraft flux) !! Choose a random # evenly distributed in [0,1] rn=ran3(88) if (rn .le. fmix) then ! inside cloud write(*,*)'well mixed, fmix=,rn=',fmix,rn ! --|-- umfzf(j), zf(j) ! --|X- rn2 (particle position) ! --|-- umfzf(j-1),zf(j-1) rn2=ran3(881) " hbarbosa 222 Richardson Failure - Flexpart WRF 3.3 FP input data Support igpis assigned 2019-01-09T11:05:43Z 2023-03-29T16:26:15Z "Dear all, I'm trying to run flexpart-wrf-3.3 on LINUX (INTEL) but sometime I try running it, it crashes with ""richardson failure"". There is a crash in richardson.f90 due to calcpar - richardson failure - ix,jy= 82 148. #171 shows this is caused by using time-integrated output in WRF and starting the FLEXPART simulation so that the first WRF output is ingested. Obviously, time-integrated winds can't be defined in this first output. Here are some options: 20140727 050000 YYYYMMDD HHMISS beginning date of simulation 20140731 050000 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 216 how to know endpoint of each released particle FP input data Defect igpis assigned 2018-11-27T01:41:10Z 2023-03-29T16:23:11Z "Hi I am using Flexpart-WRF to simulate the trajectory of seed dispersion. So I want to know the trajectory of each seed released and their deposition position for each particles. so I have two questions: 1 In order to draw th trajectory of each seed released, is there any way that I can have the ID number for each particles I released so I can match them through different files of hourly dumped particles? 2 Is there any way that I can have the end point for each particle I released includes the ones that I lost before the simulation finished. Thank you for addressing the possiblities and modifications on subrountines regarding to these two questions. Best regards, Iris " ZhenhuaHao 242 richardson not working -- bad h FP coding/compilation Defect igpis assigned 2019-06-24T23:01:41Z 2023-03-29T16:21:22Z "I'm using FLEXPART-WRF_v3.3.2 with input data obtained from WRF-ARW. I keep getting the following error: richardson not working -- bad h = -2.87909937 where the negative h usually varies a bit. After this the programs aborts. I delved into the code and found out that this is due to FLEXPART getting a negative value for the Boundary layer height. How can Flexpart think that h is negative? what can be the source of this problem? As a workaround, I chose SFC_OPTION = 1 but then I got {{{ #### FLEXPART MODEL ERROR! SFC_OPTION = 1 }}} I went into the code again and find out that this option aborts the program since SFC_OPTION = 1 is no longer supported: {{{ write(*,*) ' #### Reading from WRF no longer supported.' write(*,*) ' #### ---------------------------------' }}} I modified the code so that it will not abort, but im wondering why this option is no longer supported" daliaga 271 SFC_OPTION = 1 not working FP input data Support pesei accepted 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 307 Flexpart-WRF crashes due to array boundary violation in outgrid_init_reg.f90 FP coding/compilation Defect pesei accepted 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 327 Incorrect output in header for variable ReleaseZstart_end FP other Defect new 2023-02-14T10:37:15Z 2023-02-14T10:37:15Z "I use FLEXPART-WRF in backward mode. I used releases that have different values for `ZPOINT1` and `ZPOINT2`. In the header_d01.nc however, both are saved to be the same value (both the value of `ZPOINT1`). To be sure that it is no problem with my input file, I tested the same configuration with equal values for `ZPOINT1` and `ZPOINT2` as they got saved to the header file. The results where different, so I recon the simulation runs correctly but the information of `ZPOINT2` is not correctly saved into the header file." cluekenwinkels 297 gridcheck_ecmwf.f90: fix of small bug and improvements FP coding/compilation Defect anphi accepted 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 326 error: STOP READWIND: NUVZ NOT CONSISTENT FP other Defect new 2023-02-02T10:19:19Z 2023-02-02T10:19:19Z "This error occurred when the simulation was about to finish as follow: ... Global NCEP fields: using cloud water 1209600 Seconds simulated: 93368 0 Particles: Uncertainty: 0.000 0.000 0.000 1216800 Seconds simulated: 939236 Particles: Uncertainty: 0.000 0.000 0.000 1224000 Seconds simulated: 944791 Particles: Uncertainty: 0.000 0.000 0.000 Global NCEP fields: using cloud water 1231200 Seconds simulated: 950347 Particles: Uncertainty: 0.000 0.000 0.000 1238400 Seconds simulated: 955902 Particles: Uncertainty: 0.000 0.000 0.000 1245600 Seconds simulated: 961458 Particles: Uncertainty: 0.000 0.000 0.000 Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP READWIND: NUVZ NOT CONSISTENT When the particle numbers was 1000000 it stopped at 961458; it stops at 96146 when the particle number was 100000. According to par_mod.f90, the variable nuvzmax is the maximum dimension of (u,v) wind fields in z direction (for fields on eta levels). I don't know if it's due to incorrect setup. It's not a serious problem because the results before stop were ""OK"" to use, but I wonder how to solve it. The simulations were using necp fnl files from 20220101 to 20220115. Thank you so much." hshen 305 FLEXTRA fails with NCEP GFS data after 2021-03-22 FLEXTRA Defect pesei accepted 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 325 Flexpart v10.4 test cases run FP input data Enhancement new 2023-01-10T10:36:30Z 2023-01-31T08:23:14Z "Hello, I have started FLEXPART recently on Ubuntu18.04LTS(WSL2). First of all, I use flex_extract v7.1.2 to download the input data. As a local public user, I could successfully get EA~ data. I made AVAILABLE file and didn't modify other files in the directory options. Then I tried to run example files in the folder tests/examples (section 7 of Pisso et al. (2019)) and received an error message discussed in #279. I modified parameters in par_mod.f90 and recompile. However, I'm now receiving another error message as following together with many warning messages stated in #303(WARNING: undefined GRIB2 message found!). {{{ Mother domain: Longitude range: -24.00000 to 60.37500 Grid distance: 0.28125 Latitude range : 9.87500 to 74.00000 Grid distance: 0.28125 -25.0000000 10.0000000 60.3750000 74.0000000 -24.0000000 9.87500000 60.0000000 75.0000000 1.00000000 1.00000000 #### FLEXPART MODEL ERROR! PART OF OUTPUT #### #### GRID IS OUTSIDE MODEL DOMAIN. CHANGE #### #### FILE OUTGRID IN DIRECTORY #### ./options_1-1_1/ }}} I would appreciate it if someone tells me how to resolve this issue. I guess I have to modify OUTGRID and other parameters of par_mod.f90. I would also like to know how to find the correct values that match the resolution of wind fields. Thanks." myoshimura 323 Wrong scaling of snow depth and convective precip when reading ECMWF input in GRIB2 FP input data Defect new 2022-11-04T15:40:51Z 2022-11-04T15:40:51Z "Flexpart expects precipitation in mm/h and snow depth in m water equivalent. This is the same for GRIB1 and GRIB2. For GRIB2 however, when the input field is SD or CP, the conversion_factor=1000. is set in readwind_ecmwf.f90. Later in this subroutine, the values of the SD and CP fields read from GRIB2 are divided by conversion_factor, i.e. by 1000. This seems to be wrong, as flex_extract outputs precipitation in mm/h, which is what flexpart expects according to com_mod.f90 and get_wetscav.f90. SD is in m, as expected by flexpart according to getvdep.f90. In both cases no conversion is needed in flexpart." pirmink 321 UNKNOWN METDATA FORMAT error while using NCEP data FP other Defect new 2022-09-16T08:28:01Z 2022-10-18T14:37:55Z "I am using NCEP wind fields(from [http://rda.ucar.edu/datasets/ds093.0/]) to run flexpartv10.4. However, the model is unable to detect the metdata format. The model works fine with ECMWF fields. Any help is appreciated. thanks" sannadate 322 Problem with backward simulation FP coding/compilation Support new 2022-10-07T12:12:39Z 2022-10-07T12:12:39Z "Dear community I am trying to run a backward simulation with FLEXPART-WRF. I have changed the LDIRECT to -1. Even though the simulations terminates successfully without any errors, the tracer released is nowhere to be found in the output files. I was wondering if you could think of what I might be doing wrong. Thank you " dmantsis 318 reading receptor output FP post-processing New feature pesei accepted 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 317 Correct OH reaction coefficients for SO2, CO FP other Enhancement new 2022-06-16T18:30:40Z 2022-06-17T15:16:07Z "I note first that I am actually using the dev branch, but I think this is the same in Flexpart V10.x Currently, the amounts of SO2 and CO in Flexpart do not decay via reaction with OH. This is because the variables POHCCONST and POHDCONST in the files SPECIES_xxx are set to a negative value. The user cannot turn on the reaction with OH just by removing the - signs because the absolute values are placeholders, used for all species where reaction with OH is not enabled. (If you cluelessly remove the - signs for SO2, it decays far too fast.) I would be very grateful if someone could supply me with the correct values for POHCCONST, POHDCONST and POHNCONST for SO2 (and, less urgently, CO). The ideal thing would be for the correct values to go into the SPECIES_xxx files supplied with Flexpart. But I would be happy for now to get the values as a reply in this ticket --- I can easily put them into SPECIES_xxx myself. (This would also leave the values where a person searching the web could find them.) If no-one knows the right values and I manage to dig suitable ones out of the literature I shall add them to this ticket." hcpxvi 122 Improve MQUASILAG option FP physics/numerics Enhancement pesei accepted 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 316 Post-processing issue: Negative deposition values FP physics/numerics Defect new 2022-02-25T14:43:06Z 2022-03-15T11:26:36Z "I am experiencing an issue with my FLEXPART outputs (using the NetCDF format) that I noticed when trying to analyze it with Python. I am trying to run two species with two sepearate releases in forward mode, for 1 month but single species are causing the same issue. Some of the wet and dry depositions are showing up as negative values, very small negative values but negative nonetheless. I have tried changing the settings in the different key user files like particle number released, grid size, species files etc but nothing changes the outcome. The only time I am not getting negative values is when the settling velocity is disable. I looked at the data in the netcdf files in ncview as well which shows the same outcome so it seems to be flexpart related. I would appreciate any insight to what could be causing this. Thanks! Julia " jshafer 56 Parameter numbers in GRIB1/GRIB2 FP input data Task anphi accepted 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 312 EMOSLIB to disappear on new HPC in Bologna flex_extract Task anphi accepted 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 301 Bug in flex_extract due to python3 upgrade at ECMWF ecgate env flex_extract Defect anphi accepted 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 286 Bug for local public ERA5 data / flex_extract v7.1.2 flex_extract Defect anphi accepted 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 310 EMPTY LINES in the AVAILABLE file FP other Defect new 2021-12-17T14:25:42Z 2021-12-17T14:25:42Z "After spending some time trying to find out why Flexpart gave me a FLEXPART WARNING: NO WIND FIELDS ARE AVAILABLE. A TRAJECTORY HAS TO BE TERMINATED. STOP NO METEO FIELDS AVAILABLE, I realized it was because first two lines of my AVAILABLE file were missing: XXXXXX EMPTY LINES XXXXXXXXX XXXXXX EMPTY LINES XXXXXXXX Would that be possible to make them not required anymore for the next version? Thank you in advance" tcarion 309 "something wrong Matlab read the output ""header"" from FLEXPART10.4" FP post-processing Defect new 2021-11-19T14:40:50Z 2021-11-19T14:40:50Z "After finished the backward run from FLEXPART 10.4,I used this code from: '''Matlab functions to read FLEXPART gridded output and concentrations (S. Eckhardt, H. Sodemann, S. Raja) http://zardoz.nilu.no/~sabine/matlab4FLEXPART.tar.gz''',the function: flex_header.m to read the header file. My code as followed: ########################################### {{{ %% beginning clear all; clc; pathname = 'C:\Users\dell\Desktop\matlab4FLEXPART\'; % anonymous helper function to skip some bytes skip = @(fid) fread(fid,2,'int32'); nest=0; readp=1; % default: do not read release points calcarea=0; % datespath=pathname; header.path=pathname; fhd=fopen([header.path 'header']); %fprintf('\nreading header'); header.nest=0; %% % default settings header.decayconstant=0; % start reading if header was opened if fhd~=-1 rl=fread(fhd,1,'int32'); header.open=1; header.ibdate=fread(fhd,1,'int32'); header.ibtime=fread(fhd,1,'int32'); pivot_vec=(datevec(date)); header.simulationstart=datenum([num2str(header.ibdate) num2str(header.ibtime,'%06d')],'yyyymmddhhMMss'); header.ver=char(transpose(fread(fhd,13,'char'))); %% skip(fhd); header.loutstep=fread(fhd,1,'int32'); header.loutaver=fread(fhd,1,'int32'); header.loutsample=fread(fhd,1,'int32'); skip(fhd); header.outlon0=fread(fhd,1,'float'); header.outlat0=fread(fhd,1,'float'); header.numxgrid=fread(fhd,1,'int32'); header.numygrid=fread(fhd,1,'int32'); header.dxout=fread(fhd,1,'float'); header.dyout=fread(fhd,1,'float',8); header.numzgrid=fread(fhd,1,'int32'); header.outheight=fread(fhd,header.numzgrid,'float'); header.outheight=cat(1,[0],header.outheight); skip(fhd); header.jjjjmmdd=fread(fhd,1,'int32'); header.hhmmss=fread(fhd,1,'int32',8); header.nspec=fread(fhd,1,'int32')/3; end %% }}} ################################################### Here is my COMMAND file {{{ *************************************************************************************************************** * * * Input file for the Lagrangian particle dispersion model FLEXPART * * Please select your options * * * *************************************************************************************************************** &COMMAND LDIRECT= -1, ! Simulation direction in time ; 1 (forward) or -1 (backward) IBDATE= 20120101, ! Start date of the simulation ; YYYYMMDD: YYYY=year, MM=month, DD=day IBTIME= 000000, ! Start time of the simulation ; HHMISS: HH=hours, MI=min, SS=sec; UTC IEDATE= 20120101, ! End date of the simulation ; same format as IBDATE IETIME= 230000, ! End time of the simulation ; same format as IBTIME LOUTSTEP= 3600, ! Interval of model output; average concentrations calculated every LOUTSTEP (s) LOUTAVER= 3600, ! Interval of output averaging (s) LOUTSAMPLE= 900, ! Interval of output sampling (s), higher stat. accuracy with shorter intervals ITSPLIT= 99999999, ! Interval of particle splitting (s) LSYNCTIME= 900, ! All processes are synchronized to this time interval (s) CTL= -5.0000000, ! CTL>1, ABL time step = (Lagrangian timescale (TL))/CTL, uses LSYNCTIME if CTL<0 IFINE= 4, ! Reduction for time step in vertical transport, used only if CTL>1 IOUT= 5, ! Output type: [1]mass 2]pptv 3]1&2 4]plume 5]1&4, +8 for NetCDF output IPOUT= 1, ! Particle position output: 0]no 1]every output 2]only at end 3]time averaged LSUBGRID= 1, ! Increase of ABL heights due to sub-grid scale orographic variations;[0]off 1]on LCONVECTION= 1, ! Switch for convection parameterization;0]off [1]on LAGESPECTRA= 0, ! Switch for calculation of age spectra (needs AGECLASSES);[0]off 1]on IPIN= 0, ! Warm start from particle dump (needs previous partposit_end file); [0]no 1]yes IOUTPUTFOREACHRELEASE= 1, ! Separate output fields for each location in the RELEASE file; [0]no 1]yes IFLUX= 0, ! Output of mass fluxes through output grid box boundaries MDOMAINFILL= 0, ! Switch for domain-filling, if limited-area particles generated at boundary IND_SOURCE= 2, ! Unit to be used at the source ; [1]mass 2]mass mixing ratio IND_RECEPTOR= 2, ! Unit to be used at the receptor; [1]mass 2]mass mixing ratio 3]wet depo. 4]dry depo. MQUASILAG= 0, ! Quasi-Lagrangian mode to track individual numbered particles NESTED_OUTPUT= 0, ! Output also for a nested domain LINIT_COND= 0, ! Output sensitivity to initial conditions (bkw mode only) [0]off 1]conc 2]mmr SURF_ONLY= 0, ! Output only for the lowest model layer, used w/ LINIT_COND=1 or 2 CBLFLAG= 0, ! Skewed, not Gaussian turbulence in the convective ABL, need large CTL and IFINE OHFIELDS_PATH= ""../../flexin/"", ! Default path for OH file / }}} ################################################# Here is my RELEASE file {{{ *************************************************************************************************************** * * * * * * * Input file for the Lagrangian particle dispersion model FLEXPART * * Please select your options * * * * * * * *************************************************************************************************************** &RELEASES_CTRL NSPEC = 1, ! Total number of species SPECNUM_REL= 22, ! Species numbers in directory SPECIES / &RELEASE ! For each release IDATE1 = 20120101, ! Release start date, YYYYMMDD: YYYY=year, MM=month, DD=day ITIME1 = 000000, ! Release start time in UTC HHMISS: HH hours, MI=minutes, SS=seconds IDATE2 = 20120101, ! Release end date, same as IDATE1 ITIME2 = 230000, ! Release end time, same as ITIME1 LON1 = 126.542, ! Left longitude of release box -180 < LON1 <180 LON2 = 126.542, ! Right longitude of release box, same as LON1 LAT1 = 45.755, ! Lower latitude of release box, -90 < LAT1 < 90 LAT2 = 45.755, ! Upper latitude of release box same format as LAT1 Z1 = 0, ! Lower height of release box meters/hPa above reference level Z2 = 50.000, ! Upper height of release box meters/hPa above reference level ZKIND = 1, ! Reference level 1=above ground, 2=above sea level, 3 for pressure in hPa MASS = 1.0000E0, ! Total mass emitted, only relevant for fwd simulations PARTS = 10000, ! Total number of particles to be released COMMENT = ""RELEASE 1"", ! Comment, written in the outputfile / &RELEASE ! For each release IDATE1 = 20120101, ! Release start date, YYYYMMDD: YYYY=year, MM=month, DD=day ITIME1 = 000000, ! Release start time in UTC HHMISS: HH hours, MI=minutes, SS=seconds IDATE2 = 20120101, ! Release end date, same as IDATE1 ITIME2 = 230000, ! Release end time, same as ITIME1 LON1 = 126.561, ! Left longitude of release box -180 < LON1 <180 LON2 = 126.561, ! Right longitude of release box, same as LON1 LAT1 = 45.8167, ! Lower latitude of release box, -90 < LAT1 < 90 LAT2 = 45.8167, ! Upper latitude of release box same format as LAT1 Z1 = 0, ! Lower height of release box meters/hPa above reference level Z2 = 50.000, ! Upper height of release box meters/hPa above reference level ZKIND = 1, ! Reference level 1=above ground, 2=above sea level, 3 for pressure in hPa MASS = 1.0000E0, ! Total mass emitted, only relevant for fwd simulations PARTS = 10000, ! Total number of particles to be released COMMENT = ""RELEASE 2"", ! Comment, written in the outputfile / &RELEASE ! For each release IDATE1 = 20120101, ! Release start date, YYYYMMDD: YYYY=year, MM=month, DD=day ITIME1 = 000000, ! Release start time in UTC HHMISS: HH hours, MI=minutes, SS=seconds IDATE2 = 20120101, ! Release end date, same as IDATE1 ITIME2 = 230000, ! Release end time, same as ITIME1 LON1 = 126.979, ! Left longitude of release box -180 < LON1 <180 LON2 = 126.979, ! Right longitude of release box, same as LON1 LAT1 = 45.5422, ! Lower latitude of release box, -90 < LAT1 < 90 LAT2 = 45.5422, ! Upper latitude of release box same format as LAT1 Z1 = 0, ! Lower height of release box meters/hPa above reference level Z2 = 50.000, ! Upper height of release box meters/hPa above reference level ZKIND = 1, ! Reference level 1=above ground, 2=above sea level, 3 for pressure in hPa MASS = 1.0000E0, ! Total mass emitted, only relevant for fwd simulations PARTS = 10000, ! Total number of particles to be released COMMENT = ""RELEASE 3"", ! Comment, written in the outputfile / }}} ##################### Here is my header_txt file {{{ # ibdate,ibtime, iedate, ietime, flexversion 20120101 0 20120101 230000 Version 10.4 (2019-11-12) # interval, averaging time, sampling time -3600 -3600 -900 # information on grid setup #outlon0,outlat0,numxgrid,numygrid,dxout,dyout 110.000000 40.0000000 200 200 0.100000001 0.100000001 # numzgrid, outheight(.) 5 10.0000000 100.000000 500.000000 1000.00000 2000.00000 # jjjjmmdd,ihmmss 20120101 230000 # information on species # 3*nspec,maxpointspec_act 3 3 # for nspec: # 1, WD_ # 1, DD_ # numzgrid,species 1 WD_CO 1 DD_CO 5 CO # information on model switches # method,lsubgrid,lconvection, ind_source,ind_receptor 0 1 1 2 2 # information on age class 1 999999999 }}} ################################### Problem: Actually, after Matlab read this header file, header.loutstep should be ""-3600"", but the header strcture in matlab: header.loutstep = 691155245. header.loutaver should be ""-3600"", but the header strcture in matlab: header.loutaver = 538976288 header.loutsample should be ""-900"", but the header strcture in matlab: header.loutsample = 538976288 header.outlon0 shoule be ""110.0000"", but the header strcture is matlab: header.outlon0 = 1.3563e-19. What's more, header.outlat0, header.numxgrid, header.numygrid, header.dxout, header.dyout ... the values are wrong!!! header.jjjjmmdd, header.hhmmss, header.nspec, header.numpointspec in matlab structure is NULL. I wonder where is wrong when I used the matlab code read the header file values??? " zhangxun 308 FLEXPART-WRF: Sorry t not in [K] FP other Defect new 2021-09-07T07:21:07Z 2021-09-07T07:21:07Z "Hello everyone, I am trying to run FLEXPART-WRF backwards, using wrfout files at 100km resolution, with 200 by 200 points. Initially, I was getting an error link to the number of wind grids in y-direction. I modified the par_mod.f90 file and more specifically I increased the number of dimensions (nymax). Since then I am getting an error ""Sorry t not in [K]"". I found this error message in the ew.f90 function, which is being called, if I am not mistaken, in some of the read modules. After some digging, I found in readwind.f90 that the model reads some parameters from wrfout files. The error occurs because the subroutine is reading more grids than actually exist in wrfout file for temperature (if I got it right). I tried to force it to read less grid points but I am still getting the same error. I am not sure I am looking in the right place to fix this error. For me it could also be an interpolation error, so I could adjust the time step but I am not sure If that is possible in FLEXPART-WRF. I doubled-check the wrfout files for any problematic wind, but all the parameters look correct. Has any of you have ever come across this error? How did you solve it? Any ideas are more than welcome. Thank you, Lefteris PS: I run FLEXPART-WRF at 20km using 86 by 86 points without any error." lioannidis 306 FLEXPART_MPI does not work properly with mquasilag=1 FP coding/compilation Enhancement espen assigned 2021-08-02T21:11:02Z 2021-08-06T08:57:57Z Quasi-Lagrangian output (mquasilag=1) is not implemented in the parallel version of FLEXPART v10.4. espen 304 INSTALLDIR not passed to the installation flex_extract Defect anphi accepted 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 302 Create flex_extract_precip flex_extract New feature anphi accepted 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 266 FIX: Remove flex_extract v7.1 from ECMWF server before new installation flex_extract Task anphi accepted 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 226 flex_extract WRF data flex_extract New feature anphi accepted 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 296 "Compiling fails on Mac OS 10.15 with ""unable to execute command: Illegal instruction"" error" FP coding/compilation Defect mduetsch accepted 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 140 vertransform.f90 occasionally fails to initialize FP other Defect pesei accepted 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 294 domain filling runs output for each release is forbidden FP input data Support new 2021-01-07T03:29:03Z 2021-01-12T06:35:45Z "Hi, everyone, i run a case using FLEXPART10.4 backward simulation during 200701-200710,i set the domain filling is 0, i run success. When i change domain filling to 1, the error: domain filling runs output for each release is forbidden? Is there anyone know how to solve it. I attach my COMMAND file for your reference." xu_ru 295 New interpolation scheme for precipitation FP physics/numerics New feature anphi accepted 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 31 Wet deposition - problems with in-cloud/below-cloud scheme FP physics/numerics Defect pesei accepted 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 293 FLEXPART-WRF takes wrong OUTGRID information FP other Defect new 2020-12-18T13:00:54Z 2021-01-07T12:56:41Z "Dear all, I am trying to run Flexpart-WRF v3.3.2 with two nested domains over a regional domain. My nested domain is having a resolution of **0.08^o^** lon x **0.09^o^** lat(which are supplied into the 'OUTGRID_NEST' section of the flexwrf.input file). But the model is not taking into account this resolution and instead it is taking the higher values(**0.275^o^ x 0.237^o^**) from the section 'FORMER OUTGRID FILE'. So the model is giving wrong grids in the output of nested run. My nested domain values for WRF output(Flexwrf input) are: minimum latitude: 26.41 ; maximum latitude: 30.94 minimum longitude: 74.49 ; maximum longitude: 79.65 With resolution: 0.08^o^ x 0.09^o^ But the nested domain values which I am getting from the Flexwrf output is : minimum latitude: 26.52 ; maximum latitude: **39.80** minimum longitude: 74.62 ; maximum longitude: **90.02** The larger values for max lat and max lon are due to the resolution: 0.275^o^ x 0.237^o^ which the model is taking from the mother domain. My values for the namelist are: =====================FORMER OUTGRID FILE===================== 70.26 OUTLONLEFT geograhical longitude of lower left corner of output grid 22.73 OUTLATLOWER geographical latitude of lower left corner of output grid 49 NUMXGRID number of grid points in x direction (= # of cells ) 49 NUMYGRID number of grid points in y direction (= # of cells ) 0 OUTGRIDDEF outgrid defined 0=using grid distance, 1=upperright corner coordinate **0.275** DXOUTLON grid distance in x direction or upper right corner of output grid **0.237** DYOUTLON grid distance in y direction or upper right corner of output grid 2 NUMZGRID number of vertical levels 100.0 LEVEL height of level (upper boundary) 20000.0 LEVEL height of level (upper boundary) ================OUTGRID_NEST========================== 74.49 OUTLONLEFT geograhical longitude of lower left corner of output grid 26.41 OUTLATLOWER geographical latitude of lower left corner of output grid 57 NUMXGRID number of grid points in x direction (= # of cells ) 57 NUMYGRID number of grid points in y direction (= # of cells ) 0 OUTGRIDDEF outgrid defined 0=using grid distance, 1=upperright corner coordinate **0.08** DXOUTLON grid distance in x direction or upper right corner of output grid **0.09** DYOUTLON grid distance in y direction or upper right corner of output grid Any help for a work around will be highly useful. Thanking in advance. Header files from the Flexwrf output, flexwrf.input file and wrf output are attached" srakesh 134 Issue using *.grb and *.grib2 FP input data Defect anphi accepted 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 281 problem with caldate FP other Enhancement pesei accepted 2020-07-22T18:16:02Z 2020-11-11T11:53:18Z "was reported for FLEXTRA, see #280 should be fixed in FLEXPART as well" pesei 50 FLEXPART can crash with some GFS data FP coding/compilation Enhancement jbrioude accepted 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 205 Output format for trajectories.txt FP post-processing Defect pesei accepted 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 214 global OUTGRID is rejected FP coding/compilation Defect pesei accepted 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 204 namelist input for RELEASES needs more checking FP coding/compilation Defect pesei accepted 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 282 Eliminate code duplications FP other Enhancement new 2020-08-21T18:49:06Z 2020-08-21T18:50:30Z There are several instances of duplicated code (e.g. ECWMF and GFS subroutines, mother and nested grid subroutines). If it is affordable performance-wise, such pieces of code should be de-duplicated by moving them into a new function or subroutine (or maybe include file in case it is a performance issue - compiler can be tasked to inline functions as well). pesei 25 Dynamic memory allocation FP coding/compilation Enhancement anphi accepted 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 275 FLEXTRA not compilable against eccodes FLEXTRA Enhancement pesei accepted 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 280 Trajectory time 240000 instead of 000000 next day FLEXTRA Enhancement pesei accepted 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 49 erf.f90 type mismatch with newer gfortran compilers FP coding/compilation Defect igpis assigned 2013-09-27T22:01:52Z 2020-07-16T15:50:22Z "Hello, I'm pasting in an error report that I emailed to a few people on 11 February 2013. I see that the error is still present in the most recent v9.2 downloaded from flexpart.eu. I listed priority as ""major"" because if you're using the newer gfortran, well, it's not going to compile. Other than that, though, it's probably not a big deal. --- Email from 11 Feb 2013 --- I've been installing and running the latest FLEXPART v9.02, compiled with gfortran 4.7.1 and 4.7.2. As I mentioned to Delia and Jerome recently, the newer gfortran compilers are very strict (I think starting somewhere around 4.6 or so). I spent a lot of time last summer and autumn working with NCEP on some porting to gfortran. Stuff that would compile and run fine with Intel, Portland Group, and even older versions of gfortran had to be modified to compile and run correctly with the newest gfortran compilers. In my humble opinion, this is generally a good thing - it means that if you can get your code through the gfortran 4.7.1+ gauntlet, you might have some pretty solid code. Always better to have problems caught by the compiler than to have to spend lots of time debugging elusive runtime problems. So, in compiling FLEXPART v9.02 tonight, I ran into some type mismatch issues in erf.f90 where double precision values were being stored in single precision variables. I know, it's all petty, but the newer gfortran wants you to be aware of these. My ""quick fix"" was just to declare an offending external function as type double precision and convert an argument to double precision before passing into a function. diff erf.f90 erf.f90.ORIG 106c106 < double precision, external :: gammln --- > real, external :: gammln 111c111 < gln=gammln(DBLE(a)) --- > gln=gammln(a) 140c140 < double precision, external :: gammln --- > real, external :: gammln 145c145 < gln=gammln(DBLE(a)) --- > gln=gammln(a) I don't feel like the changes I made adhered to your paradigm of using a ""dp"" KIND as defined in par_mod.f90, but I didn't want to make assumptions. I just wanted a quick fix, which I would notify you of, and then let you decide if/how you want to modify things. " donaldjmorton 238 Inconsistency when shifting longitudes? FP coding/compilation Defect new 2019-04-12T22:03:20Z 2020-07-16T15:46:14Z "I'm looking at how longitudes are being handled by FLEXPART, and I think I found a problem. In many places, the longitudes are being shifted left by 360 degrees, when the they are `>` 180°: {{{ if (xaux1.gt.180.) xaux1=xaux1-360.0 }}} I believe that almost everywhere this should happen when the longitude is `>=` 180°: The logic seems to be that the longitudes have to be between -180..180 degrees. Therefore, any longitude except for the rightmost one should be `<` 180°. How did I come across this? I'm trying to use hemispheric (i.e., with longitudes from -180..180°) ERA5 data, and for some strange reason which I don't understand, {{{ call grib_get_real8(igrib,'longitudeOfFirstGridPointInDegrees', & xaux1in,iret) }}} in `gridcheck_ecmwf.f90` returned 180.0 instead of -180.0 into `xaux1in`, which lead to the grid being shifted right by 360° because of the `>180` check: {{{ Mother domain: Longitude range: 180.00000 to 540.00000 Grid distance: 0.25000 Latitude range : 0.00000 to 90.00000 Grid distance: 0.25000 0.00000000 0.00000000 540.000000 90.0000000 180.000000 0.00000000 720.000000 180.000000 0.500000000 0.500000000 #### FLEXPART MODEL ERROR! PART OF OUTPUT #### #### GRID IS OUTSIDE MODEL DOMAIN. CHANGE #### #### FILE OUTGRID IN DIRECTORY #### }}} After changing all instances of `...gt.180.0` to `...ge.180.0` in the code (except for where it's explicitly being the right edge of the domain that is being checked), gridcheck correctly gives the longitude range as -180..180 degrees: {{{ Mother domain: Longitude range: -180.00000 to 180.00000 Grid distance: 0.25000 Latitude range : 0.00000 to 90.00000 Grid distance: 0.25000 }}} and the model starts and seems to run fine. I'm attaching the patch." ahilboll 235 Problems when restarting from a partposit file FP coding/compilation Defect new 2019-03-20T13:58:52Z 2020-07-16T15:45:29Z "Using the new FLEXPART 10.3, I have trouble restarting from a previous partposit file --- not `partposit_end`, but some intermediate timestep. (I needed this functionality while debugging #234 because I didn't want to wait for the model to reach the point where it broke). While this seems to work, it would be more user-friendly if there were checks in the code like `if restart_run .. release_not_required` (suggestion by @pesei via e-mail). Optimally, the procedure to restart from a previous state would be documented in the current Pisso et al. GMDD paper. I could prepare a patch implementing this, by just checking for `IPIN/=1` around all the `stop` statements I mention below, if that would be helpful. These are the steps I had to do when restarting: 1. I copied header and partposit file to a new output directory, {{{ cp output_partdump_103/header output_debug/ cp output_partdump_103/partposit_20180821160000 output_debug/partposit_end }}} 2. I set `IPIN=1` in `COMMAND` and adapting the simulation start time to the time of my partposit file 3. I removed the release from the `RELEASE` file by commenting out everything inside the only `&RELEASE` section and setting `NSPEC=0`. If I wouldn't do this there were errors about the number of points / releases 4. I had to comment out several sanity checks in the code in order to get rid of several errors regarding number of releases / points / species {{{ diff --git a/src/advance.f90 b/src/advance.f90 index 539a473..632e0f9 100644 --- a/src/advance.f90 +++ b/src/advance.f90 @@ -540,8 +540,8 @@ subroutine advance(itime,nrelpoint,ldt,up,vp,wp, & end do if (nsp.gt.nspec) then ! This should never happen - write(*,*) 'advance.f90: ERROR: could not find releasepoint' - stop +! write(*,*) 'advance.f90: ERROR: could not find releasepoint' +! stop end if if (density(nsp).gt.0.) then call get_settling(itime,real(xt),real(yt),zt,nsp,settling) !bugfix @@ -710,8 +710,8 @@ subroutine advance(itime,nrelpoint,ldt,up,vp,wp, & end do if (nsp.gt.nspec) then ! This should never happen - write(*,*) 'advance.f90: ERROR: could not find releasepoint' - stop +! write(*,*) 'advance.f90: ERROR: could not find releasepoint' +! stop end if if (density(nsp).gt.0.) then call get_settling(itime,real(xt),real(yt),zt,nsp,settling) !bugfix @@ -920,8 +929,8 @@ subroutine advance(itime,nrelpoint,ldt,up,vp,wp, & end do if (nsp.gt.nspec) then ! This should never happen - write(*,*) 'advance.f90: ERROR: could not find releasepoint' - stop +! write(*,*) 'advance.f90: ERROR: could not find releasepoint' +! stop end if if (density(nsp).gt.0.) then call get_settling(itime+ldt,real(xt),real(yt),zt,nsp,settling) !bugfix diff --git a/src/coordtrafo.f90 b/src/coordtrafo.f90 index 2747c60..7d22fb4 100644 --- a/src/coordtrafo.f90 +++ b/src/coordtrafo.f90 @@ -47,7 +47,7 @@ subroutine coordtrafo integer :: i,j,k real :: yrspc ! small real number relative to x - if (numpoint.eq.0) goto 30 +! if (numpoint.eq.0) goto 30 ! TRANSFORM X- AND Y- COORDINATES OF STARTING POINTS TO GRID COORDINATES !*********************************************************************** @@ -107,11 +107,11 @@ subroutine coordtrafo endif end do -30 if(numpoint.eq.0) then - write(*,*) ' FLEXPART MODEL SUBROUTINE COORDTRAFO: ERROR ! ' - write(*,*) ' NO PARTICLE RELEASES ARE DEFINED!' - write(*,*) ' CHECK FILE RELEASES...' - stop - endif +!30 if(numpoint.eq.0) then +! write(*,*) ' FLEXPART MODEL SUBROUTINE COORDTRAFO: ERROR ! ' +! write(*,*) ' NO PARTICLE RELEASES ARE DEFINED!' +! write(*,*) ' CHECK FILE RELEASES...' +! stop +! endif end subroutine coordtrafo diff --git a/src/readpartpositions.f90 b/src/readpartpositions.f90 index 3e98ded..180d6bd 100644 --- a/src/readpartpositions.f90 +++ b/src/readpartpositions.f90 @@ -67,13 +67,13 @@ subroutine readpartpositions read(unitpartin) read(unitpartin) nspecin nspecin=nspecin/3 - if ((ldirect.eq.1).and.(nspec.ne.nspecin)) goto 997 +! if ((ldirect.eq.1).and.(nspec.ne.nspecin)) goto 997 do i=1,nspecin read(unitpartin) read(unitpartin) read(unitpartin) j,specin - if ((ldirect.eq.1).and.(species(i)(1:7).ne.specin)) goto 996 +! if ((ldirect.eq.1).and.(species(i)(1:7).ne.specin)) goto 996 end do read(unitpartin) numpointin }}} 5. Now the model was running, but in the next timestep, all particles were terminated due to mass, so I commented out that part as well. This seems to be a bug on its own. {{{ diff --git a/src/timemanager.f90 b/src/timemanager.f90 index 58d8a89..f515254 100644 --- a/src/timemanager.f90 +++ b/src/timemanager.f90 @@ -669,12 +669,12 @@ subroutine timemanager(metdata_format) end if end do - if (xmassfract.lt.minmass) then ! terminate all particles carrying less mass - itra1(j)=-999999999 - if (verbosity.gt.0) then - print*,'terminated particle ',j,' for small mass' - endif - endif +! if (xmassfract.lt.minmass) then ! terminate all particles carrying less mass +! itra1(j)=-999999999 +! if (verbosity.gt.0) then +! print*,'terminated particle ',j,' for small mass' +! endif +! endif ! Sabine Eckhardt, June 2008 ! don't create depofield for backward runs }}}" ahilboll 211 Incremental vs. cumulative deposition FP coding/compilation Enhancement ignacio assigned 2018-11-08T08:56:46Z 2020-07-16T15:44:48Z "There was an issue about incremental deposition (#113). However, I cannot find that code in the current dev branch. Was it left out on purpose? #113 seems to suggest that the reason for the associated changeset was to not have to backport that feature all the time. While talking about deposition, it would be good if the netCDF attributes of the deposition variables could reflect that they contain either cumulative or incremental deposition. One could use the `long_name` attribute and set it to `cumulative wet/dry deposition` or `incremental wet/dry deposition`. Also, I would argue that in the case of incremental deposition, the units should be adapted to `kg m-2 timestep-1` (whatever timestep is in that case). I'd be happy to prepare a patch for adding the `long_name` attribute. Implementing (or back-porting) incremental deposition is probably better done by someone who knows the code properly." ahilboll 234 Segmentation fault in interpol_wind_short FP coding/compilation Defect new 2019-03-19T09:51:09Z 2020-07-16T15:42:49Z "I'm running FLEXPART 10.3beta with ERA-5 meteorological data which I downloaded using `flex_extract`; here's the relevant parts of the `CONTROL` file I used: {{{ M_GRID 250 M_LEFT -155000 M_LOWER 35000 M_UPPER 70000 M_RIGHT -40000 M_LEVELIST 60/to/137 }}} After some days of simulation, I'm running into a segmentation fault: {{{ call releaseparticles timemanager> SYSTEM CLOCK 6259.19092 timemanager> call convmix -- forward timemanager> call advance At line 125 of file interpol_wind_short.f90 Fortran runtime error: Index '-2147483648' of dimension 2 of array 'uu' below lower bound of 0 Error termination. Backtrace: #0 0x493c4e in interpol_wind_short_ at /mnt/beegfs/user/hilboll/tmp/flexpart_era5/test_segfault/flexpart/src/interpol_wind_short.f90:131 #1 0x5ee861 in advance_ at /mnt/beegfs/user/hilboll/tmp/flexpart_era5/test_segfault/flexpart/src/advance.f90:911 #2 0x43cc02 in timemanager at /mnt/beegfs/user/hilboll/tmp/flexpart_era5/test_segfault/flexpart/src/timemanager.f90:534 #3 0x441656 in flexpart at /mnt/beegfs/user/hilboll/tmp/flexpart_era5/test_segfault/flexpart/src/FLEXPART.f90:455 #4 0x441b7c in main at /mnt/beegfs/user/hilboll/tmp/flexpart_era5/test_segfault/flexpart/src/FLEXPART.f90:50 }}} So I re-ran the simulation using `IPOUT=1` to get an idea of each particle's evolution, and I can see that in the last ``partposit`` file before the segmentation fault, there is at least one particle very close to the edge of the meteo domain: {{{ In [2]: read_partposit('output_partdump/partposit_20180821160000')[1].ylat.min() Out[2]: 35.000393 }}} So it seems to me that there is a problem when applying the Petterssen scheme to particles at the meteo domain edges. From a logical point of view, I believe that in `advance.f90`, before applying the Petterssen scheme, one should check if the particle is still within the meteo domain, and terminate the particle otherwise. There are already several other `return` statements in there, so maybe just adding another check and `return` in there is enough? I'm happy to try and contribute a patch, but would like to hear your thoughts first." ahilboll 278 Receptor output - missing features FP physics/numerics Enhancement new 2020-07-13T17:04:19Z 2020-07-13T17:04:19Z "There are missing features in the receptor output, at least - `ioutputforeachrelease` not honoured - `ind_source`, `ind_receptor` not honoured It would be desirable to implement that. I already have a version with `ioutputforeachrelease` working." pesei 276 Problems creating NetCDf output with many output levels FP coding/compilation Defect ignacio accepted 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 169 Seg fault - particles moving out of ABL by hor. diffusion FP physics/numerics Defect jbrioude assigned 2017-04-18T17:20:27Z 2020-06-24T17:00:59Z "I am using flexpart-wrf version 3.3.1. I have it compiled in parallel (mpi) using intel compilers. I have successfully run flexpart with 2 million particles for 4 simulation, but on the 5th simulation, I get this error: forrtl: severe (174): SIGSEGV, segmentation fault occurred These 5 flexpart simulations are all using output from the same WRF simulation - the only thing I am changing is the release time. In the experiment which fails, if I change the number of particles from 2 million to 500000 it works ok. Any idea how I can fix this problem? I have tried giving the jobs lots of memory so I don't think that is the problem. Thanks " victoria.sinclair@… 274 Non-ascii characters in FLEXTRA output FLEXTRA Defect pesei accepted 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 37 Kernels for receptor output FP physics/numerics Enhancement sthen new 2013-09-12T17:54:55Z 2020-06-05T16:31:49Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Regarding the FLEXPART receptor output option, Stephan introduced a possibility to deal with receptors above the ground; in this modified kernel approach, the kernel width can be specified as an input parameter; temporally variable receptors (aircrafts, ships,…) would be useful, but currently not implemented; Stephan agreed to look into implementing a scheme with modified (user specified) kernel width in Version 9.2+ of FLEXPART as the presently hardcoded kernel width appears to be quite big. " pesei 191 Grib1 total cloud water field is not recognized FP other Defect ignacio assigned 2018-03-28T09:42:26Z 2020-06-05T16:25:05Z "I believe there is a problem with reading ECMWF total cloud water (looking at the v10.2beta tag in Git). The problem is that when I have Grib1 files, the `indicatorOfParameter` (which is used to identify the variable in that version) for the `qc` field is 31 and not 201031. This means that FLEXPART will always complain about ''Global fields: using cloud water from Parameterization'' even though the files do contain the cloud water information. For all other variables present in the Grib files, the `paramId` seems to be the same as the `indicatorOfParameter`, so I believe this fixes the problem: {{{ --- a/src/readwind.f90 +++ b/src/readwind.f90 @@ -144,7 +144,7 @@ subroutine readwind(indj,n,uuh,vvh,wwh) !print*,'GRiB Edition 1' !read the grib2 identifiers - call grib_get_int(igrib,'indicatorOfParameter',isec1(6),iret) + call grib_get_int(igrib,'paramId',isec1(6),iret) call grib_check(iret,gribFunction,gribErrorMsg) call grib_get_int(igrib,'level',isec1(8),iret) call grib_check(iret,gribFunction,gribErrorMsg) --- a/src/readwind_mpi.f90 +++ b/src/readwind_mpi.f90 @@ -154,7 +154,7 @@ subroutine readwind(indj,n,uuh,vvh,wwh) !print*,'GRiB Edition 1' !read the grib2 identifiers - call grib_get_int(igrib,'indicatorOfParameter',isec1(6),iret) + call grib_get_int(igrib,'paramId',isec1(6),iret) call grib_check(iret,gribFunction,gribErrorMsg) call grib_get_int(igrib,'level',isec1(8),iret) call grib_check(iret,gribFunction,gribErrorMsg) }}} " ahilboll 243 New NCEP FV3 GRIB files result in minor FLEXPART errors FP input data Defect new 2019-07-24T02:06:12Z 2020-06-05T16:23:24Z "I believe this is a very minor issue, but I've examined it extensively to back up my beliefs, and thought I would post my report here just in case somebody, someday thinks this is a bigger issue and wants to look into it further. In short, I think that the new NCEP FV3 GRIB files will work fine for low-altitude simulations (like, within the tropopause!!), but if anybody starts doing things at very high altitudes, ""maybe"" there is reason for concern. The report is being attached to this ticket (I hope)." donaldjmorton 26 configure script FP coding/compilation New feature assigned 2013-09-12T17:23:44Z 2020-06-05T16:20:39Z "write a `configure` script that will produce an appropriate makefile (Paul / Matthias). Regarding construction of makefiles, Petra proposed to use the tool [http://www.gfdl.noaa.gov/~vb/mkmf.html mkmf]; Ignacio will look into that (one Makefile for different Versions) it was also proposed to adapt the FLEXPART directory structure (separate executable from sources)" pesei 252 FLEXPART-WRF crashes for array bound mismatch FP coding/compilation Defect new 2019-10-18T09:33:24Z 2020-06-05T16:04:59Z "Hi The flexpart-wrf version 3.3.2 crashes after about five hours of backward mode run when it is run using mpirun. [[BR]] Using `-fbacktrace` and `-fbounds-check` option, I found that it crashes at line 132 in subroutine sendint_mpi.f90 {{{ if (tag.eq.1) npoint(jj2+1:numpart2)=mpi_npoint(1:chunksize2) }}} with error {{{ Fortran runtime error: Array bound mismatch for dimension 1 of array 'npoint' (2500/2511) }}} My input file is similar to flexwrf.input.backward1 provided in the flexwrf_v31_testcases.tar.gz except for the release locations and dates. Also, the par_mod.f90 file has been modified to accommodate larger grid size of the WRF data being used in following manner {{{ integer, parameter :: naxmax=721, nymax=361,nuvzmax=64, nwzmax=64, nzmax=64 }}} The code was run using LSF command bsub < mpijobfile where the mpijobfile is {{{ mpirun -np 12 ./flexwrf33_gnu_mpi flexwrf.input.backward1 }}} The code runs without crashing for serial mode, however grid_time file does not contain other than zero values in that case with all file size 372 bytes. I am not sure if this two issues are related or separate. Any help/hint to resolve this issue will be highly appreciated. The input file being used is attached. I will be glad to provide more information. Harish " harish 233 Error: NetCDF: Invalid dimension ID or name FP coding/compilation Defect pasko accepted 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 248 Inconsistency between Pisso et al paper and model behavior FP other Defect saeck accepted 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 247 allow for using WRF output with lakes FP other Defect new 2019-09-05T16:20:29Z 2019-09-05T16:43:50Z "There is a hard-coded check for the value of `num_land_cat` in the WRF output, and FLEXPART-WRF would only recognize values 24 (for USGS) and 20 (for MODIS). However, when one uses lakes in WPS geogrid, the value of `num_land_cat` will be 28 or 21 for USGS and MODIS land use data, respectively. This patch modifies the check accordingly. Also, now a warning message is printed if the value of `num_land_cat` is not recognized. {{{ 1 file changed, 3 insertions(+), 2 deletions(-) readwind.f90 | 5 +++-- modified readwind.f90 @@ -1125,7 +1125,7 @@ enddo enddo enddo - if (num_land_cat.eq.24) then ! Assume USGS landuse data + if (num_land_cat.eq.24 .or. num_land_cat.eq.28) then ! Assume USGS landuse data do j = 0, nymin1 do i = 0, nxmin1 k = nint(landuse_wrf(i,j)) ! Safely convert element to integer (nearest) @@ -1174,7 +1174,7 @@ endselect enddo enddo - elseif (num_land_cat.eq.20) then ! Assume MODIS data + elseif (num_land_cat.eq.20 .or. num_land_cat.eq.21) then ! Assume MODIS data do j = 0, nymin1 do i = 0, nxmin1 k = nint(landuse_wrf(i,j)) ! Safely convert element to integer (nearest) @@ -1219,6 +1219,7 @@ enddo enddo endif + write(*,*) 'WARNING: unknown num_land_cat in WRF files:', num_land_cat endif ! lu_option.eq.1 ! snow depth }}} " ahilboll 244 Problem in grid area size FP physics/numerics Support new 2019-08-01T13:59:32Z 2019-08-01T14:28:38Z "Dear FLEXPART-WRF Community, I have some problems using WRF fields in very high resolution. My set-up looks as follows: Using WRF I created up to 5 Domains, leading to a horizontal resolution up to 40m. My FLEXPART(-WRF) outgrid I desgined in a way to lay directly on the WRF Grid (see attached config file). The origin is shifted half a grid box to the upper right corner. The reason for this is, that I noticed, that the difference of latitude and longitude in the centre of each gridbox in FLEXPART and WRF is smaller when shifting the FLEXPART grid than without. When looking at the GRIDAREA output inside the header file I noticed a very large range of grid areas as you can see in the attached image 'gridarea_40m.png' (please note the logarithmic scale in this plot) As you can see, the grid area varies by one magnitude in a systematic pattern. Also there are some very small grid areas (three to four magnitudes smaller) spread around the domain. My question is, why is this happening? Due to a coord transfo error (compare ticket #168, https://www.flexpart.eu/ticket/168) I slightly increased the threshold in the map_proj_wrf.f90 file, because the MAPFAC_* values in the corresponding WRF fields seem to be ok (between 1.000075 and 1.000143, so below 2%). But the strange behaviour of grid areas also occurs in my coarser domains with spatial resolution of 200m and 1000m where I did not touch the threshold. Images of this are also attached to this ticket (see gridarea_200m.png and gridarea_1000m.png). You can see that in the case of 200m spatial resolution I seem to have an increase of variation when going to the right, while in the 1000m case a have two vertical stripes in the middle of the domain. I hope someone can help me to understand where the problems come from and to find a solution (best without re-runing all the WRF runs). Best regards Sarah" slmeyer 168 the coordinate transfo error exceeds 0.02*dx FP other Support adingwell reopened 2017-03-02T10:45:49Z 2019-07-30T14:30:56Z "I am trying to run FLEXPART-WRF (forward) using WRF input data on a mercator grid. I keep getting the error: test_xyindex_to_ll_wrf calling map_set -- map_proj_id, map_set_proj_code = 3 1 test_xyindex_to_ll_wrf -- lgrid, rmserr (km) = 0 1.03E+03 ************************************************************ * * * WARNING - the coordinate transfo error exceeds 0.02*dx * * * ************************************************************ problem with the projection. wrf+flexpart stops. I have attached my input file I am using. The WRF output is at 9km grid spacing and has 249 points in the east-west direction and 255 points in the north-south direction. Any advice in how to solve this problem would be appreciated. " victoria.sinclair@… 241 *** read_ncwrfout_1realfield -- var ndims mismatch for CLDFRA FP input data Defect new 2019-06-24T22:16:59Z 2019-06-24T22:16:59Z "I'm using FLEXPART-WRF_v3.3.2 with input data obtained from WRF-ARW. I keep getting the following error: *** read_ncwrfout_1realfield -- var ndims mismatch for CLDFRA The variable CLDFRA is available in the input files but i guess the dimensions are not what FLEXPART expects. Will this have any influence on the results? " daliaga 237 Inconsistent netCDF output FP other Defect new 2019-03-28T22:52:32Z 2019-05-14T11:35:28Z "While looking at the netCDF output from FLEXPART 10.3, I find some inconsistencies: 1. in backward mode (irrespective of the combination of `IND_SOURCE` and `IND_RECEPTOR` I try), the netCDF output file contains `DD_specNNN` and `WD_specNNN` variables which are completely filled with the value `9.969209968386869e+36`. I believe it would be less confusing for the user if these variables were not added to the netCDF output in case of backward runs 2. for `LINIT_COND=1` and `LINIT_COND=2`, there is no initial conditions written to the netCDF output; the initial conditions are just there in form of a `grid_initial_001` binary file. I believe it would be nice for the user if this information were also contained in the netCDF output. 3. for `IFLUX=1`, there is no flux data written to the netCDF output; the fluxes are just there in form of a `grid_flux_YYYYMMDDHHMMSS` binary file. I believe it would be nice for the user if this information were also contained in the netCDF output. 4. for `IND_SOURCE=1` and `IND_RECEPTOR=3` or `IND_RECEPTOR=4`, the netCDF output contains a variable `spec001_mr` with units `s m3 kg-1`; however according to Table 1 in Eckhardt et al. 2017, it should be `m`. 5. for `IND_SOURCE=2` and `IND_RECEPTOR=3` or `IND_RECEPTOR=4`, the netCDF output contains a variable `spec001_mr` with units `s`; however according to Table 1 in Eckhardt et al. 2017, it should be `kg m-2`. Issues 1+4+5 are based on the assumption that the deposition variables should not be present for backward runs; one could argue that for `IND_RECEPTOR=3` only `WD_spec001` should be there, and for `IND_RECEPTOR=4` only `DD_spec001` should be there. Any way, the way the variables are currently handled in the netCDF output is confusing and should be fixed before officically releasing FLEXPART 10.3 " ahilboll 236 Bad wind_option / time_option combination is not forbidden by WRF-FLEXPART FP other Defect new 2019-03-22T16:22:22Z 2019-03-22T16:22:22Z "FLEXPART-WRF 3.3.2 does not prevent `time_option == 1` from being used with `wind_option /= 1`. According to Brioude et al. 2013 (doi:10.5194/gmd-6-1889-2013), `time_option=1` is meant to be used with `wind_option=1` (time-averaged winds). However, the source code does not enforce this. The problem is that in `getfields.f90`, `readwind_timeav` is being called when `time_option == 1` and `wind_option == 1`. After that, `readwind` is being called no matter what. Within `readwind`, the `u`, `v`, and `w` fields are only read from wrfout files if `time_option == 0`. This means that when the user uses `wind_option /= 1` together with `time_option = 1`, there is no `u`, `v`, and `w` ever read from wrfout files. At a later point in `readwind`, the surface layer of `u` and `v` is being overwritten with `u10` and `v10`. Therefore, particles are being moved by wind as long as they stay in the surface layer. As soon as they leave the surface layer, they are in a layer where `u==v==0` (since gfortran compilation uses `-finit-local-zero`), which means the particle will not move significantly afterwards. The following code adds a check to `readinput.f90` to prevent the model from running with this bad parameter combination: {{{ diff --git a/readinput.f90 b/readinput.f90 index 48a435d..dddad01 100644 --- a/readinput.f90 +++ b/readinput.f90 @@ -586,6 +586,15 @@ subroutine readinput stop endif + ! time_option=1 prevents uu and vv from being read in readwinds, so + ! there is no uu and vv at all + !*************************************************************************** + if ((time_option.eq.1) .and. (wind_option.ne.1)) then + write(*,*) ' #### FLEXPART MODEL ERROR! #### ' + write(*,*) ' #### TIME_OPTION=1 can only be used with WIND_OPTION=1 #### ' + stop + endif + ! iouttype -- convert negative values to 0; positive out of range values to 2 if (iouttype .lt. 0) iouttype = 0 if (iouttype .gt. 2) iouttype = 2 }}}" ahilboll 231 RELEASE time variation problem FP coding/compilation Defect ignacio assigned 2019-03-08T13:11:59Z 2019-03-08T13:25:03Z "I'm using FLEXPART 10 from the download https://www.flexpart.eu/downloads/63 When running a simulation with a RELEASE that has a duration longer than `ltimesync / 2`, and when I don't specify `PPOINT_HOUR` and `PPOINT_DOW` in the `SPECIES` file, then no particles ever get released. I introduced some debugging statements in the code in order to find out what's the problem, and the problem seems to be that `average_timecorrect` in file `releaseparticles.f90` has some really low value ~4E-09, which leads to `rfraction` being ~1E-04, which in combination with `npart(i)=1000000` leads to `numrel=0`. When I set the `PPOINT_HOUR` and `PPOINT_DOW` to 1.0 (multiple times, i.e., for each of the 24 hours / 7 days) in the `SPECIES_NNN` file, then everything works as expected." ahilboll 228 Add horizontal self-propelled vector to particle FP other New feature new 2019-02-04T00:36:18Z 2019-02-04T00:36:18Z "Hi there, I am using WRF_WRF and wondering if I can give a horizontal release direction/speed to the particle in any subrountine, or if I can modify any subrountine to enable this function? I hope to use this feature to simulate the trajectory of self-propelled insect flying. FP-WRF only enales me to give a deposition speed of released particles. Thak you so much for your reply!" ZhenhuaHao 220 Issue with NCEP GFS data after 2015-01-14 FP other Defect new 2019-01-07T10:10:11Z 2019-01-08T06:45:04Z We have noticed that the potential emission sensitivity (PES) values calculated using NCEP GFS data (ds083.2) and FLEXPART version 9.0.2 suddenly increases for the date after 14th January 2015. We know that some new variables like 2m dew point temperature are added to NCEP files 15 January 2015 onward but not sure if they are causing the change in model's behaviour. The spatial pattern which we get for PES is fine and comparable between pre and post 14 Jan 2015 except that the values are increased significantly in case of post 14 Jan 2015 runs. harish 210 RECEPTOR syntax error FP other Support pesei accepted 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 217 t not in K FP coding/compilation Defect new 2018-11-30T02:20:00Z 2018-11-30T02:20:00Z I'm having this same problem as described in Ticket #50. I cannot figure out how to fix it in FLEXPART-WRF. The issue described in ticket #50 seemed to occur due to an issue with grib2 data format versus grib1 data. I have used wrfout* files generated using both grib1 and grib2 data. I still get an error that says Sorry: t not in [K]. I only get this issue when I specify a run with less than 1 000 000 particles. When I use a run with 10 000 000 particles I get a segmentation fault. Any help would be appreciated. I don't know what else to try. mitchekc 213 wrong unit for max convection level in gridcheck FP coding/compilation Defect new 2018-11-12T16:17:08Z 2018-11-12T16:17:08Z "`gridcheck.f90` (in Fp10, `gridcheck_ecmwf.f90` and `gridchec_gfs.f90` has the following code {{{ #!fortran ! Determine the uppermost level for which the convection scheme shall be applied ! by assuming that there is no convection above 50 hPa (for standard SLP) !***************************************************************************** do i=1,nuvz-2 pint=akz(i)+bkz(i)*101325. if (pint.lt.5000.) goto 96 end do 96 nconvlev=i if (nconvlev.gt.nconvlevmax-1) then nconvlev=nconvlevmax-1 write(*,*) 'Attention, convection only calculated up to ', & akz(nconvlev)+bkz(nconvlev)*1013.25,' hPa' endif }}} The output message will not give the pressure at `nconvlev` in hPa, because `akz` is in Pa. furthermore, the purpose of all this is not clear as the convection subroutines only use `nconvlevmax`. Note that these lines were added going from v4.4 to v5.1 and are still present in the latest v10.3 draft." pesei 206 header binary file not created when compiled without netcdf support FP coding/compilation Defect new 2018-10-05T08:54:02Z 2018-10-28T20:21:06Z "Missing in the `FLEXPART.f90` the option in which flexpart is compiled without the netcdf module. I fixed this problem by changed the lines 358 - 376 with: {{{#!fortran #ifdef USE_NCF if (lnetcdfout.eq.1) then call writeheader_netcdf(lnest=.false.) else ! call writeheader goto 10 end if if (nested_output.eq.1) then if (lnetcdfout.eq.1) then call writeheader_netcdf(lnest=.true.) else ! call writeheader_nest goto 11 endif endif #endif if (verbosity.gt.0) then print*,'call writeheader' endif 10 call writeheader 11 if (nested_output.eq.1) then call writeheader_nest endif }}} Another option could be to declare the variable `lnetcdfout` outside of netcdf module in `FLEXPART.f90` and it to be included as parameter in the command file" camelia 85 Input file templates FP input data Enhancement pesei accepted 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 77 Speeding up FLEXPART FP input data Enhancement pesei accepted 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 199 gridcheck: checking array dimensions needs to be improved FP coding/compilation Defect new 2018-06-25T15:22:12Z 2018-06-25T15:22:12Z "In `gridcheck*.f90`, there is a check whether the array dimension for the met input as defined in `par_mod.f90` are sufficient for the data being read. However, the check comes after data have been assigned to arrays. This means that array boundary violations will still occur, even if FLEXPART is terminated soon after. In v10, a copy of the x-dimension check has been placed at an earlier location. However, the other dimensions are still not properly checked, and in `gridcheck_gfs.f90` even this has not been done (so running the code with -fcheck=all, I received an error message - that is how I discovered the problem)." pesei 198 Unsorted trajectories in FLEXTRA flightmode with constant initialization time FLEXTRA Enhancement pesei accepted 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 151 Improper use of MPI_IN_PLACE FP coding/compilation Defect espen assigned 2016-06-16T07:15:51Z 2018-06-07T12:57:04Z "In '''mpi_mod.f90''' and '''FLEXPART_MPI.f90''' there are calls to MPI_REDUCE which use MPI_IN_PLACE. The non-root calls to MPI_RECEIVE currently use the same buffer for send and receive; this is will produce errors when running with Intel-MPI. The correct way of doing this is to set RECBUF (second argument) to 0, in non-root calls where MPI_IN_PLACE was assigned by the root. E.g. in **FLEXPART_MPI.f90**, this block: {{{#!fortran if (lroot) then call MPI_Reduce(MPI_IN_PLACE, tot_blc_count, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) call MPI_Reduce(MPI_IN_PLACE, tot_inc_count, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) else if (mp_partgroup_pid.ge.0) then ! Skip for readwind process call MPI_Reduce(tot_blc_count, tot_blc_count, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) call MPI_Reduce(tot_inc_count, tot_inc_count, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) end if end if }}} should be replaced with this: {{{#!fortran if (lroot) then call MPI_Reduce(MPI_IN_PLACE, tot_blc_count, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) call MPI_Reduce(MPI_IN_PLACE, tot_inc_count, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) else if (mp_partgroup_pid.ge.0) then ! Skip for readwind process call MPI_Reduce(tot_blc_count, 0, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) call MPI_Reduce(tot_blc_count, 0, 1, mp_pp, MPI_SUM, id_root, & & mp_comm_used, mp_ierr) end if end if }}} (Corresponding changes should also be made in **mpi_mod.f90**)" adingwell 139 Bad do-loop in richardson.f90 FP coding/compilation Defect pesei accepted 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 138 FLEXPART.f90 should not call readpaths with an argument FP coding/compilation Defect pesei accepted 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 193 Wrong date format in output filename FP coding/compilation Defect pesei accepted 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 175 FpWrf header_nest dxoutn, dyoutn always in metre FP coding/compilation Defect pesei accepted 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 176 No error issued if insufficient number of SPECIES (FpWrf) FP coding/compilation Defect pesei accepted 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 48 Crash with grib1 GFS/FNL FP input data Defect ignacio assigned 2013-09-13T00:33:17Z 2017-08-03T17:58:55Z "Hi all, I am trying to create a transport climatology for an observatory station. I collected some GFS wind fields of 2005 and 2006 which are in old grib1 format. Then I got error message generated by ""readoutgrid"" like this: Mother domain: Longitude range: 0.00 360.00 Grid distance: 1.00 Latitude range: -90.00 90.00 Grid distance: 1.00 #### FLEXPART MODEL ERROR! PART OF OUTPUT #### #### GRID IS OUTSIDE MODEL DOMAIN. CHANGE #### #### FILE OUTGRID IN DIRECTORY #### Then I printed some related variable: write(*,*) outlon0,outlat0,eps,dx,dy,nxmin1,nymin1 write(*,*) xr1,yr1,xlon0,ylat0,xr,yr,dxout,dyout -179.0000 0.000000 9.9999997E-05 1.000000 1.000000 360 180 360.0000 90.00000 0.000000 -90.00000 181.0000 90.00000 1.000000 1.000000 In OUTGRID, I normally set the longitude domain from -179 to 181, which runs flawlessly with grib2 GFS data after 2007. Same settings cannot get through with grib1 GFS data. I personally remember fields are set in a different sequence in grib1, which could be the potential reason for this. I am current looking for the files set the domain. However, I have never digged too deep into FLEXPART codes. I hope someone can point me to the right files or provide solutions/suggestions. I will also post any progress I make in the future. Thanks." bzhang 67 Support for removing levels from EN files FP input data New feature anphi accepted 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 110 Warm start crashes FLEXPART-WRF FP other Defect jbrioude accepted 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 114 FLEXPART-WRF of v3.2 cannot read in more than 96 met files? FP other Defect anphi accepted 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 173 "Variables ""settling"" and ""idummy"" not properly initialized in advance.f" FP coding/compilation Defect pesei accepted 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 162 Add version information to preprocessing files in FPV9.3.1 FP other Enhancement new 2016-10-05T08:41:23Z 2016-10-05T10:54:20Z One user has suggested that, given the ongoing changes in the preprocessed met file format, it would be useful to have a version string in each preprocessed file so that we can easily identify the version, and hence the format, of preprocessed files. donaldjmorton 36 Convection - don't call every time step FP physics/numerics Enhancement pesei accepted 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 143 readwind_gfs() not reading total cloud cover from GRIB2 FP input data Defect pesei accepted 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 101 Code review for changeset 31 / hasod FP coding/compilation Task pesei accepted 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 38 Testing environment FP other New feature anphi accepted 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 27 ETEX1 data as part of FLEXPART distribution FP input data Task pesei accepted 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 94 Code review for changeset 27 / hasod FP coding/compilation Task pesei accepted 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 33 Precipitation treatment FP physics/numerics Defect dearn accepted 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 54 Particle loss at poles FP physics/numerics Defect hasod reopened 2013-11-18T10:13:47Z 2015-07-01T16:17:08Z Running FLEXPART 9.1 in domainfilling global mode results in loosing particles at the poles. alaedera 124 Suggest easing of restriction on number of releases in readpartpositions.f90 FP other Enhancement pesei accepted 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 115 Bug in readspecies.f90 FP coding/compilation Defect pesei accepted 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 123 bwd runs and receptor output FP physics/numerics Enhancement somebody new 2015-06-08T10:22:09Z 2015-06-08T10:22:09Z "`readreceptor.f90`: {{{ ! For backward runs, do not allow receptor output. Thus, set number of receptors to zero !***************************************************************************** if (ldirect.lt.0) then numreceptor=0 return endif }}} Why this limitation? Should we remove it?" pesei 59 Improve error messages FP coding/compilation Enhancement anphi accepted 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 113 Option for incremental wet deposition output FP physics/numerics New feature pesei accepted 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 52 Particle release density FP physics/numerics Enhancement ignacio assigned 2013-10-28T16:16:19Z 2014-06-02T14:28:25Z "Presently, particles are released homogeneously in 4D space. They represent mass in the forward mode. Under well-mixed conditions, the mixing ratio should be constant. Thus, they should be released proportional to air density. For not too large release domains, the difference will not be important. It would also be better to release particles in a way that ensures homogenous filling of the release domain instead of randomly, as done now. For small particle numbers per time step, the randomness may lead to clustering of particles in parts of the domain." pesei 34 Wet deposition - washout coefficients FP physics/numerics Defect pesei accepted 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 43 Library for reading output FP post-processing Task pesei accepted 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 51 Wet deposition - other models FP physics/numerics Task pesei accepted 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 30 Documentation for domain-filling runs FP other Task hasod accepted 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 44 Cittycat interface FP post-processing Task ignacio accepted 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 28 Trivial parallelisation FP input data Task pesei accepted 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 39 Interpolation close to the poles FP physics/numerics Task somebody new 2013-09-12T17:58:13Z 2013-09-12T17:58:13Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Close to the poles, the implemented scheme should be looked at" pesei