I am working with Pyradi version: 1.1.0 but the issue and suggestion that I describe below applies beyond that version to newer versions.
Description of issue:
When an object of class rylookup.RadLookup is instantiated, the class would load all the spectrals and then calculate the lookup-tables. The sequence of code-lines in the definition of RadLookup.__init__ is as follows (summarised):
In RadLookup.__init__ the following is noted: After calling on LoadSpectrals() to load the spectrals the calculation of specEffWiFil and specEffNoFil is appropriately done before calling on CalculateDataTables(). This sequence is critical for calculation of the lookup tables with correct dependency on the spectrals.
The definition of RadLookup does seem to allow for subsequent change of spectals (i.e. a programmer could change the input data for one or more of the spectrals), keeping in mind that reloading of spectrals and recalculation of lookup tables become necessary.
I have experimented with changing one of the spectrals and found the following. When I change one of the input spectrals after instantiating a RadLookup object, e.g. changing object.filterTau. I then called LoadSpectrals(), followed by CalculateDataTables() and found that the lookup tables still represented the radiometric values as if the original old filter applied (i.e. filter which was passed through at object instantiation time), not the new filter data that I provided.
(a) I intially experimented with the flags trying to force the object to recalculate the
lookup-tables properly:
(b) Only on more careful scrutiny of the definition of RadLookup I grasped the cause of
the behaviour, i.e. that the following code lines were hard-coded into RadLookup.__init__:
Therefore for an existing RadLookup object when changing one of the spectrals (e.g. filterTau) the
workaround to effect the change of data, would be to follow the following steps:
(b) Consideration can also be given to calling on ResetAllContainers()
from early inLoadSpectrals() to ensure that none of the old
lookup tables mistakenly gets used.
I am working with Pyradi version: 1.1.0 but the issue and suggestion that I describe below applies beyond that version to newer versions.
Description of issue:
When an object of class
rylookup.RadLookup
is instantiated, the class would load all the spectrals and then calculate the lookup-tables. The sequence of code-lines in the definition ofRadLookup.__init__
is as follows (summarised):In
RadLookup.__init__
the following is noted: After calling onLoadSpectrals()
to load the spectrals the calculation ofspecEffWiFil
andspecEffNoFil
is appropriately done before calling onCalculateDataTables()
. This sequence is critical for calculation of the lookup tables with correct dependency on the spectrals.The definition of
RadLookup
does seem to allow for subsequent change of spectals (i.e. a programmer could change the input data for one or more of the spectrals), keeping in mind that reloading of spectrals and recalculation of lookup tables become necessary.I have experimented with changing one of the spectrals and found the following. When I change one of the input spectrals after instantiating a
RadLookup
object, e.g. changingobject.filterTau
. I then calledLoadSpectrals()
, followed byCalculateDataTables()
and found that the lookup tables still represented the radiometric values as if the original old filter applied (i.e. filter which was passed through at object instantiation time), not the new filter data that I provided.(a) I intially experimented with the flags trying to force the object to recalculate the lookup-tables properly:
(b) Only on more careful scrutiny of the definition of
RadLookup
I grasped the cause of the behaviour, i.e. that the following code lines were hard-coded intoRadLookup.__init__
:Therefore for an existing
RadLookup
object when changing one of the spectrals (e.g.filterTau
) the workaround to effect the change of data, would be to follow the following steps:RECOMMENDATIONS
(a) That the following code lines be removed from
RadLookup.__init__
and rather moved toRadLookup.LoadSpectrals()
:(b) Consideration can also be given to calling on
ResetAllContainers()
from early inLoadSpectrals()
to ensure that none of the old lookup tables mistakenly gets used.