-
Notifications
You must be signed in to change notification settings - Fork 24
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
Bugfix: Fix the fill value setting used in the write_tmp_dataplane internal Python embedding script #2525
Comments
This will be a general solution at python/met/dataplane.py when MET_PYTHON_EXE is defined:
|
Closing since PR #2529 was merged into develop. |
pp_dataplane.py wil be introduced and the user's python script is executed by "pp_dataplane.py". Arguments for plot_data_plane:
MET calls the following command intenally python3 /d1/personal/hsoh/git/features/feature_2525_fill_value_at_dataplane/MET/share/met/python/examples/read_ascii_numpy.py letter.txt LETTER";' -plot_range 0.0 255.0 -title "Python enabled numpy plot_data_plane" -v 8 This will be changed to python3 /d1/personal/hsoh/git/features/feature_2525_fill_value_at_dataplane/MET/share/met/python/met/pp_dataplane.py /d1/personal/hsoh/git/features/feature_2525_fill_value_at_dataplane/MET/share/met/python/examples/read_ascii_numpy.py letter.txt LETTER";' -plot_range 0.0 255.0 -title "Python enabled numpy plot_data_plane" -v 8 pp_dataplane.py checks values at dataplane and converts NaN, INF, and 1e10 (missing value for Numpy masked array) to missing value, -9999. If user_fill_value is set, it will be changed to -9999. |
…aplane Feature #2525 fill value at dataplane
Describe the Problem
In #2509, an error was corrected inside
write_tmp_dataplane.py
.The code changed from this:
MET/data/wrappers/write_tmp_dataplane.py
Lines 45 to 49 in 5ffa5f1
To this:
MET/scripts/python/met/dataplane.py
Lines 91 to 95 in bf0e5ad
Previously, the
try
block was failing and so-9999.
was used as thefill_value
when writing the temporary netCDF file (used only for Python embedding withMET_PYTHON_EXE
set). This is actually desirable, because-9999.
is thefill_value
recognized by MET tools.In #2509, the
try
block was corrected so thatmet_in.met_data
was properly referenced. Downstream in METplus wrappers, a use case failed using this new code. The reason is because thefill_value
in the temporary netCDF file was now set to thefill_value
of themet_in.met_data
object controlled by the user. In the METplus use case, the user is using a NumPy masked array and for a data type offloat64
, the defaultfill_value
is 1e+20 (https://numpy.org/doc/stable/reference/generated/numpy.ma.default_fill_value.html). However, MET tools do not respect this as a missing data value and so for this use case 1e+20 was treated as valid data.Some questions:
fill
always be set to-9999.
?createVariable
, how are missing data in themet_data
object handled? For example, if the user has a NumPy N-D array that containsnan
, butfill=-9999.
is set increateVariable
, does netcdf4-python automatically know to substitute-9999.
fornan
everywhere in the user's data? I did a quick test of this case forPYTHON_NUMPY
andPYTHON_XARRAY
and it appears that is the case. But if the user has a special value for fill_value, like "-99", then this does not work. I think that our temporary Python embedding code assumes that the user hasnan
where there is missing data. We should state this if that is the case. Ironically, I tried substituting "-9999." for "nan" in my data, andnetcdf4
did not recognize this as missing data, even though we setfill=-9999.
inwrite_tmp_dataplane.py
. Therefore, it really is critical to communicate to the user they must be usingnan
.nan
where there is missing data. MET respects this using the compile time instance, and also usingMET_PYTHON_EXE
Python. If any other value is substituted, it will not be respected as missing data in MET.For the "bug" in this issue, to get the use case to pass downstream, I think we can just remove the entire
try/except
block and always forcefill=-9999.
. From what I read aboutnetcdf4.createVariable
, it seems that if a user passes a masked array (asmet_data
), and it has a fill/mask value of 1e+20, then it will be respected automatically bynetcdf4
. Otherwise, the user must pass a NumPy N-D array withnan
as the FillValue or an Xarray DataArray object withnan
as the FillValue. I tested this for the use case that was failing, and simply just forcing `fill=-9999.' worked. However, we will need to test other cases that do not use masked arrays to make sure this doesn't break that, but I don't think it will.Expected Behavior
Provide a clear and concise description of what you expected to happen here.
Environment
Describe your runtime environment:
1. Machine: (e.g. HPC name, Linux Workstation, Mac Laptop)
2. OS: (e.g. RedHat Linux, MacOS)
3. Software version number(s)
To Reproduce
Describe the steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
Post relevant sample data following these instructions:
https://dtcenter.org/community-code/model-evaluation-tools-met/met-help-desk#ftp
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Define the source of funding and account keys here or state NONE.
Define the Metadata
Assignee
Labels
Projects and Milestone
Define Related Issue(s)
Consider the impact to the other METplus components.
Bugfix Checklist
See the METplus Workflow for details.
Branch name:
bugfix_<Issue Number>_main_<Version>_<Description>
Pull request:
bugfix <Issue Number> main_<Version> <Description>
Select: Reviewer(s) and Development issue
Select: Organization level software support Project for the current coordinated release
Select: Milestone as the next bugfix version
Branch name:
bugfix_<Issue Number>_develop_<Description>
Pull request:
bugfix <Issue Number> develop <Description>
Select: Reviewer(s) and Development issue
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
The text was updated successfully, but these errors were encountered: