Closed ACHMartin closed 1 year ago
Simultaneous retrieval tested, all working as expected. 25 pixel simple case:
L2 Ocean Surface Wind Speed = 4.483 GEO Ocean Surface Wind Speed = 4.49 L2 Earth Relative Wind Speed = 4.978 GEO Earth Relative Wind Speed = 5.0
Tested on simultaneous retrieval with OSCAR data and working as expected
Implementation of "OceanSurfaceWind" and "EarthRelativeWind" in place of the ambiguous "Wind". All references to "WindSpeed" and "WindDirection" should have been removed.
It remains reference to Wind in oscar/level1/init_auxiliary. Do we still use this function?
@DavidMcCann-NOC and/or @elemerle could you please run the processing chain for one track for both the iterative and simultaneous retrieval using this branch before we merge it to the main.
@d-andrievskaia it runs on my SciRec branch, I will push it to the main and ask you to review.
Just tested the sequential retrieval and it is here that init_auxiliary
is currently implemented, or at least in my processing chain. The function is used to create a geo
dataset out of single wind vectors and is now rather outdated. I will raise a new issue to update it.
init_auxiliary
currently only outputs the now obsolete variables WindSpeed
and WindDirection
, however this does not break the rest of the processing chain - I.e., there is no warning when running compute_radial_surface_current
that there are no OceanSurfaceWind
variables being passed.
Implementation of "OceanSurfaceWind" and "EarthRelativeWind" in place of the ambiguous "Wind". All references to "WindSpeed" and "WindDirection" should have been removed. It remains reference to Wind in oscar/level1/init_auxiliary. Do we still use this function? @DavidMcCann-NOC and/or @elemerle could you please run the processing chain for one track for both the iterative and simultaneous retrieval using this branch before we merge it to the main. @d-andrievskaia it runs on my SciRec branch, I will push it to the main and ask you to review.
Just tested the sequential retrieval and it is here that
init_auxiliary
is currently implemented, or at least in my processing chain. The function is used to create ageo
dataset out of single wind vectors and is now rather outdated. I will raise a new issue to update it.
Thanks
init_auxiliary
currently only outputs the now obsolete variablesWindSpeed
andWindDirection
, however this does not break the rest of the processing chain - I.e., there is no warning when runningcompute_radial_surface_current
that there are noOceanSurfaceWind
variables being passed.
Sad there is no warning. You don't remove them by any chance ;). I will look at this on Thursday. If anybody has a suggestion in the meantime...
Implementation of "OceanSurfaceWind" and "EarthRelativeWind" in place of the ambiguous "Wind". All references to "WindSpeed" and "WindDirection" should have been removed. It remains reference to Wind in oscar/level1/init_auxiliary. Do we still use this function? @DavidMcCann-NOC and/or @elemerle could you please run the processing chain for one track for both the iterative and simultaneous retrieval using this branch before we merge it to the main. @d-andrievskaia it runs on my SciRec branch, I will push it to the main and ask you to review.
Just tested the sequential retrieval and it is here that
init_auxiliary
is currently implemented, or at least in my processing chain. The function is used to create ageo
dataset out of single wind vectors and is now rather outdated. I will raise a new issue to update it.Thanks
init_auxiliary
currently only outputs the now obsolete variablesWindSpeed
andWindDirection
, however this does not break the rest of the processing chain - I.e., there is no warning when runningcompute_radial_surface_current
that there are noOceanSurfaceWind
variables being passed.Sad there is no warning. You don't remove them by any chance ;). I will look at this on Thursday. If anybody has a suggestion in the meantime...
That was my first thought too! I'll have a look this afternoon and see if I can trigger the warning, it will be either something on my end or a simple change to the warning call. Otherwise it all appears to work as expected
Hi guys,
Currently I am using the init_auxillary function with uniform values of wind speed and direction for the OSCAR level2 calculation. I plan to use the ERA5 data for the Med campaign. Does the wind info in the ERA5 model correspond to "EarthRelativeWind"? If so we just need to rename the variables in the DataArray named "aux" bellow right?
Does this steps are correct for the retrieval of OSCAR level2:
u10 = 5 # wind speed wind_direction = 25 # wind direction aux = ss.oscar.level1.init_auxiliary(dsl1, u10, wind_direction)
dsl1 = ss.oscar.level1.compute_radial_surface_current(dsl1, aux, gmf='mouche12')
dsl2=ss.oscar.level1.init_level2(dsl1)
dsl2=seastar.retrieval.level2.compute_current_magnitude_and_direction(dsl1, dsl2)
dsl2['CurrentVectorUComponent'], dsl2['CurrentVectorVComponent'] =\ ss.utils.tools.currentVelDir2UV(dsl2['CurrentMagnitude'], dsl2['CurrentDirection'])
Hi Eva,
I assume so yes – Geophysical wind models will be EarthRelativeWind. I started having a look at a better init_auxiliary function as you may have noticed the function there is a bit restricted, I’d like it to deal with all sorts of wind inputs eventually – basically a wind field interpolation function.
The general workflow below is correct, however you’ll likely run into issues with dimensions if you load in the three beam files for a track, particularly the ‘Antenna’ dimension. In my processing notebook it goes (after computing the aux dataset):
rsc = [ss.oscar.level1.compute_radial_surface_current(dsl1.sel(Antenna=a), aux.sel(Antenna=a), gmf=gmf) for a in dsl1.Antenna]
dsl1['RadialSurfaceCurrent'] = xr.concat(rsc, 'Antenna', join='outer')
dsl2 = ss.oscar.level1.init_level2(dsl1)
dsl2= ss.retrieval.level2.compute_current_magnitude_and_direction(dsl1, dsl2)
dsl2['CurrentU'], dsl2['CurrentV'] = ss.utils.tools.currentVelDir2UV(dsl2['CurrentVelocity'], dsl2['CurrentDirection'])
The list comprehension is necessary to get round the fact that we compute the rsc as an xr.DataArray, and then we build it back in to an xr.Dataset with the appropriate Antenna dimension. Happy to go over this with you at some point soon – I have a comprehensive notebook that does all of this for the Iroise Sea campaign data that you can use as the basis for a processing chain.
Cheers, Dave
From: elemerle @.> Sent: 20 June 2023 09:50 To: ACHMartin/seastar_project @.> Cc: McCann, David L. @.>; Mention @.> Subject: Re: [ACHMartin/seastar_project] Implementation of "OceanSurfaceWind" and "EarthRelativeWind" in place… (PR #270)
Caution: This email has originated from outside of the organisation. Do not click links or open attachments unless you have verified the sender and content is safe. Thank you.
Hi guys,
Currently I am using the init_auxillary function with uniform values of wind speed and direction for the OSCAR level2 calculation. I plan to use the ERA5 data for the Med campaign. Does the wind info in the ERA5 model correspond to "EarthRelativeWind"? If so we just need to rename the variables in the DataArray named "aux" bellow right?
Does this steps are correct for the retrieval of OSCAR level2:
Generating geophysical data fields for GMF doppler computation, data taken from DAR
u10 = 5 # wind speed wind_direction = 25 # wind direction aux = ss.oscar.level1.init_auxiliary(dsl1, u10, wind_direction)
Compute RSC
dsl1 = ss.oscar.level1.compute_radial_surface_current(dsl1, aux, gmf='mouche12')
Initialise l2 dataset
dsl2=ss.oscar.level1.init_level2(dsl1)
Compute current magnitude and direction
dsl2=seastar.retrieval.level2.compute_current_magnitude_and_direction(dsl1, dsl2)
Compute current vectors
dsl2['CurrentVectorUComponent'], dsl2['CurrentVectorVComponent'] = ss.utils.tools.currentVelDir2UV(dsl2['CurrentMagnitude'], dsl2['CurrentDirection'])
— Reply to this email directly, view it on GitHubhttps://github.com/ACHMartin/seastar_project/pull/270#issuecomment-1598373668, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZSIUT63SNBIJ3VBVZE6IFTXMFP4PANCNFSM6AAAAAAZJOZ254. You are receiving this because you were mentioned.Message ID: @.**@.>>
This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. The National Oceanography Centre (NOC) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. NOC does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to NOC business are solely those of the author and do not represent the views of NOC.
Implementation of "OceanSurfaceWind" and "EarthRelativeWind" in place of the ambiguous "Wind". All references to "WindSpeed" and "WindDirection" should have been removed.
It remains reference to Wind in oscar/level1/init_auxiliary. Do we still use this function?
@DavidMcCann-NOC and/or @elemerle could you please run the processing chain for one track for both the iterative and simultaneous retrieval using this branch before we merge it to the main.
@d-andrievskaia it runs on my SciRec branch, I will push it to the main and ask you to review.