Applying nter and cter flag for protein with different termini ends

[mbrosz]

Hi Martinize2-Developer Team,

I currently try to martinize2 a protein with multiple chains and different types of termini. For example, one chain is capped with an ACE and NME residue. Another chain is capped with a GLY and ALA residue. So if I know use the default c-ter and n-ter flag, the ACE, NME cap is not recognized. On the other hand, if I use -nter ACE -cter NME the GLY, ALA termini are not recognized.

I was wondering if there is the possibility to provide a list for the n-ter flag to allow multiple termini to be recognized? Something like -nter [ACE, N-ter] ? Or may be there is a more clever solution to this issue, which is already implemented somehow, and I just can not see it.

Another issue, I encountered is that if one martinzes a protein ranging from -1100 to 1100 nm in one dimension. The PDB-Write function overwrites the "-" sign for values smaller -1000. As a result, part of the molecule is shifted to the positive direction. For example, an atom in the AA pdb at position x=-1050 would be placed at position +1050 in the CG pdb.

May be this issue is already solved, however my current solution was to change the output format of the coordinate from 8.3 to 8.2. The coordinates look like -1050.32 instead of 1050.323. This solution is not nice, since it also cuts off the coordinates for values larger -1000. For example, -989.82 instead of -989.824, although there is space for one more digit.

Thanks for your advice and best, Matthias

[fgrunewald]

@mbrosz thanks for bringing this to our attention. If I understood correctly there are two different issues/bugs. One is that you cannot set the terminal modifications separately for all terminals in the protein.

And the second one concerns coordinate shifts, where coordinates with less than -1000 are shifted to their positive counterpart value. Is that right?

Could you provide the martinize2 version you were using? Is it possible to share the protein complex with the coordinates with us? Is it possible to share the protein that needs the different termini?

[pckroon]

Hello hello!

You can (should be able to) assign different termini to different chains with the -modify flag. But, see also #295 --- we can detect modifications based on the atoms in the pdb file, but this gets clobbered for the termini.

For the PDB writer truncating the sign: this is a bit tricky. We currently use 8.3ft as format string: 8 characters with 3 decimals. Maybe that should be changed to 8.3ft (space significant) so that a character will be reserved for the sign. There's an annoying interaction with https://github.com/marrink-lab/vermouth-martinize/blob/master/vermouth/truncating_formatter.py though, since that will always truncates from the front. PR welcome ;)

[mbrosz]

Hi the both of you,

thanks for the fast reply concerning my issue with the martinize2 package. I highly appreciate your advices and will look more into the -modify flag. I think it is cool, that one can use different termini on the protein. Lucky me, thanks for sorting my thoughts through this post here, I came up with another solution. Just in case someone else encounters the same problem, I will share my solution here:

1) Concerning the problems with the different termini: I first tried to mutate the ALA, GLY termini to NME, ACE and apply the NME, ACE flag later one. This works pretty well, however, since the chemistry between, e.g. ACE and the GLY termini is different, the solution was not too nice. Next I decided to split the large PDB in multiple small pdb's (one pdb per chain) and martinize2 them separately. This allowed me to specify the termini individually to each chain. Later than I merge both the typologies and coordinate files together. A bit complicated, however this kind of solved the issue with the termini. Nevertheless, I will also try and look into the modify flag to see if this speeds up the martinize2 command.

2) Concerning the issue with the -1000 coordinate, the solution I proposed (above) was not really working... So my workaround was to shift the whole system to positive values in order to circumvent the problem with the minus sign. So rather a target oriented solution, than a nice one. However, it should be working as long as the system is smaller than 1000 nm :)

Finally, thanks again for the reply to my issue and all the best.

[fgrunewald]

@mbrosz has this been resolved or is it still open?

[mbrosz]

Ah sorry, yes for sure the issue has been resolved. Thanks again for asking.