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

728 spice kernel furnishing decorator #734

Conversation

subagonsouth
Copy link
Contributor

Change Summary

Overview

Sorry for the size of this PR. I don't think that it is possible to break it up any smaller. The most important piece is the ensure_spice decorator. I think that the docstrings are descriptive enough for you all to understand what it does without additional clarification, but let me know if there are any questions. All other changes have to do with setting up testing infrastructure needed to test the decorator.

New Dependencies

None

New Files

  • imap_processing/tests/spice/test_data/imap_sclk_0000.tsc
    • test sclk kernel
  • imap_processing/tests/spice/test_data/imap_test_metakernel.template
    • test metakernel template that is used in the fixture that inserts the local absolute path so that tests work anywhere
  • imap_processing/tests/spice/test_data/naif0012.tls
    • test leapsecond kernel

Deleted Files

None

Updated Files

  • imap_processing/spice/kernels.py
    • Added ensure_spice decorator which will handle automatic kernel furnishing when needed
  • imap_processing/tests/conftest.py
    • Added several testing fixtures used to set up spice kernel needs
    • Of particular note is the autouse=true fixture that was added to ensure spice kernels are always cleared after each test
  • imap_processing/tests/spice/test_kernels.py
    • Added tests coverage for ensure_spice decorator with different use cases

Testing

Test coverage for ensure_spice decorator

closes #728

@subagonsouth subagonsouth added the SPICE Related to SPICE label Aug 6, 2024
@subagonsouth subagonsouth self-assigned this Aug 6, 2024
imap_processing/spice/kernels.py Show resolved Hide resolved
except SpiceyError as spicey_err:
try:
# Step 2.
metakernel_path = os.environ["SPICE_METAKERNEL"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this standard? Does this mean we are only allowing metakernels and not any other way of loading individual kernels?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If kernels are already furnished, then the Step 1 code will call the function and proceed. This allows for custom/manual furnishing of whatever kernels you want. If they are not furnished, then the secondary default behavior is to look for a metakernel pointed to by this environment variable. We can certainly tweak this functionality as we define details about how we want kernels to be furnished in the pipeline.

It seems like I should put some slides together and set up a meeting to discuss this decorator and the logic flow with the team.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 I think an overview of what is happening in ppt would be helpful.

Would we not know if kernels were already furnished? Could we use this

with spice.KernelPool(kernels):

Instead of this?
spice.furnsh(test_sclk) yield test_sclk spice.kclear()

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have also been putting our global configuration / env variables in the imap-data-access repository. I'm not sure if the SPICE configuration options should go over there too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on an overview. That would be really helpful

Comment on lines 22 to 30
@pytest.fixture(scope="session")
def monkeypatch_session():
from _pytest.monkeypatch import MonkeyPatch

m = MonkeyPatch()
yield m
m.undo()


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't being used currently, can we remove it? It looks like you are using the monkeypatch fixture directly below instead of the "session" based one here.
\



@pytest.fixture()
def furnish_sclk(spice_test_data_path):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this fixture isn't used, do you want to use it here, planning on needing it later? (I assume it might come in future PR of test_time, but just wanted to call it out)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think that it will be useful later, especially in test_time. Mostly wanted to put it in to help others with testing fixtures that they might need.



@pytest.fixture()
def use_test_metakernel(tmpdir_factory, monkeypatch, spice_test_data_path):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to make use of any of the IMAP_DATA directory locations for spice file paths?
https://github.com/IMAP-Science-Operations-Center/imap-data-access/blob/ff6c637533d39a8c5359f2e456e918f2495b0871/imap_data_access/file_validation.py#L354

You might be able to use that location as your tmpdir by accessing imap_data_access.config["DATA_DIR"] / imap/spice/... .

def _set_global_config(monkeypatch, tmp_path):
"""Set the global data directory to a temporary directory."""
monkeypatch.setitem(imap_data_access.config, "DATA_DIR", tmp_path)
monkeypatch.setitem(
imap_data_access.config, "DATA_ACCESS_URL", "https://api.test.com"
)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, maybe. I would like to add this to a discussion. I'm not sure I fully grok what you are suggesting but think that it might work better than using this template metakernel.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was not very clear above. I meant to write your template metakernel to that DATA_DIR location (so just pointing to a different tmpdir location, not changing any logic). The DATA_DIR in tests is already set to a temporary directory, so it'd just avoid another temporary directory/location and possibly be closer to where we want the kernels during the mission I think.

assert func(577365941.184, "ISOC", 3) == "2018-04-18T23:24:31.998"


def test_ensure_spice_time_kernels():
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these next two tests failing because we aren't using the fixture use_test_metakernel? It might be good to add a quick comment about that if so.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a clock kernel in the tools directory. I need to compare to this one and keep only one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a leapsecond kernel checked in in the tools directory. We should have only on in the repo. I will either move the other one or point to it in the metakernel template.

Copy link
Contributor

@laspsandoval laspsandoval left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tenzin is using sds-data-manager/lambda_code/efs_lambda/lambda_function.py to figure out which attitude and ephemeris kernels to use for the symlink. I think getting together to discuss your code and hers and how they work together will be important for this PR.

Another thing that I have been thinking about lately is what about the additional kernels that are not part of the metakernels?

  • de430.bsp for example I don't think will be delivered to us by the MOC. Something to think about.

It looks good though. A very nice start. Looking forward to discussing. You have boldly gone where none of us dared to go. Nicely done.

except SpiceyError as spicey_err:
try:
# Step 2.
metakernel_path = os.environ["SPICE_METAKERNEL"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 I think an overview of what is happening in ppt would be helpful.

Would we not know if kernels were already furnished? Could we use this

with spice.KernelPool(kernels):

Instead of this?
spice.furnsh(test_sclk) yield test_sclk spice.kclear()

…ice kernels in correct module

Add test incomplete test coverage of ensure_spice decorator in correct location
Add leapsecond kernel to test data
Add sclk kernel to test data
Add metekrnel template to test data
Add test coverage for ensure_spice failure -> SpiceyError
Move metakernel template to other spice kernel location
@subagonsouth subagonsouth force-pushed the 728-spice-kernel-furnishing-decorator branch from 217d104 to 78ae704 Compare August 7, 2024 23:38
Comment on lines +80 to +84
if f_py and not callable(f_py):
raise ValueError(
f"Received a non-callable object {f_py} as the f_py argument to"
f"ensure_spice. f_py must be a callable object."
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI that my editor says this is unreachable code, so I think it could be removed. i.e. you don't decorate something that isn't callable.

except SpiceyError as spicey_err:
try:
# Step 2.
metakernel_path = os.environ["SPICE_METAKERNEL"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have also been putting our global configuration / env variables in the imap-data-access repository. I'm not sure if the SPICE configuration options should go over there too.

Comment on lines 39 to 40
def spice_test_data_path(imap_tests_path):
return imap_module_directory.parent / "tools/tests/test_data/spice"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want to move these data files into the main package. I'm pretty sure if we released this, the tests would get included in the release, but the test data wouldn't so you wouldn't be able to test the actual sdist because the test data would be missing.

@vmartinez-cu
Copy link
Contributor

Nice job on the detailed docstrings!

… test metakernel

Move leapsecond and spacecraft clock kernel into imap_processing package
@subagonsouth subagonsouth merged commit 4a2642b into IMAP-Science-Operations-Center:dev Aug 16, 2024
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SPICE Related to SPICE
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

SPICE kernel furnishing decorator
4 participants