You are here

When using "screening job files" in small molecule-docking I get: Residue type already exists in the cache Error

5 posts / 0 new
Last post
When using "screening job files" in small molecule-docking I get: Residue type already exists in the cache Error

Hi everyone, 

I detected an issue with the small molecule-docking application using rosetta scripts and the setup for doing large-sized libraries screening. In this set up you generally use a "screening_job_file" input that specifies which combination of ligand and protein structures will be used during the simulation. This file looks something like this:

 "jobs": [
   "proteins": [
   "ligands": [
   "group_name": "protein"
 "params": [

The program works fine when building the first pose. But, when it attempts to build the second pose it complaints that the residue type 'AE' already exists in the cache:

protocols.jd2.ScreeningJobInputter: ScreeningJobInputter::pose_from_job
protocols.jd2.ScreeningJobInputter: filling pose from PDB proteins/protein.pdb params/c1/AE.pdb
core.chemical.ResidueTypeSetCache: [ ERROR ] Residue type AE is already in the ResidueTypeSetCache!

ERROR: Error in core::chemical::ResidueTypeSetCache::add_residue_type(): Attempting to add a new residue type, but residue type 'AE' already exists in the cache.  (Did you load a .params file with the -extra_res_fa commandline option that was already listed in residue_types.txt, perhaps?)
ERROR:: Exit from: src/core/chemical/ line: 106

The same input worked fine in previous rosetta releases, but now it seems that a control check has been implemented that does not allow to load the same parameter file twice. This is attempted automatically for every trajectory when the input is a screening_job_file. I did try to remove the "params" entry from the screening_job_file, but is mandatory. Also, my option file (flags) does not contain any other call to any ligand parameter file.

Does any one have a workaround to this issue (besides not using this way of setting up the docking protocol)?

Post Situation: 
Thu, 2020-09-17 06:01
Martin Floor


I ran into this same error the other day with a mistake in an auto-generated command line in which the params file was listed twice. Removing the extraneous input fixed the issue. I'm not familiar with this particular method but I would guess that you could move past this error if you only input the params file for that residue type the first time it is needed (or maybe input all of the novel params files from commandline instead). I know it's a bit of a workaround instead of a fix but at least you can continue in the research.

Fri, 2020-09-18 09:28

That is actually what I did try first, but the petition to load the params file comes directly from how the job distributor handles jobs when using a screening job file as input. It tries to reload it every time the nstruct index is moving up, which gives rise to the error mentioned above. Since the params entry in the screening file is mandatory, it does not matter if I try to load the params files from the command line, it will always complain. 

For now, it seems to be impossible to use this kind of input again unless there is a way to disable the params file redundancy issue. I searched for an available option that could allow me to overwrite previously loaded param files that added the same ligand name, but without luck. Maybe is something that could be added to enable the correct handling of this input type.

Sat, 2020-09-19 02:55
Martin Floor

Hi! Sorry this didn't work for you. I'll highlight this issue to the community as something to address. For reference, what Rosetta version are you using?

Mon, 2020-09-21 08:50

The version is numbered as Rosetta 3.12.

Thanks for passing through the information!

Tue, 2020-09-22 00:48
Martin Floor