-
Notifications
You must be signed in to change notification settings - Fork 1
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
no drift.rdb file after the LBL processing in APERO #796
Comments
I had not run LBL before with this setup of APERO, so the SKIP set to True shouldn't have had any impacts. |
Do you have a FP directory in the If so could you try just running the following steps (i.e. set them to True and everything else to False)
I'd like to have the log if possible for these ones to see whats happening. |
I'll do this test asap @njcuk9999 in the mean time, I'm running another LBL with APERO in another flavor of APERO , the quicklook. No lbl ran before withing this profile. I can see already a problem with FP: the Template_s1dv_FP_sc1d_v_file_AB.fits cannot be found
|
Yes there is a FP/ |
@njcuk9999 should I reset lbl first and then run the FP steps as you suggest ? |
I'd like to see whats happening without resetting (to see the current problem). If there is no template you can just run the |
Here is the log after I launched apero_processing.py LBL_run_LBLCOMPILE_FP_only.ini on Dec19. 06:14:45.730- |PROC| *************************************************************************** 06:14:45.811- |PROC| *************************************************************************** |
@njcuk9999 I got some explanation from Sidik about the plot above: "The pink line is "committed". "committed" means something called malloc() for a huge amount of memory (310Gb) but didn't touch all of it yet. It may never touch all of it - that's called "sparse" use, and Linux luckily allows it -- doesn't fail right away -- because it's a normal programming style these days for some types of software, usually ones that need large arrays which are populated by a lot of data with holes in it... but does it actually make sense that whatever it is doing should require more than 100 gigabytes of RAM? How high did "committed" go in relation to the green for similar past operations which succeeded? This might give us a ratio." |
So it make sense that it may go this high - but it shouldn't be the case. I think it is holding open all the FP files (or a good fraction of them) so it isn't just one array it will be many smaller ones... @eartigau and I need to look in to this! |
For the record, the Linux version is Ubuntu 24.04.4 LTS |
After the completion of a full reprocessing with APERO, I ran the LBL for a set of targets.
APERO 0.290/291
here is how the lbl was set in the ini file:
Define what to run
Run the lbl recipes
RUN_LBLREF = True
RUN_LBLMASK_FP = True
RUN_LBLCOMPUTE_FP = True
RUN_LBLCOMPILE_FP = True
RUN_LBLMASK_SCI = True
RUN_LBLCOMPUTE_SCI = True
RUN_LBLCOMPILE_SCI = True
Define what to skip (if files found)
Skip the lbl recipes
SKIP_LBLREF = False
SKIP_LBLMASK_FP = True
SKIP_LBLCOMPUTE_FP = True
SKIP_LBLCOMPILE_FP = True
SKIP_LBLMASK_SCI = False
SKIP_LBLCOMPUTE_SCI = False
SKIP_LBLCOMPILE_SCI = False
The text was updated successfully, but these errors were encountered: