__group__ ticket summary component version type owner status created modified _description _reporter Milestone 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 Milestone 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 Milestone 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 Milestone 42 ECMWF pre-processor too heavy FP input data Enhancement anphi closed 2013-09-12T18:05:41Z 2021-07-21T09:21:16Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) The current ECMWF data pre-processor needs excessive cpu resources; the retrieval of global high-resolution ECMWF data currently only works on the ECMWF HPC system; ZAMG/Matthias is ready to look into that, and to propose updates; Standard FLEXPART input data sets (e.g., global 0.5 degrees) could be stored at ECMWF for direct download for the FLEXPART community (ZAMG) " pesei Milestone 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 Milestone 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 Milestone 144 Producing Meteorology Data FP input data Support closed 2016-03-24T10:03:37Z 2016-03-24T10:35:11Z "I have used real weather data from GFS for input in FLEXPART 8.2 but I want to imaginary data which I can edit. Is it possibble to produce our met. data for Flexpart? " ebilgic Milestone 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 Milestone 202 Bug in flex_extract v7.0.3 public user mode flex_extract Defect anphi closed 2018-08-17T09:14:40Z 2019-01-17T20:54:55Z "I got a message from a user who reported a problem in the public user mode with the following error message: {{{ Traceback (most recent call last): File ""./submit.py"", line 112, in main() File ""./submit.py"", line 57, in main getMARSdata(args,c) File ""/media/flexpart/FLEXPART_ROOT_TEMPLATE/scripts/flex_extract_v7.0.3/python/getMARSdata.py"", line 111, in getMARSdata flexpart.retrieve(server, c.public, dates, times, c.inputdir) File ""/media/flexpart/FLEXPART_ROOT_TEMPLATE/scripts/flex_extract_v7.0.3/python/FlexpartTools.py"", line 979, in retrieve MR.dataRetrieve() File ""/media/flexpart/FLEXPART_ROOT_TEMPLATE/scripts/flex_extract_v7.0.3/python/FlexpartTools.py"", line 655, in dataRetrieve print 'target: ', target UnboundLocalError: local variable 'target' referenced before assignment }}}" anphi Milestone 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 Milestone FLEXPART 10 29 OH chemistry FP physics/numerics New feature sthen closed 2013-09-12T17:30:34Z 2020-08-21T17:57:37Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Regarding linear chemistry, Stephan uses already OH reactions including species production; It was agreed that Stephan’s OH module should be integrated into the FLEXPART standard version, but not into the next release (Version 9.2+) " pesei Milestone FLEXPART 10 32 Wet deposition: use of cloud water fields FP physics/numerics Enhancement anphi closed 2013-09-12T17:35:09Z 2020-08-21T19:17:29Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) In the future, it was agreed that the cloud liquid water content/cloud ice content from ECMWF should be utilized. One current obstacle is that this would mean the introduction of two additional 3-D fields. " pesei Milestone FLEXPART 10 35 Backward mode for deposition FP input data New feature saeck closed 2013-09-12T17:43:41Z 2018-10-29T12:36:19Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) '''Backward mode for deposition quantities''' This was considered as “nice to have”, but there are no plans to implement it as of now; this could be implemented as a pre-processing tool " pesei Milestone FLEXPART 9.2 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 Milestone FLEXPART 9.2 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 Milestone FLEXPART 9.2 40 netCDF output FP post-processing New feature hasod closed 2013-09-12T18:02:07Z 2017-07-06T13:45:11Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) The introduction of netCDF output (post-processing) was considered useful, post-processing software should be put on the FLEXPART home page; as a disadvantage, however, it needs to be stressed that output in netCDF format is much larger compared with standard FLEXPART output. With the introduction of a FLEXPART netCDF output converter, a large variety of visualization software becomes available I think implementation should be as a postprocessing tool. Binding in netCDF libs can create trouble as we see in ticket:14 and makes the code more dependent on other software, while not everyone would want to use the feature." pesei Milestone FLEXPART 9.2 41 header file in ASCII FP coding/compilation Enhancement ignacio closed 2013-09-12T18:04:19Z 2015-07-03T14:51:32Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Currently, the FLEXPART output file `header` is binary. An ASCII-text header file for basic parameters would be useful (maybe in addition to the current header file to preserve compatibility with existing postprocessing software); in the header file, additional information should be stored, for example path names for input data (e.g., windfields)" pesei Milestone FLEXPART 9.2 45 Consolidation of various code changes FP coding/compilation Task ignacio closed 2013-09-12T18:09:23Z 2014-04-04T10:30:20Z "(from minutes of [wiki:DevelopersWs2013 FpDev Workshop 2013]) Consolidate code changes into new version. NILU will collect the code changes made by various people and consolidate them into a new official release." pesei Milestone FLEXPART 9.2 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 Milestone Long-term tasks 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 Milestone Long-term tasks 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 Milestone Long-term tasks 46 Version policy / Roadmap FP other Task pesei closed 2013-09-12T18:10:22Z 2015-07-03T14:58:58Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) The introduction of a version policy is regarded as necessary; a new FLEXPART version should be introduced not more than once a year" pesei Milestone flex_extract_v7.1.3 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 Milestone 130 flex_extract (was: ECMWFDATA) 7.0 test version flex_extract flex_extract_v7.0.2 New feature leohaim closed 2015-12-03T09:26:50Z 2019-01-17T18:12:06Z "Dear FLEXPART users, a new version 7.0 of the ECMWFDATA software (also known as `flex_extract`, see FpInputMetEcmwf) used for retrieving ECMWF input data for FLEXPART is available for testing. Some preliminary documentation is attached as well. Features: 1. It uses WebMARS for data retrieval as default, although the conventional retrieval via ecgate or the HPC is still supported. 2. Most parts are now written in python 3. The scripts are prepared to be embedded in the FLEXPART file tree and support features in FLEXPART 10, e.g. retrieval of cloud water content or production of input files on height levels (.fp files) 4. experimental support for retrieval of input files for WRF in addition to those for FLEXPART 5. Support for retrieving long (>24h) range forecasts This is a test version, so there are likely some bugs or gaps in the documentation. Any feedback is appreciated. The tarball that includes a Software Installation Protocol and a Software User Tutorial can be downloaded as ftp://srvx7.img.univie.ac.at/pub/ECMWFDATA7.0.tar.gz With best regards, Leo Haimberger " leohaim Milestone 215 Bug in flex_extract v7.0.3 ERA5 data extraction flex_extract flex_extract_v7.0.3 Defect anphi closed 2018-11-26T15:51:04Z 2019-01-17T19:15:10Z "Recently, I found out that flex_extract version 7.0.3 has an error in the extraction of ERA5 data! = PLEASE STOP USING ERA5 DATA EXTRACTION!!!! = Times 17 and 18 do not contain any flux fields (e.g. precipitation). And the rest of the times it seems that the flux fields are shifted in time. == I'll provide a bug fix as soon as possible! == Explanations will follow ..." anphi Milestone flex_extract_v7.1 212 "Bug in flex_extract v7.0.3 Fortran program ""CONVERT2""" flex_extract flex_extract_v7.0.3 Defect anphi closed 2018-11-12T15:09:07Z 2019-01-17T17:11:31Z "During a test with ERA5 and CERA with the gateway version (submitting the jobscript to the ecgate server) I had problems in the CONVERT2 Fortran program. I received the following error with grib_api: {{{ grib_ieee_to_long: Number is too large: x=3.35531257646599394446e+44 > xmax=3.40282346638528859812e+38 /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_ieeefloat.c at line 147: assertion failure Assert(0) Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x3dd543250f in ??? #1 0x3dd5432495 in ??? #2 0x3dd5433c74 in ??? #3 0x7ffff7b38a42 in grib_fail at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_errors.c:111 #4 0x7ffff7b2241b in grib_ieee_to_long at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_ieeefloat.c:147 #5 0x7ffff7b226c7 in grib_ieee_nearest_smaller_to_long at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_ieeefloat.c:237 #6 0x7ffff7b2283e in grib_nearest_smaller_ieee_float at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_ieeefloat.c:280 #7 0x7ffff7b01b1e in pack_double at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_accessor_class_data_simple_packing.c:678 #8 0x7ffff7b0627d in pack_double at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_accessor_class_data_g2simple_packing.c:206 #9 0x7ffff7b3726a in _grib_set_double_array_internal at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_value.c:559 #10 0x7ffff7b3731b in _grib_set_double_array at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_value.c:586 #11 0x7ffff7b373e0 in grib_set_double_array_internal at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_value.c:608 #12 0x7ffff7b0ef3a in pack_double at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_accessor_class_data_apply_bitmap.c:311 #13 0x7ffff7b3726a in _grib_set_double_array_internal at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_value.c:559 #14 0x7ffff7b3731b in _grib_set_double_array at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_value.c:586 #15 0x7ffff7b37474 in __grib_set_double_array at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/src/grib_value.c:679 #16 0x7ffff7deec6c in grib_f_set_real8_array_ at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/grib_api/fortran/grib_fortran.c:2619 #17 0x7ffff7df067a in __grib_api_MOD_grib_set_real8_array at /scratch/ma/deploy/metabuilds/ecflow-metab_5062/ecgb/GNU.63/grib_api/builds/fortran/grib_f90.f90:2953 #18 0x409733 in __rwgrib2_MOD_writelatlon at /home/ms/at/km4a/flex_extract_v7.1/source/fortran/rwGRIB2.f90:154 #19 0x417b61 in preconvert at /home/ms/at/km4a/flex_extract_v7.1/source/fortran/preconvert.f90:682 #20 0x418bf9 in main at /home/ms/at/km4a/flex_extract_v7.1/source/fortran/preconvert.f90:53 }}} and the following error while using eccodes: {{{ ECCODES ERROR : Maximum value out of range: -nan ECCODES ERROR : unable to compute packing parameters ECCODES ERROR : unable to set double array codedValues (Encoding invalid) ECCODES ERROR : set: values Encoding invalid readspectral: 1 records read readlatlon: 76 records read STATISTICS: 97406.7212 97402.4837 908.5665 readlatlon: 38 records read readlatlon: 38 records read readlatlon: 38 records read }}} " anphi Milestone 224 on ecgate, ECCODES ERRORS : Maximum value out of range: inf flex_extract flex_extract_v7.0.4 Defect anphi closed 2019-01-16T21:20:08Z 2019-01-17T19:19:19Z "Dear Flex_EXTRACT developers or users, I'm trying to extract fields at ECMWF on ecgate. `flex_extract_v7.0.4` or `flex_extract_v7.0.3` always produce the same error: {{{ ECCODES ERROR : Maximum value out of range: inf. }}} This happens, when `submit.py` executes `prepareFLEXPART.py`. The downloading of the data from MARS archive works without problems. The error `Maximum value out of range: inf` also occurs, if I use the module `grip_api` instead of `eccodes`. What I'm doing wrong? My installation process : I have installed `flex_extract_v7.0.4` directly on ecgate and I directly execute it there. The gfortran I'm using is: `/usr/local/apps/gcc/6.3.0/bin/gfortran` I have loaded the required modules in this order: `python 2.7.12-01 , jasper 1.900.1 , eccodes 2.9.2 , fftw 3.3.4 , emos 458` I have compiled the code in the subdirectory python with: `./install.py --target=local --makefile=Makefile.gfortran` Compilation is successful, no problems, no warnings here. After inserting `DAY1 20180711` and `DAY2 20180711` in `CONTROL.temp`, I run the model on ecgate with following command: {{{ ./submit.py --controlfile CONTROL.temp --inputdir /scratch/ms/datex/dw0/FLEXPART/INPUT --outputdir / scratch/ms/datex/dw0/FLEXPART/OUTPUT }}} After the successful download of the data from MARS-archive and the creation of a lot of flux and fort files the process crashes with the following error message: {{{ ECCODES ERROR : Maximum value out of range: inf ECCODES ERROR : unable to compute packing parameters ECCODES ERROR : unable to set double array codedValues (Encoding invalid) ECCODES ERROR : set: values Encoding invalid Traceback (most recent call last): File ""./submit.py"", line 115, in main() File ""./submit.py"", line 59, in main prepareFLEXPART(args,c) File ""/home/ms/datex/dw0/FLEXPART/flex_extract_v7.0.4/flex_extract/python/prepareFLEXPART.py"", line 96, in prepareFLEXPART flexpart.create(inputfiles, c) # produce FLEXPART-ready GRIB files File ""/home/ms/datex/dw0/FLEXPART/flex_extract_v7.0.4/flex_extract/python/FlexpartTools.py"", line 1468, in create p=subprocess.check_call([os.path.expandvars(os.path.expanduser(c.exedir))+'/CONVERT2'],shell=True) File ""/usr/local/apps/python/2.7.12-01/lib/python2.7/subprocess.py"", line 541, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/home/ms/datex/dw0/FLEXPART/flex_extract_v7.0.4/flex_extract/python/../src//CONVERT2']' returned non-zero exit status 242 }}} The same happens using `flex_extract_v7.0.3`. I have also tested other control files. Always the same error. Thank you very much, with kind regards, Benedikt Steil" bsteil Milestone 225 flex_extract v7.0.4 flex_extract flex_extract_v7.0.4 Enhancement anphi closed 2019-01-17T17:53:24Z 2019-01-18T07:30:21Z "Dear FLEXPART users, we prepared a bugfix version for flex_extract v7.0.3 used for retrieving ECMWF input data for FLEXPART. This was necessary since there were errors in ERA5 and CERA retrievals. Also, there were some other problems. __ NEW FEATURES: - This version can now retrieve ERA5 and CERA data. - It can retrieve public datasets by using the command line parameter `public` - It can write an extra file `mars_requests.csv` which contains all mars request parameters for each request. Use the command line pararmeter `request` - It can retrieve analysis and forecast ensembles efficiently e.g. by setting number=0/to/9. In this case output files get an additional suffix for the ensemble member number. __MODULE PACKAGE CONDITIONS: On ecgate we use the following module packages: - jasper/1.900.1(default) - eccodes/2.9.2(nov18:default) - ecfs/2.2.5(nov18:test:new:prodn:default) - python/2.7.12-01(may18:new:default) - ecaccess/4.0.2(default) - fftw/3.3.4(default) - emos/455-r64 Please be aware that all of the above packages are the current default versions except for `emos`! This is important since emos/458 does not work! __DOWNLOAD The tarball that includes a Software Installation Protocol and a Software User Tutorial can be downloaded here [https://www.flexpart.eu/downloads/62 flex_extract v7.0.4] With best regards, Anne Philipp and Leopold Haimberger " anphi Milestone 227 Retrieve global ERA5 data flex_extract flex_extract_v7.0.4 Defect anphi closed 2019-01-29T10:32:41Z 2019-02-15T14:02:05Z "I'm having trouble retrieving hemispheric (i.e., northern hemisphere) ERA5 data using flex_extract version 7.0.4. I'm using the GATEWAY mode, i.e., I have flex_extract installed on my local system to submit jobs to the ECGATE queue. Installation works fine, and I can retrieve non-hemispheric ERA5 data just fine. E.g., this COMMAND file works fine: {{{ DAY1 DAY2 DTIME 1 TYPE AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ACCTYPE FC ACCTIME 06/18 ACCMAXSTEP 12 M_CLASS EA M_STREAM OPER M_NUMBER OFF M_EXPVER 1 M_GRID 250 M_LEFT -170000 M_LOWER 10000 M_UPPER 80000 M_RIGHT 170000 M_LEVELIST 1/to/137 M_RESOL 799 M_GAUSS 0 M_ACCURACY 24 M_OMEGA 0 M_OMEGADIFF 0 M_ETA 1 M_ETADIFF 0 M_DPDETA 1 M_SMOOTH 0 M_FORMAT GRIB2 M_ADDPAR /186/187/188/235/139/39 PREFIX EA ECSTORAGE 0 ECTRANS 1 ECFSDIR ectmp:/${USER}/econdemand/ MAILOPS hilboll@uni-bremen.de MAILFAIL hilboll@uni-bremen.de EOF }}} However, this here does *not* work: {{{ DAY1 DAY2 DTIME 1 TYPE AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ACCTYPE FC ACCTIME 06/18 ACCMAXSTEP 12 M_CLASS EA M_STREAM OPER M_NUMBER OFF M_EXPVER 1 M_GRID 250 M_LEFT -180000 M_LOWER 00000 M_UPPER 90000 M_RIGHT 180000 M_LEVELIST 1/to/137 M_RESOL 799 M_GAUSS 0 M_ACCURACY 24 M_OMEGA 0 M_OMEGADIFF 0 M_ETA 1 M_ETADIFF 0 M_DPDETA 1 M_SMOOTH 0 M_FORMAT GRIB2 M_ADDPAR /186/187/188/235/139/39 PREFIX EA ECSTORAGE 0 ECTRANS 1 ECFSDIR ectmp:/${USER}/econdemand/ MAILOPS hilboll@uni-bremen.de MAILFAIL hilboll@uni-bremen.de EOF }}} I tried already different left/right combinations, like -180/180, -179750/180, -180/179750, -179875/179875, and the like. The error message I'm getting is this: {{{ Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x3dd543250f in ??? #1 0x3dd54896f6 in ??? #2 0x40a1c5 in __rwgrib2_MOD_readlatlon at /home/ms/datex/gdmv/flexpart/scripts_gateway/flex_extract_v7.0.4/src/rwGRIB2.f90:72 #3 0x41240b in preconvert at /home/ms/datex/gdmv/flexpart/scripts_gateway/flex_extract_v7.0.4/src/preconvert.f90:402 #4 0x418c6d in main at /home/ms/datex/gdmv/flexpart/scripts_gateway/flex_extract_v7.0.4/src/preconvert.f90:53 }}}" ahilboll Milestone 253 Flex_Extract MARS request failed flex_extract flex_extract_v7.0.4 Support anphi closed 2019-10-28T05:59:57Z 2020-02-28T12:34:28Z "Hi, Im getting the following error, when I request data using submit.py. {{{ 2019-10-28 10:56:25 ECMWF API python library 1.5.4 2019-10-28 10:56:25 ECMWF API at https://api.ecmwf.int/v1 2019-10-28 10:56:27 Welcome nanditha js Error: MARS Request failed Traceback (most recent call last): File ""./submit.py"", line 114, in main() File ""./submit.py"", line 59, in main getMARSdata(args,c) File ""/home/nanditha/lib/src/flexpart_9.0.3/flex_extract_v7.0.3/python/getMARSdata.py"", line 116, in getMARSdata flexpart.retrieve(server, c.public, dates, times, c.inputdir) File ""/home/nanditha/lib/src/flexpart_9.0.3/flex_extract_v7.0.3/python/FlexpartTools.py"", line 979, in retrieve MR.dataRetrieve() File ""/home/nanditha/lib/src/flexpart_9.0.3/flex_extract_v7.0.3/python/FlexpartTools.py"", line 680, in dataRetrieve if not int(self.public) and os.stat(target).st_size==0: OSError: [Errno 2] No such file or directory: '/home/nanditha/lib/src/flexpart_9.0.3/flex_extract_v7.0.3/python/../work/FCOG_acc_SL.20171104.3218.18276.grb' }}} I have requested data using the command `./submit.py --start_date 20171105 --controlfile CONTROL_EA5 ` I,m attaching the control file used for retrieval request It would be highly appreciated if you could help me in this regard Thanks in advance" nanditha Milestone flex_extract v7.0.4 251 Installation issue with Flex_extract_v7.0.4 FP other flex_extract_v7.0.4 Support anphi closed 2019-10-11T08:30:15Z 2020-02-27T14:13:17Z "I'm trying to install FLEX_EXTRACT 7.0.4 locally using the command ./install.py --target=local --makefile=Makefile.local.gfortan but it is not reading the target. I'm getting an error message cal --makefile=Makefile.local.gfortan File ""./install.py"", line 60 print 'Please specify installation target (local|ecgate|cca)' ^ SyntaxError: invalid syntax " nanditha Milestone flex_extract_v7.1.2 229 flex_extract requires grib_api even when run in gateway mode flex_extract flex_extract_v7.0.4 Enhancement anphi closed 2019-02-15T14:55:52Z 2021-07-21T08:49:26Z "I've installed `flex_extract` in version 7.0.4, following the instructions given in the `SIP.pdf` file, section 3.2.2, ""Installation using a gateway server"". This works fine, I can submit jobs by running `submit.py` on my local machine, so far so good. However, I noted that in order to run `submit.py` on my local machine, I need to have *grib_api* installed locally, which doesn't seem to make sense, as all the computations are being carried out on ECMWF servers. I would suggest to modify `submit.py` so that the `from GribTools import GribTools` comes inside the `if args.queue==None` block. Actually, now that I look at the code, it seems to me that `GribTools` is not used at all in `submit.py`, so one should be able to just delete that line." ahilboll Milestone flex_extract_v7.2 226 flex_extract WRF data flex_extract flex_extract_v7.0.4 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 Milestone 261 Installation of flex_extract v7.1 FP input data flex_extract_v7.1 Defect anphi closed 2020-02-27T14:39:27Z 2020-02-28T09:27:34Z "Hi, I am trying to install last version of flex_extract (v7.1). It seems easier than older versions. But, I failed in the beginning. First, I changed related parameters in setup.sh: {{{ TARGET='ecgate' MAKEFILE='Makefile.gfortran' ECUID='tm1e' ECGID='tr' GATEWAY=None DESTINATION=None INSTALLDIR=None JOB_TEMPLATE='job.template' CONTROLFILE='CONTROL_EA5' }}} and I loaded pyhton3 module: {{{ module load python3 }}} I get this message: {{{ load python3 3.6.8-01 (PATH, MANPATH) }}} I think everything is ok, but wen I run the setup.sh (./setup.sh), I received following message: {{{ Please enter your ECMWF user id and group id as well as the name of the local gateway and the ectrans destination with command line options --ecuid --ecgid --gateway --destination Try ""install.py -h"" to print usage information Please consult ecaccess documentation or ECMWF user support for further details }}} Regards, Efem " ebilgic Milestone 287 Suddenly ECMWF files have a GRIB2 message with shortName=unknown FP input data flex_extract_v7.1 Defect anphi closed 2020-11-29T23:48:17Z 2020-12-01T17:23:48Z "There was a reported problem that since the 25th of November 2020 the GRIB2 surface field message snow depth has a shortName=unknown instead of sd. " anphi Milestone 300 ECCODES ERROR : get: pv Passed array is too small flex_extract flex_extract_v7.1 Defect anphi closed 2021-05-07T09:22:40Z 2022-01-16T20:06:17Z "Dear all, Although this is a known error for cases where a wrong maximum layer is used for input data (cf #283), I received it after making sure this parameter was set correctly for ERA5 data (137). According to the installation test in the user guide, we have successfully installed FLEX_EXTRACT. {{{ ...... ... disaggregation of precipitation with new method. ... write disaggregated precipitation to files. ... index will be done Inputfile: /nvme/h/onabavi/data_p002/era5/ANOG__SL.20160701.65354.65355.grb Inputfile: /nvme/h/onabavi/data_p002/era5/ANOG__ML.20160701.65354.65355.grb Inputfile: /nvme/h/onabavi/data_p002/era5/ANSH__SL.20160701.65354.65355.grb ... index done current product: ('20160701', '0', '0') ECCODES ERROR : wrong size (0) for pv it contains 276 values ECCODES ERROR : get: pv Passed array is too small ... ERROR CODE: 250 ... ERROR MESSAGE: }}} run_local.sh {{{ QUEUE= START_DATE='20160701' END_DATE='20160702' DATE_CHUNK=None JOB_CHUNK=3 BASETIME=None STEP=None LEVELIST=None AREA=None INPUTDIR='/nvme/h/onabavi/data_p002/era5' OUTPUTDIR='/nvme/h/onabavi/data_p002/era5' PP_ID=None JOB_TEMPLATE= CONTROLFILE='/onyx/amd/h/onabavi/flex_extract/Run/Control/CONTROL_EA5' DEBUG=0 REQUEST=0 PUBLIC=0 }}} {{{ }}} CONTROL_EA5 {{{ START_DATE 20190901 END_DATE 20190903 DTIME 1 TYPE AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ACCTYPE FC ACCTIME 06/18 ACCMAXSTEP 12 CLASS EA STREAM OPER GRID 0.28125 LEFT 43. LOWER 10. UPPER 38. RIGHT 63. LEVELIST 1/to/137 RESOL 799 ETA 1 FORMAT GRIB2 PREFIX EA CWC 1 RRINT 1 ECTRANS 1 }}} Any help is highly appreciated, Omid." omid.nabavy Milestone 331 problem with importing eccodes library in flex_extract_v7.1.3 flex_extract flex_extract_v7.1 Support closed 2023-03-08T17:08:56Z 2023-03-09T13:45:45Z "Hello I can't solve a problem with running the new run_bologna script to extract ecmwf fields using the remote access on my new ATOS home directory. I got the following error message in the job output message {{{ MARS retrieve done ... Prepare 20220831/to/20220831 Traceback (most recent call last): File ""/home/tpn/flex_extract_v7.1.3/Source/Python/submit.py"", line 272, in main() File ""/home/tpn/flex_extract_v7.1.3/Source/Python/submit.py"", line 110, in main prepare_flexpart(ppid, c) File ""/home/tpn/flex_extract_v7.1.3/Source/Python/Mods/prepare_flexpart.py"", line 161, in prepare_flexpart flexpart.deacc_fluxes(inputfiles, c) File ""/home/tpn/flex_extract_v7.1.3/Source/Python/Classes/EcFlexpart.py"", line 974, in deacc_fluxes from eccodes import (codes_index_select, codes_get, File ""/usr/local/apps/python3/3.8.8-01/lib/python3.8/site-packages/eccodes/__init__.py"", line 13, in from .eccodes import * # noqa File ""/usr/local/apps/python3/3.8.8-01/lib/python3.8/site-packages/eccodes/eccodes.py"", line 12, in from gribapi import ( File ""/usr/local/apps/python3/3.8.8-01/lib/python3.8/site-packages/gribapi/__init__.py"", line 13, in from .gribapi import * # noqa File ""/usr/local/apps/python3/3.8.8-01/lib/python3.8/site-packages/gribapi/gribapi.py"", line 34, in from gribapi.errors import GribInternalError File ""/usr/local/apps/python3/3.8.8-01/lib/python3.8/site-packages/gribapi/errors.py"", line 16, in from .bindings import ENC, ffi, lib File ""/usr/local/apps/python3/3.8.8-01/lib/python3.8/site-packages/gribapi/bindings.py"", line 35, in raise RuntimeError(""Cannot find the ecCodes library"") RuntimeError: Cannot find the ecCodes library I have checked that eccodes is indeed mounted using python3 -m eccodes selfcheck The submitscript.template looks correct with module load python3 module load ecmwf-toolbox module load ecaccess }}} Error occurs when processing the flux accumulated fields. Could you help to solve this problem ? Best regards Gerard" gance Milestone flex_extract_v7.1.1 262 FIX: Makefile naming in flex_extract v7.1 in documentation flex_extract flex_extract_v7.1 Task anphi closed 2020-02-28T09:04:56Z 2020-04-01T18:31:17Z "The on-line documentation still contains the old makefile names. " anphi Milestone flex_extract_v7.1.1 263 FIX: Change installation check for flex_extract's v7.1 gateway and destination parameter flex_extract flex_extract_v7.1 Task anphi closed 2020-02-28T09:12:08Z 2020-03-08T14:44:16Z "If the software is to be installed on any ECMWF server, the `setup.sh` script checks whether all necessary parameter are set, namely `ECUID`, `ECGID`, `GATEWAY` and `DESTINATION`. This approach assumes to have a local gateway server in place! If this is not the case and the user will just work on ECMWF server directly and sends the resulting files via `ssh`, it is NOT necessary to set `GATEWAY` and `DESTINATION`. Check needs to be changed. " anphi Milestone flex_extract_v7.1.1 264 FIX: Update makefile for ECMWF server in flex_extract v7.1 flex_extract flex_extract_v7.1 Task pesei closed 2020-02-28T09:21:27Z 2020-03-08T15:16:00Z "The makefiles for ECMWF server are not up-to-date and still search for `.f` files. Fortran files were changed to `.f90` recently. The task is to check all makefiles, correct them and check them for all application modes and all platforms. " anphi Milestone flex_extract_v7.1.1 265 FIX: Change fortran executable name in documentation of flex_extract v7.1 flex_extract flex_extract_v7.1 Task anphi closed 2020-02-28T09:24:37Z 2020-04-01T18:30:52Z "The name of the Fortran executable was changed in v7.1 from `CONVERT2` to `calc_etadoc<_fast/debug><.out>`. Not changed yet in the on-line documentation. Still needs to be done and checked!" anphi Milestone flex_extract_v7.1.2 230 ERA5 retrieval with ECMWF Web API is deprecated; new CDS API is needed flex_extract flex_extract_v7.1 New feature anphi closed 2019-02-27T18:08:25Z 2020-07-16T18:48:33Z "With the end of February 2019, ECMWF will terminate their ECMWF Web API access to ERA5 data. This is because the C3S (Copernicus Climate Change Service) has build a new service, the Climate Data Store (CDS)[https://cds.climate.copernicus.eu/]. Up to now, they provide online access to a limited set of ERA5 pressure and single level data. The rest is still archived in MARS on ECMWF servers. At some point in time, they will move all ERA5 data to the CDS. Therefore a new feature for flex_extract have to be added to support ERA5 data download with the new CDS API[https://pypi.org/project/cdsapi/]. " anphi Milestone flex_extract_v7.1.3 285 "MARS request for ERA5 surface flux data returns ""No data is available"" error" flex_extract flex_extract_v7.1 Support anphi closed 2020-11-23T05:58:34Z 2021-07-21T08:52:32Z "Dear FLEXPART community, Recently I use flex_extract (v7.1.2) to download ERA5 data. I found that for some dates the request for ERA5 surface flux data will encounter an error as below: {{{ 2020-11-23 11:31:16,800 INFO Request is failed 2020-11-23 11:31:16,801 ERROR Message: no data is available within your requested subset 2020-11-23 11:31:16,801 ERROR Reason: Request returned no data }}} Below is the mars request (generated by flex_extract) which triggers the error. {{{ marsclass: EA dataset: ERA5 type: AN levtype: SFC levelist: 1 repres: date: 19951101 resol: 159 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/ldaiad/flex_extract_farmers/farmer_511/Run/./Workspace/EA_temp/OG_OROLSM__SL.19951101.192867.192868.grb param: 160.128/027.128/028.128/244.128 }}} ERA5 data on some other dates can be download via the same script without any problem, but there are some *dates/periods* that the same download script gives the above error. A minimal download script to reproduce this error can be as follows. {{{ import cdsapi c = cdsapi.Client() c.retrieve('reanalysis-era5-single-levels', { ""product_type"":'reanalysis', ""area"": [40.0,-10.0,30.0,10.0], ""year"": ""1995"", ""month"": ""11"", ""day"": ['1'], ""grid"": [1.,1.], ""param"": ""160.128/027.128/028.128/244.128"", #""variable"": ['standard_deviation_of_orography', 'forecast_surface_roughness'], ""time"": ['00'], ""format"":'grib2', }, 'download_era5_flux_cdsapi.grib') }}} Note that if using the variable names instead of param (i.e. use 'standard_deviation_of_orography' and 'forecast_surface_roughness' in the commented line), I can download the data without any problem. (but somehow I can't find the variables corresponding to parameters 027.128 and 028.128.) Hence, I think this may not be a problem for flex_extract. Rather, I guess there are *some* ERA5 surface flux data *missing* in the MARS database. So my question is how I can work around this error. Can I modify the source code of flex_extract so that I can just download the ERA5 surface flux data from CDS instead of MARS? If so, how can it be done? Thank you for your time in reading this post. Any advice is much appreciated! Best, Fandy " fcheng Milestone flex_extract_v7.1.3 286 Bug for local public ERA5 data / flex_extract v7.1.2 flex_extract flex_extract_v7.1 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 Milestone flex_extract_v7.1.3 298 Running preprocessing with previously loaded grib files flex_extract flex_extract_v7.1 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 Milestone flex_extract_v7.1.3 301 Bug in flex_extract due to python3 upgrade at ECMWF ecgate env flex_extract flex_extract_v7.1 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 Milestone flex_extract_v7.1.3 304 INSTALLDIR not passed to the installation flex_extract flex_extract_v7.1 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 Milestone flex_extract_v7.2 266 FIX: Remove flex_extract v7.1 from ECMWF server before new installation flex_extract flex_extract_v7.1 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 Milestone flex_extract_v7.2 302 Create flex_extract_precip flex_extract flex_extract_v7.1 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 Milestone 330 error in flex_extract-7.1.3 flex_extract flex_extract_v7.1.2 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 Milestone 332 "Warning: ""TOO COARSE LONGITUDE RESOLUTION""" FP other flex_extract_v7.1.2 Support pesei closed 2023-03-27T08:41:21Z 2023-03-29T20:28:48Z "Dear FLEXPART community, I recently used ""flex_extract"" to prepare ERA5 data for the FLEXPART model. Everything went fine, except I noticed a warning message saying {{{""TOO COARSE LONGITUDE RESOLUTION""}}} while the calc_etadot program was running. I was downloading 1˚x1˚ hourly ERA5 data. Maybe the spatial resolution is too coarse for hourly resolution? But I don't know exactly why. Can anyone explain this, please? Also, is there any recommended setting of the spatiotemporal resolution of the ERA5 data for the FLEXPART model? Below is my data-downloading job. Many thanks for your attention. Hope you have a nice day. Best, Fandy {{{ START_DATE 20190103 END_DATE 20190104 DTIME 1 TYPE AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN AN 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ACCTYPE FC ACCTIME 06/18 ACCMAXSTEP 12 CLASS EA STREAM OPER DATASET ERA5 GRID 1. LEFT -179. LOWER -90. UPPER 90. RIGHT 180. LEVELIST 1/to/137 RESOL 799 SMOOTH 0 ETA 1 GAUSS 0 ETADIFF 0 DPDETA 1 OMEGA 0 OMEGADIFF 0 CWC 1 PREFIX EA ECTRANS 1 }}}" fcheng Milestone 335 No data is available for ERA5 in Oct 2018 flex_extract flex_extract_v7.1.2 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 Milestone 336 ERA5 flux data scaling at >1h temporal resolution flex_extract flex_extract_v7.1.2 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 Milestone 337 flex_extract7.1.2 download ERA5 (20220701-20220705) parameter 77 (etadoc) is missing flex_extract flex_extract_v7.1.2 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 Milestone 342 the cdo sinfo time of ERA5 is strange FP other flex_extract_v7.1.2 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 Milestone 343 flex_extract: TypeError: an integer is required FP other flex_extract_v7.1.2 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 Milestone FLEXPART 10.4.1 339 Segmentation fault FP other flex_extract_v7.1.2 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 Milestone flex_extract_v7.1.3 313 No flux file for the second member with ENDA ERA5 data flex_extract flex_extract_v7.1.2 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 Milestone flex_extract_v7.1.3 315 flex_extract templates with reduced level number flex_extract flex_extract_v7.1.2 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 Milestone flex_extract_v7.1.3 324 flex_extract on Atos HPCF (ECMWF) in Bologna flex_extract flex_extract_v7.1.2 Support pesei closed 2022-12-01T15:47:21Z 2022-12-01T18:17:46Z Is the procedure for installing flex_extract on the ECMWF servers Atos HPCF in Bologna available? rcesari Milestone flex_extract_v7.1.3 328 GRIB2 CONVERSION FAILED! error in flex_extract flex_extract flex_extract_v7.1.2 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 Milestone flex_extract_v7.1.3 333 CDS download for ERA5 sdor,cvh,cvl,fsor sometimes fails flex_extract flex_extract_v7.1.2 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 Milestone 170 FPv10 (2016-11-2) not working with old ECMWF GRIB1 as it was in Summer 2016 FP coding/compilation FLEXPART 10.0 Defect closed 2017-04-19T10:45:02Z 2017-06-22T14:07:52Z "In Summer 2016, I used the latest FPv10 to use two of the old 92-level ECMWF GRIB1 files in test case, and it worked fine: {{{ $ ./FP Welcome to FLEXPART Version 10.0beta (2015-05-01) FLEXPART is free software released under the GNU General Public License. Vertical levels in ECMWF data: 92 92 Mother domain: Longitude range: -179.00000 to 181.00000 Grid distance: 1.00000 Latitude range : -90.00000 to 90.00000 Grid distance: 1.00000 . . . CONGRATULATIONS: YOU HAVE SUCCESSFULLY COMPLETED A FLEXPART MODEL RUN! }}} Now, in the same test setup, I use the newest FPv10, and I get: {{{ $ ./FPnew Welcome to FLEXPART Version 10.1beta (2016-11-02) FLEXPART is free software released under the GNU General Public License. Vertical levels in ECMWF data: 92 92 Mother domain: Longitude range: 180.00000 to 540.00000 Grid distance: 1.00000 Latitude range : -90.00000 to 90.00000 Grid distance: 1.00000 -179.000000 -90.0000000 540.000000 90.0000000 180.000000 -90.0000000 181.000000 90.0000000 1.00000000 1.00000000 #### FLEXPART MODEL ERROR! PART OF OUTPUT #### #### GRID IS OUTSIDE MODEL DOMAIN. CHANGE #### #### FILE OUTGRID IN DIRECTORY #### }}} I am currently investigating the parallel computing features of this code, and may investigate this problem in more detail. " donaldjmorton Milestone 185 MQUASILAG in backward mode FP other FLEXPART 10.0 Defect closed 2017-11-21T09:26:07Z 2018-03-09T12:46:20Z "Dear all, Anyone interested in implementing the MQUASILAG in backward mode? Preferably in FP v9.02, which I currently use. But if there is a reason to rather do it already in v10 its also fine, I can wait for it. I read that some people think that the option in forward mode is not properly implemented. So I think this can be dealt with at the same time. (Im not sure yet if there is some money for this from the project, but at least I can offer co-authorship.) Thanks!" mdmulder Milestone 211 Incremental vs. cumulative deposition FP coding/compilation FLEXPART 10.0 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 Milestone FLEXPART 10 151 Improper use of MPI_IN_PLACE FP coding/compilation FLEXPART 10.0 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 Milestone FLEXPART 10 197 Inconsistent use of ew in verttransform FP coding/compilation FLEXPART 10.0 Defect pesei closed 2018-06-07T08:55:54Z 2018-06-07T12:54:00Z "I found that ew is not properly initialized in verttransform.f90 These are all the occurrences of ew in each of the verttransform*-files: verttransform.f90: {{{#!fortran real :: ew,dz1,dz2,dz ... tvold(ixm,jym)=tt2(ixm,jym,1,n)*(1.+0.378*ew*(td2(ixm,jym,1,n))/ & ps(ixm,jym,1,n)) ... tvold(ix,jy)=tt2(ix,jy,1,n)*(1.+0.378*ew(td2(ix,jy,1,n))/ & ps(ix,jy,1,n)) }}} verttransform_gfs.f90: {{{ real :: ew,pint,tv,tvold,pold,dz1,dz2,dz,ui,vi ... tvold=tt2(ixm,jym,1,n)*(1.+0.378*ew(td2(ixm,jym,1,n))/ & ps(ixm,jym,1,n)) }}} verttransform_nests.f90: {{{#!fortran real :: ew,dz1,dz2,dz ... tvold(ix,jy)=tt2n(ix,jy,1,n,l)*(1.+0.378*ew*(td2n(ix,jy,1,n,l))/ & psn(ix,jy,1,n,l)) }}} Notice that in verttransform.f90 '''ew''' is used as a variable, not a function. This variable is defined but not initialized. " adingwell Milestone FLEXPART 10 204 namelist input for RELEASES needs more checking FP coding/compilation FLEXPART 10.0 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 Milestone FLEXPART 10 232 Warnings about undefined GRiB2 messages FP input data FLEXPART 10.0 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 Milestone FLEXPART 10 191 Grib1 total cloud water field is not recognized FP other FLEXPART 10.2 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 Milestone FLEXPART 10 199 gridcheck: checking array dimensions needs to be improved FP coding/compilation FLEXPART 10.2 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 Milestone FLEXPART 10 205 Output format for trajectories.txt FP post-processing FLEXPART 10.2 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 Milestone 234 Segmentation fault in interpol_wind_short FP coding/compilation FLEXPART 10.3 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 Milestone 235 Problems when restarting from a partposit file FP coding/compilation FLEXPART 10.3 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 Milestone 237 Inconsistent netCDF output FP other FLEXPART 10.3 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 Milestone 238 Inconsistency when shifting longitudes? FP coding/compilation FLEXPART 10.3 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 Milestone 248 Inconsistency between Pisso et al paper and model behavior FP other FLEXPART 10.3 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 Milestone 260 Names of species for Version 10.3 FP input data FLEXPART 10.3 Support pesei closed 2020-02-20T05:53:16Z 2020-03-08T15:05:19Z "H all, Can someone please help me with the list of species can be simulated using FLEXPART 10.3. Thanks" tjaya Milestone FLEXPART 10 231 RELEASE time variation problem FP coding/compilation FLEXPART 10.3 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 Milestone FLEXPART 10 249 related to making FLEXPART V 10.3 FP coding/compilation FLEXPART 10.3 Defect pesei closed 2019-10-01T07:04:44Z 2020-07-16T15:28:46Z "Dear sir/madam I am trying to make FLEXPART v10.3. I am getting the .exe file of FLEXPART. But, no message like successful completion. It is giving some warning related to readpath. When I am running the excercise it is giving segmentation fault.. sometime. {{{ -345600 SECONDS SIMULATED: 16864 PARTICLES: Uncertainty: 0.000 0.000 0.000 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f2e3d573c2d in ??? #1 0x7f2e3d572e45 in ??? #2 0x7f2e3d25ef5f in ??? #3 0x5642d9636d4b in ??? #4 0x5642d965541d in ??? #5 0x5642d9625b6a in ??? #6 0x5642d960c852 in ??? #7 0x7f2e3d241b6a in ??? #8 0x5642d960c889 in ??? #9 0xffffffffffffffff in ??? Segmentation fault (core dumped) }}} Kindly help me to install FLEXPART V 10.3 Regards Sanjeev Dwivedi" sdwivedi Milestone 254 Segmentation Fault at first step in version 10.4 FP coding/compilation FLEXPART 10.4 Support pesei closed 2019-11-04T14:17:11Z 2020-07-16T15:25:50Z "Hi all, I tried to redo some simulations that succeeded with Flexpart 9.0.2 and 9.0.3. Using version 10.4, after compiling with eccodes and jasper and adapting the input files to the namelist, i get the following error: {{{ Welcome to FLEXPART Version 10.4 (2019-07-23) FLEXPART is free software released under the GNU General Public License. FLEXPART WARNING: TIME DIFFERENCE BETWEEN TWO WIND FIELDS IS BIG. THIS MAY CAUSE A DEGRADATION OF SIMULATION QUALITY. NCEP metdata detected Vertical levels in NCEP data: 31 31 Mother domain: Longitude range: -179.00 181.00 Grid distance: 1.00 Latitude range : -90.00 90.00 Grid distance: 1.00 Releasepoints : 24 SPECIES file not in NAMELIST format, attempting to read as fixed format Average settling velocity: 1 NaN Below-cloud scavenging: OFF In-cloud scavenging: OFF Particles allocated (maxpart) : 150000 Particles released (numpartmax): 120000 Total mass released: 2.4000000E+01 Allocating fields for global output (x,y): 360 90 Allocating fields for nested output (x,y): 0 0 Concentrations are calculated using kernel Simulated 0.0 hours ( 0 s), 0 particles Global NCEP fields: using cloud water Global NCEP fields: using cloud water Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fc3510eb2da in ??? #1 0x7fc3510ea503 in ??? #2 0x7fc35171df1f in ??? #3 0x5571b5a3c530 in conccalc at /workingdir/flexpart_v10.4_e4925fb/src/conccalc.f90:128 #4 0x5571b5a49677 in timemanager_ at /workingdir/flexpart_v10.4_e4925fb/src/timemanager.f90:377 #5 0x5571b5a23e80 in flexpart at /workingdir/flexpart_v10.4_e4925fb/src/FLEXPART.f90:472 #6 0x5571b5a24250 in main at /workingdir/flexpart_v10.4_e4925fb/src/FLEXPART.f90:50 Segmentation fault (core dumped) }}} As input data I used the NCEP FNL 1deg in grib2 format (the same ones with which the older versions succeeded). Did I overlook anything? Thanks for your help. Regards, Martin" mradenz Milestone 272 particle release on a grid FP input data FLEXPART 10.4 Support pesei closed 2020-06-06T15:54:30Z 2020-07-16T15:26:47Z "Hello, is there a way to specify specific positions for particles released? For instance, is it possible to release particles on a grid defined by the user? " nehstand Milestone 277 trouble understanding init_domainfill.f90 FP coding/compilation FLEXPART 10.4 Support closed 2020-07-08T18:35:03Z 2020-07-16T15:20:58Z "Hello, I am trying to understand the initialization of particles in `init_domainfill.f90`. I'm having trouble understanding the following lines (54 to 57) : {{{ nx_we(1)=max(int(xpoint1(1)),0) nx_we(2)=min((int(xpoint2(1))+1),nxmin1) ny_sn(1)=max(int(ypoint1(1)),0) ny_sn(2)=min((int(ypoint2(1))+1),nymin1) }}} As far as I understand nx_we, ny_sn are the grid indices for western, eastern, southern and northern boundary of the release domain. My question is the following : what happens if one of the longitudes and/or latitudes bounding the domain are negative? That is if one of xpoint1, xpoint2, ypoint1, ypoint2 < 0 ? It seems to me that these code lines restrict our domain to positive values. However, I know from experience, when using Flexpart, that there is no such restriction. Thank you in advance!" nehstand Milestone 284 Strange big bouncing of particles when hitting ground FP other FLEXPART 10.4 Support pesei closed 2020-10-17T02:27:18Z 2021-03-07T16:58:24Z "Dear FLEXPART community, I observe that the particles released by FLEXPART have seemingly overexaggerated bouncing behavior when they are hitting the ground, sometimes they can be reflected by a few km or even up to 10km in just one hour. This really confuses me since it just does not make sense. I think the source code that controls the bouncing of particles is related to advance.f90, and maybe also the default setting of SPECIES 24. But I just could not really identify where the problem comes from. For your information, here is my RELEASES file {{{ &RELEASES_CTRL NSPEC = 1, ! Total number of species SPECNUM_REL= 24, ! Species numbers in directory SPECIES / &RELEASE ! For each release IDATE1 = 20080601, ! Release start date, YYYYMMDD: YYYY=year, MM=month, DD=day ITIME1 = 00000, ! Release start time in UTC HHMISS: HH hours, MI=minutes, SS=seconds IDATE2 = 20080601, ! Release end date, same as IDATE1 ITIME2 = 00000, ! Release end time, same as ITIME1 LON1 = -179.000, ! Left longitude of release box -180 < LON1 <180 LON2 = 179.000, ! Right longitude of release box, same as LON1 LAT1 = -89.000, ! Lower latitude of release box, -90 < LAT1 < 90 LAT2 = 89.000, ! Upper latitude of release box same format as LAT1 Z1 = 0.000, ! Lower height of release box meters/hPa above reference level Z2 = 5000.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 = 6000000, ! Total number of particles to be released COMMENT = ""RELEASE 1 test, particles released in an hour."", ! Comment, written in the outputfile / }}} And my COMMAND {{{ &COMMAND LDIRECT= 1, ! Simulation direction in time ; 1 (forward) or -1 (backward) IBDATE= 20080601, ! Start date of the simulation ; YYYYMMDD: YYYY=year, MM=month, DD=day IBTIME= 00000, ! Start time of the simulation ; HHMISS: HH=hours, MI=min, SS=sec; UTC IEDATE= 20080601, ! End date of the simulation ; same format as IBDATE IETIME= 210000, ! 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= 1, ! 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= 0, ! 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= 0, ! 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= 1, ! Switch for domain-filling, if limited-area particles generated at boundary IND_SOURCE= 1, ! Unit to be used at the source ; [1]mass 2]mass mixing ratio IND_RECEPTOR= 1, ! Unit to be used at the receptor; [1]mass 2]mass mixing ratio 3]wet depo. 4]dry depo. MQUASILAG= 1, ! 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 / }}} And, here is the hourly altitude (meters a.g.l.) of a particle that had a big bounce (and there are many particles with such a behavior) {{{ 397.4110413 40.72389984 537.1908569 289.5689392 937.1464233 323.7579346 98.35718536 138.9232025 74.352005 155.2883759 11351.6709 11257.2832 11149.76074 11025.70117 10902.66504 10848.78516 10827.65918 10822.45605 10803.74316 10752.75 10698.94824 }}} Is such a big bouncing behavior normal? Any hints and help are much appreciated. Thanks a lot! Warm regards, Fandy" fcheng Milestone 289 Why the output file is rectangle (the extent is same as the release box) FP other FLEXPART 10.4 Support pesei closed 2020-12-11T07:54:05Z 2020-12-13T11:20:38Z "Hi, everyone. It seems i have successufly execute a simple case as the 'Congratulations’has appeared (FLEXPART10.4). However, the grid_conc* file is rectangle, not the same as previous study that spread far away. The COMMAND file and RELEASE file set correctly. " xu_ru Milestone 291 GRIB_API ERROR: grib_get: centre Invalid grib id with NCEP_FNL data FP input data FLEXPART 10.4 Support closed 2020-12-17T02:46:01Z 2021-01-07T13:20:49Z "Hi, everyone, I have successfully run CERA-C20 data before. Recenly, I run FLEXPART 10.4 using NCEP-FNL (grib1) data from 2007-03-01 to 2007-03-05. I successfuly compiling FLEXPART FNL by revise parameters in par_mod.f90. However, the attach error appear when i run ./FLEXPART. Have you ever know this error?" xu_ru Milestone 294 domain filling runs output for each release is forbidden FP input data FLEXPART 10.4 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 Milestone 296 "Compiling fails on Mac OS 10.15 with ""unable to execute command: Illegal instruction"" error" FP coding/compilation FLEXPART 10.4 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 Milestone 303 Flexpart V10.4 example contained in Pisso et al. (2019) fails FP coding/compilation FLEXPART 10.4 Support closed 2021-06-07T12:18:58Z 2022-01-24T16:30:29Z "I have installed Flexpart V10.4 along with Flexextract etc. on a Lubuntu 20.04 system. So far as I can see the installation went well. To proceed with testing my aim was to run the first example described in Pisso et al. (2019). I have used Flex_extract to download the relevant input met data: {{{ $flex_extracthome/Python>./submit.py --start_date 20170102 --controlfile CONTROL_EA5 }}} and this succesfully results in the EA17010200 etc. files. I then proceeded to amend the pathnames file to point to the correct locations and run Flexpart. Since I assumed the AVAILABLE, OUTGRID, COMMAND and RELEASES files etc. sent with Flexpart would match this example I did not edit them. However, these example files do not match and it seems they are for another date (20120101). Given this I attempted to amend the relevant input files to match the met data I had downloaded. Having done this I have managed to get past many of the initial errors. However, I am now stuck with a series of GRIB1 and GRIB2 message errors e.g.: {{{ ***WARNING: undefined GRIB2 message found! 192 128 27 1 parID 27 isec1(6) ***WARNING: undefined GRIB2 message found! 192 128 28 1 parID 28 isec1(6) ***WARNING: undefined GRIB2 message found! 192 128 244 1 parID 244 isec1(6) ***ERROR: input file needs to contain GRIB1 formatted messages }}} I would appreciate knowing how to resolve this issue. That or which met data I should download to match the other input files associated with Flexpart V10.4. One other point, I also get the following note: {{{ Note: The following floating-point exceptions are signalling: IEEE_DENORMAL }}} Perhaps this is related and points to other issues I may have? " msalter Milestone 311 flex_extract 7.1.2 local extraction no flux data flex_extract FLEXPART 10.4 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 Milestone 317 Correct OH reaction coefficients for SO2, CO FP other FLEXPART 10.4 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 Milestone 318 reading receptor output FP post-processing FLEXPART 10.4 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 Milestone 321 UNKNOWN METDATA FORMAT error while using NCEP data FP other FLEXPART 10.4 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 Milestone 323 Wrong scaling of snow depth and convective precip when reading ECMWF input in GRIB2 FP input data FLEXPART 10.4 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 Milestone 325 Flexpart v10.4 test cases run FP input data FLEXPART 10.4 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 Milestone 326 error: STOP READWIND: NUVZ NOT CONSISTENT FP other FLEXPART 10.4 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 Milestone 338 FLEXPART failing on eccodes v2.30.0 FP other FLEXPART 10.4 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 Milestone FLEXPART 10 257 Issue with warm start FP other FLEXPART 10.4 Support closed 2020-01-14T12:57:15Z 2020-07-16T15:41:11Z "I am using Flexpart 10.4 and am trying to restart from the positions of the last simulation in partposit_end. But I am not sure how to modify the RELEASES file for the simulation to run. When I try to set PARTS = 0 (Total number of particles to be released), I get the error : FLEXPART MODEL ERROR RELEASES file is corrupt. At least for one release point, there are zero If I try to set PARTS = 1, I get : ##################################################### #### FLEXPART MODEL SUBROUTINE RELEASEPARTICLES: #### #### #### #### ERROR - TOTAL NUMBER OF PARTICLES REQUIRED #### #### EXCEEDS THE MAXIMUM ALLOWED NUMBER. REDUCE #### #### EITHER NUMBER OF PARTICLES PER RELEASE POINT#### #### OR REDUCE NUMBER OF RELEASE POINTS. #### ##################################################### I also tried to set NSPEC = 0, but then I get #### FLEXPART MODEL ERROR IN READPARTPOSITIONS#### #### THE NUMBER OF SPECIES TO BE READ IN DOES #### #### NOT AGREE WITH CURRENT SETTINGS! #### Any help will be appreciated, thank you! " nehstand Milestone FLEXPART 10 276 Problems creating NetCDf output with many output levels FP coding/compilation FLEXPART 10.4 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 Milestone FLEXPART 10 278 Receptor output - missing features FP physics/numerics FLEXPART 10.4 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 Milestone FLEXPART 10 281 problem with caldate FP other FLEXPART 10.4 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 Milestone FLEXPART 10 283 eccodes error when using ERA5 data as Flexpart's input FP coding/compilation FLEXPART 10.4 Support closed 2020-10-12T06:16:51Z 2023-09-22T08:41:14Z "Dear Flexpart community, I have encountered an error message when using ERA5 data (downloaded by flex_extract v7.1.2) as the model input for Flexpart: {{{ ECMWF metdata detected ECCODES ERROR : wrong size (244) for pv it contains 276 values ECCODES ERROR : gridcheck: Error Passed array is too small }}} It seems to point out the wrong size of the pv data (potential vorticity?). But the FLEXPART model can run without bugs if I use ERA-interim data. So I guess the error may come from the ERA5 data. Below is my CONTROL file to download the ERA5 data using flex_extract v7.1.2: {{{ START_DATE 20080601 END_DATE 20080601 DTIME 1 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 DATASET ERA5 GRID 1 LEFT -179. LOWER -70. UPPER 70. RIGHT 180. LEVELIST 1/to/137 RESOL 159 ETA 1 CWC 1 RRINT 1 FORMAT GRIB2 PREFIX EAnew ECTRANS 0 }}} Is there anything wrong with the CONTROL setting? Any helps/hints with this error message would be much appreciated. Thanks a lot! Warm regards, Fandy " fcheng Milestone FLEXPART 10 295 New interpolation scheme for precipitation FP physics/numerics FLEXPART 10.4 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 Milestone FLEXPART 10 297 gridcheck_ecmwf.f90: fix of small bug and improvements FP coding/compilation FLEXPART 10.4 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 Milestone FLEXPART 10 309 "something wrong Matlab read the output ""header"" from FLEXPART10.4" FP post-processing FLEXPART 10.4 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 Milestone FLEXPART 10.4.1 269 Compilation without netCDF not properly implemented, grib_api -> eccodes FP coding/compilation FLEXPART 10.4 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 Milestone FLEXPART 10.4.1 306 FLEXPART_MPI does not work properly with mquasilag=1 FP coding/compilation FLEXPART 10.4 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 Milestone FLEXPART 10.4.1 310 EMPTY LINES in the AVAILABLE file FP other FLEXPART 10.4 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 Milestone FLEXPART 10.4.1 316 Post-processing issue: Negative deposition values FP physics/numerics FLEXPART 10.4 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 Milestone FLEXPART 11 270 readreceptors.f90: bug in namelist version FP coding/compilation FLEXPART 10.4 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 Milestone Long-term tasks 282 Eliminate code duplications FP other FLEXPART 10.4 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 Milestone 145 meteorology data for Fukushima Accident FP input data flexpart 8.2 Support closed 2016-03-30T07:35:14Z 2016-03-30T08:25:36Z "I use GFS input data for modeling. I want to simulate fukushima nuclear accident but there is no data in accident date. How can find march-april (2011) data which I can use in Flexpart? " ebilgic Milestone 148 Can we identify source more than one? FP input data flexpart 8.2 Support pesei closed 2016-06-05T11:41:03Z 2016-06-17T17:48:48Z We can one source identify in Release file. Yet, I want to simulate radioactive plume releases from nuclear power plants in different two location. Does Flexpart allow multiple source? ebilgic Milestone 152 Flexpart postprocess FP post-processing flexpart 8.2 Support pesei closed 2016-06-16T21:52:12Z 2016-06-17T17:45:05Z "Hello. I can plot FLEXPART output with quicklook developed by radekholfman. However, I want to do some calculations with output data. For example,I want to determine area the activity concentration in the air bigger than 1E+5 at the end of 5th day at 23.00 in my sutdy area with a GIS software. But output data are binary format. There is a subroutine developed by Stohl to read Flexpart output. But I don't understand how I can use it. Is it possible to output data convert from binary format to readable/editable format with these codes? if so, how can I do? I have one question too. If direction is forward, ind_source and ind_receptor are 1, and input unit is kg, output unit is ng/m3 (according to table 2 in FLEXPART82 document). My input unit is Bq an the other variables are same, so, my output unit is pBq/m3, isn't it? " ebilgic Milestone 188 AVAILABLE file problems FP other flexpart 8.2 Support pesei closed 2017-12-21T13:42:08Z 2018-02-09T18:45:54Z "Hello everyone, I am new to flexpart and having some problem in running model. The error I am getting is {{{ #### FLEXPART MODEL ERROR! NO WIND FIELDS #### #### AVAILABLE FOR SELECTED TIME PERIOD. #### }}} I am using input data from NCEP FNL since GFS data one was not available for year 2016. I have tried with two kinds of AVAILABLE files (self generated as mkAVAIL.py didn't work for FNL data) but the error is same. Both the files have been attached for reference. Any help would be greatly appreciated. Thank you in advance." psrivastava Milestone FLEXPART 10 31 Wet deposition - problems with in-cloud/below-cloud scheme FP physics/numerics flexpart 8.2 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 Milestone FLEXPART 9.2 36 Convection - don't call every time step FP physics/numerics flexpart 8.2 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 Milestone FLEXPART 9.2 48 Crash with grib1 GFS/FNL FP input data flexpart 8.2-2 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 Milestone 221 Issue while running FLEXPART 9.0 with FNL 2014 and earlier years data. FP input data FLEXPART 9.0 Support pesei closed 2019-01-08T17:02:30Z 2020-05-06T13:44:48Z "Dear all, I am facing a problem while running FLEXPART 9.0 with FNL 2014 and earlier years data. It is showing the following error message. GRIB_API ERROR : JPEG support not enabled. GRIB_API ERROR : unable to get codedValues as double array (Function not yet implemented) GRIB_API ERROR : gridcheckwind_gfs: Error Function not yet implemented. However, the model is running perfectly with 15 January 2015 onward. While posting this issue we noticed a related issue by Dr. Harish from Ahmedabad regarding FNL data from 14 January 2015 (https://www.flexpart.eu/ticket/220). Kindly suggest some solution to resolve this problem. With regards Akhil " arajst Milestone 250 Error: input file needs to contain GRiB1 formattedmessages FP input data FLEXPART 9.0 Support pesei closed 2019-10-09T14:37:49Z 2019-11-08T13:18:03Z "I find the following error message while executing the model. ***ERROR: input file needs to contain GRiB1 formattedmessages I found it is due to gridcheck.f90, line number 383. I am using ECMWF data downloaded via copernicus using API request. So I have a sinfle grib file that contains u and v component of wind, and vertical velocity at 3 hour duration for a month.Please tell me whether it is due to any compatibility issue of grib file with FLEXPART 9.0. Kndly guide me in fixing the issue. Im attaching my AVAILABLE and pathname files. " nanditha Milestone FLEXPART 9.2 57 Wrong version strings in header and header_nest files FP other FLEXPART 9.0 Defect anphi closed 2013-11-26T10:53:28Z 2014-05-23T16:45:46Z "When reading outputs from FLEXPART 9.0, there are different version strings in ''header_nest'' and ''header'' files: header_nest contains ""FLEXPART V8.2"" and header contains ""FLEXPART V9.0"" which is confusing. For reading headers I used ''flex_81.py'' module: ""Reading and unpacking routines from J.Brioude (NOAA)""." radekhofman Milestone 147 Arbitrary shape of area source FP physics/numerics FLEXPART 9.0.1 Support closed 2016-05-12T09:04:53Z 2016-06-07T11:35:35Z We are trying to model an arbitrary shape of an area source. Can someone help us with this, we are not sure if FLEXPART has an option for this. Or other wise, when we try to split the arbitrary area source into smaller rectangular areas, the outputs generated for each small area source comes separately. Does FLEXPART not solve for all the multiple area sources together? tjaya Milestone 12 learning to use FLEXPART - problem with COMMAND file FP other FLEXPART 9.0.2 Support jbrioude closed 2013-08-16T16:28:07Z 2013-08-19T19:56:18Z "I've just started trying to use FLEXPART with ECMWF data. I've compiled the code successfully but when I try to the run the code I get an error: #### FLEXPART MODEL ERROR! FILE ""COMMAND"" #### #### CANNOT BE OPENED IN THE DIRECTORY #### /home/vsinclai/FLEXPART/EXERCISES/HelloWorld/options The COMMAND file is in the directory the code expects to find it and has read / execute permission so I think the format of the file is wrong. I've tried with an unformatted and formatted file but neither work. I've attached both files here. I'd greatly appreciate any help - I suspect it is a minor problem. Victoria Sinclair. (University of Helsinki) " victoria.sinclair@… Milestone 13 check for / in pathnames FP other FLEXPART 9.0.2 Enhancement somebody closed 2013-08-19T19:55:14Z 2013-09-12T16:57:45Z See #12 - implement comment:3:ticket:12 pesei Milestone 22 dates file updated before end of execution FP coding/compilation FLEXPART 9.0.2 Enhancement ignacio closed 2013-09-10T12:50:32Z 2013-09-12T16:57:08Z "Maybe we could consider updating the file ""dates"" on the fly. Sometimes FLEXPART may crash for other reasons than the model and yet you want to work with the results. It is not problematic to manually (or by a script) generate it a posteriori, but it maybe it could be considered as a small enhancement in newer versions if it is worth the effort." dearn Milestone 62 error reading ECMWF grib files, gridcheck.f90 FP input data FLEXPART 9.0.2 Support somebody closed 2014-01-29T09:39:05Z 2014-04-04T10:28:50Z "Hello, I have a problem when running Flexpart using ECMWF with a gfortran compiler. An error message appears : '***ERROR: input file needs to contain GRiB1 formatted messages' I found that the problem comes from the file ""gridcheck.f90"": ! ! GET NEXT FIELDS ! call grib_new_from_file(ifile,igrib,iret) if (iret.eq.GRIB_END_OF_FILE ) then goto 30 ! EOF DETECTED I can not find why it does not work. I can make it work by modifying gridcheck.f90 and writing a list of every name of the wind field that will be used for the run, but this is constraining and I am not sure how many fields are taken into account for the spin up. " marine Milestone 71 FLEXPART NetCDF output FP post-processing FLEXPART 9.0.2 Support hasod closed 2014-04-02T09:38:46Z 2014-10-21T07:54:49Z I would like to ask if there is any FLEXPART version available that supports NetCDF output. (other than FLEXWRF) stavros Milestone 75 installation of FLEXPART 9.0.2 FP other FLEXPART 9.0.2 Support pesei closed 2014-05-06T13:05:16Z 2014-11-21T22:20:54Z "I have been trying to installation of FLEXPART 9.0.2. My first question, does this only work on LINUX and UBuntu? The second question is that how do i go about installing this because I cant see the installation file? Regards Nkanyiso Mbatha South Africa, Cape Point GAW Station " nmbatha Milestone 76 course notes: WS11_visu.ppt FP other FLEXPART 9.0.2 Support somebody closed 2014-05-06T13:41:06Z 2014-05-07T15:17:14Z I have only started today to be interested in the FLEXPART software. I do have linux in your computer and would like to first look at the 2013 course notes that I downloaded from the FLEXPART website. My problem is that it needs a password to open. The name of the file I want to open is WS11_visu.ppt. nmbatha Milestone 82 Seasonal sensitivity plot FP post-processing FLEXPART 9.0.2 Support somebody closed 2014-06-06T05:47:49Z 2014-06-06T15:40:13Z I would like to know if there is any measure by which I can plot (using plfexible) only the average winter/summer months sensitivities resulting from a continuous backward run of 5 years or so? srvsxc Milestone 98 data resolution error FP coding/compilation FLEXPART 9.0.2 Defect pesei closed 2014-10-05T00:11:52Z 2014-10-22T18:17:19Z "Dear all, I have been trying to install FLEXPART 9.02 on my machine, Linux 64_ubuntu/ RAM: 4, but because of numerous errors I had to use already compiled file (http://packages.ubuntu.com/trusty/flexpart). Although I finally managed to install, it gives this error: FLEXPART error: Too many u,v grid points in z direction. Reduce resolution of wind fields. Or change parameter settings in file par_mod. 92 64"" I have read that in version 8 it was possible to change data resolution in ""includepar"" but in that version I got many other errors. I would be grateful if you help me to solve this issue. Best regards" omid.nabavy Milestone 114 FLEXPART-WRF of v3.2 cannot read in more than 96 met files? FP other FLEXPART 9.0.2 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 Milestone 127 Error loading shared libraries FP other FLEXPART 9.0.2 Support pesei closed 2015-11-02T14:45:50Z 2016-08-23T15:20:47Z "Hi all, I don't get any error while compiling Flexpart. But while executing I get the following message, ./FLEXPART_GFS: error while loading shared libraries: libgrib_api_f90.so.0: cannot open shared object file: No such file or directory. Here is a part of my makefile. '''Note:''' libgrib_api_f90.so.0 does exist in the LIBPATH1 in makefile. {{{ SHELL = /bin/bash MAIN = FLEXPART_GFS INCF = incl* # FC = ifort INCPATH = /gpfs1/home/Libs/INTEL/GRIB_API/include LIBPATH1 = /gpfs1/home/Libs/INTEL/GRIB_API/lib LIBPATH2 = /gpfs1/home/Libs/INTEL/JASPER/jasper-1.900.1/lib FFLAGS = -O3 -r8 -I$(INCPATH) -mcmodel=medium #LDFLAGS = $(FFLAGS) -L$(LIBPATH2) -L$(LIBPATH1) -lgrib_api_f90 -lgrib_api -lm -ljasper LDFLAGS = $(FFLAGS) -L$(LIBPATH1) -lgrib_api_f90 -lgrib_api -L$(LIBPATH2) -lm -ljasper # }}} Attention please!! Thank you in advance." srvsxc Milestone 141 Bad value during integer read. readavailable.f90 FP input data FLEXPART 9.0.2 Support pesei closed 2016-03-15T23:24:02Z 2016-08-23T15:18:16Z "Hello, when i run flexpart after configure the COMMAND file and generate the AVAILABLE file, i have the following error: at line 99 of file readavailable.f90 (uni=1, file 'path to AVAILABLE file') Fortran runtime error: Bad value during integer read. The first line about the windfield file in my AVAILABLE file looks like this: 20130614 120000 2013/201306141200.cdas1.20130614.pgrbh.grb2 " rbarragan Milestone 142 GRIB_API ERROR : gridcheck: Error Key/value not found FP other FLEXPART 9.0.2 Support pesei closed 2016-03-16T00:12:17Z 2019-11-07T05:14:18Z "When i run flexpart after configure everything i have the following error: GRIB_API ERROR : gridcheck: Error Key/value not found . I have checked the scripts bu i don't have found this error line. I don't know what is happening, " rbarragan Milestone 149 Clarification on the concentration output at different levels FP physics/numerics FLEXPART 9.0.2 Support closed 2016-06-07T09:41:01Z 2016-06-07T11:34:30Z "We are using FLEXPART for forward model run and obtaining concentrations at 3 different levels. There are few basic doubts for which we need some clarifications. 1. Whether the concentrations that we get in output are column integrated or at a particular height only? 2. If it is at a particular height only, what is the band of height within which the concentrations have been given? 3. And if it is column integrated, at the second level output, is the average along the column from the earth's surface or from the previous height/level. 4. Is there any restriction on the lowest height level at which the output can be obtained or to what minimum height would the simulations give us reliable concentration " tjaya Milestone 153 Problem while installing flexpart FP coding/compilation FLEXPART 9.0.2 Defect pesei closed 2016-07-11T08:35:01Z 2016-07-11T10:41:35Z "Dear Sir/Ms, I am trying to install flexpart in our system. The changes I have made in the Makefile are: # diff makefile.ecmwf_gfortran Makefile 6,8c6,8 < INCPATH = /xnilu_wrk/flex_wrk/bin64/grib_api/include < LIBPATH1 = /xnilu_wrk/flex_wrk/bin64/grib_api/lib < LIBPATH2 = /flex_wrk/flexpart/lib64/gfortran/lib/ --- > INCPATH = /usr/local/include > LIBPATH1 = /usr/lib64 > LIBPATH2 = /usr/lib64 During make I receive this error # make … gfortran -c -O2 -m64 -mcmodel=medium -fconvert=little-endian -frecord-marker=4 -I/usr/local/include erf.f90 erf.f90:106.26: real, external :: gammln 1 Error: Return type mismatch of function 'gammln' at (1) (REAL(4)/REAL(8)) erf.f90:111.13: gln=gammln(a) 1 Warning: Type mismatch in argument 'xx' at (1); passed REAL(4) to REAL(8) erf.f90:140.26: real, external :: gammln 1 Error: Return type mismatch of function 'gammln' at (1) (REAL(4)/REAL(8)) erf.f90:145.13: gln=gammln(a) 1 Warning: Type mismatch in argument 'xx' at (1); passed REAL(4) to REAL(8) make: *** [erf.o] Error 1 I would appreciate your help with the installation. Regards, Melina Dayan Israel Meteorological Service " mdayan Milestone 177 Error in installi Grib-API library FP other FLEXPART 9.0.2 Support pesei closed 2017-07-10T20:13:34Z 2017-10-18T09:34:34Z "Dear All, I am trying to install Grib-API library,but after I write the ""make"" command in the terminal, I get the following error: {{{ /home/maryam/lib/jasper-1.900.1//lib/libjasper.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status make[2]: *** [libgrib_api.la] Error 1 make[2]: Leaving directory `/home/maryam/lib/src/grib_api-1.23.0-Source/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/maryam/lib/src/grib_api-1.23.0-Source/src' make: *** [all-recursive] Error 1 }}} Any help would be appreciated," mhakimzadeh Milestone 186 Compile fails using gfortran due to error in erf.f90 FP other FLEXPART 9.0.2 Defect closed 2017-12-14T15:50:06Z 2017-12-14T16:31:38Z "I have built Flexpart from source on a couple of Linux machines and I always get a compile error due to a problem in erf.f90. The error message is: gfortran -c -O2 -m64 -mcmodel=medium -fconvert=little-endian -frecord-marker=4 -I/usr/lib64/gfortran/modules erf.f90 erf.f90:106.26: real, external :: gammln 1 Error: Return type mismatch of function 'gammln' at (1) (REAL(4)/REAL(8)) erf.f90:111.13: gln=gammln(a) 1 Warning: Type mismatch in argument 'xx' at (1); passed REAL(4) to REAL(8) The same error happens at line 140. The following patch allows Flexpart to compile although it may not be the best way of achieving this: aurora.hcp>diff baderf.f90 erf.f90 106c106 < real, external :: gammln --- > double precision, external :: gammln 111c111 < gln=gammln(a) --- > gln=gammln(DBLE(a)) 140c140 < real, external :: gammln --- > double precision, external :: gammln 145c145 < gln=gammln(a) --- > gln=gammln(DBLE(a)) The version of gfortran used does not appear to be important; the same thing happens with gfortran 4.8.5 on Scientific Linux 7 and with gfortran 6.3.0 on Debian 9.2. " hcpxvi Milestone 187 ECMWF data retrieval software, V4.1 for 2017 data flex_extract FLEXPART 9.0.2 Support pesei closed 2017-12-18T11:10:20Z 2019-01-17T17:10:43Z "Dear FLEXPART utilizator, I am trying to extract ECMWF windfield with ECMWF data retrieval software V4.1 on ecgate to use in FLEXPART_9.02 for windfiled in 2017. First, I had some problem to compile source.tar that I fixed by deleted one compiler option. By Now I have one problem to extract the data every 3 hours, the run seems to work for the first day but then the second day, I have the error ""ENFILE does not exist"", actually, the program did not create some intermediates file as 003 (hour). Does anyone have a program for data extraction in 2017 or a solution to this problem? Thank you in advance Sincerely Gisèle Krysztofiak " gtong Milestone 189 FLEXPART Release - Consistent Cs-137 isotope releases and output interpretation FP other FLEXPART 9.0.2 Support closed 2018-02-19T10:31:30Z 2018-03-09T12:49:54Z "Hello everyone, I'm trying to correctly set releases to simulate a nuclear plant incident. I tried with masses (Kg) to specify the release. An incident such as Fukushima or Chernobyl with about 10^16 Bq Cs-137 radionuclide activity, the corresponding mass released in the atmosphere is about 3.2Kg. With ""3.2"" set for masses and a 12hr release, the resulting Cs-137 forecasted concentrations are lower than 10^-13 (Kg/m^3 ?). Is that a sounding result or I'm missing something? Generally, what's the ""best"" way to configure a nuclear plant incident? Thank you in advance Alessandro Cheloni " acheloni Milestone 194 Flexpart from apt-get install FP coding/compilation FLEXPART 9.0.2 Support pesei closed 2018-05-10T08:57:36Z 2018-05-15T11:01:16Z "Hi! Just wondering where to find all the f90 files from the install through apt-get install (Ubuntu 18.04 LTS) for modification. E.g. where are they stored (parmod.f90, err.f90)? I also wanted to ask if someone has worked with FLEXPART code through Metview GUI, and know how to set environmental variables for FLXEPART retrieval when working in Metview? Best regards, Josefine" jaxelsson Milestone 195 Help with input file and available FP other FLEXPART 9.0.2 Support closed 2018-05-15T10:35:42Z 2018-05-15T11:07:07Z "Hi! I'm completely new to the Flexpart model, and I'm trying to modify an input file and write my available file. Would someone please have a look at it to see if it seems right? I'm working with ERA5 data, how do I handle the fact that for each day I have three files, Pressure levels (plev), Forecast (fc), and Surface data (sfc)? Each .grb file contains hours 00, 06, 12, 18 - how do I set up the available file right for that issue? Should the input file or the available file be a .py or no specific? I'm running Flexpart on Linux, and when compiled FLEXPART, my executable became just FLEXPART_GFORTRAN - should I write it as a .exe file or just let it not have a file descriptor? To execute the code, is it simply:./FLEXPART_GFORTRAN Bwd1.input ? Best regards, Josefine " jaxelsson Milestone 220 Issue with NCEP GFS data after 2015-01-14 FP other FLEXPART 9.0.2 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 Milestone 256 About stratospheric ozone tracer FP coding/compilation FLEXPART 9.0.2 Support pesei closed 2019-12-23T05:55:05Z 2020-03-08T15:06:21Z Please explain how to select release location and outgrid domain for successful run of stratospheric ozone tracer (mdomainfill=2) option in flexpart. prajjwal Milestone 279 """Too many grid points""" FP other FLEXPART 9.0.2 Support closed 2020-07-17T01:58:30Z 2020-12-16T09:37:44Z "Hello, I am using v10.4 with GFS data. I am receiving the following error: FLEXPART error: Too many grid points in x direction. Reduce resolution of wind fields. Or change parameter settings in file par_mod. 721 361 I have changed these values in par_mod. I have also checked with grep that these values do not appear in the file anymore. Yet, I continue to receive the same error message as above. Could someone tell me what I'm doing wrong? Thanks." stiwari Milestone 290 How can i get trajectory output from FLEXPART 10.4 FP other FLEXPART 9.0.2 Support closed 2020-12-16T08:54:58Z 2020-12-17T16:24:02Z "Hi, everyone, I have run a case using CEAR-20 datasets, but i can only get grid_con* result, not the 'trajectory' file. I have checked again and again for the settings in COMMAND file. But i can not find how to set the parameters to get trajectory. Is there anyone who knows how to obtain the trajectory output file. " xu_ru Milestone 308 FLEXPART-WRF: Sorry t not in [K] FP other FLEXPART 9.0.2 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 Milestone 319 Available file FP other FLEXPART 9.0.2 Support pesei closed 2022-08-24T22:07:35Z 2022-08-25T11:55:41Z "what could be the reason tha the AVAILABLE file cannot be open? I'm using flexpart 9.02, when I run FLEXPART_ECMWF_GFORTRAN command I got this message {{{ Welcome to FLEXPART Version 9.0 FLEXPART is free software released under the GNU General Public License. #### FLEXPART MODEL ERROR! FILE #### /home/nns/flex/FLEXPART_90.02/data/AVAILABLE/ #### CANNOT BE OPENED #### }}} Please help!" ashalsabila Milestone 320 Backward trajectory of PM FP input data FLEXPART 9.0.2 Support closed 2022-08-26T05:50:16Z 2022-08-26T08:43:42Z I plan to do backward trajectory of particulate matter with different diameter (PM10, PM2,5, PM1, and PM0,1) with no information about it's chemical composition, is it possible? ashalsabila Milestone 341 Test FP other FLEXPART 9.0.2 Defect closed 2023-07-05T08:13:35Z 2023-07-05T08:14:26Z admin Milestone FLEXPART 10 49 erf.f90 type mismatch with newer gfortran compilers FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 10 206 header binary file not created when compiled without netcdf support FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 10 214 global OUTGRID is rejected FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 10.4.1 122 Improve MQUASILAG option FP physics/numerics FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 11 readpartpositions.f90 seems to have a flawed value check FP coding/compilation FLEXPART 9.0.2 Defect ignacio closed 2013-08-15T21:18:53Z 2013-09-12T19:00:52Z "In readpartpositions.f90, line 79 (from version 9.0.2), there is a check for numpointin being equal to numpoint, and the program exits if this is not the case. In our case, with ongoing wildfire smoke modeling, we want to read in the particles from a previous run, but the previous run may have more or less emissions points than the current run (new fires, or extinguished fires). So, in our case I have to comment out that statement in order for the program to progress correctly. " donaldjmorton Milestone FLEXPART 9.2 50 FLEXPART can crash with some GFS data FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 56 Parameter numbers in GRIB1/GRIB2 FP input data FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 61 Wrong physical half-life of Xe-133 - SPECIES_021 FP input data FLEXPART 9.0.2 Defect saeck closed 2014-01-22T18:55:03Z 2015-03-08T17:59:07Z Physical half-life of SPECIES_021 (Xe-133) is set to 198720.0 sec, which corresponds to 2.3 days but it should be approx. 5.245 days. radekhofman Milestone FLEXPART 9.2 64 STOP sorry: t not in [k] FP input data FLEXPART 9.0.2 Defect jbrioude closed 2014-02-18T19:29:31Z 2020-09-20T20:03:34Z I am getting this error but all my met data is in Kelvin. Is this referring to the met data? sureshraja1 Milestone FLEXPART 9.2 77 Speeding up FLEXPART FP input data FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 115 Bug in readspecies.f90 FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 123 bwd runs and receptor output FP physics/numerics FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 124 Suggest easing of restriction on number of releases in readpartpositions.f90 FP other FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 134 Issue using *.grb and *.grib2 FP input data FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 137 Unit of Total mass emitted FP other FLEXPART 9.0.2 Support closed 2016-03-01T18:14:58Z 2016-03-01T21:46:33Z "Hi.. I am using FLEXPART 9.02 for forward run. I want to know about the units Total mass emitted( g or kg)." pthever Milestone FLEXPART 9.2 138 FLEXPART.f90 should not call readpaths with an argument FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 139 Bad do-loop in richardson.f90 FP coding/compilation FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 143 readwind_gfs() not reading total cloud cover from GRIB2 FP input data FLEXPART 9.0.2 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 Milestone FLEXPART 9.2 166 Output concentrations levels FP input data FLEXPART 9.0.2 Support pesei closed 2016-11-07T07:09:27Z 2017-04-26T19:04:14Z Is there an option to obtain output concentrations with respect to ground or mean seal level or different pressure levels. We understand that in OUTGRID, heights can be specified, but those are with respect to what? In the releases file, there is an option for above ground, above sea level or pressure in hpa. But does that correspond to outputs also? tjaya Milestone FLEXPART 9.2 218 Date error FP input data FLEXPART 9.0.2 Support pesei closed 2018-12-14T03:05:16Z 2018-12-20T11:41:51Z "We are new to FLEXPART and encountered an error "" There is no year zero"" We have tried changing the format of dates in the COMMAND and AVAILABLE file. However the same error appears. Even with an empty available file, the error appears too. Thank you for any comments or sharing of experiences regarding this error" jiahao Milestone FLEXPART 9.2 219 Gridcheck error message FP input data FLEXPART 9.0.2 Support pesei closed 2018-12-20T08:41:47Z 2018-12-20T11:46:02Z jiahao Milestone FLEXPART_WRF_3.4_FPbase_9 239 wrong units for deposition in FLEXPART-WRF? FP other FLEXPART 9.0.2 Defect closed 2019-05-14T11:27:37Z 2019-05-15T09:38:57Z "Dear colleagues, It seems that deposition units in output NETCDF files of FLEXPART-WRF are defined erroneously (pg·m-2) while It should be (ng·m-2) This problem was first noted because of extremely high underestimation of deposition following release scenario as compared to results of simulations of other models. E.g. dry deposition calculated by the RODOS system for the same site, same release scenario and using the same meteorological data was on average by about 3 orders of magnitude higher as compared to FLEXPART results. The source of potential error was identified by analysis of the FLEXPART code. The variable drygrid2 which is written to output netcdf file is defined in subroutine nc_write_output (source file netcdf_output_mod) as: drygrid2(ix,jy,kp,nage)=1.e12*drygrid(ix,jy)/area(ix,jy) Thus converstion to pico- units is done by multiplication on 1E12 factor here. Further inspection of code showed that the variable drygrid is in case of 1 age class and single specie simply equal to the variable drygridunc2, while the latter is defined in time loop when running model in the subroutine drydepokernel: drygridunc2(ix,jy,ks,kp,nunc,nage)= & drygridunc2(ix,jy,ks,kp,nunc,nage)+deposit(ks) Regarding the variable deposit the comment in the same subroutine states that: ! deposit amount (kg) to be deposited Thus final deposition should be in pKg·m-2=ng·m-2. Attached is file with formulas used for conversion from kg to Bq." ikovalets Milestone 255 Using GFS 0.25deg Data FP input data FLEXPART 9.0.3 Support closed 2019-11-04T14:34:14Z 2019-11-06T13:58:38Z "Hi all, has anybody ran Flexpart 9.0.3 successfully with GFS 0.25 degree data in grib2 format? (e.g. from here: [https://rda.ucar.edu/datasets/ds083.3/#!description]) After compiling with par_mod.f90 set to the larger grid {{{integer,parameter :: nxmax=1441,nymax=721,nuvzmax=64,nwzmax=64,nzmax=64}}}, the error with {{{t not in [K]}}} occurs for any input data (1deg or 0.25deg, both grib2). Hence I suspect a problem related to the grid size. Any workaround? Thanks in advance, Martin" mradenz Milestone FLEXPART 10 213 wrong unit for max convection level in gridcheck FP coding/compilation FLEXPART 9.0.3 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 Milestone FLEXPART 10 140 vertransform.f90 occasionally fails to initialize FP other FLEXPART 9.2 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 Milestone FLEXPART 10 203 inconsistency / bug in verttransform_gfs.f90 FP coding/compilation FLEXPART 9.2 Defect pesei closed 2018-08-24T16:29:29Z 2020-08-21T18:52:31Z "Dear all, in FLEXPART 9.2 I stumbled upon what is most probably a bug, and it is still present in the FLEXPART git dev branch. Comparing `verttransform.f90` (now seems to be `verttransform_ecmwf.f90`) to `verttransform_gfs.f90`, around line 500, one notices pieces of code which probably should be identical, but they aren't: for ECMWF it looks like: {{{#!fortran if (vv(nx/2-1,0,iz,n).lt.0.) then ddpol=atan(uu(nx/2-1,0,iz,n)/ & vv(nx/2-1,0,iz,n))+xlonr else if (vv(nx/2-1,0,iz,n).gt.0.) then ddpol=pi+atan(uu(nx/2-1,0,iz,n)/ & vv(nx/2-1,0,iz,n))+xlonr }}} (+ + xlonr) whereas for GFS: {{{#!fortran if(vv(nx/2-1,0,iz,n).lt.0.) then ddpol=atan(uu(nx/2-1,0,iz,n)/vv(nx/2-1,0,iz,n))+xlonr elseif (vv(nx/2-1,0,iz,n).gt.0.) then ddpol=pi+atan(uu(nx/2-1,0,iz,n)/vv(nx/2-1,0,iz,n))-xlonr }}} (+ - xlonr) I would thus propose changes as you can see in the attached picture (i.e. changing to ""+ +"" in the GFS version, and modifying the infinity case to be consistent with both approaches to the limit). [[Image(http://shaching.userweb.mwn.de/Screenshot_20180824_181601.png)]] Unfortunately, I am neither an atmospheric transport expert nor do I have an idea anymore why I fixed it this way (I looked into that like several months ago, and I think I did a comparison with corresponding code pieces in FLEXTRA). However, I think I write this here now as ""as is"" and some more expert people maybe check and fix this. Thanks very much! Stephan ----------------------------- contact: http://shaching.userweb.mwn.de" shachinger Milestone FLEXPART 9.2 117 Output unit of backward simulation for stratospheric ozone tracking FP other FLEXPART 9.2 Support jbrioude closed 2015-04-04T01:58:37Z 2015-05-11T05:23:06Z As there are three output unit for backward simulation, s, s kg/m3 and s m3/kg, how can I get mixing ratio such as ppb and ppb, in backward simulation for stratospheric ozone tracking? sulinust Milestone FLEXPART 9.2 135 FLEXPART output in NETCDF format FP post-processing FLEXPART 9.2 Support closed 2016-01-08T10:36:37Z 2016-02-01T11:37:30Z How can FLEXPART output be obtained in NETCDF format? tjaya Milestone Long-term tasks 85 Input file templates FP input data FLEXPART 9.2 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 Milestone 59 Improve error messages FP coding/compilation FLEXPART 9.2 beta 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 Milestone 113 Option for incremental wet deposition output FP physics/numerics FLEXPART 9.2 beta 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 Milestone 136 various compilation problems FP coding/compilation FLEXPART 9.2 beta Support pesei closed 2016-02-08T21:35:13Z 2016-02-14T15:38:14Z "Hello. I have been studying atmospheric dispersion of radionuclides origin a nuclear accident and I want to use flexpart for this purpose. I have been trying to compile flexpart for few months but I have encountered with some problems. 1. Any version of Flexpart which I used needs a file, ""grib_api.mod"", and current versions of grib_api doesn't create this file. Therfore I use an old version of grib_api (1.9.5). 2. Flexpart 9.2 doen't work because erf.f90 file has some problems. So I have to use flexpart 8.2 or flexpart 9.2-beta. 3. There are some warnings, when Flexpart 8.2 (32 bit or 64 bit) compiles. (Deleted features: Pause statement at (1)). I guess it is about fortran language. The compilation doesn't stop becase they are only warning. But after complete the conversion of all fortran file to object file, compilation always stops suddenly. 4. There are no warnings or errors in Flexpart 9.2. But after complete the conversion of all fortran file to object file, compilation always stops suddenly, too. As a result I cannot compile flexpart. I don't understand what my fault is? " ebilgic Milestone FLEXPART 9.2 94 Code review for changeset 27 / hasod FP coding/compilation FLEXPART 9.2 beta 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 Milestone FLEXPART 9.2 101 Code review for changeset 31 / hasod FP coding/compilation FLEXPART 9.2 beta 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 Milestone FLEXPART 9.2 118 error compling flexpart 9.2 beta on ubuntu 14.04 x64 machine FP other FLEXPART 9.2 beta Support pesei closed 2015-05-06T14:51:00Z 2016-08-23T15:23:54Z "hey, i've got flexpart 9.2, when it comes to the compilation it says; gfortran -c -O2 -m64 -mcmodel=medium -fconvert=little-endian -frecord-marker=4 -I/usr/local/incl readwind.f90:63.6: use GRIB_API 1 Fatal Error: Can't open module file 'grib_api.mod' for reading at (1): Aucun fichier ou dossier make: *** [readwind.o] Erreur 1 but this seems to be strange for me, because when i locate the file grib_api.mod, it's there in /usr/include/grib_api.mod. how can i solve this?" metroid2012 Milestone 150 Correct minor issues in grib2nc4 code and makefile FP other FLEXPART 9.3 Defect closed 2016-06-13T19:25:42Z 2016-08-23T15:03:52Z "In fp2nc4io_mod.F90, the following construct will work in gfortran v4.8.4, but in v4.4.7, the DIMENSION statement needs a specific value {{{ CHARACTER, DIMENSION(*), PARAMETER :: VALID_VARS = & & (/ 't', 'u', 'v', 'w', 'q', & & 'T', 'U', 'V', 'W', 'Q' /) }}} ---- In the Makefile, I need to add the GRIBAPI dynamic libs for the ```make test``` ---- In the Makefile, as long as I'm doing the above, I will add in some commented out variable assignments for * Paths in CTBTO system * Commands and comments for creating static binaries" donaldjmorton Milestone 154 Adding CTBTO-requested features to FPv9.3.1 GRIB2FLEXPART FP other FLEXPART 9.3 Task closed 2016-08-26T18:11:49Z 2017-06-22T14:13:15Z "* When compiled for CTBTO (`-DCTBTO`), insert a CTBTO-specific greeting * Remove the ''_fwd.fp'' and ''_bwd.fp'' extensions from the preprocessed met files. For operational purposes, it's best to have them retain the same name as the original metfile * Given that original GRIB files and preprocessed met files will have the same name, add in feature to insure no writing into the original GRIB file directory." donaldjmorton Milestone 155 Minor modifications in packaging of FPv9.3.1c for CTBTO use FP other FLEXPART 9.3 Task closed 2016-08-31T19:21:58Z 2017-06-09T14:50:18Z "This is a brief statement of some minor changes made to FPv9.3.1. No action is necessary " donaldjmorton Milestone 161 Add a dimensions check to FPv9.3.1 when reading preprocessed files FP other FLEXPART 9.3 Enhancement closed 2016-10-04T07:53:55Z 2016-11-11T15:25:47Z "Currently, the output and input of preprocessed met files (referred to as ""fp files"") is accomplished with raw binary dumps of scalars and arrays - this is done for efficiency. However, this requires that the GRIB2FLEXPART that generated the fp files is compiled with exactly the same dimensions as the FLEXPART that reads the fp files. This is not unreasonable, especially since the two binaries are generated with a single Makefile. However, in one case, a user unknowingly generated fp files with the z-dimension set to 138, and then read them with a FLEXPART where the z-dimension was 140. In this case, the program ran for a quite a while, then bombed, wasting a lot of time. Therefore, I'm going to implement a check in FLEXPART so that when it reads an fp file for input, it will insure that the dimensions written into the fp file are the same as the dimension with with FLEXPART was compiled. If this is not the case, FLEXPART will simply abort with an informative message. For anybody who reads this, please note that at this point, we're still trying to determine whether the ""raw binary dump"" is the best format for the fp files, or if we should switch to something like NetCDF4." donaldjmorton Milestone 162 Add version information to preprocessing files in FPV9.3.1 FP other FLEXPART 9.3 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 Milestone 163 FPv9.3.1 - changes related to CTBTO environment and grib2flexpart FP other FLEXPART 9.3 Enhancement closed 2016-10-12T14:05:03Z 2016-11-11T15:25:02Z "Several changes have been made by myself and Gerald Klinkl (CTBTO) * grib-api libs for ifort have moved, and I changed those in the relevant Makefiles * gfortran compilation now requires `-mcmodel=large`. It seems to be an artifact of adding more information to the preprocessed file formats. It seems like we've ""just gone over the line"" in terms of static storage. * Some preprocessed file format ""versioning"" information was modified so it's more useful to CTBTO * grib2flexpart was modified so that it will more efficiently detect (and abort) if output files already exist (in which case, because they are named just like the GRIB files, the GRIB files might be overwritten). This ticket may be closed by anybody with such authorization." donaldjmorton Milestone 172 Creating new FPv9.3.2 branch for NetCDF4 implementation of intermediate met files FP other FLEXPART 9.3 New feature closed 2017-04-27T08:00:06Z 2017-06-22T14:12:04Z "The ''FPv9.3.1'' branch has been used by CTBTO since October 2016 for testing purposes. Since then, I've changed the format of the intermediate met files from raw binary to NetCDF. To facilitate this, I'm now creating new branch (from Tag ''FPv9.3.1f''), ''FPv9.3.2'', in which I will apply modifications, and this will become the ""operational testing version"" for CTBTO." donaldjmorton Milestone 182 Documentation of changes to FPv9.3.2 FP other FLEXPART 9.3 Task donaldjmorton closed 2017-08-24T19:06:17Z 2017-08-24T19:20:00Z "I'm creating this ticket to offer documentation on changes made in ''FPv9.3.2'', primarily used by CTBTO. * Created tag ''FPv9.3.2b'' to mark the current stable version of ''FPv9.3.2'' * Made the following modifications related to CTBTO work orders focused on intermediate met data formats (now in NetCDF4): {{{ modified: fpmetbinary_mod.F90 modified: grib2nc4/Makefile modified: grib2nc4/README modified: grib2nc4/fp2nc4io_mod.F90 modified: grib2nc4/grib2nc4.F90 new file: grib2nc4/nc4cmp.F90 modified: grib2nc4/processmetfields.F90 new file: grib2nc4/verttransform_grib2nc4_ecmwf.f90 new file: grib2nc4/verttransform_grib2nc4_gfs.f90 }}} * Created new tag, ''FPv9.3.2c'' to mark the above modifications. This ticket may be closed by whoever has the authority to close tickets." donaldjmorton Milestone 192 Issue during install of FLEXPARTv9.3. FP coding/compilation FLEXPART 9.3 Support closed 2018-04-17T12:45:26Z 2018-05-28T18:07:19Z "Dear all, I receive error once I run the command ""make -f makefile.gfortran: {{{ Josefines-MacBook-Air-2:flexpart_code josefineaxelsson$ make -f makefile.gfortran gfortran -c -O2 -m64 -mcmodel=medium -fcheck=all -fconvert=little-endian -frecord-marker=4 -I/usr/local/include -DPERFTIMER class_vtable_mod.F90 gfortran -c -O2 -m64 -mcmodel=medium -fcheck=all -fconvert=little-endian -frecord-marker=4 -I/usr/local/include -DPERFTIMER grib2check.F90 gfortran -c -O2 -m64 -mcmodel=medium -fcheck=all -fconvert=little-endian -frecord-marker=4 -I/usr/local/include -DPERFTIMER fpgridcheck.F90 gfortran -c -O2 -m64 -mcmodel=medium -fcheck=all -fconvert=little-endian -frecord-marker=4 -I/usr/local/include writeheader.f90 gfortran -c -O2 -m64 -mcmodel=medium -fcheck=all -fconvert=little-endian -frecord-marker=4 -I/usr/local/include assignland.f90 /var/folders/bh/tl9b2kj11qg1cf4vttxlbhp80000gn/T//ccgoJe5a.s:84:2: error: unsupported symbol modifier in relocation movabsq $37440000+_xlandusep.3473@GOTOFF, %rax ^ make: *** [assignland.o] Error 1 }}} All the paths should be set accordingly in the makefile.gfortran, hence I don't see why there is an error. Is anyone willing to help me solve it? Best! " jaxelsson Milestone 299 Synchronised FPv9.3.2 with current CTBTO version FP other FLEXPART 9.3 New feature closed 2021-04-27T18:18:35Z 2021-04-27T18:23:49Z "This ticket serves as notification/documentation of a change made to the Flexpart CTBTO (v9.3.2) branch. By request, I have updated the flexpart.eu FPv9.3.2 branch so that it is identical to the master branch being stored internally at CTBTO. The only change this presents is that a new utility (developed in Spring 2020), ''checkgrib'', was added in ''flexpart_code/checkgrib/'' This tool is used internally for checking various attributes of GRIB files before actually running in FLEXPART, with the intent of finding majour problems in GRIB files before wasting time on a simulation. Documentation is available in ''flexpart_code/checkgrib/README.md'' Additionally, I created tag ''FPv9.3.2f'' for this current version." donaldjmorton Milestone FLEXPART 10 243 New NCEP FV3 GRIB files result in minor FLEXPART errors FP input data FLEXPART 9.3 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 Milestone 14 runtime errors linked to compile-time options FP coding/compilation FLEXPART-WRF Support jbrioude closed 2013-08-30T14:51:55Z 2013-09-19T14:56:48Z "Kind Flexpart team, I'm trying to run a Flexpart-WRF (version 3) simulation but I encounter code-related runtime errors. I'm compiling flexpart using a PGI compiler: - if I compile with openmp, the program compiles with no error, but at runtime it returns only a ""segmentation fault (core dumped)"" error (even at verbosity 100) - if I streamline compilation reducing the needs of external libraries with a ""serial"" compilation, the program compiles with no error but at runtime it returns ""PGFIO-F-235/formatted write/unit=6/ edit descriptor does not match item type. File name=stdout formatted, sequential access record=7 In source file_read_ncwrfout.f90 at line number 781"". May it be linked with the wrf netcdf extension? My wrf netcdf files are written with no final .nc in filename (see attached input and available files)." wintermute Milestone 53 FLEXPART-WRF v3.1 FP other FLEXPART-WRF New feature somebody closed 2013-11-01T15:14:51Z 2013-11-01T15:15:21Z "Dear Flexpart users, A new version of FLEXPART-WRF (version 3.1) is now available for download at http://flexpart.eu/wiki/FpLimitedareaWrf The model description is published at http://www.geosci-model-dev.net/6/1889/2013/gmd-6-1889-2013.html For those of you who have used FLEXPART-WRF v3.0, version 3.1 has some bugfixes and we recommend you to use the latest version. A bug was found related to the sign of the sensible heat flux read from WRF which subsequently made FLEXPART-WRF underestimate the turbulence in a convective PBL in the Hanna scheme, and overestimate it in stable conditions. This bug doesn’t affect FLEXPART-ECMWF. Minor fixes were also applied to the skewed PBL scheme (CBL), to the PBL schemes that use TKE, and the NetCDF FLEXPART-WRF output format when a nested domain is used. Detailed explanations can be found at http://www.geosci-model-dev-discuss.net/6/C1467/2013/gmdd-6-C1467-2013.pdf Kind Regards" jbrioude Milestone 68 Problem with OUTGRID felxpart wrf FP other FLEXPART-WRF Support jbrioude closed 2014-03-30T05:38:23Z 2014-04-02T11:59:51Z "Hello, I have a problem to create an outgrid domain. I need a little bit smaller domain than the mother one. but i try a lot of values to test and run flexpart-wrf but no thing works. and already i get this erreur. £ of vertical levels in WRF data n_bottom_top & ""true"" nuvz: 50 50 nwz & ""augmented"" nuvz: 51 51 nwzmax, nuvzmax, nzmax : 61 61 61 nconvlevmax, nconvlev : 60 49 nx, ny, nxmax, nymax : 149 119 334 334 Mother domain: east-west range: 0.0 2220000.0 Grid distance: 15000.0 south-north range: 0.0 1770000.0 Grid distance: 15000.0 *** ll_to_xyindex_wrf error -- x_i, y_j out of bounds x_lon, y_lat = 2.160E+08 1.500E+08 x_i, y_j = 1.387E+09 -1.764E+03 forrtl: severe (59): list-directed I/O syntax error, Now i am confused what i should putting in FORMER OUTGRID namelist. my domaine is : LON :-10.52 to 12.52 LAT : 28.22 N 43.07 N with 15Km resolution and mercator projection -9.0 OUTLONLEFT geograhical longitude of lower left corner of output grid 29 OUTLATLOWER geographical latitude of lower left corner of output grid 120 NUMXGRID number of grid points in x direction (= # of cells ) 100 NUMYGRID number of grid points in y direction (= # of cells ) 0 OUTGRIDDEF outgrid defined 0=using grid distance, 1=upperright corner coordinate 1800000 DXOUTLON grid distance in x direction or upper right corner of output grid 1500000 DYOUTLON grid distance in y direction or upper right corner of output grid 3 NUMZGRID number of vertical levels " rab_h Milestone 69 flexwrfv3.0 running problem FP other FLEXPART-WRF Support somebody closed 2014-04-01T01:13:07Z 2014-04-01T07:10:45Z "Hi i try to run felxpart-wrf. I configure my flexwrf.input namelist but when try to run it i have this message error : [rabah@localhost flexwrf_v31_testcases]$ ./flexwrf30_intel_serial flexwrf.input the input file used is flexwrf.input ---------------- INFORMATION: SUBGRIDSCALE TERRAIN EFFECT IS NOT PARAMETERIZED DURING THIS SIMULATION. ---------------- test_xyindex_to_ll_wrf calling map_set -- map_proj_id, map_set_proj_code = 1 3 test_xyindex_to_ll_wrf -- lgrid, rmserr (km) = 0 1.79E-03 # of vertical levels in WRF data n_bottom_top & ""true"" nuvz: 50 50 nwz & ""augmented"" nuvz: 51 51 nwzmax, nuvzmax, nzmax : 61 61 61 nconvlevmax, nconvlev : 60 49 nx, ny, nxmax, nymax : 149 119 334 334 Mother domain: east-west range: 0.0 2220000.0 Grid distance: 15000.0 south-north range: 0.0 1770000.0 Grid distance: 15000.0 forrtl: severe (24): end-of-file during read, unit 1, file /home/rabah/disp_project/flexwrf_v3.0/flexwrf_v31_testcases/flexwrf.input Image PC Routine Line Source libintlc.so.5 00007F18985F6F6A Unknown Unknown Unknown libintlc.so.5 00007F18985F5AE5 Unknown Unknown Unknown libifcore.so.5 00007F18994B2B92 Unknown Unknown Unknown libifcore.so.5 00007F189942852B Unknown Unknown Unknown libifcore.so.5 00007F1899427C3E Unknown Unknown Unknown libifcore.so.5 00007F18994630E7 Unknown Unknown Unknown flexwrf30_intel_s 00000000004E75B5 Unknown Unknown Unknown flexwrf30_intel_s 000000000046B473 Unknown Unknown Unknown flexwrf30_intel_s 000000000040286C Unknown Unknown Unknown libc.so.6 00007F189807DAFD Unknown Unknown Unknown flexwrf30_intel_s 0000000000402769 Unknown Unknown Unknown Please find attached my flexwrf.input" rab_h Milestone 70 flexwrfv3.1 running problem FP other FLEXPART-WRF Support somebody closed 2014-04-01T16:58:04Z 2014-04-02T09:44:45Z "Hi I try running flexwrf V 3.1, [rabah@localhost flexwrf_v31_testcases]$ ./flexwrf31_intel_serial flexwrf.input the input file used is flexwrf.input ---------------- INFORMATION: SUBGRIDSCALE TERRAIN EFFECT IS NOT PARAMETERIZED DURING THIS SIMULATION. ---------------- test_xyindex_to_ll_wrf calling map_set -- map_proj_id, map_set_proj_code = 1 3 test_xyindex_to_ll_wrf -- lgrid, rmserr (km) = 0 1.79E-03 # of vertical levels in WRF data n_bottom_top & ""true"" nuvz: 50 50 nwz & ""augmented"" nuvz: 51 51 nwzmax, nuvzmax, nzmax : 61 61 61 nconvlevmax, nconvlev : 60 49 nx, ny, nxmax, nymax : 149 119 334 334 Mother domain: east-west range: 0.0 2220000.0 Grid distance: 15000.0 south-north range: 0.0 1770000.0 Grid distance: 15000.0 forrtl: severe (24): end-of-file during read, unit 1, file /home/rabah/disp_project/flexwrf_v3.0/flexwrf_v31_testcases/flexwrf.input Image PC Routine Line Source libintlc.so.5 00007F563D2E2F6A Unknown Unknown Unknown libintlc.so.5 00007F563D2E1AE5 Unknown Unknown Unknown libifcore.so.5 00007F563E19EB92 Unknown Unknown Unknown libifcore.so.5 00007F563E11452B Unknown Unknown Unknown libifcore.so.5 00007F563E113C3E Unknown Unknown Unknown libifcore.so.5 00007F563E14F0E7 Unknown Unknown Unknown flexwrf31_intel_s 00000000004E70BB Unknown Unknown Unknown flexwrf31_intel_s 000000000046B3E3 Unknown Unknown Unknown flexwrf31_intel_s 00000000004028BC Unknown Unknown Unknown libc.so.6 00007F563CD69AFD Unknown Unknown Unknown flexwrf31_intel_s 00000000004027B9 Unknown Unknown Unknown [rabah@localhost flexwrf_v31_testcases]$ attached the namelist used." rab_h Milestone 83 FlexWRF runtime error FP input data FLEXPART-WRF Support jbrioude closed 2014-06-10T04:53:41Z 2014-06-11T14:32:17Z "Hi, I would greatly appreciate your help with the following runtime error: I have run WRF V3.3 and, in attempting to run FlexWRF using the WRF output, I get the following fatal error: FLEXPART WARNING: NO WIND FIELDS ARE AVAILABLE. I have checked my WRF output variable listing and compared it against the required variables for FlexWRF (as per the Brioude et al , 2013 paper in Geosci. Model. Dev.). I can also view the WRF output variables, so the data have been generated. I have even tried running with a larger nest, but get the same error. Previously, I ran FlexWRF successfully run for the testcase (i.e. with Flexwrf.input.forward1 and the downloaded test WRF output files), so I am certain that it is not a compiler issue. I have attached my input file, log file and output header file. Thank you in anticipation for your kind assistance. PeterD" Peter_D Milestone 93 problem when running in OpenMP mode FP other FLEXPART-WRF Support jbrioude closed 2014-07-01T09:09:49Z 2014-11-18T04:44:28Z "Hello, I am running Flexpart-WRF 3.1 for nested input and output domains with 10 million particles. I get significantly different tracer clouds when I run in serial (1 cpu) or in OpenMP mode (4 or 6 OpenMP threads). For the OpenMP run it seems as if the tracer cloud would have much less particles (resembles a run with 2-3 million particles) then in the serial run (see attached plots). There is no difference between the 4 and 6 thread OpenMP runs and I get the same problem with gnu and intel compilers. When I do not use input and output nesting, then there seems to be no such problem (i.e. serial and OpenMP runs are rather similar). Thanks a lot for your help in advance. Balazs " bszintai Milestone 96 FLEXWRF3.1 output in lat/lon grid FP input data FLEXPART-WRF Support jbrioude closed 2014-08-04T20:17:05Z 2014-08-08T03:44:11Z "Hi FPers, I would like to thank all the develops of FLEXWRFv3.1 for your hard work. I run it perfectly with OUTGRID_COORD set to 0, which means the output will adopt the grids in wrf fields. However, when I try to set OUTGRID_COORD to 1 and expect to get a lat/lon grid output, I was confused about settings in the OUTGRID part and couldn't run the package. Actually, the descriptions of several parameters in this section are confusing to me. I hope '''someone can share with me a working input file with OUTGRID_COORD set to 1'''[[BR]], and explain a little bit more about how to set the following parameters right. OUTLONLEFT OUTLATLOWER (these two were actually need to be set as meter coordinate when OUTGRID_COORD was set to 0 and wrf files in meter coordinate. The description says geographical lon/lat) NUMXGRD NUMYGRID (As I found out for my case, when OUTGRID_COORD was set to 0, these two were grids set within the wrf domain.) OUTGRIDDEF DXOUTLON DYOUTLON (I think this is a typo, should be DYOUTLAT.) I tried my old settings in 8.22, OUTLONLEFT as -179, OUTLATLOWER as 0 , NUMXGRID as 360 and NUMYGRID as 90 for a full North Hemisphere run. The settings do not work here. The nc output feature is very nice, but the description for these settings may need to be specified more according to the griding method. I am now testing by guessing how these parameters are taken and digging into the fortran codes. Hope someone can help me out. Many thanks, Bo Zhang Michigan Technological University " bzhang Milestone 97 FLEXWRF3.1 compiling issue with netcdf4.3.2 FP coding/compilation FLEXPART-WRF Defect jbrioude closed 2014-08-18T15:50:22Z 2014-11-07T12:51:03Z "The package was compiled fine with netcdf3.6. I just updated my netcdf lib to 4.3.2 because of a requirement from a software ncview. The netcdf was installed with netcdf4 enable for supporting ncview. After the update, I changed the dir for netcdf and flag for netcdf in the makefile, then it wont compile with the following errors: gfortran -c -I/home/bzhang3/research/libs/netcdf/include -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check write_ncheader.f90 write_ncheader.f90:126.60: ncret = nf_create(path(1)(1:length(1))//ncname, NF_NETCDF4,ncid) 1 Error: Symbol 'nf_netcdf4' at (1) has no IMPLICIT type write_ncheader.f90:359.10: ncret = NF_DEF_VAR_deflate(ncid,nclonvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:372.10: ncret = NF_DEF_VAR_deflate(ncid,nclonvid2, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:383.10: ncret = NF_DEF_VAR_deflate(ncid,nclatvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:391.10: ncret = NF_DEF_VAR_deflate(ncid,nclatvid2, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:401.10: ncret = NF_DEF_VAR_deflate(ncid,nclvlvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:412.10: ncret = NF_DEF_VAR_deflate(ncid,ncspcvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:420.10: ncret = NF_DEF_VAR_deflate(ncid,ncagevid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:430.10: ncret = NF_DEF_VAR_deflate(ncid,ncrecvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:438.10: ncret = NF_DEF_VAR_deflate(ncid,ncrnvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:448.10: ncret = NF_DEF_VAR_deflate(ncid,ncrtvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:459.10: ncret = NF_DEF_VAR_deflate(ncid,ncrxvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:470.10: ncret = NF_DEF_VAR_deflate(ncid,ncryvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:481.10: ncret = NF_DEF_VAR_deflate(ncid,ncrzvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:491.10: ncret = NF_DEF_VAR_deflate(ncid,ncspvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:500.10: ncret = NF_DEF_VAR_deflate(ncid,ncrmvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:515.10: ncret = NF_DEF_VAR_deflate(ncid,nctovid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:528.10: ncret = NF_DEF_VAR_deflate(ncid,ncarvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type make: *** [write_ncheader.o] Error 1 " bzhang Milestone 99 Flexpart-WRF v3.1 OMP FP other FLEXPART-WRF Support jbrioude closed 2014-10-06T15:02:30Z 2014-11-18T04:43:40Z "Hi! I am trying to compile FLEXPART-WRF v3.1 on a linux x86_64 machine. I have successfully compiled it in serial mode, however I am having difficulty running the program once it is compiled with openMP. I compile as follows: $ OMP_NUM_THREADS=2 make -f makefile.mom omp and the compilation runs fine. However, when I run the program, it almost immediately throws a seg fault. I have a feeling this has to do with how openmp is setting the stack size on compilation. I tried adding the flag: ""-fmax-stack-var-size=n"" for various numbers of bit, n, and this compiles fine, (it does give plenty of warnings that this overrides -frecursive); however, then I run into issues with the variable maxomp in par_mod.f90 . How can I get the compiler to set the appropriate stack size?" acificap Milestone 100 Flexpart-WRF grid_flux Output FP post-processing FLEXPART-WRF Support somebody closed 2014-10-09T16:51:37Z 2015-12-03T11:35:24Z "I've been reading the documentation, and there's very little to say at all about the IFLUX option. I have three questions: - How is it calculated? - Flux through what surface? - What format is the output? (it doesn't appear to be grib2 or netcdf)" acificap Milestone 102 flexpart-wrf build fails on OSX with PGI fortran FP coding/compilation FLEXPART-WRF Support somebody closed 2014-10-24T23:54:15Z 2014-11-04T21:51:03Z "I can't get flexpart-wrf to build on OSX with either PGI or GNU fortran. I did get it to build and run with linux/gnu fortran. Here is info about the OSX/PGI attempt: OSX version 10.9.5 Xcode version 6.0.1 pgf90 version 13.10-0 64-bit target on Apple OS/X -tp sandybridge Source code from http://flexpart.eu/downloads/src_flexwrf_v3.1.tar.gz Modified makefile.mom to Choose using PGI compiler Set path for NetCDF include and lib Set path to pgf90 compiler Remove -mcmodel=medium option Attempt to build with make -f makefile.mom serial Output = /opt/pgi/osx86-64/13.10/bin/pgf90 -c -I/sw/include -fastsse par_mod.f90 /opt/pgi/osx86-64/13.10/bin/pgf90 -c -I/sw/include -fastsse com_mod.f90 /opt/pgi/osx86-64/13.10/bin/pgf90 -c -I/sw/include -fastsse conv_mod.f90 ... /opt/pgi/osx86-64/13.10/bin/pgf90 -c -I/sw/include -fastsse write_ncheader.f90 /opt/pgi/osx86-64/13.10/bin/pgf90 -c -I/sw/include -fastsse write_ncinfo.f90 /opt/pgi/osx86-64/13.10/bin/pgf90 *.o -o flexwrf31_pgi_serial -L/sw/lib -fastsse -lnetcdff final section layout: __TEXT/__text addr=0x100000E60, size=0x001D3090, fileOffset=0x00000E60, type=1 __TEXT/__stubs addr=0x1001D3EF0, size=0x000002DC, fileOffset=0x001D3EF0, type=28 __TEXT/__stub_helper addr=0x1001D41CC, size=0x000004D4, fileOffset=0x001D41CC, type=32 __TEXT/__cstring addr=0x1001D46A0, size=0x000045B3, fileOffset=0x001D46A0, type=13 __TEXT/__const addr=0x1001D8C60, size=0x00002468, fileOffset=0x001D8C60, type=0 __TEXT/__unwind_info addr=0x1001DB0C8, size=0x000008A0, fileOffset=0x001DB0C8, type=22 __TEXT/__eh_frame addr=0x1001DB968, size=0x00013680, fileOffset=0x001DB968, type=19 __DATA/__dyld addr=0x1001EF000, size=0x00000010, fileOffset=0x001EF000, type=30 __DATA/__nl_symbol_ptr addr=0x1001EF010, size=0x00000010, fileOffset=0x001EF010, type=29 __DATA/__got addr=0x1001EF020, size=0x00000050, fileOffset=0x001EF020, type=29 __DATA/__la_symbol_ptr addr=0x1001EF070, size=0x000003D0, fileOffset=0x001EF070, type=27 __DATA/__mod_init_func addr=0x1001EF440, size=0x00000468, fileOffset=0x001EF440, type=33 __DATA/__const addr=0x1001EF8C0, size=0x00000800, fileOffset=0x001EF8C0, type=0 __DATA/__data addr=0x1001F00C0, size=0x00039664, fileOffset=0x001F00C0, type=0 __DATA/__common addr=0x100230000, size=0x00077AE0, fileOffset=0x00000000, type=25 __DATA/__bss addr=0x1002A7AE0, size=0x00184F30, fileOffset=0x00000000, type=25 __DATA/__huge addr=0x100430000, size=0x129362108, fileOffset=0x00000000, type=25 __PGIinfo/__IPDINFO addr=0x229793000, size=0x000570B1, fileOffset=0x00234000, type=0 __PGIinfo/__IPEINFO addr=0x2297EA0B1, size=0x00000179, fileOffset=0x0028B0B1, type=0 ld: unexpected bindingNone in '_boundcond_domainfill_' from boundcond_domainfill.o for architecture x86_64 make: *** [serial] Error 2 " rfe Milestone 103 FLEXWRFV3.1 runtime probIems (about IOUTPUTFOREACHREL and NAGECLASS) FP other FLEXPART-WRF Defect jbrioude closed 2014-10-27T11:54:44Z 2014-11-09T14:29:05Z "Hi, everyone I was able to run FLEXWRF sucessfully, but there was a problem in the flxout output file. when IOUTPUTFOREACHREL=1 (let NUMPOINT=n), if NAGECLASS>2 then I found that the concentration field caused by previous n-1 release sites of all age classes was only domain-wide ZERO. And if I did nothing except change NAGECLASS to 2, the concentration output for all n release sites were reasonable. I am not sure if there was a bug within FLEXWRF? I would appreciate if you do me a favor. Best regards. " tauhonson Milestone 105 error when compiling flexpart-wrf 3.1 FP coding/compilation FLEXPART-WRF Support jbrioude closed 2014-11-19T13:34:53Z 2015-12-03T11:43:27Z "i'm trying to compile flexpart-warf and after installing jasper and grib-api libraries. when it comes to compiling either whith parallel or serial it shows the error of a file netcdf.inc not founded..how can i solve this problem? rq: i've a kubuntu 14.04 trusty tahr x 64 version " metroid2012 Milestone 111 where is the MQUASILAG option FP input data FLEXPART-WRF Defect jbrioude closed 2014-12-23T06:36:01Z 2015-04-04T01:40:05Z "Hello, I used flexpart-wrf6.2 for INDIVIDUAL track.But I can not found the MQUASILAG (command file 21 opt )in the new flexwrf3.x. I also find that the out put of particles for individual path program and ""MQUASILAG=1"" was commented in the timemanager.f90. For this reason, I think the first column in the particle output file was the release area only. I don't know where should I find the id of each particles? Thanks!" firepad Milestone 112 Flexpart-WRF instaltion issues FP coding/compilation FLEXPART-WRF Support somebody closed 2015-01-07T14:05:54Z 2015-01-27T11:54:38Z "Hi, I have compiled flexpart-wrf but I get a warning during compilation, as below. The executable is created, but when I run it's 'killed' immediately. I have set the stack size to be unlimited. '''Compilation warning for flexpart-wrf''' fortran -c -I/usr/local/netcdf/include -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check random.f90 random.f90:68.12: 1 v1=2.*ran3(idum)-1. 1 Warning: Missing actual argument for argument 'inext' at (1) random.f90:69.12: v2=2.*ran3(idum)-1. 1 I have compiled and run flexpart (gfortran). Initially I did have a problem running flexpart. The executable was 'killed' immediately (as above). To compile for GFORTRAN, I had to edit, for flexpart, “erf.f90” to fix an error about real vs double precision. See http://flexpart.eu/ticket/49. gfortran --version GNU Fortran (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Regards, Cillian" cillianjoy Milestone 125 Makefile for Flexpart-wrf FP coding/compilation FLEXPART-WRF Support somebody closed 2015-07-07T13:21:16Z 2017-07-06T15:23:37Z I am working on IBM AIX operating system with xlf_r fortran compiler. Can anyone please help me with the makefile for Flexpart-wrf v3.1. Thank you. srvsxc Milestone 131 Error when compiling the flexwrf3.2 with GNU for OPENMP parallel run FP coding/compilation FLEXPART-WRF Support jbrioude closed 2015-12-11T08:57:31Z 2016-02-22T09:21:12Z "Hi, When I compile the flexwrf3.2 beta with GNU compiler for OPENMP parallel run with following command make -f makefile.mom omp for OPENMP parallel run I received error message as follows '''mt_stream.f90:110:52 integer (INT32), parameter :: MT19937_MATA =INT (Z' 9908b0df', INT32) Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check'' This was compiled successfully with following command without any error '''gfortran -c -I/home/gnu/netcdf-4.1/include -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check mt_stream.f90''' Again I received the same error message for mt_stream.f90, this program also compiled with '''gfortran -c -I/home/gnu/netcdf-4.1/include -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check mt_stream.f90''' after compilation of this program I have used make -f makefile.mom omp for OPENMP parallel run command for installation This time I received '''read_ncwrfout.f90:82 Error: Con't open include fiel 'netcdf.inc'''' complete netcdf libraries path was set in makefile.mom, but still I received this message. Pls, help me to install model with GNU for parallel simulation Thanks in advance. " skarri Milestone 132 Error while installation flexwrf3.2 with GNU for OPENMP parallel run FP coding/compilation FLEXPART-WRF Support closed 2015-12-17T11:14:47Z 2016-08-23T15:16:55Z "Hi, I installed netcdf fortran according to you I have given complete path of netcdf in makefile.mom after that I have received the following error write_ncheader.f90:126.60: ncret = nf_create(path(1)(1:length(1))//ncname, NF_NETCDF4,ncid) 1 Error: Symbol 'nf_netcdf4' at (1) has no IMPLICIT type write_ncheader.f90:359.10: ncret = NF_DEF_VAR_deflate(ncid,nclonvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:372.10: ncret = NF_DEF_VAR_deflate(ncid,nclonvid2, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:383.10: ncret = NF_DEF_VAR_deflate(ncid,nclatvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:391.10: ncret = NF_DEF_VAR_deflate(ncid,nclatvid2, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:401.10: ncret = NF_DEF_VAR_deflate(ncid,nclvlvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:412.10: ncret = NF_DEF_VAR_deflate(ncid,ncspcvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:420.10: ncret = NF_DEF_VAR_deflate(ncid,ncagevid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:430.10: ncret = NF_DEF_VAR_deflate(ncid,ncrecvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:438.10: ncret = NF_DEF_VAR_deflate(ncid,ncrnvid, shuffle, 1, deflate_level) 1 Error: Function 'nf_def_var_deflate' at (1) has no IMPLICIT type write_ncheader.f90:448.10: pls, suggest me Thanking you" skarri Milestone 133 Error while installation flexwrf3.2 with GNU for OPENMP parallel run FP coding/compilation FLEXPART-WRF Support closed 2015-12-18T04:50:50Z 2016-02-22T09:21:52Z "Dear, I able to compile all programs, objective files also generated for all programs including ""flexwrf.o"", after that I received the following error message ''' /user/bin/gfortran *.o -o gfortran: argument to '-o' missing make: *** [omp] Error 1''" skarri Milestone 167 Running test cases with FLEXPART-WRF FP input data FLEXPART-WRF Support adingwell closed 2017-01-31T09:36:45Z 2017-05-17T18:26:47Z "I am new to FLEXPART-WRF and I am trying to run the test cases. I have sucessfully compiled the code (no error messages and I have an executable). I have downloaded the test WRF input data. However when I run the following command ./flexwrf32_gnu_serial flexwrf.input.forward1 I get the following error: the input file used is flexwrf.input.forward1 Pre-generating random numbersCalling readinput Opening 'flexwrf.input.forward1 ' for reading Reading pathnames At line 236 of file readinput.f90 (unit = 1, file = 'flexwrf.input.forward1') Fortran runtime error: Bad integer for item 1 in list input The only changes I made to the input file were to change the pathnames at the very top. I have attached the file and the AVAILABLE file I am using. " victoria.sinclair@… Milestone 168 the coordinate transfo error exceeds 0.02*dx FP other FLEXPART-WRF 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@… Milestone 171 Segmentation Fault Flexpart WRF 3.3 FP coding/compilation FLEXPART-WRF Defect pesei closed 2017-04-26T15:01:45Z 2017-06-14T11:33:46Z "Dear all, I'm trying to run flexpart-wrf-3.3 on Ubuntu Budgie 17.04 (gfortran) but every time I try running it, it crashes with ""Segmentation fault"". - Error happens both with serial and omp - Using netcdf 4 - Stack-size unlimited with {{{ulimit -s unlimited}}} and confirmed by running {{{ulimit -S -a}}} - No errors during compilation, only two warnings: ---- gfortran -c -I/usr/local/include -O3 -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check -DNETCDF4_OUTPUT random.f90 random.f90:68:14: 1 v1=2.*ran3(idum)-1. 1 Warning: Missing actual argument for argument ‘inext’ at (1) random.f90:69:14: v2=2.*ran3(idum)-1. 1 Warning: Missing actual argument for argument ‘inext’ at (1) ---- - Program is being compiled and run into a VM at the moment (my main workstation is locked into a WRF job) Thanks for the support! " fcarotenuto Milestone 174 BUG in FLEXPART-WRF makefile.mom FP coding/compilation FLEXPART-WRF Defect pesei closed 2017-06-07T21:08:52Z 2017-06-12T13:28:12Z "In the current (i.e., v3.3.1) `makefile.mom`, there's a small bug regarding the Intel compiler's name. Here's the patch: {{{ diff --git a/makefile.mom b/makefile.mom index 5a8a7b9..5b43c88 100644 --- a/makefile.mom +++ b/makefile.mom @@ -80,7 +80,7 @@ endif ifeq ($(COMPILER), intel) FCSER = ifort FCOMP = ifort -openmp - FCMPI = mpifort -openmp + FCMPI = mpiifort -openmp # NETCDF = /apps/netcdf/4.1.3-intel FFLAGS = -I${NETCDF}/include $(INTEL_FFLAGS) $(FPP_FLAGS) }}} " ahilboll Milestone 178 FLEXPART-WRF crashes with segmentation fault FP coding/compilation FLEXPART-WRF Support pesei closed 2017-08-01T21:48:09Z 2018-03-07T18:05:58Z "Hi All, I'm currently trying to get FLEXPART-WRF (version 3.3.2) up and running on a Mac, but am having some issues. I can compile the OPENMP version, however the following two warnings occur: {{{ random.f90:68:14: 1 v1=2.*ran3(idum)-1. 1 Warning: Missing actual argument for argument 'inext' at (1) random.f90:69:14: v2=2.*ran3(idum)-1. 1 Warning: Missing actual argument for argument 'inext' at (1) }}} If I then try to run the test case (or any case) it crashes with the following output: the input file used is flexwrf.input.forward1 Pre-generating random numbers Calling readinput Segmentation fault: 11 Using VERBOSE = 100 in the input file does not generate any additional output. Also, compiling with an optimization option of -02 in the makefile has no impact. Any help at all would be greatly appreciated! Thanks very much Sarah " shanna Milestone 179 FLEXPART-WRF installation procedure FP coding/compilation FLEXPART-WRF Support closed 2017-08-05T08:58:42Z 2017-09-18T19:54:44Z "I am trying to install FLEXPART-WRF v3.1, and I am have some questions in its installing procedure. For example, do we need Jasper and Grib_API libraries installed for this or netcdf library is the only library needed for that. Furthermore, as it is written in a related paper, we need to install netcdf4, edit par_mod.f90 and then edit makefile.mom and use this command: make -f makefile.mom omp (omp is chosen according to my PC). However, I don't know whether we should do other steps too. For instance, how we should configure FLEXPART-WRF? Any helps would be appreciated, M," mhakimzadeh Milestone 180 Error in compiling MPI (instaling Flexpart-WRF) FP other FLEXPART-WRF Support pesei closed 2017-08-09T15:24:35Z 2018-03-07T18:07:33Z "I am installing FLEXPART-WRF on intel compiler with mpich library, while I type `make -f makefile.mom mpi`, I get the following error: {{{ echo 'Compiling MPI' Compiling MPI ifort -openmp *.o -o flexwrf31_intel_mpi -L/home/maryam/net4/netcdf4/lib -mcmodel=medium -shared-intel -lnetcdff -debug all -lpthread -L/lib -lmpi flexwrf.o: In function `flexwrf': /home/maryam/FPW/src_flexwrf_v3.1/flexwrf.f90:23: multiple definition of `MAIN__' flexwrf_mpi.o:/home/maryam/FPW/src_flexwrf_v3.1/flexwrf_mpi.f90:23: first defined here timemanager_serial.o: In function `timemanager': /home/maryam/FPW/src_flexwrf_v3.1/timemanager_serial.f90:24: multiple definition of `timemanager_' timemanager.o:/home/maryam/FPW/src_flexwrf_v3.1/timemanager.f90:24: first defined here ld: cannot find -lmpi make: *** [mpi] Error 1 }}} Thanks in advance for your help, " mhakimzadeh Milestone 181 netcdf output from WRF-FLEXPART FP other FLEXPART-WRF Support adingwell closed 2017-08-20T09:08:01Z 2017-09-18T19:40:10Z "I did run WRF-FLEXPART v3.1. and I got the message that I have successfully run the WRF-FLEXPART. For output files, I got the file with ""grid_time_201005180x0000_001"" name , in which x is each run hour and format of the files is binary. However, I did not get any file with NETCDF format. My question is how I can get the NETCDF output files from WRF-FLEXPART. Thanks in advance for your help, " mhakimzadeh Milestone 183 Concentration Results of Flexpart-WRF Being Equal to Zero. FP other FLEXPART-WRF Support pesei closed 2017-08-31T13:10:44Z 2020-12-07T09:34:12Z "I got run from Flexpart-Wrf test case and I got the message that I have successfully completed a Flexpart-Wrf model run. However, when I see the netcdf result, all of the concentration values are equal to zero. I don't know why I get this result. Thanks in advance for your help. P.S: I changed line 233 of `convmix_kfeta.f90` file as it was mentioned in ticket #107, but I still get zero as the result of model." mhakimzadeh Milestone 184 Particle Positions from Flexpart-Wrf Output FP other FLEXPART-WRF Support pesei closed 2017-09-20T14:17:06Z 2017-10-30T09:46:55Z "I need to get particle positions after I release the particles in my measurement site in order to have the number of trajectory segment endpoints in cell ijth in T time interval. I need particle positions in order to obtain Residence Time Analysis and subsequently, Concentration Field Analysis. My question is how can I get the particle positions? Is CONC output parameter (in netCDF format) with s. m^3 /kg unit representing the residence time of each grid divided by concentration at the measurement site? If not, what is this parameter representing? Many Thanks in advance for your kind help." mhakimzadeh Milestone 200 Installation help FP coding/compilation FLEXPART-WRF Support anphi closed 2018-08-06T01:34:43Z 2020-05-06T13:46:50Z "I'm trying to install FLEXPART_WRF. I found another ticket that said only netCDF libraries were needed. Is that correct? I have been unable to get the grib api libraries to install. I tried using the cmake command as directed in the README file but I just get an error that says the folder I set for the install cannot be found. when I use the command cmake install the installation tries to copy files to the computing cluster software directory - which is read only to all users. I want to install FLEXPART-WRF in a sub-folder of home directory. I cannot figure out how to make this work. Can you please help?" mitchekc Milestone 207 Error running FLEXPART FP input data FLEXPART-WRF Support pesei closed 2018-10-21T18:08:40Z 2018-10-28T20:14:37Z "Hi there, My job output file contains the following error text when I attempt to run FLEXPART. I don't know what the error means. I have checked the values for each variable in my flexwrf.input file and they appear to be set using the correct type. What can I do to further troubleshoot the issue? Thank you the input file used is flexwrf.input in the local folder of the executable Pre-generating random numbers Calling readinput Opening ' flexwrf.input ' for reading Reading pathnames forrtl: severe (59): list-directed I/O syntax error, unit 1, file /project/6006014/kcmrowse/FLEX/flexpart_wrf-3.3/flexwrf.input Image PC Routine Line Source libifcoremt.so.5 00002ACB5B91CDF2 for__io_return Unknown Unknown libifcoremt.so.5 00002ACB5B96582F for_read_seq_lis_ Unknown Unknown flexwrf32_intel_o 00000000004C35CA Unknown Unknown Unknown flexwrf32_intel_o 00000000004607E7 Unknown Unknown Unknown flexwrf32_intel_o 000000000040327E Unknown Unknown Unknown libc-2.24.so 00002ACB5DB8B2E0 __libc_start_main Unknown Unknown flexwrf32_intel_o 000000000040317A Unknown Unknown Unknown " mitchekc Milestone 208 WRF specific files FP other FLEXPART-WRF Support pesei closed 2018-10-24T01:16:50Z 2018-10-28T20:13:52Z Does FLEXWRF v3.2 use the namelist.input or namelist.wps files? Should copies of these files be placed in any particular folder? Is there a FLEXWRF sub-routine that compares the meteorological fields defined in the namelist files with the field defined in the flexwrf.input file? mitchekc Milestone 210 RECEPTOR syntax error FP other FLEXPART-WRF 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 Milestone 217 t not in K FP coding/compilation FLEXPART-WRF 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 Milestone 223 ASCII output type UNFORMATTED FP coding/compilation FLEXPART-WRF Support pesei closed 2019-01-16T16:05:06Z 2023-03-29T16:27:19Z "Hello, my name is Sara and I have a question about how to save data in ASCII format. I am running flexpart-wrf 3.3 and the first time I wanted to obtain ASCII outputs I found this error message: At line 287 of file concoutput_irreg.f90 (unit = 97, file = '/home/usc/fp/scg/lustre/PROYECTOS/FLEXPART/TEST/test_damian/output_back_2/grid_time_19821014170000_001') Fortran runtime error: Format present for UNFORMATTED data transfer srun: error: c7026: task 0: Exited with exit code 2 srun: Terminating job step 2165917.0 I looked for that line in the code and, from my point of view, it was difficult the program save ASCII outputs providing that this format was declared as UNFORMATTED. There is a high probability I had been doing something wrong, but I try to solve this incident by changing the concoutput_irreg.f90 file. I would like to share this new file in case this problem persists. In other terms, I am wondering if it is possible to obtain by any way the partposition file in latlon coordinates if we are working with a Lambert projection and there is not a regular grid for mother domain. Thank you for your time. Regards, Sara" scloux Milestone 228 Add horizontal self-propelled vector to particle FP other FLEXPART-WRF 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 Milestone 233 Error: NetCDF: Invalid dimension ID or name FP coding/compilation FLEXPART-WRF 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 Milestone 236 Bad wind_option / time_option combination is not forbidden by WRF-FLEXPART FP other FLEXPART-WRF 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 Milestone 241 *** read_ncwrfout_1realfield -- var ndims mismatch for CLDFRA FP input data FLEXPART-WRF 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 Milestone 244 Problem in grid area size FP physics/numerics FLEXPART-WRF 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 Milestone 245 particles below ground are reflected FP coding/compilation FLEXPART-WRF New feature closed 2019-08-07T00:33:37Z 2019-08-07T14:59:26Z "hi there, I reaslise that in subrountine 'advance.o', all the particles that below the ground are reflected which means they are moved back to the altitude above ground. I could understand this setting for gas, but maybe not for some particles, and it make no sense for my case when I am simulating seed dispersions. So I would suggest to set up a switch to do reflection or not. If I want to fix in my own version, could you comment on how to fix it in the most simple way? " ZhenhuaHao Milestone 247 allow for using WRF output with lakes FP other FLEXPART-WRF 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 Milestone 252 FLEXPART-WRF crashes for array bound mismatch FP coding/compilation FLEXPART-WRF 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 Milestone 258 FLEXPART WRF Output Format FP post-processing FLEXPART-WRF Support pesei closed 2020-02-05T10:28:37Z 2020-02-21T13:33:07Z "I am using flexpart wrf and I am a beginner here .. I didn't get a netcdf output so i can't analyase the data after run ... any small help will be highly apreciatable I am sai prasad and I am working on flexpart wrf 3.3.2 and I am a beginner. I run the model succesfully and i get the files are {{{ grid_time_20100518060000_001 grid_time_20100518070000_001 grid_time_20100518080000_001 grid_time_20100518090000_001 grid_time_20100518100000_001 }}} these files didnt have better format and it is not .txt,.grib or .nc so we cant analyse it easily... please help im a beginner and the small help also makes big impact on me " sprasad Milestone 267 setting up flexpartwrf for radionuclide dispersion at meso-scale FP input data FLEXPART-WRF Support pesei closed 2020-03-04T12:31:25Z 2020-07-16T15:30:21Z "Dear all, I want to simulate radionuclide atmospheric dispersion at meso-scale related to an hypothetical accidental release from UAE Barakah Nuclear Power Plant. My WRF domain is 218 per 179 points with 5 km resolution. Question 1: What would be a reasonable number of Lagrangian particles to use for this application. Is 2 millions particles is enough ? Question 2: For Cs-137/and I-131 (in its particulate form). What typical values to specify for the mean particulate diameter and the standard deviation for these species. Question 3: Any thoughts for including the emission due to re-suspension. Thank you very much for your feedback " rabida Milestone 268 Cant understand the variables in the trajectory.txt file FP post-processing FLEXPART-WRF Support pesei closed 2020-03-06T11:02:37Z 2020-06-05T14:40:48Z "I already registered a complaint that I can't understand what are that numbers in the txt file are indicating. the text file has lots of numbers and there are no mentioning about which number is indicating lat,long etc how can i understand that..? please help me with some answers" sprasad Milestone 271 SFC_OPTION = 1 not working FP input data FLEXPART-WRF 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 Milestone 273 Point source emission with temporal variation FP input data FLEXPART-WRF Support pesei closed 2020-06-10T09:51:16Z 2023-03-29T16:12:09Z "Dear all, I want to simulate dispersion from a point source with a hourly varying emission rate. The release has a duration of 48 hours. Could you please clarify how can I set this in FLEXPART-WRF. Thank you in advance" rabida Milestone 288 Installation and examples for flexpart-wrf v.3.3.2 FP other FLEXPART-WRF Support ignacio closed 2020-12-02T14:59:38Z 2021-02-08T10:39:17Z "I am trying to install flexpart-wrf v3.3.2 but have some difficulties to run the examples provided in the source code. I plan to use the hybrid MPI-OpenMP version on a HPC system. To familiarise my self with wrf-flexpart (I do not have worked with flexpart-wrf nor flexpart before), I started with the serial version. After including the NetCDF-Fortran path `makefilie.mom` I used `make -f makefile.mom serial` to compile the serial version. The executable `flexwrf33_gnu_serial` is succeesfully created, however I got the following warnings during compilation: {{{ netcdf_output_mod.F90:1619:70: 1617 | do jy=0,grid_ny-1 | 2 1618 | do ix=0,grid_nx-1 1619 | grid3(ix,jy,kz,kp,nage)= 1.e12*grid(ix,jy,kz)/grid_vol(ix,jy,kz)/outnum* & | 1 Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2) netcdf_output_mod.F90:1619:67: 1618 | do ix=0,grid_nx-1 | 2 1619 | grid3(ix,jy,kz,kp,nage)= 1.e12*grid(ix,jy,kz)/grid_vol(ix,jy,kz)/outnum* & | 1 Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2) random.f90:68:14: 68 | 1 v1=2.*ran3(idum)-1. | 1 Warning: Missing actual argument for argument ‘inext’ at (1) random.f90:69:14: 69 | v2=2.*ran3(idum)-1. | 1 Warning: Missing actual argument for argument ‘inext’ at (1) verttransform.f90:769:24: 769 | do 100 ix=0,nxmin1 | 1 Warning: Fortran 2018 deleted feature: Shared DO termination label 100 at (1) verttransform_nests.f90:442:27: 442 | do 100 ix=0,nxn(l)-1 | 1 Warning: Fortran 2018 deleted feature: Shared DO termination label 100 at (1) readinput.f90:118:0: 118 | if (path(numpath+2*(i-1)+1)(1:5).ne.'=====') then | Warning: ‘__builtin_memcmp_eq’ reading 5 bytes from a region of size 0 [-Wstringop-overflow=] }}} ''Are there any fixes for this?'' After compilation, I tried to run one of the examples in `examples/`. As I could not find any `data/` directory related to v3.3.2, I downloaded the 'WRF input files' (`Wrfdata/`), from flexpart-wrf version 3.1. Moreover, I adopted the following lines in `flexwrf.input.forward1`: * In the 'Former Pathnames File' section (all paths are absolute paths) * Output directory (directory already exists) * Path to meteo input data (Wrfdata) * Location of the AVAILABLE2 file * In the 'Former Command File' section: * Set `SFC_OPTION` to zero (as mentioned in #271) Running `./flexwrf33_gnu_serial flexwrf.input.forward1` yields {{{ the input file used is flexwrf.input.forward1 Pre-generating random numbers Calling readinput Opening 'flexwrf.input.forward1 ' for reading Reading pathnames option_verbose= 100 ---------------- INFORMATION: SUBGRIDSCALE TERRAIN EFFECT IS NOT PARAMETERIZED DURING THIS SIMULATION. ---------------- SFC_OPTION = 0 nageclass 2 Opening file: /p/project/deepacf/intelliaq/kleinert1/flexpart-wrf_ticket-test/Src_flexwrf_v3.3.2/examples/AVAILABLE2 for reading readinput() calling gridcheck() test_xyindex_to_ll_wrf calling map_set -- map_proj_id, map_set_proj_code = 1 3 test_xyindex_to_ll_wrf -- lgrid, rmserr (km) = 0 1.22E-03 # of vertical levels in WRF data n_bottom_top & ""true"" nuvz: 59 59 nwz & ""augmented"" nuvz: 60 60 nwzmax, nuvzmax, nzmax : 61 61 61 nconvlevmax, nconvlev : 60 58 nx, ny, nxmax, nymax : 180 180 250 190 Mother domain: east-west range: 0.0 2148000.0 Grid distance: 12000.0 south-north range: 0.0 2148000.0 Grid distance: 12000.0 readinput() calling gridcheck_nests() Reading OUTGRID readoutgrid diagnostics xtmp1, ytmp1 (in) -1.2300000000E+02 3.8000000000E+01 xtmp2, ytmp2 (in) -1.2000000000E+02 4.1500000000E+01 out_xm0, out_ym0 3.6903406250E+05 1.0307651250E+06 dxout, dyout 1.4537512695E+04 1.0897026367E+04 Reading OUTGRID nest readoutgrid_nest diagnostics xtmp1, ytmp1 (in) -1.2300000000E+02 3.8000000000E+01 xtmp2, ytmp2 (in) -1.2000000000E+02 4.1500000000E+01 out_xm0n, out_ym0n 3.6903406250E+05 1.0307651250E+06 dxoutn, dyoutn 1.4537512695E+04 1.0897026367E+04 Reading RECEPTORS Reading SPECIES option_verbose: 100 option_verbose: 100 Reading RELEASES nspec = 2 emitvar = 0 Reading species: 1 of 2 Reading species: 2 of 2 Releasepoints allocated: 2 numpoint = 2 release location= 1 COMPOINT = ""box1 NAME OF RELEASE LOCATI release location= 2 COMPOINT = ""box2 maxpart2 110000 0 alloc part 110000 110000 0 Main: Old IGBP data will be used for land use categories #### FLEXPART ERROR! FILE CONTAINING #### #### RELATION LANDUSE,z0 DOES NOT EXIST #### #### IT IS NEEDED FOR DRY DEPOSITION #### #### COPY DATA FROM src_flexwrf_v3.0/data #### #### IN YOUR CURRENT DIRECTORY #### #### OR USE A DIFFERENT SPECIES #### }}} which seems to be related to the dry deposition of Cs-137. The `IGBP_int1.dat` file is located in the `Wrfdata/` directory (`LU_OPTION` is set to zero as given by default). I also copied this file as well as the executable into the `examples/`dir. ''Is this error related to some changes between flexpart-wrf versions 3.1 and 3.3.2?'' ''Are the example input data from version 3.1 outdated, if so are there new example data?'' For simplicity, I replaced the Cs-137 with a second air tracer to omit the deposition. This, however, results in a Richardson failure. In #242 daliaga supposed to uncomment some lines in `readwind.f90`, and `readwind_nests.f90` which finally resulted in a complete serial forward model run after recompilation (`make -f makefile.mom [clean, serial]`). Both, the forward1 and die backward1 example showing the following warning `WARNING: No (or incomplete) flux data contained in WRF output file wrfout_d02_2010-05-18_00.nc` but did not crash. I am therefore unsure if this is related to #233. ''Can you confirm that the steps mentioned above are adequate to test the installation of flexpart-wrf v3.3.2 for the serial and omp mode?'' Before continuing with the hybrid-mode, I thought it might be good to clarify all the issues mentioned above to ensure that they won't cause any additional issues later on. I already saw that I might have to include the MPI_ROOT path into makefile.mom for compilation. Thank you in advance for your answer and best regards! " fkleinert Milestone 292 Problem reading TKE_PBL - Flexpart-WRF FP input data FLEXPART-WRF 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 Milestone 293 FLEXPART-WRF takes wrong OUTGRID information FP other FLEXPART-WRF 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 Milestone 307 Flexpart-WRF crashes due to array boundary violation in outgrid_init_reg.f90 FP coding/compilation FLEXPART-WRF 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 Milestone 322 Problem with backward simulation FP coding/compilation FLEXPART-WRF 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 Milestone 327 Incorrect output in header for variable ReleaseZstart_end FP other FLEXPART-WRF 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 Milestone 329 Bias of footprint dependant on particle number FP other FLEXPART-WRF Defect closed 2023-02-22T13:30:15Z 2023-06-21T15:17:37Z "Hello, I currently use `FLEXPART-WRF` in an urban setting on roughly 1 km resolution. In a test for the statistical error due to the limited particle number, I found not only statistical, but systematic differences (bias) between runs with different particle numbers. In particular, the sum of the footprints entries grows with the particle number. As I understand it the footprints' values should not generally grow with larger partical numbers, but become more and more consistent, which is not the case here. The same footprint was calculated for 10, 50, 250, and 500 thousand particles with very different results for the same release location, time and meteorology. The lowest paritcle number is chosen due to the vaule in reviewed papers using `FLEXPART-WRF` in an urban/meso scale setting: - Cui 2015 https://doi.org/10.1002/2014JD023002 (10,000 particles per release) - Nathan 2021 https://doi.org/10.5194/acp-2020-1303 (10,000 particles per release)." cluekenwinkels Milestone 340 Deposition and particle reflection FP coding/compilation FLEXPART-WRF 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 Milestone FLEXPART 9.2 33 Precipitation treatment FP physics/numerics FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.2_FPbase_9 58 Memory leak in netcdf ouput routine FP other FLEXPART-WRF Defect jbrioude closed 2013-12-02T18:02:12Z 2014-11-18T04:44:48Z "The files created by write_ncconc.f90 aren't closed unless the maximum number of records per file is reached. This leads to a lot of memory being wasted when making repeated runs (without any external means of cleaning out dead memory). It can be fixed by putting the following lines at the end of write_ncconc.f90: {{{ if ( jul .ge. edate ) then write(*,*) ""write_ncconc: End of simulation reached, closing output file"" ncret=nf_close(ncid) call check_ncerror(ncret) endif }}} " adingwell Milestone FLEXPART_WRF_3.2_FPbase_9 74 Problem in FLEXPART run with stratospheric ozone tracer option FP other FLEXPART-WRF Defect jbrioude closed 2014-04-20T11:52:36Z 2014-05-21T23:40:59Z I have been trying a bunch of test run with FLEXPART-WRF using WRF output data, the results turn out to be reasonable if I set mdomainfill to be 0, but the output concentrations are all 0 if I choose stratospheric ozone tracer option (mdomainfill=2), so I am wondering if anyone could help find out what the problem is, please find the model configuration attached, any help is very much appreciated. sulinust Milestone FLEXPART_WRF_3.2_FPbase_9 104 FLEXPART-WRF v3.2, beta version FP coding/compilation FLEXPART-WRF New feature jbrioude closed 2014-11-18T04:49:33Z 2017-07-06T15:21:53Z "The beta version of FLEXPART-WRF v3.2 is available for download here [/downloads/src_flexwrf_v3.2.tar.gz FLEXPART-WRF version 3.2 beta version] This version fixes the problems reported in tickets #99, #58, #103, #74. Some problems and with netcdf reading have been reported and fixes given by Alan Griffiths. I have problems with svn at my institute. I'll try to upload the new version into the svn branch for FLEXPART-WRF" jbrioude Milestone FLEXPART_WRF_3.2_FPbase_9 107 why the values for the potential voricity output are zero? FP other FLEXPART-WRF Defect jbrioude closed 2014-11-21T08:19:28Z 2015-04-04T01:34:43Z "I have tried to run flexpart-wrf with different version(from 3.0 to 3.2). However, I found the valuse of potential voricity equal zeros, while I set particle dump for every output interval. Is any bugs in the programes? thanks for your help in advance. BTW: There seems a bug in convmix_kfeta.f90 programe, if set variable ""maxpar"" not equal ""numpart"", which could make the value of ""maxval(igrid)"" too big and programe stop at the line of ""too much x and y grid modify convmix_kfeta.f"". This bug could be solved by add another loop behind the line 154. do ipart=1,maxpart igrid(ipart)=-1 enddo " chenbin Milestone FLEXPART_WRF_3.2_FPbase_9 109 error when compiling the flexwrf3.2 with netcdf 4.0 FP coding/compilation FLEXPART-WRF Defect jbrioude closed 2014-12-05T07:06:18Z 2015-05-11T05:23:27Z "Hi, When I compile the flexwrf3.2 beta with netcdf 4.0.1, the errors was accured as follows : pgf90 -c -I/home/weipeng/programfile/lib/netcdf4.0.1-pgi10/include -fastsse -mcmodel=medium write_ncheader.f90 PGF90-S-0038-Symbol, nf_netcdf4, has not been explicitly declared (write_ncheader.f90) PGF90-S-0038-Symbol, nf_def_var_deflate, has not been explicitly declared (write_ncheader.f90) 0 inform, 0 warnings, 2 severes, 0 fatal for write_ncheader There was no errors while compiling the *.f file but the script stoped when making the excute file. I don't konw how to solve it and any helps will be appreciate. Thanks! " koala2014 Milestone FLEXPART_WRF_3.2_FPbase_9 116 FLEXPART-WRF v3.2 runtime segmentation fault FP other FLEXPART-WRF Defect jbrioude closed 2015-03-26T15:08:02Z 2016-02-22T09:20:25Z "Hi,everyone: I could successfully compile FLEXPART-WRF v3.2 with intel, the exe of flexwrf32_intel_serial works just fine to finish simulation; however, when I type mpiexec -n 6 ./flexwrf32_intel_mpi flex..., it stops soon with error message: ************************************** Allocating fields for nested and global output (x,y): 100 100 ==================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 11 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES ==================================================================== YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11) ****************************** I previously used FLEXPART-WRF v3.2 with pgi13.7 smoothly in another cluster. I have to build FLEXPART-WRF v3.2 in this new cluster which is not installed with pgi. I would appreciate it if someone do me a favor. " tauhonson Milestone FLEXPART_WRF_3.2_FPbase_9 120 Simulated particles are fewer then requested in FLEX-WRF FP other FLEXPART-WRF Support jbrioude closed 2015-05-08T19:40:49Z 2015-05-19T17:11:42Z "I'm using the latest version of flexwrf (beta v3.2) to do forward simulations during 24hs. When I request 100000 particles to be released during these 24hs, only 62921 are actually sent out. You can see this in the attached file flexwrf.output, and I copy a small part below. After 56400 seconds (16hs) the total number of particles stops increasing. 51600 SECONDS SIMULATED: 59756 PARTICLES: Uncertainty: 0.000 0.000 0.000 52800 SECONDS SIMULATED: 61142 PARTICLES: Uncertainty: 0.000 0.000 0.000 54000 SECONDS SIMULATED: 62302 PARTICLES: Uncertainty: 0.000 0.000 0.000 55200 SECONDS SIMULATED: 62901 PARTICLES: Uncertainty: 0.000 0.000 0.000 56400 SECONDS SIMULATED: 62921 PARTICLES: Uncertainty: 0.000 0.000 0.000 57600 SECONDS SIMULATED: 62921 PARTICLES: Uncertainty: 0.000 0.000 0.000 58800 SECONDS SIMULATED: 62921 PARTICLES: Uncertainty: 0.000 0.000 0.000 60000 SECONDS SIMULATED: 62921 PARTICLES: Uncertainty: 0.000 0.000 0.000 61200 SECONDS SIMULATED: 62921 PARTICLES: Uncertainty: 0.000 0.000 0.000 If I ask for 50k particles, it also stops after 16hs but with 31443 particles simulated. And if I ask for 30k particles, it also stops after 16hs now at 18898 simulated particles. And if I ask for 20k particles, the programs crashes with a SIGSEGV segmentation fault!!! It should be straight forward to reproduce this error. " hbarbosa Milestone FLEXPART_WRF_3.2_FPbase_9 128 Particles disappear in FLEXPART RUN at longitude 180 FP coding/compilation FLEXPART-WRF Support jbrioude closed 2015-11-12T12:00:51Z 2016-08-23T15:19:20Z "I run FLEXPART_WRFV3.2(beta) for backward run over Pacific Ocean, the particles are disappeared at lonitude 180, inside the domain see attached gif animated. my domain is : lat from 5N to 60 N and lon from 153.8E to 85W The wrf model outputs are lambert map project. I have a guess that the problem is in lateral boundary condition. So I choose ""proj_cyclic = .true."" in the file map_proj_wrf_subaa.f90 but there is no differnce in the ouput. thank you Sayed " sayed Milestone FLEXPART_WRF_3.2_FPbase_9 129 Particles disappear in FLEXPART RUN at longitude 180 FP coding/compilation FLEXPART-WRF Support closed 2015-11-12T12:01:32Z 2015-11-16T23:14:39Z "I run FLEXPART_WRFV3.2(beta) for backward run over Pacific Ocean, the particles are disappeared at lonitude 180 see attached gif animated. The wrf model outputs are lambert map project. I have a guess that the problem is in lateral boundary condition. So I choose ""proj_cyclic = .true."" in the file map_proj_wrf_subaa.f90 but there is no differnce in the ouput. thank you Sayed " sayed Milestone FLEXPART_WRF_3.2_FPbase_9 164 question about flexwrf v3.2 FP input data FLEXPART-WRF Support closed 2016-10-21T07:04:09Z 2016-10-24T09:55:10Z " I was using flexwrf v3.2 while faced with a problem, i couldn't solve this problem and wanna ask for help. The program said that "" readwind -- unable to locate date/time in met file indj, itime = 2 2 file = /apps/flexwrf_new/test/case_test/wrfout_d02_2015-07-16_00:00:00"". The input files of Flexwrf v3.2 and WRF v3.5 are attached. Thank you very much!" tyang Milestone FLEXPART_WRF_3.2_FPbase_9 165 a lot of NaNf in flexwrf output data FP input data FLEXPART-WRF Support jbrioude closed 2016-11-03T15:27:17Z 2017-07-06T15:25:13Z "hi, I had some problems with flexwrf, most of output data were NaNf(while some are ""inf""),the program didn't give any errors or warnings. I tried to checked the input file but couldn't find the reason.Could you help me? Some of input and output files are attached below(I have convert .nc files to .txt files for reading), thank you! File list: 1. namelist.wps and namelist.input(input file for wps and WRF) 2. flexwrf.input(input file for flexwrf) 3. output_message.txt(output message of flexwrf with verbose=100) 4. header_d01.txt (output header file of flexwrf) 5. flxout_d01_20150716_030000.txt(one of output files of flexwrf)" tyang Milestone FLEXPART_WRF_3.3_FPbase_9 108 Problem with mercator projection FP other FLEXPART-WRF Defect adingwell closed 2014-12-02T10:51:39Z 2016-09-30T08:09:27Z "I've tried running FLEXPART-WRF with Mercator projection and got the error: {{{ need orientation longitude (stdlon) as: -180e <= lon1 <= 180w STOP map_init }}} This error should not occur if Mercator projection is used. The problem is in the subroutine map_set. The variable 'proj_merc' is referenced before it is defined. I've marked the changes needed to fix the problem below: {{{ proj_code = proj_code_in !!! This is where map_init should be called to fix the problem call map_init ! first, check for validity of mandatory variables in proj if ( abs(lat1) .gt. 90.001 ) then print '(a)', 'latitude of origin corner required as follows:' print '(a)', ' -90n <= lat1 < = 90.n' stop 'map_init' endif if ( abs(lon1) .gt. 180.) then print '(a)', 'longitude of origin required as follows:' print '(a)', ' -180e <= lon1 <= 180w' stop 'map_init' endif if ((dx .le. 0.).and.(proj_code .ne. proj_latlon)) then print '(a)', 'require grid spacing (dx) in meters be positive!' stop 'map_init' endif if ((abs(stdlon) .gt. 180.).and.(proj_code .ne. proj_merc)) then print '(a,i3)', 'proj_code: ', proj_code print '(a,i3)', 'proj_merc: ', proj_merc print '(a)', 'need orientation longitude (stdlon) as: ' print '(a)', ' -180e <= lon1 <= 180w' stop 'map_init' endif if (abs(truelat1).gt.90.) then print '(a)', 'set true latitude 1 for all projections!' stop 'map_init' endif !!! This is where ""map_init"" is called in 3.2 BETA }}} It's also rather confusing when the stop code is 'map_init' but the problem occurs in the subroutine 'map_set'." adingwell Milestone FLEXPART_WRF_3.3_FPbase_9 156 Flexpart-WRF 3.3, new parameter in readinput.f90 FP other FLEXPART-WRF Defect adingwell closed 2016-09-28T12:18:01Z 2016-09-30T08:13:45Z " There seems to be a new parameter listed in readinput.f90 of the newly released Flexpart-WRF3.3. In line 225 lu_option is listed between turb_option and cbl_scheme, but it is not listed in the flxp_input.txt examples. This makes the existing flxp_input format incompatible with the new Flexpart-WRF version. What is the purpose of lu_option? In order to make Flexpart-WRF 3.3 work with the existing flxp_input format, we had to remove line 225 from readinput.f90 and recompile." mschoeppner Milestone FLEXPART_WRF_3.3_FPbase_9 157 Flexpart-WRF 3.3 forces verbose setting FP coding/compilation FLEXPART-WRF Defect adingwell closed 2016-09-28T12:24:37Z 2016-09-30T08:16:52Z In lines 237-238 of readinput.f90 of Flexpart-WRF 3.3 the verbose variable is automatically set to 10, overwriting the input from flxp_input.txt. We have removed these lines to allow user input for verbose mode. mschoeppner Milestone FLEXPART_WRF_3.3_FPbase_9 158 Reading of the (no longer used) 'ALT' variable from WRF FP coding/compilation FLEXPART-WRF Defect closed 2016-09-28T12:33:26Z 2016-09-30T08:31:48Z In order to make Flexpart-WRF (3.1, 3.2 and 3.3) work with nested input data, we had to remove/deactivate the section that reads the variable ALT in lines 595-611 in readwind_nests.f90. mschoeppner Milestone FLEXPART_WRF_3.3_FPbase_9 160 SFC_OPTION=1 no longer supported FP coding/compilation FLEXPART-WRF Defect adingwell closed 2016-09-30T08:27:24Z 2016-10-21T12:38:55Z SFC_OPTION currently only has one valid choice (0). Setting SFC_OPTION=1 (WRF) either does nothing or causes crashes (see ticket #158), I suggest keeping the option for possible future use, but adding an error message if bad values are given. adingwell Milestone FLEXPART_WRF_3.4_FPbase_9 110 Warm start crashes FLEXPART-WRF FP other FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 119 random numbers with fixed seeds in convective scheme FP physics/numerics FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 159 MPI Compilation FP coding/compilation FLEXPART-WRF Defect adingwell closed 2016-09-28T12:42:40Z 2020-05-06T13:48:34Z "We had problems with the compilation of Flexpart-WRF 3.3 with GNU/OMP. Our system runs with gcc/4.4.7 and openmpi/1.8.1. In case other users have similar problems, here are the changes in makefile.mom that solved it in our case: Line 69: FCOMP = mpif90 Line 74: Add “-lgomp” to LDFLAGS" mschoeppner Milestone FLEXPART_WRF_3.4_FPbase_9 169 Seg fault - particles moving out of ABL by hor. diffusion FP physics/numerics FLEXPART-WRF 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@… Milestone FLEXPART_WRF_3.4_FPbase_9 175 FpWrf header_nest dxoutn, dyoutn always in metre FP coding/compilation FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 176 No error issued if insufficient number of SPECIES (FpWrf) FP coding/compilation FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 190 NetCDF: Start+count exceeds dimension bound FP other FLEXPART-WRF Support closed 2018-03-21T11:47:27Z 2018-10-28T20:20:12Z "I'm running Flexpart-WRF 3.3.2. When I output as netcdf, I get ""NetCDF: Start+count exceeds dimension bound"". When I output as binary it seems to work okay. Last message during netcdf run: readwind 1.301500 calcpar 0.2720000 verttran 0.6025000 concoutput_reg: Calling write_ncconc for main outgrid write_ncconc: writing netcdf output for: domain,kp,nage = 1 1 1 write_ncconc: calling write_ncinfo write_ncinfo: creating file: ./output/flxout_d01_20150416_130000.nc write_ncinfo: ncout,ncoutn= 458752 0 nc_write_global_attributes: Setting up forward simulation attributes nc_write_global_attributes: Setting up map projection attributes nc_write_global_attributes: Setting up common model attributes nc_write_global_attributes: Setting up OUTPUT_INTERVAL nc_write_global_attributes: Setting up AVERAGING_TIME nc_write_global_attributes: Setting up AVERAGE_SAMPLING nc_write_global_attributes: Setting up WEST-EAST_GRID_DIMENSION nc_write_global_attributes: Setting up SOUTH-NORTH_GRID_DIMENSION nc_write_global_attributes: Setting up BOTTOM-TOP_GRID_DIMENSION nc_write_global_attributes: Setting up DX and DY nc_create_main_outfile: Setting up main grid dimensions nc_create_main_outfile: Setting up release point dimensions nc_create_main_outfile: Setting up receptor point dimensions nc_create_main_outfile: Setting up TIMES dimension variable nc_create_main_outfile: Setting up CONC variable nc_create_main_outfile: Setting up DRYDEP variable nc_create_main_outfile: Setting up WETDEP variable ncid,nccovid= 458752 2 write_ncconc: record index 1 Error: NetCDF: Start+count exceeds dimension bound For info: nc-config --all This netCDF 4.3.0 has been built with the following features: --cc -> icc --cflags -> -I/ichec/packages/netcdf/intel/4.3.0/include --libs -> -L/ichec/packages/netcdf/intel/4.3.0/lib -lnetcdf --has-c++ -> no --cxx -> --has-c++4 -> no --cxx4 -> --fc -> ifort --fflags -> -g -I/ichec/packages/netcdf/intel/4.3.0/include --flibs -> -L/ichec/packages/netcdf/intel/4.3.0/lib -lnetcdff -L//ichec/packages/netcdf/intel/4.3.0/lib/ -L/ichec/packages/hdf5/intel/1.8.11/lib/ -L/ichec/packages/szip/intel/2.1/lib -lnetcdf -lnetcdf --has-f90 -> yes --has-dap -> no --has-nc2 -> yes --has-nc4 -> yes --has-hdf5 -> yes --has-hdf4 -> no --has-pnetcdf-> no --prefix -> /ichec/packages/netcdf/intel/4.3.0 --includedir-> /ichec/packages/netcdf/intel/4.3.0/include --version -> netCDF 4.3.0 Thanks, Cillian" cillianjoy Milestone FLEXPART_WRF_3.4_FPbase_9 201 Installation issue FP other FLEXPART-WRF Support closed 2018-08-16T18:57:58Z 2018-08-16T19:33:08Z "Hi there I am still having trouble getting the FLEXPART WRF installation to work. I have tried both the intel compiler and the PGI compiler. With the intel compiler I got an error saying that the command mpiifort was not found. With the PGI compiler my NetCDF.inc file could not be opened. My NetCDF files are organized with separate sub folders for lib, include, etc. I tried moving up a level. This seemed to correct the issue with finding the NetCDF.inc file. However now I am getting an error that says I have an old or corrupt module file NetCDF.mod. This occurs at the netcdf_output_mod.F90 step. I tried getting to the web address below for the user mailing list. I get a Forbidden URL warning when I click the link below. Are you able to provide any advice regarding the issue above? Thank you very much Kim Mitchell Sent from my iPhone On Aug 16, 2018, at 10:25 AM, FLEXPART.EU wrote: #200: Installation help ------------------------------------+-------------------------- Reporter: mitchekc | Owner: Type: Support | Status: new Priority: major | Milestone: Component: FP coding/compilation | Version: FLEXPART-WRF Resolution: | Keywords: ------------------------------------+-------------------------- Comment (by pesei): Are you satisfied with this answer? Please let us know so that we can close the ticket. In general, it is not necessary to install libraries from source if a distribution package is available. Please also note that questions like this could also be posted to the FLEXPART user mailing list (https://lists.univie.ac.at/mailman/listinfo/flexpart). -- Ticket URL: FLEXPART.EU " mitchekc Milestone FLEXPART_WRF_3.4_FPbase_9 209 Out of bounds error FP coding/compilation FLEXPART-WRF Support pesei closed 2018-10-25T00:19:02Z 2020-05-06T13:45:49Z When I run flexpart-wrf using the command `./flexwrf_intel_omp` I get out of bounds errors when my WRF geographical grid is compared to the grid in flexwrf.input. Where does FLEXPART-WRF look to find the WRF geographical grid to compare to? I have tried multiple settings in flexwrf.input and I can't determine which specific fields in the flexwrf.input file are causing the issue. mitchekc Milestone FLEXPART_WRF_3.4_FPbase_9 216 how to know endpoint of each released particle FP input data FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 222 Richardson Failure - Flexpart WRF 3.3 FP input data FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 240 FLEXPART-WRF particle height does not change for 16 hours FP other FLEXPART-WRF Support pesei closed 2019-05-22T02:45:37Z 2019-07-26T01:59:39Z "Hi there, I am using flexpart-WRF to simulate particel trajectories and what come out seem unnatural and may be casued by some issues. The altitudes of all particles keep increasing for first 8 hours (10am to 18) and then remain at exactly same altitude for another 16 hours (18-8) before increasing again. The last recorded altituedes are often far off the ground (above 200 m). I changes my WRF inputdata to different dates and files but it keeps having the same problem. So could you please be possible to advise any potential issue causing this? Thank you so much for you help and support in advance. Cheers, Iris" ZhenhuaHao Milestone FLEXPART_WRF_3.4_FPbase_9 242 richardson not working -- bad h FP coding/compilation FLEXPART-WRF 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 Milestone FLEXPART_WRF_3.4_FPbase_9 259 did not getting the proper output file FP other FLEXPART-WRF Support closed 2020-02-17T12:35:10Z 2020-03-06T12:58:14Z "I did run WRF-FLEXPART v3.3.2 and I got the message that I have successfully run the WRF-FLEXPART. For output files, I got the file with ""grid_time_201005180x0000_001"" name , in which x is each run hour and format of the files is binary. However, I did not get any file with NETCDF format. My question is how I can get the NETCDF output files from WRF-FLEXPART. at first i try to raise a ticket in the same option and i get a reply that to choose IOUT OPTION =2 BUT i tried it also and its not working im here attaching the script and the screenshot of the run when i type IOUT=2 please help me ...if you have better documents or pdf to study about these topic thats also welcomes Thanks in advance for your help," sprasad Milestone 173 "Variables ""settling"" and ""idummy"" not properly initialized in advance.f" FP coding/compilation flexpart_8.2-3 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 Milestone 193 Wrong date format in output filename FP coding/compilation flexpart_8.2-3 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 Milestone 72 Issues while compiling FLEXTRA FLEXTRA FLEXTRA 3 Support pesei closed 2014-04-10T09:36:33Z 2014-05-28T14:44:44Z "I would be really grateful if someone could help to compile flextra makefile. I've already install all the needed library (Jasper, Emos & Grib Api). But when I try to compile, it seems that the make file is pointing to the wrong library and cannot find : g77 *.o -o FLEXTRA -fno-f2c -O1 -fforce-addr -funroll-loops -fschedule-insns2 -L/home/as/grib -lgrex /usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: cannot find -lgrex /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make: *** [FLEXTRA] Error 1 Does someone know how to fix it ? Or have a compiling procedure ? Best regards, Liliane " lnguyen5 Milestone FLEXTRA 6 274 Non-ascii characters in FLEXTRA output FLEXTRA FLEXTRA 5 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 Milestone FLEXTRA 6 275 FLEXTRA not compilable against eccodes FLEXTRA FLEXTRA 5 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 Milestone FLEXTRA 6 280 Trajectory time 240000 instead of 000000 next day FLEXTRA FLEXTRA 5 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 Milestone FLEXTRA 6 305 FLEXTRA fails with NCEP GFS data after 2021-03-22 FLEXTRA FLEXTRA 5 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 Milestone 4 tarball contains MacOS file FP other none Defect admin closed 2013-07-09T14:17:13Z 2013-07-18T15:46:52Z "The tarball of download:16 contains a file `.DS_Store` which is typical for MacOS. Unpacking the tar on ecaccess gives a checksum error. All tarballs should be checked for such files and recreated without." pesei Milestone 9 Issues with getting the correct data from ECMWF server FP input data none Support leohaim closed 2013-08-09T13:02:44Z 2015-12-03T11:40:37Z All the test program runs (update_script.ksh) are OK and no errors are reported. But while running the script 'flex_91_ecmwf_finegrid_ecgate' there are errors. I hope I have set all the input parameters correct. I have attached the input, output (error and procedure) files for reference. Thank you. adityavaishya Milestone 23 Coding standards FP coding/compilation none Task ansto closed 2013-09-12T17:12:04Z 2014-05-22T11:19:23Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) Regarding coding standards, it was agreed that coding standards would be useful. Stephan sent out the “European Standards for Writing and Documenting Exchangeable Fortran 90 Code” from the COSMO consortium (see Pirmins email: this standard is not restricted to COSMO), which is a quite lengthy document; FLEXPART coding standards shall be much more condensed and simpler; '''AS to send out first version of coding standards by e-mail''' " pesei Milestone 47 FLEXPART Logo FP other none Task admin closed 2013-09-12T19:05:03Z 2014-02-25T09:37:27Z The new FLEXPART logo should be made available in various resolutions and if possible also in vector format in the [/downloads]. pesei Milestone 67 Support for removing levels from EN files FP input data none 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 Milestone 126 Segmentation fault - invalid memory reference FP coding/compilation none Support closed 2015-09-09T14:51:18Z 2015-09-09T14:56:10Z "I just tested FLEXPART and successfully run for the test data given on the home page. But when I do the same thing for the data downloaded from NCEP it is followed by: {{{ Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7FBEED9CA777 #1 0x7FBEED9CAD7E #2 0x7FBEED31CD3F #3 0x44E331 #4 0x41D154 #5 0x44ACD2 #6 0x401E66 #7 0x401960 #8 0x7FBEED307EC4 #9 0x401990 #10 0xFFFFFFFFFFFFFFFF Segmentation fault (core dumped) }}} Can any one help please? Best regards, Gezahegn" gezahegn Milestone 314 Update mkAVAIL.py and grib_domain.py FP other none Task pesei closed 2022-01-25T18:20:39Z 2022-02-01T13:54:01Z [FpInputMetMkavail mkAVAIL.py] and [FpInputMetGribinfo grib_domain.py] are still Python2. They need to be checked for Python3 readiness and probably be updated. pesei Milestone FLEXPART 10 25 Dynamic memory allocation FP coding/compilation none 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 Milestone FLEXPART 9.2 24 Namelist option for input files FP coding/compilation none Enhancement ignacio closed 2013-09-12T17:14:55Z 2014-07-07T07:26:14Z "(from minutes of [wiki:DevelopersWs2012 FpDev Workshop 2012]) to be implemented" pesei Milestone FLEXPART 9.2 55 Particles over highest model level FP physics/numerics none Defect hasod closed 2013-11-18T10:18:51Z 2014-10-21T07:37:49Z When running FLEXPART 9.1 in global domainfilling mode, particles make it over the highest model level. Eventhough this is observed rarely, it results in a crash with division by zero error. alaedera Milestone Long-term tasks 26 configure script FP coding/compilation none 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 Milestone Long-term tasks 44 Cittycat interface FP post-processing none 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 Milestone Long-term tasks 51 Wet deposition - other models FP physics/numerics none 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