The core request of the program exceeded the set limits

[jeteveux]

I didnot run into this with demos,only with my own case.
here is job submit scripts

#!/bin/bash
#JSUB -q normal 
#JSUB -n 64
#JSUB -J sidechaingraft
module purge
module restore rosetta
mpirun -np 34 rosetta_scripts.cxx11threadmpiserialization.linuxgccrelease \
-l AD.txt -use_input_sc  -ex1  -ex2  -nstruct 1 \
-parser:protocol MotifGraft_sc.xml

log file end like this without and error,fully log file is provide
log.txt

Exited with exit code 1.

Resource usage summary:

		CPU time:       33.08 sec.
		Max Memory:     9.9 GB
		Max Processes:  37

[roccomoretti]

I'd check the consistency of your Job submission parameters with your mpirun specifications. From the log, it appears that you're launching 64 different Rosetta processes. I don't know the particulars of your queuing & MPI system setup, but I think this is conflicting with your mpirun -np 34 specification (but is consistent with your #JSUB -n 64 specification). -- Double check your cluster documentation (and/or consult with your cluster admins) to make sure you're setting up and running MPI jobs in the way the admins have set things up to work.

Note that Rosetta will actively and aggressively use all the cores assigned to it. Some processors and queuing systems have "hyperthreading" or "oversubscription" mechanisms, which allow you to launch more processes than you have actual physical CPUs. The philosophy being that at any one time a non-trivial number of processes won't be actively using the CPU (e.g. waiting for IO) or will only be using a part of it, and the other parts can be used by other processors. Rosetta tends not to benefit from that, as all Rosetta processes will be running pretty much continuously, and will be actively using the same parts of the CPU. As such, when figuring out how many Rosetta processes to launch, it's best to limit yourself to the number of actual physical CPUs you have.

At any rate, from the log it looks like you're able to get through most of the results prior to the program being canceled. It looks like there's only ~6 outputs which are left to process.