[go: nahoru, domu]

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

differences in pdstemplates between g2 and g2c libraries #383

Open
edwardhartnett opened this issue Nov 20, 2022 · 0 comments
Open

differences in pdstemplates between g2 and g2c libraries #383

edwardhartnett opened this issue Nov 20, 2022 · 0 comments
Assignees
Labels
bug Something isn't working

Comments

@edwardhartnett
Copy link
Contributor

When we have the same data in two places it's an invitation for bugs. We invited them in, now we have them. ;-)

pdstemplate info is stored in both the C and Fortran libraries. What I have just discovered is that there are numerous differences.

For example, in NCEPLIBS-g2/src/pdstemplates.F90:

  data templates(1)%template_num /0/     !  Fcst at Level/Layer
  data templates(1)%mappdslen /15/
  data templates(1)%needext /.false./
  data (templates(1)%mappds(j), j = 1, 15)  &
       /1, 1, 1, 1, 1, 2, 1, 1, 4, 1, -1, -4, 1, -1, -4/

From NCEPLIBS-g2c/src/pdstemplates.c:

{0, 15, 0, {1, 1, 1, 1, 1, 2, 1, 1, -4, 1, -1, -4, 1, -1, -4}},

Note that the 9th template item is 4 in Fortran, -4 in C. (The correct answer is -4, see #381).

To fix we need firstly full testing of all these values in both C and Fortran, to lock everything down.

Then we will find the differences and fix them.

The final solution will be that only the C library maintains these numbers, and the Fortran library gets them from the C library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: In progress
Development

No branches or pull requests

2 participants