knutfrode / openwind

A python package for estimating high resolution wind from SAR images
0 stars 2 forks source link

Make openwind.SARwind a class instead of a function #1

Open knutfrode opened 10 years ago

knutfrode commented 10 years ago

Current usage is:

>>> s = Nansat(SAR_filename)
>>> w = Nansat(wind_filename)
>>> sarwind = openwind.SARwind(s, w)  # SARwind is a function, returning a SAR wind object
>>> sarwind.plot()

New usage will be similar:

>>> sarwind = openwind.SARwind(s, w) # SARwind is here a class

where s is either a SAR filename or Nansat object w (optional) is either a wind filename or Nansat object, or a constant direction.

If w is not given, SAR wind will be calculated with a second call:

>>> sarwind = openwind.SARwind(SAR_filename)
(>>> sarwind.reproject(some domain) )
>>> w = Nansat(wind_filename)
>>> sarwind.calculate_wind(w)
>>> sarwind.plot()

The latter two-step process allows the possibility to reproject the SARwind object before wind calculation, taking proper care that look direction is available also after reprojection (currently not possible). If w is not given here either, download of NCEP GFS wind is attempted.

mortenwh commented 10 years ago

For the last part (if w is not given) - the user should not have to do this manually (except plotting), it would be better to have a default functionality which takes online wind information. However, it would be nice to be able to change the wind direction after creating the SARwind object, then automatically get updated cmod wind speed.

knutfrode commented 10 years ago

The two-step process is needed to give the user the possibility to reproject/subset the SAR image before calculating wind.

But one could add an option to the constructor of SARWind (calculateWind) which could be set to True if the user wants to do this directly, and to let openwind fetch the online NCEP wind directly.

mortenwh commented 10 years ago

Ok - so default True, and then the user could override this? But why not just have the SAR image as nansat, reproject this, then get the wind? Is this where the look direction is lost? Why is it lost in that case?

knutfrode commented 10 years ago

The SAR look direction is calculated by finding the azimuth direction from a point (lon, lat) on the SAR image to a point further to the right/left (for right/left looking SAR). But after reprojection this is no longer possible, as the look direction is no longer directly to the right (or left) within the image/domain.

But within openwind this could be solved by calculating the SAR look direction and store as a full numPy array before reprojection, by overloading the reproject class in Nansat. The drawback is the need to (temporarily) store this as a full resolution array in memory. Perhaps it is possible to make a workaround by performing this calculation on a smaller array, as the look direction varies smoothly over the image area.

mortenwh commented 10 years ago

Aha - so storing the look direction as a separate band when initializing the SARwind object would work. Note that we can use the function add_band with option nomem=True to save the vrt to a temporary file instead of in memory.

Are we then doing the following?

1: Let the constructor use online wind information as default if no wind (as filename or nansat object) is given 2: The constructor should add the SAR look direction as a separate band (with nomem=True)

knutfrode commented 10 years ago

Ok, the temporary file option might be good for users who do not have enough memory to store full sized SAR bands.

  1. I suggest the option winddir='online' if user want to calculate wind directly with online wind, and perhaps winddir='archive' to use an updated version of model_wind.py, fetching wind from the users local archive. No wind should be calculated automatically otherwise, as user might want to reproject or resize image first.
  2. It should not be calculated and added automatically, as it is only needed before reprojecting, and would otherwise be waste of memory and processing time. But the nansat.reproject method could be overloaded by SARWind, to do this before the reprojection, keeping the look direction.
mortenwh commented 10 years ago

1: Ok, perhaps we should add winddir='none' to not use any of those two but let the user do it manually after constructing the object. That means we can use winddir='online' as default, and this will be a quick and simple way to get a first assessment of the wind speed. 2: Ok

mortenwh commented 10 years ago

(sorry for the norwegian - started this as a mail)

Din versjon kjører ihvertfall her og fungerer i utgangspunktet fra mine andre programmer, men kræsjer nå fordi vi har problemer med issue 30 (https://github.com/nansencenter/nansat/issues/30) igjen... Løsningen der fungerer ikke på alle installasjoner... Anton ser på det nå.

Ellers et par ting:

1: er det ingen resize av SARWind nå? Pikslene der bør være 500 m som default (se kode i nansencenter/openwind), for det første for å spare minne (min maskin henger voldsomt nå - måtte til slutt drepe prosessen (prøvde å kjøre med tilbakestilt nansat #30)) og for det andre at vinden får mindre støy (Birgitte reagerte med "dette er feil" da hun så første versjon med fulloppløselig vind - sånne reaksjoner må vi unngå hvis vi skal ha brukere)

2: ser du har laget et nytt vindobjekt under self. Det fungerer ikke iom at "api'en" blir endret. De nye båndene må legges til som self.add_band (helst med nomem=True). Ser det da blir problemer hvis self er reprojisert eller endret i størrelse, men sistnevnte løste jeg i nansencenter/openwind. I tillegg blir vel dette løst med issue #38 i nansat, gjør det ikke? Isåfall kan vi vente til det med å la SARWind akseptere reprojiserte sar-data.

Når det gjelder endring i størrelse, så håndterte jeg dette i nansencenter/openwind. Hvis du legger inn den metoden her, så burde det fungere med punkt 1 pluss at vi kan bruke self.add_band. Usikker på om det er noe problem om SARWind får et allerede "resized" bilde som input..., hvorfor er det egentlig det? Kan vi ikke bare mellomlagre gitt domain, tilbakestille med n.reproject() og n.resize(), utføre beregninger, og så reprojisere til mellomlagret domain?

mortenwh commented 10 years ago

The "cleanup" function should also be added... Like in model_wind.py:

def del(self): if hasattr(self, 'windGribFile') and os.path.exists(self.windGribFile):

Delete grib-file

        os.remove(self.windGribFile)
knutfrode commented 10 years ago
  1. The command line utility resizes by default by a factor of 0.1 For the Python API there is no automatic resizing, as the user is expected to do this using standard Nansat functions before calculating wind, e.g.

s.resize(factor=0.1)

But I agree that a default pixel size of 500 m is meaningful, unless overridden. However, resizing to a given pixel size should be handled by Nansat, we should not duplicate such functionality in SARWind (which is subclass of Nansat). Thus I propose to update nansat.resize() to allow:

s.resize(pixel_size=500)

This would again require a utility function (useful for other purposes):

s.get_pixel_size()

The retrieval of pixel size in first version of Openwind was hardcoded for Radarsat - but we need generic functionality for any SAR or other domains.

  1. Yes, wind is stored as a sub-object since adding bands is currently not possible before #38 is solved. But I think this is better in any case, as it is simpler (trivial) to export the calculated SAR wind and direction without automatically saving all the SAR parameters (incidence, raw_counts, HH, HH normalized ice etc) to the netCDF file (usually not desired).
mortenwh commented 10 years ago

1: Ok, but the resizing should be done in the class definition. It should of course also be possible to override it. I agree that nansat should have such functionality - can you file an issue there (for both resize(pixel_size=500) and s.get_pixel_size())? In SARWind.init, we should then do self.resize(pixel_size=500) - like in nansencenter/openwind.

2: No - that doesn't work. It means I will have to change all my code that depends on openwind... It is possible to add bands with the workaround in nansencenter/openwind. It is (or will at least be) also possible to export selected bands with nansat. Openwind should be made with this in mind. No need to overcomplicate...

mortenwh commented 10 years ago

Just added an issue in nansat regarding exporting selected bands only (https://github.com/nansencenter/nansat/issues/47) - it turned out it wasn't possible nor planned...

knutfrode commented 10 years ago

Added an issue to update resize function in Nansat: https://github.com/nansencenter/nansat/issues/48