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
All flux data which are uploaded are calculated with a shower-specific population index r_old which is stored in column 10 of the *.flx file.
When the user selects a different population index r_new in the web UI, this has currently only an effect on the ZHR which is plotted at the right y-axis. However, in reality also the flux density is affected, which is plotted at the left y-axis.
In order to account for that effect, each individual data set (i.e. one row in the *.flx file resp. one database record) needs to be corrected as follows: Columns 11 of the *.flx gives the exponent PowExp for that record, and column 12 the effective collection area (ECA_old). The corrected collection area ECA_new is calculated by
ECA_new = r_new^PowExp / r_old^PowExp x ECA_old
The details of this conversion are described in my 2014 IMC paper.
With the corrected collection area we will get a different flux density, because the flux density is the number of observed meteors divided by the collection area.
Note, however, that the binning should not change! So when I apply the minimum collection area parameter this should always refer to the original collection area ECA_new. I don´t want that the binning changes when I select a different population index.
The calculation seems quite simple, but may need some clever coding here. We are calling an exponential function (which costs CPU time) and we do it for every single record in the database that is used for the plot, i.e. up to several ten thousand times. If that delays the generation of the plot too much, we may use some lookup table for the power function or some other acelleration method.
The text was updated successfully, but these errors were encountered:
All flux data which are uploaded are calculated with a shower-specific population index r_old which is stored in column 10 of the *.flx file.
When the user selects a different population index r_new in the web UI, this has currently only an effect on the ZHR which is plotted at the right y-axis. However, in reality also the flux density is affected, which is plotted at the left y-axis.
In order to account for that effect, each individual data set (i.e. one row in the *.flx file resp. one database record) needs to be corrected as follows: Columns 11 of the *.flx gives the exponent PowExp for that record, and column 12 the effective collection area (ECA_old). The corrected collection area ECA_new is calculated by
ECA_new = r_new^PowExp / r_old^PowExp x ECA_old
The details of this conversion are described in my 2014 IMC paper.
With the corrected collection area we will get a different flux density, because the flux density is the number of observed meteors divided by the collection area.
Note, however, that the binning should not change! So when I apply the minimum collection area parameter this should always refer to the original collection area ECA_new. I don´t want that the binning changes when I select a different population index.
The calculation seems quite simple, but may need some clever coding here. We are calling an exponential function (which costs CPU time) and we do it for every single record in the database that is used for the plot, i.e. up to several ten thousand times. If that delays the generation of the plot too much, we may use some lookup table for the power function or some other acelleration method.
The text was updated successfully, but these errors were encountered: