-
Notifications
You must be signed in to change notification settings - Fork 15
Feature/query cxx types #1044
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
Feature/query cxx types #1044
Changes from all commits
2c9a19a
911ab75
7292097
4197505
63ccb24
0267205
2fe07fc
e6a57ed
0bcdf01
569c0d4
a28c35c
0c2dd81
9bf4a30
be4c663
df685f0
5c40747
2ef38f9
a30979d
3aad615
80dbe6e
129fb53
4c37c3b
ec23950
6de09ed
9f7b8fa
b165236
0051a0e
c655f4a
8644963
25982ab
2b81f86
0dabeb8
9eb5f62
1679444
ef43b58
7dfe9ef
92aedb7
a48e36a
aa1f4ff
a723efc
f655842
a815020
a9983fc
af1304a
48f5189
eebbf26
81a63a1
3432e9c
6402f03
2159242
ee81939
69a2f72
7378b39
598ebf6
2406042
d8240c0
81931e3
430850c
f083af6
85c1a3e
d16bf12
6e158c7
68bc140
6c9f1d6
eeb0896
552aceb
d74796c
26ab396
56a452c
b86c4da
9da4fb3
da9c483
5153474
8300c35
a052afb
418b1f4
e83ff00
6a892fd
c683b4b
fb5f07f
067390d
efa2763
0a79cb3
ccbbeb6
f09a98c
d403b75
dff7251
eca2524
d723ac0
20eb76b
6fe7e43
664c2bf
394ae09
b5d4cdc
b55c75d
b98c09d
3122f9a
da75624
24d6a3e
68e94ec
6a5043e
724b104
9657fb2
107376f
f76dbc8
bcda337
c80d02c
29a65b3
9325c5b
a0dd8e1
4bd2e8c
ac14e75
f611e3a
4adeaef
afbcb8f
a518afe
9bba0bf
b8165a7
297b19a
b4a32e4
65ffefb
3aecf36
53b6e41
92e46f3
230ad33
bf8606e
c2fc683
a6e38a2
2bd39d0
2be7961
36419c6
d7d3f91
3ec5043
aafc721
df7d5c8
4fb7bae
22c73b6
27a670a
a53f0e1
03bbffd
dccf5a4
a76894e
dfc55d7
fbadda3
703b087
482f684
aff8124
bdd5c9b
f3fe27e
adf9c7e
a2f7e65
39bfe36
ec02de9
d4905fe
509af0f
03dadc4
06fb678
79ad913
1360fd9
8dff03a
d823c86
a5a1b1b
4c43af3
f4477bf
37c0e49
71f2046
5281c18
ba1b34b
2cf589b
e49879a
71d2c26
c78b93e
6c29f1f
f92e4e5
cdecff3
25b31d9
cb80b94
09c01c7
4e14eb9
8d5d8e4
5367711
db27ad3
9c65f78
5ae5209
40f0516
8f1e3fb
ccb9cb6
a300e9c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,6 +12,8 @@ | |
| #include <iostream> | ||
| #include <unordered_map> | ||
|
|
||
| #include "eckit/exception/Exceptions.h" | ||
|
|
||
| namespace | ||
| { | ||
| const char* Subset = "SUB"; | ||
|
|
@@ -32,6 +34,7 @@ namespace bufr { | |
|
|
||
| void DataProvider::updateData(int bufrLoc) | ||
| { | ||
| bufrLoc_ = bufrLoc; | ||
| int size = 0; | ||
| int *intPtr = nullptr; | ||
| double *dataPtr = nullptr; | ||
|
|
@@ -98,5 +101,60 @@ namespace bufr { | |
| { | ||
| delete_table_data_f(); | ||
| } | ||
|
|
||
| TypeInfo DataProvider::getTypeInfo(FortranIdx idx) const | ||
| { | ||
| static const unsigned int UNIT_STR_LEN = 24; | ||
| static const unsigned int DESC_STR_LEN = 55; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is 55 a hard-wired limit? Kinda arbitrary. This may be entirely unimportant, but I often like to declare string lengths to remain multiples of 8 for memory reasons; so could this be 64? No idea what downstream effects would occur.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where do these numbers come from? Are they part of the BUFR spec for example. A comment here would be helpful so that future developers know what's going on. Thanks! |
||
|
|
||
| char unitCStr[UNIT_STR_LEN]; | ||
| char descCStr[DESC_STR_LEN]; | ||
|
|
||
| int retVal; | ||
| TypeInfo info; | ||
|
|
||
| nemdefs_f(fileUnit_, | ||
| getTag(idx).c_str(), | ||
| unitCStr, | ||
| UNIT_STR_LEN, | ||
| descCStr, | ||
| DESC_STR_LEN, | ||
| &retVal); | ||
|
|
||
| if (retVal == 0) | ||
| { | ||
| // trim the unit string | ||
| auto unitStr = std::string(unitCStr); | ||
| size_t end = unitStr.find_last_not_of(" \n\r\t\f\v"); | ||
| unitStr = (end == std::string::npos) ? "" : unitStr.substr(0, end + 1); | ||
| info.unit = unitStr; | ||
|
|
||
| // trim the unit string | ||
| auto descStr = std::string(descCStr); | ||
| end = descStr.find_last_not_of(" \n\r\t\f\v"); | ||
| descStr = (end == std::string::npos) ? "" : descStr.substr(0, end + 1); | ||
| info.description = descStr; | ||
|
|
||
| int descriptor; | ||
| int table_idx; | ||
| char table_type; | ||
|
|
||
| nemtab_f(bufrLoc_, | ||
| getTag(idx).c_str(), | ||
| &descriptor, | ||
| &table_type, | ||
| &table_idx); | ||
|
|
||
| nemtbb_f(bufrLoc_, | ||
| table_idx, | ||
| unitCStr, | ||
| UNIT_STR_LEN, | ||
| &info.scale, | ||
| &info.reference, | ||
| &info.bits); | ||
| } | ||
|
|
||
| return info; | ||
| } | ||
| } // namespace bufr | ||
| } // namespace Ingester | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,8 +9,8 @@ | |
|
|
||
| #include <string> | ||
| #include <vector> | ||
| #include <math.h> | ||
| #include <memory> | ||
|
|
||
| #include <gsl/gsl-lite.hpp> | ||
|
|
||
| namespace Ingester{ | ||
|
|
@@ -31,11 +31,48 @@ namespace bufr { | |
| Character | ||
| }; | ||
|
|
||
| struct TypeInfo | ||
| { | ||
| int scale = 0; | ||
| int reference = 0; | ||
| int bits = 0; | ||
| std::string unit; | ||
| std::string description; | ||
|
|
||
| bool isString() const { return unit == "CCITT IA5"; } | ||
| bool isSigned() const | ||
| { | ||
| // To better support Fortran clients for the generated ObsGroups we will assume all | ||
| // fields are signed. Otherwise this code would be reference < 0. | ||
| return true; | ||
| } | ||
| bool isInteger() const { return scale <= 0; } | ||
| bool is64Bit() const | ||
| { | ||
| bool is64Bit; | ||
| if (isInteger() && !isSigned()) | ||
| { | ||
| is64Bit = (log2((pow(2, bits) - 1) / pow(10, scale) + reference) > 32); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure what this function is doing. Some comments would be helpful. My guess is that from a BUFR table you get some description of the data for each variable, but that description isn't quite enough to simply know what precision that data will require. So you have to run a few tests to determine the required precision. Calling log and pow seems expensive. However, this point is moot if this routine only gets called a few times. If it gets called many times, is there a way to do this with less expensive computations? |
||
| } | ||
| else if (isInteger() && isSigned()) | ||
| { | ||
| is64Bit = (log2(fmax(-1 * reference, | ||
| (pow(2, bits - 1) - 1) / pow(10, scale) + reference) * 2) + 1 > 32); | ||
| } | ||
| else | ||
| { | ||
| is64Bit = false; | ||
| } | ||
|
|
||
| return is64Bit; | ||
| } | ||
| }; | ||
|
|
||
| /// \brief Responsible for exposing the data found in a BUFR file in a C friendly way. | ||
| class DataProvider | ||
| { | ||
| public: | ||
| DataProvider() = default; | ||
| explicit DataProvider(int fileUnit) : fileUnit_(fileUnit) {} | ||
| ~DataProvider() = default; | ||
|
|
||
| /// \brief Read the data from the BUFR interface for the current subset and reset the | ||
|
|
@@ -63,8 +100,10 @@ namespace bufr { | |
| inline FortranIdx getNVal() const { return nval_; } | ||
| inline FortranIdx getInv(FortranIdx idx) const { return inv_[idx - 1]; } | ||
| inline double getVal(FortranIdx idx) const { return val_[idx - 1]; } | ||
| TypeInfo getTypeInfo(FortranIdx idx) const; | ||
|
|
||
| private: | ||
| int fileUnit_; | ||
| std::string subset_; | ||
|
|
||
| // Table data; | ||
|
|
@@ -78,6 +117,7 @@ namespace bufr { | |
| // Subset data | ||
| int inode_; | ||
| int nval_; | ||
| int bufrLoc_; | ||
| gsl::span<const double> val_; | ||
| gsl::span<const int> inv_; | ||
| }; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure it matters, but would this make more sense as 10.0d10 since it is declared double precision?
I also admit some confusion because I thought BUFR had a single-precision missing value since a double missing would require more space to store than a single-precision. Is this actually a NCEP bufr-lib thing not actually something inherent to BUFR storage itself?