Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement MET's Filetype determination logic in METplus #114

Open
jimfrimel opened this issue Sep 6, 2018 · 0 comments
Open

Implement MET's Filetype determination logic in METplus #114

jimfrimel opened this issue Sep 6, 2018 · 0 comments
Labels
type: enhancement Improve something that it is currently doing

Comments

@jimfrimel
Copy link
Contributor

jimfrimel commented Sep 6, 2018

Implement MET's Filetype determination logic in METplus.

This is sort of a continuum from issue #72 and the relevant closing comments from
issue #72 are included below:

The overall determination of file type needs to be revisited to match MET's behavior.
That way there is consistency between applications.

Requirement) Review MET's logic on this.

Look at this function: grd_file_type()
In this file: ./src/libcode/vx_data2d_factory/data2d_factory_utils.cc

Requirement) Handle the following unique case ?
There is also the issue of a Grib file that did not have the magic-cookie information
in the first 4 bytes of the file. One could argue that it is not a valid grib file. However,
the individual records in the file were correctly identified and formatted. Also, the file was
able to be processed by MET, IF the "filetype=GRIB" option was passed to MET.

Requirement) ?
Add functionality to pass along "filetype" option to MET

Requirement) specify expected input FILETYPE in METplus conf file ?
There is some complication to this problem ... such as identifying the file type in the
METplus conf file where as the input in one step may be GRIB 1 or GRIB 2 .. the output is
NetCDF which will be input to the next step in the process list .... So what is the best way
to identify and handle this ?

@jimfrimel jimfrimel added the type: enhancement Improve something that it is currently doing label Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Improve something that it is currently doing
Projects
None yet
Development

No branches or pull requests

2 participants