Spin data and Spin Phase function setup

[tech3371]

Change Summary

Overview

Added function to create spin sample data for input date range. Created bare bone function to calculate spin phase and will extend it in future PR.

Updated Files

• imap_processing/spice/geometry.py
  • function to calculate spin phase
  • Added fixture to generate spin sample data

Testing

• imap_processing/tests/spice/test_geometry.py
  • minimal tests

[subagonsouth]

This is looking good. I think that more can be filled in. If you have spin table data (whether it is from a file or generated), you should be able to calculate the spin phase for a set of times.

One piece that I think is missing is a function that takes a list of METs and returns tabular data from the spin table for each MET. Then the spin phase could be implemented.

Maybe this is growing into too big of a PR?

[tech3371]

If you have spin table data (whether it is from a file or generated), you should be able to calculate the spin phase for a set of times.
One piece that I think is missing is a function that takes a list of METs and returns tabular data from the spin table for each MET. Then the spin phase could be implemented.

@subagonsouth I do plan to tackle this in upcoming PR. I didn't want to make this PR too big. I want this PR to only generate spin data and then in upcoming PR, use that data to calculate spin phase which will include those that you are thinking. I also need to spend some time to figure out how to implement it. I will take your current ideas as I am thinking about it.

[laspsandoval]

I want Tim's feedback on the repointing times. For now it is ok, but you might have to add the gaps in the test ck kernel in.

[greglucas]

I think this seems like a good approach. Loading a spin file from somewhere on the disk into a pandas dataframe. In the tests, you're making it for the user similar to the SPICE metakernel. In processing we'll set this environment variable to wherever the actual data is.

Something to think about is that we are adding a lot of environment variables now, is this going to be in a separate location from IMAP_DATA_DIR, or is it going to be relative to that and we can leverage that environment variable that is already there?

[greglucas]

Your "00" test will always be true, so you can either drop that one, or say +/- 10 minutes so you get before and after midnight.

Suggested change

	# Find index of all timestamps that fall within 10 minutes after midnight
	repointing_times = spin_start_dates_series[
	(spin_start_dates_series.dt.time >= pd.Timestamp("00:00:00").time())
	& (spin_start_dates_series.dt.time < pd.Timestamp("00:10:00").time())
	]
	# Find index of all timestamps that fall within 10 minutes of midnight
	repointing_times = spin_start_dates_series[
	(spin_start_dates_series.dt.time > pd.Timestamp("23:50:00").time())
	& (spin_start_dates_series.dt.time < pd.Timestamp("00:10:00").time())
	]

[tech3371]

I am assuming nominal repointing time is 10 minutes. With this, it will become 20 minutes. Is that right? Did you want this to five minutes before and after instead.

[tech3371]

Something to think about is that we are adding a lot of environment variables now, is this going to be in a separate location from IMAP_DATA_DIR, or is it going to be relative to that and we can leverage that environment variable that is already there?

@greglucas, @laspsandoval and @subagonsouth was thinking in similar manner. This will depend on where we decide to store spin data and how we get it. But I think having some fixed path for spin data in imap-data-access repo will be good if we decide to keep spin data in csv file and use download API to get it. Something to revisit in the near future.

[subagonsouth]

This looks good to go once my one nit-pick is addressed. Thanks for your persistence on this PR!