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

KeyError when accessing section_text for certain sections #17

Open
ahnaf-tahmid-chowdhury opened this issue Oct 10, 2024 · 8 comments · May be fixed by #18
Open

KeyError when accessing section_text for certain sections #17

ahnaf-tahmid-chowdhury opened this issue Oct 10, 2024 · 8 comments · May be fixed by #18

Comments

@ahnaf-tahmid-chowdhury
Copy link

Description

I encountered a KeyError while trying to access specific sections of an ENDF material. Below is a summary of the issue:

Steps to Reproduce:

  1. Load a material using endf.Material(), for example:

    import endf
    mat = endf.Material('n-092_U_235.endf')
  2. The following warnings appear:

    /path/to/venv/lib/python3.12/site-packages/endf/material.py:228: UserWarning: MF=31, MT=452 ignored
      warn(f"{MF=}, {MT=} ignored")
    /path/to/venv/lib/python3.12/site-packages/endf/material.py:228: UserWarning: MF=31, MT=456 ignored
      warn(f"{MF=}, {MT=} ignored")
    /path/to/venv/lib/python3.12/site-packages/endf/material.py:228: UserWarning: MF=35, MT=18 ignored
      warn(f"{MF=}, {MT=} ignored")
    
  3. Attempt to access a specific section:

    print(mat.section_text[12, 75])

    This raises the following error:

    KeyError: (12, 75)
    
  4. Attempting to access other sections like:

    mat.section_data[3, 16]

    works as expected and returns data.

Expected Behavior:

mat.section_text[12, 75] should return the corresponding section data, or provide a clearer error if this section is not available.

Actual Behavior:

A KeyError is raised when trying to access section_text for certain sections.

System Information:

  • Python version: 3.12
  • endf version: 0.1.4 through pip
  • ENDF file used: n-092_U_235.endf

Additional Context:

The warnings related to MF=31 and MF=35 might be linked to the issue, but it's unclear if this is the cause.

@MicahGale
Copy link

Which nuclear data library are you using? I want to verify that the data are present first.

The MF=31/35 warnings are not relevant here. MF 31/35 would appear much later in the file and would have no impact on MF=12.

@MicahGale
Copy link

So MF=12, MT=75 is there for U-235 in ENDF/B-VIII.0, but not ENDF/B-VII.1. I suspect this is what is causing the KeyError. If this is in fact the root cause a clearer error message like:

raise MissingDataError(f"The requested data: MAT={MAT}, MF={MF}, MT={MT} does not exist in this ENDF.")

would be a good idea.

@paulromano
Copy link
Owner

The sections attribute on a Material object tells you what sections are available in a file. If a section is not present, to me KeyError is already conveying the right information.

@MicahGale
Copy link

Maybe the KeyError could be a little bit more verbose to make it clear this is user Error?

@ahnaf-tahmid-chowdhury
Copy link
Author

Yes, I think it will be a nice feature. We can develop a fallback function that provides verbose logs about the file, which will also help people like me who are just starting to learn about different data formats.

@MicahGale
Copy link

Logging seems look far too big of a hammer. Like @paulromano said the information is there for the user, and I don't see the value in producing a log that would duplicate would could be queried directly.

@ahnaf-tahmid-chowdhury
Copy link
Author

@MicahGale, I apologize if I wasn’t clear in my earlier comment, and I appreciate your feedback. I didn’t mean to suggest extensive logging. My idea was more about having a fallback function that triggers when a KeyError is raised. The goal is to provide additional context, without overwhelming the system with logs.

Instead of full logging, this fallback could simply explain why the error occurred and, perhaps, point out which sections are available for the material being queried. It wouldn’t duplicate what’s already in place but would help users better understand the issue when encountering missing data.

@MicahGale
Copy link

Oh ok that makes sense.

@MicahGale MicahGale linked a pull request Oct 11, 2024 that will close this issue
3 tasks
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

Successfully merging a pull request may close this issue.

3 participants