![]() ![]() ![]() I will paste in the section with the u attributes that I get from an ncinfo on the netcdf file. Maybe if that is fixed, the rotation ambiguity may also be resolved. I would prefer to use the CF_generic reader, so any clues as to why it gave me zero velocities are most welcome. Note that the reference to rotation in myreader.txt says that the rotation is zero, which is good, but reference to rotation in cfgenericreader.txt is a little ambiguous (at least to me). Here is a link to both of the console runtime outputs (myreader.txt, which is my modified ROMS_native reader, and cfgenericreader.txt): !AvnPG7Gh4JsAhMcXooqIMQZK6KEUKQ?e=5YoIG3. That was why I switched to the ROMS_native reader (which I modified by changing the variable_mappings of u and v as described before). Originally I tried the CF_generic reader, but it resulted in zero velocities. ![]() Table 1 in Laxague seems to imply that 3.7% may be an underestimate for certain situations, but my main concern was more the reason for the adjustment, than its amplitude, and your answer makes that quite clear. Thanks for explaining about the wind-drift factor and for the links to references, which were also helpful. If you use loglevel=0, you will see in your log whenever vectors are rotated, and by how many degrees. Here is the method that is used internally in OpenDrift to rotate vectors. If the projection is PlateCaree or Mercator these should be identical. But it might be necessary if your forcing data is in a personal or in-house file format.īut anyway, OpenDrift will understand both x_sea_water_velocity and u_eastward, and rotate them accordingly whenever needed.Įach reader will have its own projection (or Coordinate Reference System), and x_sea_water_velocity means that this component is along the x-axis of that CRS, whereas u_eastward always means eastwards (of course :-). Normally it should not be necessary to make new readers, as reader_netCDF_CF_generic should "eat" nearly all CF-compatible netCDF files. the Leeway coefficients, which should include: 1) direct wind drag on the object, 2) Stokes drift, and 3) the additional surface shear ( wind_drift_factor), but then also subtracted the water drag as object stick into the ocean, and as wind is generally faster than current. So the wind_drift_factor has a quite different meaning than e.g. the above mentioned publications, the default depth of 10cm is more a "hand waving" number based on plots in Laxague, 2018. Whereas the surface value is well grounded in e.g. oil droplets or plastic particles floating near the surface. Thus this compensation is in OpenDrift applied to the very surface ( z=0), and linearly decreasing to 0 at a depth of 10cm, which can also be modified with: It's physical meaning is thus not a direct wind drag on the object (by some called windage), but rather a compensation factor for the inability of ocean models to resolve the very strong shear observed in the upper few centimeters of the ocean, see e.g. If Stokes drift is disabled ( o.set_config('drift:stokes_drift', False)) or not available, wind_drift_factor should be increased to about 0.03. Thus when Stokes drift is included, wind_drift_factor should be ~0.02 (which is default for OpenOil module). However, that includes surface Stokes drift, which is about 1.5% of the wind. By experiments (including our own) this is found to be around 3-3.5% of the wind ( Schwartberg, 1971, Jones, 2016). I believe the term originates from oil drift modeling, where it is the fraction of the wind you need to add to the surface current, to match the observed drift. Yes, the term wind_drift_factor might be misleading. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |