Open knutfrode opened 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.
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.
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?
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.
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)
Ok, the temporary file option might be good for users who do not have enough memory to store full sized SAR bands.
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
(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?
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):
os.remove(self.windGribFile)
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: 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...
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...
Added an issue to update resize function in Nansat: https://github.com/nansencenter/nansat/issues/48
Current usage is:
New usage will be similar:
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:
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.