opendrift icon indicating copy to clipboard operation
opendrift copied to clipboard

ROMS native reader warnings

Open John-Luick opened this issue 3 years ago • 3 comments

I have been away from OpenDrift for a while, but now have a new project and am a bit rusty. I wrote a program to convert an output file from CMEMS/Mercator ocean model to ROMS format in order to read it using ROMS Native reader. Actually, as I recall OpenDrift already has a reader for that model (right?) but I would like to get my program running anyway. At present OpenDrift throws a lot of warning messages when roms_native reads from my converted file. Here are a couple lines (which are repeated numerous times): 14:44:07 INFO: 2020-01-03 23:40:00 - step 287 of 288 - 200 active elements (0 deactivated) 14:44:07 WARNING: Multiprocessing has previously failed, reverting to using single processor for lonlat -> xy I don't get those warnings when reading from your files! I thought it might have something to do with the way I set up variables like lat_rho, so I will paste in what my lat_rho looks like (what Matlab ncdisp shows is in my ROMS-formatted file): lat_rho
Size: 400x300 Dimensions: xi_rho,eta_rho Datatype: double Attributes: standard_name = 'latitude' units = 'degrees north' By contrast, this is what lat_rho looks like in your example for the Nordic model output: lat_rho
Size: 151x81 Dimensions: xi_rho,eta_rho Datatype: int16 Attributes: long_name = 'latitude of RHO-points' units = 'degree_north' standard_name = 'latitude' field = 'lat_rho, scalar' scale_factor = -9.2165e-05 add_offset = 68.6641

The question is, do you think it is the lack of "scale factor" or one of the other descriptors that causes OpenDrift to throw those warnings? (It still runs and the plots look fine). Or could it be the datatype I use? I doubt it would be that I call the units slightly differently than OpenDrift, but... Thanks John

John-Luick avatar Jan 19 '22 07:01 John-Luick

Hi John, and welcome back!

I don't see any reason to convert Mercator ocaen model output to ROMS format. Firstly, it is not a ROMS model, so you would struggle a lot to force it into that format. And secondly, these data are already CF-compliant, and works out of the box with the generic reader.

In the meantime, it is also good news that CMEMS data have become available through Thredds/OPeNDAP. Thus you may use this URL directly with the same generic reader: https://nrt.cmems-du.eu/thredds/dodsC/global-analysis-forecast-phy-001-024-hourly-merged-uv Only thing is that you need to store your CMEMS username/password in a .netrc file: https://www.labkey.org/Documentation/wiki-page.view?name=netrc

>>> from opendrift.readers.reader_netCDF_CF_generic import Reader
>>> r = Reader('https://nrt.cmems-du.eu/thredds/dodsC/global-analysis-forecast-phy-001-024-hourly-merged-uv')
>>> print(r)
===========================
Reader: https://nrt.cmems-du.eu/thredds/dodsC/global-analysis-forecast-phy-001-024-hourly-merged-uv
Projection: 
  +proj=latlong
Coverage: [degrees]
  xmin: -180.000000   xmax: 179.916672   step: 0.0833282   numx: 4320
  ymin: -80.000000   ymax: 90.000000   step: 0.0833359   numy: 2040
  Corners (lon, lat):
    (-180.00,  90.00)  (179.92,  90.00)
    (-180.00, -80.00)  (179.92, -80.00)
Vertical levels [m]: 
  [-0.494025]
Available time range:
  start: 2019-01-01 00:30:00   end: 2022-01-27 23:30:00   step: 1:00:00
    26952 times (0 missing)
Variables:
  eastward_sea_water_velocity
  northward_sea_water_velocity
  sea_surface_wave_stokes_drift_x_velocity
  sea_surface_wave_stokes_drift_y_velocity
  x_sea_water_velocity
  y_sea_water_velocity
===========================

knutfrode avatar Jan 19 '22 08:01 knutfrode

Hi Knut-Frode,

Thanks. I am very glad to read what you have said. I will proceed as you suggest tomorrow, and let you know.

You will not realise it, but I have been a big ambassador for OpenDrift, praising it to many people. Also I have promised to set up a Flinders University PhD student with OpenDrift. She will be doing tracking around the entire continent around mid-year as part of her thesis.

By the way, a few hours ago my partners in UAE asked me about tracking airborne pollutants. I said I would see what was out there. Any suggestions for that?

All the best

John

From: Knut-Frode Dagestad @.> Sent: Wednesday, 19 January 2022 6:49 PM To: OpenDrift/opendrift @.> Cc: John Luick @.>; Author @.> Subject: Re: [OpenDrift/opendrift] ROMS native reader warnings (Issue #834)

Hi John, and welcome back!

I don't see any reason to convert Mercator ocean model output to ROMS format. Firstly, it is not a ROMS model, so you would struggle a lot to force it into that format. And secondly, these data are already CF-compliant, and works out of the box with the generic reader.

In the meantime, it is also good news that CMEMS data have become available through Thredds/OPeNDAP. Thus you may use this URL directly with the same generic reader: https://nrt.cmems-du.eu/thredds/dodsC/global-analysis-forecast-phy-001-024-hourly-merged-uv Only thing is that you need to store your CMEMS username/password in a .netrc file: https://www.labkey.org/Documentation/wiki-page.view?name=netrc

from opendrift.readers.reader_netCDF_CF_generic import Reader

r = Reader('https://nrt.cmems-du.eu/thredds/dodsC/global-analysis-forecast-phy-001-024-hourly-merged-uv')

print(r)

===========================

Reader: https://nrt.cmems-du.eu/thredds/dodsC/global-analysis-forecast-phy-001-024-hourly-merged-uv

Projection:

+proj=latlong

Coverage: [degrees]

xmin: -180.000000 xmax: 179.916672 step: 0.0833282 numx: 4320

ymin: -80.000000 ymax: 90.000000 step: 0.0833359 numy: 2040

Corners (lon, lat):

(-180.00,  90.00)  (179.92,  90.00)

(-180.00, -80.00)  (179.92, -80.00)

Vertical levels [m]:

[-0.494025]

Available time range:

start: 2019-01-01 00:30:00 end: 2022-01-27 23:30:00 step: 1:00:00

26952 times (0 missing)

Variables:

eastward_sea_water_velocity

northward_sea_water_velocity

sea_surface_wave_stokes_drift_x_velocity

sea_surface_wave_stokes_drift_y_velocity

x_sea_water_velocity

y_sea_water_velocity

===========================

— Reply to this email directly, view it on GitHubhttps://github.com/OpenDrift/opendrift/issues/834#issuecomment-1016189270, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQGKJMBZA2MRIH5BKAIDVZLUWZXXFANCNFSM5MJDWBJQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

John-Luick avatar Jan 19 '22 08:01 John-Luick

Thank you for being an ambassador :-)

OpenDrift was in fact designed to also do airborne transport, but there is not much functionality for that so far, basically only following surface winds: https://opendrift.github.io/gallery/example_windblow.html

I am not very familiar with tools for atmospheric transport, but believe that Flexpart is one of the most widely used tools: https://www.flexpart.eu

knutfrode avatar Jan 19 '22 10:01 knutfrode