Project removal is buggy (?)

[ligerzero-ai]

Sometimes this command deletes the folder, sometimes it doesn't.

Project("Pdash-Sdash-jdash").remove(enable=True)

This sometimes leaves a directory.

On the other hand, assigning the project to a variable :

pr = `Project("Pdash-Sdash-jdash")
pr.remove(enable=True)

always succeeds with clean removal.

Idk if this weirdness is a quirk of python's or something weird with pyiron.

[pmrv]

Both snippets should be strictly equivalent in terms of python, so I'd be very confused it's this difference that leaves the directory. The project directory is not removed when there's still (non-pyiron) files inside. Could that be the cause?

[ligerzero-ai]

Actually, this behaviour appears to be not related to the syntax so it's actually a pyiron-side problem. I haven't touched anything terminal-side.

Calling du -ah on the failed folders yields outputs like so:

du -ah
384K    ./nest-level-1-subproject-1/job-0/job-0.h5
512     ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/INCAR
512     ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/KPOINTS
512     ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/POSCAR
512     ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/time.out
0       ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/pyiron.log
704K    ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/POTCAR
512     ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/run_queue.sh
512     ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0/error.out
708K    ./nest-level-1-subproject-1/job-0/job-0_hdf5/jobm0
709K    ./nest-level-1-subproject-1/job-0/job-0_hdf5
1.1M    ./nest-level-1-subproject-1/job-0
512     ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/INCAR
512     ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/KPOINTS
512     ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/POSCAR
512     ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/time.out
0       ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/pyiron.log
704K    ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/POTCAR
512     ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/run_queue.sh
512     ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1/error.out
708K    ./nest-level-1-subproject-1/job-1/job-1_hdf5/jobm1
709K    ./nest-level-1-subproject-1/job-1/job-1_hdf5
384K    ./nest-level-1-subproject-1/job-1/job-1.h5
1.1M    ./nest-level-1-subproject-1/job-1
2.2M    ./nest-level-1-subproject-1
384K    ./nest-level-1-subproject-0/job-0/job-0.h5
512     ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/INCAR
512     ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/KPOINTS
512     ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/POSCAR
512     ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/time.out
0       ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/pyiron.log
704K    ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/POTCAR
512     ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/run_queue.sh
512     ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0/error.out
708K    ./nest-level-1-subproject-0/job-0/job-0_hdf5/jobm0
709K    ./nest-level-1-subproject-0/job-0/job-0_hdf5
1.1M    ./nest-level-1-subproject-0/job-0
512     ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/INCAR
512     ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/KPOINTS
512     ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/POSCAR
512     ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/time.out
0       ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/pyiron.log
704K    ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/POTCAR
512     ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/run_queue.sh
512     ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1/error.out
708K    ./nest-level-1-subproject-0/job-1/job-1_hdf5/jobm1
709K    ./nest-level-1-subproject-0/job-1/job-1_hdf5
384K    ./nest-level-1-subproject-0/job-1/job-1.h5
1.1M    ./nest-level-1-subproject-0/job-1
2.2M    ./nest-level-1-subproject-0
4.3M    .

I found this when investigating:
pyiron/pyiron_atomistics#645

and all these folders contain only calculations that error'd out once it was attempted to be executed on the cluster (i.e. errors in error.out appear).

I note that all of these jobs failed. So the pr.remove(enable=True) fails whenever there are only failed calculations present in the folder.

You can work around this by removing the folders manually with rm -r */ on the terminal side and deleting the databases with another call of

pr = Project("deleted_database_name")
pr.remove(enable=True) 

to remove the database entries.

Still somewhat annoying.

[ligerzero-ai]

Actually, thinking more about it, I am not clear on if this behaviour will exist if there's even a single failed calculation present in the folder structure.

I can imagine that this behaviour is also occurring in that case, and that makes this error even more problematic.