Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper population index handling #11

Open
Molau opened this issue Oct 30, 2017 · 0 comments
Open

Proper population index handling #11

Molau opened this issue Oct 30, 2017 · 0 comments

Comments

@Molau
Copy link

Molau commented Oct 30, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant