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.

Sign up for GitHub

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

Add the "state of ground" to bring in the extra snow depth reports #1368

Draft
wants to merge 20 commits into
base: develop
Choose a base branch
from
Draft

Add the "state of ground" to bring in the extra snow depth reports #1368

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
1c8096f
Add state of ground to increase the snow depth reports.
jiaruidong2017 Nov 9, 2024
365675d
Update the defined index with zero snow depth.
jiaruidong2017 Nov 13, 2024
aee4dc2
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Nov 13, 2024
0c02522
Move python code to parm/gdas/snow/ directory to aviod extra copy.
jiaruidong2017 Nov 13, 2024
e57ac67
Modif to only replace the missing/filled snod values.
jiaruidong2017 Nov 13, 2024
4376049
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Nov 13, 2024
244693c
Address reviewer's comments.
jiaruidong2017 Nov 14, 2024
76a5e94
Fix py norms error.
jiaruidong2017 Nov 14, 2024
2a72e4d
Add the mapping_path indicating the script backend requirements.
jiaruidong2017 Nov 15, 2024
a2d87fd
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Nov 15, 2024
fbd1bb9
Add comments
jiaruidong2017 Nov 15, 2024
db46314
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Nov 22, 2024
91f160e
Update the missing value for elevation from bufr file.
jiaruidong2017 Nov 22, 2024
dc8d9b8
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Dec 20, 2024
d7bf5d7
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Dec 24, 2024
3c1dbf7
Update the scripts and sorc/bufr-query.
jiaruidong2017 Dec 24, 2024
55b54cd
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Jan 13, 2025
5cd21ab
Remove the negative snow depth values.
jiaruidong2017 Jan 18, 2025
47bfb19
Merge branch 'develop' into feature/snow-sogr
jiaruidong2017 Jan 18, 2025
bb85eb6
Fix a logic error
jiaruidong2017 Jan 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions parm/snow/obs/config/bufr2ioda_mapping.yaml.j2
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,3 +2,4 @@ mkdir:
- '{{ DATA }}/obs'
copy:
- ['{{PARMgfs}}/gdas/snow/obs/config/bufr_sfcsno_mapping.yaml', '{{ DATA }}/obs/']
- ['{{PARMgfs}}/gdas/snow/obs/config/ioda_bufr_python_encoder.py', '{{ DATA }}']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does the python script need copied? and should it go here? we might need to talk to @emilyhcliu about the progress of SPOC

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @CoryMartin-NOAA for your suggestions. Do you agree if I put this python code to sorc/gdas.cd/parm/snow/, so that this code can be used directly?
@emilyhcliu Any suggestions?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved this py code to the parm/gdas/snow/ directory for a temporary solution. @emilyhcliu Please let me know if you have any other suggestions. Thanks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scripts shouldn't be in parm/, until we move to SPOC, it should probably go here: https://github.com/NOAA-EMC/GDASApp/tree/develop/ush/ioda/bufr2ioda

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood. Wait for @emilyhcliu suggestions.

17 changes: 10 additions & 7 deletions parm/snow/obs/config/bufr_sfcsno_mapping.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,6 @@ bufr:
query: "[*/CLON, */CLONH]"
stationIdentification:
query: "*/RPID"

stationElevation:
query: "[*/SELV, */HSMSL]"

Expand All @@ -26,11 +25,8 @@ bufr:
query: "[*/SNWSQ1/TOSD, */MTRMSC/TOSD, */STGDSNDM/TOSD]"
transforms:
- scale: 1000.0
Comment on lines 27 to 28
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on IODA data convention, the unit of totalSnowDepth is m. We should remove the conversion of it from meter to millimeter.

Copy link
Collaborator Author

@jiaruidong2017 jiaruidong2017 Jan 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above to keep use the conversion.

filters:
- bounding:
variable: totalSnowDepth
lowerBound: 0
upperBound: 10000000
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my understanding:

  • is this introducing a 10 m limit on snow depth obs?
  • if they are above 10 m, are they discarded, or set to 10.?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I previously put this large number (10000m) here for removing the missing values. Here, we don't need this any more because we need to set the missing snod values to 0 when sogr satisfies the defined conditions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might still have missing values though wouldn't we?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The missing values will be removed after applying sogr conditions.

groundState:
query: "[*/GRDSQ1/SOGR, */STGDSNDM/SOGR]"

encoder:
variables:
Expand Down Expand Up @@ -65,11 +61,18 @@ encoder:
coordinates: "longitude latitude"
source: variables/stationIdentification
longName: "Identification of Observing Location"
units: "m"
units: "index"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiaruidong2017 The unit of stationIdentification is not defined (empty) in the IODA convention table, and it is left for users to decide. Have you discussed the unit for stationIdentification with JCSDA (Ben Ruston)?
Let's leave it as "index" for now and I will open an issue in IODA repository and check if we can use "index" as unit for this variable.


# ObsValue
- name: "ObsValue/totalSnowDepth"
coordinates: "longitude latitude"
source: variables/totalSnowDepth
longName: "Total Snow Depth"
units: "mm"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiaruidong2017 The unit of the totalSnowDepth defined in IODA data convention is m, not mm

https://jointcenterforsatellitedataassimilation-jedi-docs.readthedocs-hosted.com/en/latest/inside/conventions/tbls.html

Copy link
Collaborator Author

@jiaruidong2017 jiaruidong2017 Jan 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to keep using the mm here in the observation files to match the unit used in the UFS model for the snow depth.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiaruidong2017 Is it possible to read in the totalSnowDepth in m unit from the IODA/NetCDF file and then convert it to mm in the UFS model?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible, but will require additional efforts. We can discuss this issue with the physics team.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiaruidong2017 I guess only a one-line change is necessary for UFS. You just need to convert totalSnowDepth from m to mm where it is read from IODA obs file.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This issue (mismatch between units proscribed by JEDI and those used in the UFS) is bigger than this PR - as all other snow depth IODA files are in mm too. If we change these observations to mm, we'll need to change the others. I suggest that we leave this in mm for now, and create a separate issue to address the unit mismatch (by introducing a unit transform somewhere).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Let's keep it as "mm" for now.


- name: "ObsValue/groundState"
coordinates: "longitude latitude"
source: variables/groundState
longName: "STATE OF THE GROUND"
units: "index"

31 changes: 31 additions & 0 deletions parm/snow/obs/config/ioda_bufr_python_encoder.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
import numpy as np
import bufr
from pyioda.ioda.Engines.Bufr import Encoder


def mask_container(container, mask):
new_container = bufr.DataContainer()
for var_name in container.list():
print(f" ... variable name: {var_name} ...")
var = container.get(var_name)
paths = container.get_paths(var_name)
new_container.add(var_name, var[mask], paths)

return new_container

def create_obs_group(input_path):
YAML_PATH = "./obs/bufr_sfcsno_mapping.yaml"
container = bufr.Parser(input_path, YAML_PATH).parse()

sogr = container.get('variables/groundState')
snod = container.get('variables/totalSnowDepth')
snod[(sogr <= 11.0) | (sogr == 15.0)] = 0.0
container.replace('variables/totalSnowDepth', snod)

print(f" ... Remove filled/missing snow values ...")
masked_container = mask_container(container, (~snod.mask))

encoder = Encoder(YAML_PATH)
data = next(iter(encoder.encode(masked_container).values()))

return data
6 changes: 4 additions & 2 deletions parm/snow/obs/config/sfcsno_snow.yaml.j2
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,11 @@
halo size: 250e3
obsdatain:
engine:
type: bufr
type: script
script file: "{{ DATA }}/ioda_bufr_python_encoder.py"
args:
input_path: '{{ DATA }}/obs/{{ OPREFIX }}sfcsno.tm00.bufr_d'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion:
Make the mapping file as input to the Python script for create_obs_group

args:
 input_path:  '{{ DATA }}/obs/{{ OPREFIX }}sfcsno.tm00.bufr_d'
 mapping_path: = "./obs/bufr_sfcsno_mapping.yaml"

This will make it clear that the script backend requires two inputs: bufr file and the mapping file

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @emilyhcliu for the suggestions. I made the changes as suggested.

obsfile: '{{ DATA }}/obs/{{ OPREFIX }}sfcsno.tm00.bufr_d'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to add an issue so they do not assume the formatting of the YAML file (obsfile variable shoould not be necessary). Reading the backend engines YAML breaks encapsulation (external modules should not be dependent on the private configuration for a backend type. Some backends may not have any kind of file associated with them (like a db...).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes thanks @rmclaren I'm aware of that issue, I/we/others need to figure out how best to handle it on the workflow side.

mapping file: '{{ DATA }}/obs/bufr_sfcsno_mapping.yaml'
obsdataout:
engine:
type: H5File
Expand Down
2 changes: 1 addition & 1 deletion sorc/bufr-query
Open in desktop
Submodule bufr-query updated 36 files
+4 −2 CMakeLists.txt
+5 −5 cmake/Targets.cmake
+4 −2 core/CMakeLists.txt
+8 −0 core/include/bufr/BufrParser.h
+25 −2 core/include/bufr/DataContainer.h
+523 −1 core/include/bufr/DataObject.h
+5 −7 core/include/bufr/DataProvider.h
+8 −3 core/include/bufr/File.h
+3 −0 core/include/bufr/NcepDataProvider.h
+3 −0 core/include/bufr/WmoDataProvider.h
+66 −1 core/src/bufr/BufrReader/BufrParser.cpp
+51 −11 core/src/bufr/BufrReader/Query/DataProvider/DataProvider.cpp
+8 −0 core/src/bufr/BufrReader/Query/DataProvider/NcepDataProvider.cpp
+7 −0 core/src/bufr/BufrReader/Query/DataProvider/WmoDataProvider.cpp
+12 −5 core/src/bufr/BufrReader/Query/File.cpp
+56 −0 core/src/bufr/DataContainer.cpp
+11 −2 core/src/encoders/netcdf/Encoder.cpp
+31 −0 docs/python_api.rst
+1 −0 docs/uml/BUFR_BigPicture.puml
+25 −28 python/CMakeLists.txt
+17 −10 python/DataObjectFunctions.cpp
+4 −4 python/DataObjectFunctions.h
+4 −0 python/py_bufr.cpp
+17 −1 python/py_data_container.cpp
+2 −1 python/py_file.cpp
+49 −0 python/py_mpi.cpp
+23 −0 python/py_mpi.h
+15 −2 python/py_parser.cpp
+12 −8 test/CMakeLists.txt
+2 −2 test/testinput/bufrtest_fieldname_validation.py
+88 −0 test/testinput/bufrtest_python_mpi_test.py
+21 −12 test/testinput/bufrtest_python_test.py
+3 −0 tools/bufr2netcdf/CMakeLists.txt
+140 −44 tools/bufr2netcdf/bufr2netcdf.cpp
+1 −1 tools/build_scripts/bufr_query_cpp_lint.py
+11 −3 tools/show_queries/QueryPrinter.cpp
Loading