Sure! I will provide the complete directory where you can find the Amber99SB-ILDN force field files, along with the PDB file.
I’ve been trying to add the residue, but it hasn’t been successful. When I remove it, everything works fine, but I’m concerned that omitting it might impact the quality of the simulation results.
Here is the link : Input file
I didn’t get any errors at all when running the specified command line, using the PDB file in your archive and with the amber99sb-ildn.ff directory downloaded to my local working directory. If I’m using the default installed version I get
´ Fatal error: Residue 'CU' not found in residue topology database ´
Are you sure you are using the modified version of the force field? Is it in your local directory? Or are you using the correct GMXLIB pointing to the correct system-wise installation directory?
I did not get the The residues in the chain CU400–HD402 do not have a consistent type error. Admittedly I used the current development branch rather than 2024.2, but I’m quite sure there are no differences to pdb2gmx.
Yes, it’s working now. I realized that I was always running the process by selecting the force field in the GROMACS topology file, but the file wasn’t always in my directory, which was the actual mistake. Now, everything works fine on my end without any errors.
Regarding the issue with the residues in the chain CU400–HD402, I still get the same error, but if i use the ignh option it’s okay, no error .
You mentioned that you’re using the current development branch. Okay, I’ll update mine as well. I believe there isn’t a quick update option, so I’ll need to start the process from scratch, just like I did for my current version.
I used the -ignh option as well. So, the using the development (main) branch should not make a difference.
I haven’t checked closely, but I would presume it’s the HO atoms that are causing the problem. They will probably be treated as hydrogens by -ignh and thereby removed. If you want to keep them you will have to see if you need to specify a separate residue type for them.
So, if I understand correctly, to retain the HO atom, I should add it to my force field like I did with the CU. I’ve just checked, and HO appears to be an atom of Holmium (HO a metal) in Biovia Discovery Studio. Therefore, I believe it’s necessary to keep it.
However, the error message The residues in the chain CU400–HD402 do not have a consistent type cannot be resolved by just adding CU to the force field as I did before. I also need to add HO, and in doing so, I think this will solve the issue.
Now, I need to figure out how to properly add HO (metal) to the force field, considering that the AMBER99SB-ILDN force field is primarily designed for biological systems (proteins and nucleic acids).
What are your thoughts on this new information? Do you think adding the HO atom in this way will resolve the issue and do you have any idea about a properly way to add it?
Do you know whether the holmium and copper “residue” is biologically relevant at all? If you really know that it is necessary, you would have to add the holmium parameters to the force field. You would probably (i.e., as far as I know) have to generate the parameters yourself, based on QM simulations, preferably verified against experimental observations. I would not recommend that.
I would recommend having a close look at the paper describing the PDB structure. I would hope that you can remove these “residues” completely.
I have checked some papers to see the importance of these ions. Copper is relatively important in the process, but not for holmium; some papers even exclude it.
Last time, you showed me how to fix this issue:
Program: gmx grompp, version 2024.2
Source file: src/gromacs/gmxpreprocess/grompp.cpp (line 706)
Fatal error:
The number of coordinates in the coordinate file (solv.gro, 1,136,228)
does not match the topology (topol.top, 1,136,229)
In the topology file, it indicates SOL = 377,542.
I checked the solv.gro file, which starts with 2SOL and ends with 77,543SOL. When I subtract 77,541, I replace it in the topology file, but the process still doesn’t work, and I get the same error. Am I missing something here? The file is in text format WITHOUT ANY MODIFICATIONS.
File
I’m afraid you are not counting the molecules right. You say it starts on 2SOL and ends with 77,543SOL. From that you get a number 77,541. What number would you get if you start with 1SOL and ending with 77,542SOL? Remember, it is an inclusive range. I hope you will find that the topology is correct.
But it’s very strange that you get a number of atoms that differs by 1. That indicates another error in the counting (almost certainly one of the ions). But I’m sure you can find out ways to count the number of molecules of each type in your gro file and in your topology. Consider it an exercise.
See No such molecule POP1 error during CG simulation minimization step - #19 by MagnusL if you want a step-by-step instruction how to handle atom counts not matching between your gro file and your topology file.
Hello Magnus, i’m also really surprse by myself how i did this kind of error about counting
Right now I’ve recently encountered an issue regarding hydrogen bonding analysis between a ligand and protein in my simulation. After running a short simulation (around 1 ns), I’m now facing a new issue with hydrogen bond detection.
I used the command:
Program: gmx hbond, version 2024.2
Source file: src/gromacs/trajectoryanalysis/modules/hbond.cpp (line 572)
Function: static void gmx::analysismodules::{anonymous}::Hbond::linkDA(gmx::analysismodules::{anonymous}::t_info*)Inconsistency in user input:
Selection ‘LIG’ has no donors AND has no acceptors! Nothing to be done.
I’ve checked my setup multiple times, tried different ligands and molecules, and even experimented with both the AMBER99SB-ILDN and CHARMM36 force fields. However, I still encounter the same issue. I also tested hydrogen bonding between water and the ligand, but the error persists.
Some additional details:
xyz coordinates of both the protein and ligand to ensure they are close together, as randomly placed, they tend to be far apart.Despite these adjustments, I continue to see this “no donors or acceptors” error, even with a short 1 ns simulation to really cheked again with another molecule and ligand same issue.
I’ve attached the entire simulation directory. Could please take a look and offer any advice?
Here is the file FILE
I’m sorry, I won’t download an archive that large.
Does it work with gmx hbond-legacy? It’s quite possible that this gmx hbond: add extra features (!4361) · Merge requests · GROMACS / GROMACS · GitLab change will help. In that case, it will work better with the GROMACS 2025 release.
Yes, it works with the legacy option, but the issue is the lack of interactions. As a common example, the ligand JZ4 always works with the following command: gmx hbond -s md.tpr -f md.xtc -num hb.xvg -tu ns. However, due to some issues with this command, I suspect there are errors involved. I’ve tested three different ligands with different proteins after docking to evaluate potential interactions. I don’t understand why the previous command works with JZ4 but doesn’t yield results for the other ligands, which seems abnormal. Attached is the image showing the RMSD results and the legacy hydrogen bond command analysis.
I just checked a previous simulation: in the first one, I removed the ligand JZ4 from its protein (downloaded from RCSB) and ran the gmx hbond and RMSD commands. Everything worked perfectly. Now, in another previous file, where I’d already generated hydrogen bonds using the same command and ligand JZ4 with a different protein, the gmx hbond command doesn’t work this time, which seems unusual.
The main difference between the first and second file relates to periodic boundaries. I always run these commands before building the complex to ensure the ligand is precisely positioned in the active site (XYZ coordinates from the literature):
gmx editconf -f PRO_processed.gro -o complex.gro -c -box 23.204 47.660 17.090
gmx editconf -f LIG.gro -o complex_box.gro -c -box 23.204 47.660 17.090
This procedure typically ensures the ligand aligns correctly, but this issue might suggest a GROMACS-related inconsistency.