id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 275,FLEXTRA not compilable against eccodes,hcpxvi,pesei,"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. ",Enhancement,accepted,major,FLEXTRA 6,FLEXTRA,FLEXTRA 5,,"grib_api, GFS",