ACHMartin / seastar_project

4 stars 0 forks source link

Implementation of "OceanSurfaceWind" and "EarthRelativeWind" in place… #270

Closed ACHMartin closed 1 year ago

ACHMartin commented 1 year ago

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.

DavidMcCann-NOC commented 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

DavidMcCann-NOC commented 1 year ago

Tested on simultaneous retrieval with OSCAR data and working as expected

DavidMcCann-NOC commented 1 year ago

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.

ACHMartin commented 1 year ago

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.

Thanks

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.

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

DavidMcCann-NOC commented 1 year ago

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.

Thanks

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.

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

elemerle commented 1 year ago

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')

L2 Processing

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'])

DavidMcCann-NOC commented 1 year ago

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')

L2 Processing

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.