You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the SAD files for individual instrument channels contain uncertainties / errors like this:
SAD_CHAN()%Solar%NeFR
SAD_CHAN()%Thermal%NeBT
But these are not actual instrument uncertainties - they are a combination of the forward model uncertainty in ORAC and the measurement uncertainty from the instrument. These two terms should be separated to make it explicit what each is and to enable different instruments to be more accurately characterised. At present we're using similar uncertainties for all sensors (possibly with the exception of MODIS) which is obviously not ideal.
As one of the main selling points of ORAC is that it includes uncertainty in the retrieval then we should ensure that these uncertainties are accurate. Right now they're just guesswork. For example, using the 'default' uncertainties on Himawari (presumably the default values we use for everything are from ATSR, but this is not documented) produces very high (>40) costs even for good quality retrievals. It's easy to get the costs down by playing with the NeBT values, but this is far from satisfactory.
The text was updated successfully, but these errors were encountered:
Currently the SAD files for individual instrument channels contain uncertainties / errors like this:
SAD_CHAN()%Solar%NeFR
SAD_CHAN()%Thermal%NeBT
But these are not actual instrument uncertainties - they are a combination of the forward model uncertainty in ORAC and the measurement uncertainty from the instrument. These two terms should be separated to make it explicit what each is and to enable different instruments to be more accurately characterised. At present we're using similar uncertainties for all sensors (possibly with the exception of MODIS) which is obviously not ideal.
As one of the main selling points of ORAC is that it includes uncertainty in the retrieval then we should ensure that these uncertainties are accurate. Right now they're just guesswork. For example, using the 'default' uncertainties on Himawari (presumably the default values we use for everything are from ATSR, but this is not documented) produces very high (>40) costs even for good quality retrievals. It's easy to get the costs down by playing with the NeBT values, but this is far from satisfactory.
The text was updated successfully, but these errors were encountered: