We use the same software to read ccp4 maps and mrc maps, two map file types that have almost identical file formats. To review the nature of the header for these files and the small difference between these file types, please look here: MAPLIB (CCP4: Library) — CCP4 documentation
Until recently, reading both ccp4 and mrc map files with the same software has worked out fine. However, just lately we have received several map files from collaborators, written by CryoSPARC, that cause problems for the software reading these maps. We have tracked down the problem to the header word 25, LSKFLG (a flag for skew transformation, 0 if no data present, 1 if data is present in SKWMAT**).** Words 26-35 are SKWMAT, which is the skew matrix to be applied to the map. In these recent map files the flag LSKFLG is set, indicating that data is present in SKWMAT. However, these map headers contain a non-viable matrix in SKWMAT that causes map display to fail.
We were wondering if the flag LSKFLG in the file header is now being set on purpose and if the data that follows in SKWMAT has some significance. If not, then it seems to us that the flag LSFLG should be cleared to 0 in CryoSPARC map headers to avoid any confusion. We would very much appreciate that fix.
Below is the core information that you requested for troubleshooting. I do not have direct access to the software that is causing this problem but I will be glad to try to obtain whatever additional information you need from our collaborators.
*****CryoSPARC was installed in the cluster mode.
*****Version information, etc.
[image removed]
***** Environment information (from head node) – next message since I am restricted from placing it here.
We target this MRC specification, not a CCP4 specification. Words 25 to 49 in the MRC specification are spepcified as “Extra - to be used for any purpose”, while in CCP4 they’re LSKFLG, SKWMAT, etc. As of CryoSPARC v4.7, we use that extra space to store a checksum for data integrity verification. It must be that MAPLIB interprets those fields according to CCP4, and finds the values therein invalid (justifiably so).
I’m still looking at the CCP4 documentation to see if there’s an easy workaround (one that doesn’t involve moving the checksum data), but I figured I would respond to your message with the diagnosis in case you know anything further that might help us arrive at a workaround or resolution.
EDIT: It doesn’t look like there’s a good way around this without changing how we store the checksums. For now, you can zero-out words 25 and 26 (1-based indexing) in problematic files without causing any harm to CryoSPARC compatibility. In a future release, we can move our checksum to the text labels section of the header, which seems to be in common between MRC and CCP4. I would be interested in your input on this plan.
Clearly you understand the situation at least as well as I do, if not better. The workaround you mentioned is okay. Moving the checksum sounds good, but I don’t know if using some of the text label space for the checksum could have a downside. It sounds OK, but I’m not sure. Is there anywhere else in the header not being used? One alternative might be to clear word 25 to zero, and then move your checksum into word 26 and following. That should be OK for us. I realize that any change to the location probably will make complications for compatibility of maps between versions, but that should be the only consequence.
I would prefer to use the text area since it seems like both specifications expect that to be for application-specific or user-specific purposes. Even if using words 25 and 26 in the indicated manner wouldn’t be problematic for you, it might be for someone else.
I’ll send you an example file once I have a mock-up implementation of the new checksum format.
