search

gbrammer / grizli

Grizli: The "Grism redshift and line" analysis software
MIT License
69 stars 51 forks source link

weird behavior when running grizli on GR150R #259

Open x12red opened 3 weeks ago

x12red commented 3 weeks ago

Hello,

I am testing grizli on a very small dataset and noticed a weird behavior. As a test, I am using NGDEEP data. In this particular case, F150W is the filter I am considering.

When considering grism C data, everything works fine on my laptop. I can model everything without any problem. However, when considering grism R data, my notebook (but also via command line) gives me back segmentation fault. Even when I set cpu_count = 2 (so I limit its access to the memory, in principle). Everything seems working out fine when using it on my cluster (with more RAM ad CPUs).

The error I get from my notebook is the one below:

The Kernel crashed while executing code in the current cell or a previous cell. Please review the code in the cell(s) to identify a possible cause of the failure. Click here for more info. View Jupyter log for further details.

Does anyone know why it happens?

x12red commented 3 weeks ago

I made some more inspections; this error occurs regardless the filter I want to use. It always happens when it comes for GR150R. I also created a fresh environment for testing purposes. I also made use of files processed entirely by grizli, so there is no preprocess done by myself there. Same old story, it crashes when trying to run it over GR150R. It does not say anything, so it is hard to track it down. It gives me back a simple segmentation fault.

Also on the cluster, it works, but in reality it does not model anything. Indeed, you do not see the usual output during the refinement iterations. And when I extract the spectrum for a given source, it does not return anything.

Any help? There is not a clear problem there, other than the segmentation fault, so it is really hard to debug it.

x12red commented 2 weeks ago

Okay, I digged a bit more into this error and found that the code works okay if I enlarge the padding for grism R, which actually now leads me to another question: why should I change the padding going from grism C to grism R? I tried to dig a bit into the code, but must say the differences between grism R and grism C are not well explained for NIRISS, if any.