Every Job Ran for Martinize2 is Killed/No Residues Recognized

[zamydm]

Good morrow.

I have been trying to use martinize2 for coarsegraining a protein+lipid+water system, and every single job I have run has been killed prematurely with the added issue that all residues, even very generic ones, are not recognized. It says the residues are no known to the Charmm forcefield, however I am certain that this is not an issue as all .pdb files were generated with Charmm-Gui. Any advice on how to resolve this issue of refusal to recognize residues would be greatly appreciated.

Thank you.

[csbrasnett]

From what you've described, it sounds like you're trying to generate Martini topologies for a whole system in one go. Have you tried generating a single topology of your protein on its own? Tools like insane can then be used to build your system.

[pckroon]

Hello hello, that sounds... undesirable. Could you provide us with your command line and the screen output of martinize2 (ideally with -v)? Please just copy paste the text, rather then for example a screenshot or attachment.

As a side note, martinize2 can't coarse-grain water/solvent (yet).

[zamydm]

Hey, thanks for the speedy reply!

I was uncertain of the coarse graining capabilities of Martinize2, so I tried both with the whole system and just the protein. In both cases, I get the same error where it seems that even basic residues of my protein are not being recognized. I have attached the command line prompt and the error below:

Command Line V1: martinize2 -f 8HKQStripped.pdb -x 8HKQCoarse.pdb
Command Line V2: martinize2 -f 8HKQStripped.pdb -x 8HKQCoarse.pdb -o topol.top -ff martini3001 -dssp -elastic

I hope that this isn't something as simple as I made a mistake in command line input. For both versions, I got the exact same error:

I am on Mac M2 for operating system. I know how to use Insane, and haven't had any issues in using it in conjunction with martinize.py from the martini website. This is the out of date version from several years back. I will admit though that I cannot for the life of me get simulations using files generated from those programs running no matter what I do, so if anyone has experience with that, that would also be appreciated.

[pckroon]

Instead of posting an image of the partial screen output, could you please copy paste the complete text?

[zamydm]

The complete text is thousands of lines long. It is just the same as the top of the command prompt repeated ad nauseam. It produces that line for every single atom in the protein.

[pckroon]

Alright, the following stands out: Your input structure is fishy, since atom names are not unique within residues. This is a red flag (or at least dark orange). In addition, there is an LQ9 residue that martinize2 does not know.
Martinize2 uses bonds to identify which atom is which (alongside some other criteria). If we can't get that information from atomnames (for whatever reason), we use distance criteria (as the message says), which is simply more error prone. If this results in wrong bonds it will cause all sorts of chaos, and one of the side effects can be excessive memory use and runtime as martinize2 tries to desperately salvage your simulation.
Finally, it's actually not martinize2 killing itself, but something else. Maybe the memory consumption is going to high and the kernel terminates it? How long does it run for before it breaks? More so that for martinize1, for martinize2 it is very strongly garbage in, garbage out. Please check your input structure for clashes carefully.

[zamydm]

Okay, thanks for the reply.

For reference, the .pdb that I generated was produced from Charmm-Gui. I haven't had issues with the protein when running atomistic simulations in OpenMM, so I find it hard to believe that the issue is the protein unless Martinize2 is incompatible with the Charmm36 forcefield. Note when I use the martinize.py script from the martini3 website, a script that I am aware is out of date, the protein is coarse grained without issue.

While using distance criteria for some less common residues is understandable, the fact that even extremely common residues such as ARG or LYS are not being recognized concerns me greatly. Perhaps Martinize2 is simply refusing to recognize any residues/atoms? In which case, what should I do to resolve that issue? Is there a problem with it in installation that I am missing, such as there are necessary libraries that I forgot to install in addition to Vermouth? I used the command: "$pip install vermouth" to install it.

For memory allocation, I believe you are right as the job does seem to consume most of the memory available on my system before terminating. I agree that this is likely from the distance method.

[pckroon]

Neither of that says anything about the correctness of your simulations though.
If you read the warning and my previous message you'll see that martinize2 recognizes the residues just fine (except for the last one), but that your input structure is suspect. I guess you have a dimer (multimer?) with identical chain identifiers? If so, a solution could be to add TER records in between the monomers.

[zamydm]

Okay, I will try that and let you know how it goes. Thanks so much for your help, you have been awesome!