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

BUG: indexing assumption for flash initial position #4

Open
deeplycloudy opened this issue Oct 29, 2014 · 1 comment
Open

BUG: indexing assumption for flash initial position #4

deeplycloudy opened this issue Oct 29, 2014 · 1 comment

Comments

@deeplycloudy
Copy link
Owner

It applies to data sorted with the mflash clustering method. It may also apply to the sklearn clustering method, but this has not been verified.

The point data are recorded out of order to the HDF5 file, because I sort the mflash output (which I verified is in time order) by flash_id to split the flashes up.
https://github.com/deeplycloudy/lmatools/blob/master/flashsort/autosort/autorun_mflash.py#L114
That sort algorithm, when applied to flash_id, isn’t guaranteed to preserve the original time order.

The time is still calculated correctly, since I take the minimum of the time:
https://github.com/deeplycloudy/lmatools/blob/master/flashsort/autosort/flash_stats.py#L142

But the initial position is taken to be the first index, which isn’t guaranteed to be the minimum since the time is not sorted in order:
https://github.com/deeplycloudy/lmatools/blob/master/flashsort/autosort/flash_stats.py#L146

The thing to do would be to use argmin instead of min to find the time index that is minimum, and then use that index to get the time and position of the first source.

In summary:

  1. The flash IDs go with the correct sources
  2. The start time is correct
  3. The start lat/lon/alt is incorrect when using mflash
  4. The problem could be corrected by manually recalculating the flash metadata table after applying my suggested fix.
deeplycloudy added a commit that referenced this issue Oct 29, 2014

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…e ordering (fixes issue #4)
@deeplycloudy
Copy link
Owner Author

Credit to K. Thompson of UAH for identifying this bug.

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