So I ran the collection 104 SDF files with 10 molecules in each, however 4 out of 104 files resulted in errors (1 molecule from each file). I am not sure why this happening since the ‘remove counterions’ tool seemed to work successfully. Is there something else that needs to be done to prepare ligands before using vina? This is job number 486
I have attached the history I am using for your reference as well
https://usegalaxy.org/u/jeslyn.jaic/h/new-history
Thank you
Hi @Jeslyn_Jaic
Great to see how much progress you have made!
For the error in collection 486, this is what one of them is reporting now.
I clicked into that collection, then on the i-icon for one of the red error datasets to get into the logs from the underlying tool.
PDBQT parsing error: Atom type B is not a valid AutoDock type (atom types are case-sensitive).
ATOM 1 B UNL 1 0.430 -1.782 0.000 0.00 0.00 +0.000 B
Then, tracing back through the inputs to the data line.
Scrolling up to find the exact file.
Then, reviewing that file (tab into the raw text). I only found that single line in one if the molecules.
I think we can both guess what this means but maybe not how to fix it! So I asked an AI to break it down for us. Please take this advice as being correct with caution of course, but I think these are some good leads.
Please explain an error like this one and what I can do to remedy it: > PDBQT parsing error: Atom type B is not a valid AutoDock type (atom types are case-sensitive). > ATOM 1 B UNL 1 0.430 -1.782 0.000 0.00 0.00 +0.000 B
Thought for 17s
This error is coming from AutoDock’s PDBQT parser telling you that the atom type field for that atom is not one of the allowed AutoDock types.
Your line:
> PDBQT parsing error: Atom type B is not a valid AutoDock type (atom types are case-sensitive).
> ATOM 1 B UNL 1 0.430 -1.782 0.000 0.00 0.00 +0.000 B
In PDBQT, an ATOM line is roughly:
ATOM [serial] [name] [resname] [resid] x y z charge type
So your line parses as:
ATOM1BUNL (unknown ligand)1(0.430, -1.782, 0.000)+0.000B ⟵ this is the problemAutoDock uses its own atom-type vocabulary (C, N, O, S, H, HD, A, Cl, Br, etc.), not arbitrary element symbols. B by itself is not a recognized AutoDock type, so the parser stops.
The error message “atom types are case-sensitive” is also a reminder that br ≠ Br, etc., but here the main problem is that B is simply not in the allowed list.
Typical causes:
Br, but a script truncated it to B.Check the original ligand structure (PDB, MOL2, SDF, etc.):
B?You can usually see this in the original file or in a viewer (e.g., PyMOL / ChimeraX / VMD).
Once you know what the atom should be, correct the last field of the PDBQT line to a valid AutoDock type. For example:
ATOM 1 B UNL 1 0.430 -1.782 0.000 0.00 0.00 +0.000 B
to something like:
ATOM 1 Br UNL 1 0.430 -1.782 0.000 0.00 0.00 +0.000 Br
ATOM 1 C1 UNL 1 0.430 -1.782 0.000 0.00 0.00 +0.000 C
Important: In PDBQT, the atom type is determined by the last token on the line, not the atom name field.
Instead of manual editing, the more robust approach is:
.pdb, .mol2, .sdf).prepare_ligand4.py, or an Open Babel / RDKit-based pipeline) to regenerate the PDBQT.This avoids subtle formatting or typing problems across the whole ligand.
If the element really is Boron and you want to keep it:
C) for a rough qualitative docking (not recommended for precise work).If you are screening many ligands (common in proteomics / chemoinformatics pipelines), a single mis-typed atom will break the run. A more scalable fix is to add a pre-flight QC step that:
B → Br if the underlying element is bromine).This can be done with a small Python script or Galaxy text-processing workflow so that you catch these issues before launching docking on a large set.
The suggestion to trace back through the data source to determine what your molecule represents, then making adjustments, seems valid. The file was uploaded, had counterions removed, but doesn’t appear to have gone through the prepare ligand tool again, so I would try that first.
Worse case, if that is not enough or should there legitimately be an unsupported atom type in the original data that the prepare tool does not automatically handle, then I would suggest proceeding to the other advice steps. If you need to manipulate the file directly, and want to adjust any others, using the plain text manipulation tools is definitely possible. These can be combined into a small workflow to run in batch? Maybe correct this and any others that show up?
Hope this helps to learn more about diagnosing this kind of error! 
So as suggested after using the ‘remove counterions’ tool I used the ‘prepare ligands’ tool. Then I used the vina tool and it seemed to work and there is an output, but its still highlighted as red overall even though each individual dataset is green. I have used a different history for this and I have attached the link below.
https://usegalaxy.org/u/jeslyn.jaic/h/3rd-history
Thank you
Hi @Jeslyn_Jaic
Thanks for running that is a smaller simple history. Much easier to navigate!
The error is a bit harder to find – try clicking into the second output collection and you’ll see it. It seems to be a message about the final parsing step (the actual sdf was not an error).
I would try a rerun first. Click into that single red dataset and use the rerun button. On the tool form, leave everything the same as the original run except toggle the “replace” option to Yes.
More details about how this works:
Then, if the job fails again, I would suggest reviewing the same way as we did the prior error. Compare the log content to what is in that specific chain of inputs to see if you can notice what is going wrong. Keep in mind that your job has two groups of inputs in a series.
The original dataset → then the sdf version that was created by the first step of the tool run → and finally this part of the tool that parsed the sdf output. By reviewing all together, and maybe comparing to the others in that group that were successful, you will probably be able to notice what went wrong.
I would also look at the formatting of that 10 ligand batch – especially if the error is the first or last in that set – to confirm the start and stop of that file are not missing any expected formatting. E.g. is not missing some header or is not truncated. (I hope this makes sense!).
Also keep in mind that parameters might be involved, and that single ligand was an edge case that needs to be managed. But I would always suggest looking a the data first before reviewing parameters!
Please give that a try and let us know what happens! If you get stuck and need more help, please post back screenshots of the relevant parts (to make sure we are looking at the same detail view) and we can work through this more. Try to keep the work in this same history for the single job rerun portion.
Let’s start there!
For Job number 2381: Docked Ligands for collection 1348, all the outputs are highlighted as green, but as the ‘standard output error’ mentioned the name linagliptin I clicked on it to rerun the job
however I cant seem to find the replace option when I rerun the job, so I just clicked on run tool
Below is the output I got, I am not sure what is causing the error here.
