Suggestion: RadLookup.__init__ and RadLookup.LoadSpectrals

[huisslang]

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:

1. 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):

     self.LoadSpectrals()
     # multiply to calculate the total spectral shape.
     self.specEffWiFil = self.specEmis * self.specAtmo * \
                         self.specFilter * self.specSensor * self.specOptics
     self.specEffNoFil = self.specEmis * self.specAtmo * \
                         self.specSensor * self.specOptics
     .
     .
     self.CalculateDataTables()

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

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

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

   spectralsLoaded
   hiresTablesCalculated
   calTablesCalculated
   

   (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__:

    self.specEffWiFil = self.specEmis * self.specAtmo * \
                        self.specFilter * self.specSensor * self.specOptics
    self.specEffNoFil = self.specEmis * self.specAtmo * \
                        self.specSensor * self.specOptics
   

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

   object.LoadSpectrals()
   # multiply to calculate the total spectral shape.
   object.specEffWiFil = object.specEmis * object.specAtmo * \
                        object.specFilter * object.specSensor * object.specOptics
   object.specEffNoFil = object.specEmis * object.specAtmo * \
                        object.specSensor * object.specOptics
   object.CalculateDataTables()
   

   • This example assumes that only one or more of the spectrals has changed.

6. RECOMMENDATIONS

   (a) That the following code lines be removed from RadLookup.__init__ and rather moved to RadLookup.LoadSpectrals():

   self.specEffWiFil = self.specEmis * self.specAtmo * \
                        self.specFilter * self.specSensor * self.specOptics
   self.specEffNoFil = self.specEmis * self.specAtmo * \
                        self.specSensor * self.specOptics
   

   (b) Consideration can also be given to calling on ResetAllContainers() from early in LoadSpectrals() to ensure that none of the old lookup tables mistakenly gets used.

[NelisW]

Thanks, will look into this next weekend