Changes between Initial Version and Version 1 of Ticket #275


Ignore:
Timestamp:
Jun 16, 2020, 2:16:16 PM (4 years ago)
Author:
pesei
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #275

    • Property Keywords grib_api GFS added
    • Property Owner set to pesei
    • Property Status changed from new to accepted
    • Property Milestone changed from to FLEXTRA 6

  • Ticket #275 – Description

    initial v1  
    33I 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.
    44
    5 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.
     5What 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.
    66
    7 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
     7I 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
    88
     9
     10{{{
    911TEMP:    0.00000000   
    1012STOP SORRY: T NOT IN [K]
     13}}}
    1114
    12 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:
    1315
     16A 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:
     17
     18{{{
    1419 #### TRAJECTORY MODEL SUBROUTINE READPOINTS: ####
    1520 #### ERROR - TOO MANY STARTING POINTS        #### [...]
     21}}}
    1622
    17 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.
     23
     24I 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.
hosted by ZAMG