Station files: fill values but not _FillValue attribute

Bug reports, work arounds and fixes

Moderators: arango, robertson

Post Reply
Message
Author
User avatar
m.hadfield
Posts: 520
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Station files: fill values but not _FillValue attribute

#1 Post by m.hadfield » Wed May 09, 2012 3:24 am

OK, it's a bit of a stretch to call this a bug report, more a suggestion for a minor improvement.

When a station is inside the land mask (or just outside it in the case of velocity variables) values of 1.0E37 get written to the station file. The netCDF variables in which these values are written include the dynamic variables like temp, salt, etc, but also some static variables like lon_rho/x_rho, lat_rho/y_rho, h and angle. However Ipos and Jpos are always realistic.

If special values like 1.0E37 are going to be written to the file, it is desirable to add an appropriate _FillValue attribute, indicating that they represent invalid data. Otherwise processing software can get confused.

Yes, I know this can be avoided by not having stations on or near the land mask, but the fact is that this can happen and it is desirable to have the model behave as gracefully as possible when it does.

Modified source files are attached.
Attachments
def_info.F
(114.28 KiB) Downloaded 99 times
def_station.F
(84.1 KiB) Downloaded 93 times

User avatar
arango
Site Admin
Posts: 1103
Joined: Wed Feb 26, 2003 4:41 pm
Location: IMCS, Rutgers University
Contact:

Re: Station files: fill values but not _FillValue attribute

#2 Post by arango » Wed May 09, 2012 11:45 pm

Yes, I missed this one. Except we should only put the _FillValue attribute in the variables and not in the coordinates. I recommend you to avoid doing that in def_info.F. These variables are used to process the coordinates attribute by other third party software for CF compliance. The position values are valid even if the data value at such locations are not. The values of bathymetry (h) and free-surface (zeta) are tricky because they determine the vertical coordinate and because wetting and drying. These variables are processed in ROMS specially.

Thank you for reporting this issue.

User avatar
m.hadfield
Posts: 520
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: Station files: fill values but not _FillValue attribute

#3 Post by m.hadfield » Thu May 10, 2012 1:39 am

Hi again Hernan

At the moment, values of 1.E37 are written to lon_rho/x_rho, lat_rho/y_rho, h and zeta for points in the land mask. Are you saying that this should not happen? I am inclined to agree. However if it is happening, then it is appropriate to mark them as fill values via that variables _FillValue attribute.

User avatar
arango
Site Admin
Posts: 1103
Joined: Wed Feb 26, 2003 4:41 pm
Location: IMCS, Rutgers University
Contact:

Re: Station files: fill values but not _FillValue attribute

#4 Post by arango » Thu May 10, 2012 1:57 am

Well, then I need to fix that. This was coded more than 10 years ago during ROMS development. I guess that I need to revisit this. I hope to do it soon. Now I am completely busy reworking our shared-memory strategy. It turns out that what Sasha was suggesting recently facilitates nesting. I get less restricted parallel regions. I also have this annoying problem with MPDATA that I have been trying to solve for more than a year.

I hope that you help to test this in your computers...

Post Reply