# Pdb2gmx fatal error: residue naming **URL:** \ **Category:** User discussions\ **Created:** [May 10, 2024, 1:18pm UTC](https://gromacs.bioexcel.eu/t/pdb2gmx-fatal-error-residue-naming/9124 "2024-05-10T13:18:53Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![ivangreg](https://avatars.discourse-cdn.com/v4/letter/i/7993a0/32.png) [@ivangreg](https://gromacs.bioexcel.eu/u/ivangreg)\ **Post date:** [May 14, 2024, 4:28pm UTC](https://gromacs.bioexcel.eu/t/pdb2gmx-fatal-error-residue-naming/9124/5 "2024-05-14T16:28:09Z")
Hi @scinikhil If my memory serves me right, that is the top hit that I got doing a search to try to solve this kind of problem. Could you please do the community, @kj655, and me a favour? Within that post (that is 17 years old) or any other post: **Could you please specifically point to the solution?** (Not the description of the problem but the solution.) It seems that knowledgeable scientists over the years have found this atom-naming incompatibility a challenging problem. See for instance [this](https://gromacs.bioexcel.eu/t/charmm36-to-gromacs-porting/2101) 2021 exchange between @awacha and @jalemkul . My understanding is that that very conversation lead to a [2023 publication](https://doi.org/10.1021/acs.jcim.3c00860) by those two scientists. The solution proposed in that paper points to a [converter](https://gitlab.com/awacha/charmm2gmx) on a GitLab page. Unfortunately, the README.md in GitLab says only this: " Note: This is work in progress. Do not use this code, not even at your own risk! The resulting force field is not guaranteed to be correct at all. On-line documentation: [https://awacha.gitlab.io/charmm2gmx](https://awacha.gitlab.io/charmm2gmx) " In conclusion, for over 17 years people have been reporting this problem. If you could show a documented solution, I and many others would be profoundly grateful to you. Ivan --- _[View the full topic](https://gromacs.bioexcel.eu/t/pdb2gmx-fatal-error-residue-naming/9124)._