Closed CLG68 closed 1 month ago
The new ShaEP does indeed default to use all cores, which leads to overallocation when Brutenib starts multiple instances (as is the default). Use -c 1
as a workaround. We should probably pass explicit --njobs
to ShaEP in order to retain control on how much resources it gets.
Thanks for note about the deprecation of the square bracket notation. I had missed that.
Hi,
For screening 1.4.0 is faster than the previous version but I'm not sure for rescoring. For Brutenib, I end up reverting to 1.3.1 so I could use all threads with rocker. Using 1.3.1 is not really a problem but it would be a good to add this info to the read.me file.
Best, Christian
I just realized that you already updated your Read.me.
Thanks, Christian
also, just a small correction in brutenib:
ITERATIONS="300" ACTIVENAME=""
should be
ITERATIONS="100" ACTIVENAME="CHEMBL"
to match: echo "-g number, Maximum iterations. Optional. Defaults to 100." echo "-a REGEXP, Sets ACTIVENAME for rocker. Optional. Defaults to 'CHEMBL'."
It is facultative but I also added this code to brutenib as Panther sometimes creates multiple negative-image models and saves them all in the same mol2 file. This obviously creates problems with brutenib:
MODEL_COUNT=$(grep -c "@
Hi,
I tried the new ShaEP version (1.4.0) with Brutenib. As the new ShaEP version is taking care of multi-threading, natively, it is not compatible with the way Brutenib is dealing with parallel jobs... the version 1.4.0 is slowing down brutenib to 50% as the system gets overwhelmed. Maybe you should indicate in your Read.me file that Brutenib was optimized for version 1.3.1 and not for 1.4.0
I also changed the way a formula was defined in brutenib, to be compatible with newer Bash versions: NUM=$(tail -n +$((1 + HEADER)) "${NIB}" | grep -c -v "^$")
Best, Christian