Station files: fill values but not _FillValue attribute

[m.hadfield]

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.

[arango]

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.

[m.hadfield]

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.

[arango]

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...