File formats differ with application, computation type, application version, and sometimes other parameters (mfaktc more-classes vs. less-classes, for example), making them incompatible. Files are not compatible between applications.
TF Trial factoring
Mfakto is derived from Mfaktc, and has continued the practice of storing the version description string in the checkpoint file. This makes an Mfakto checkpoint file incompatible with Mfaktc and presumably vice versa. And probably also between Mfakto on Windows and Mfakto on Linux!
Code:
94186879 75 76 4620 mfakto 0.15pre6-Win: 2505 0 2946A180
vs.
Code:
M4444091 1 63 4620 0.21: 2829 5 1FCB3F65
Mfaktc checkpoint files have been observed incompatible between minor versions (v0.20 vs v0.21) as well as between more-classes and less-classes. (Both examples above are more-classes: 4620, not 420.) One might try manually editing a copy of one to continue in the other. It's just text.
Note any CPU TF is discouraged for parameters that can be done with mfaktx, because GPUs are
far more efficient at TF.
Mprime/prime95 also can do TF.
Mfactor currently lacks save file or automated resume capability. Restarts are performed manually by examining logged stdout and stderr output to determine which pass(es) and k value(s) to resume at.
Factor5 has its own simple status.txt format.
I think there's no reason to believe any of these are compatible file formats.
P-1 factoring
A P-1 save file from CUDAPm1 is not usable by mprime/prime95, or vice versa.
Mprime/prime95 use different save file formats for PRP, LL, P-1, etc.
CUDAPm1 save files are also further constrained by GPU memory requirements determined by the exponent and bounds. Movement of a CUDAPm1 run in progress to a different GPU model typically requires both equal or greater GPU ram, and the ability to complete the GCD at the end of the stage, which has proven to be GPU-model-dependent and not very predictable from the GPU model specifications. System ram or available memory may also affect it.
Gpuowl or Mlucas files are also expected to be incompatible.
Mprime/prime95 P-1 runs in progress may restart a stage if transitioned to a newer version; read the included documentation carefully for warnings about that at certain versions.
To my knowledge there is no demonstrated cross-compatibility between applications. Except:
kruoli describes a manual method for migrating P-1 work from prime95 -> gmp-ecm
here.
Mihai Preda has announced a gpuowl version supporting P-1 stage 1 in gpuowl capable of passing that to mprime for GCD and stage 2
here; Windows build
here.
LL Lucas-Lehmer definitive test if accurately performed
Mlucas, mprime/prime95, CUDALucas, clLucas, and early Gpuowl LL save file formats were developed somewhat independently, and are not cross compatible. Based on a successful single test (LLDC relocation) mprime and prime95 are compatible, but I have not verified compatibility for other computation types. It seems likely since they share a great deal of source code, differing mainly in OS support and user interface.
Mlucas up to v19 and probably beyond, uses its own different LL test in progress file format than mprime/prime95 or the various GPU applications. Beginning Mlucas v19 there is a separate larger file format for PRP. See
https://www.mersenneforum.org/showpo...91&postcount=2.
PRP Probably Prime test (conclusive if accurately performed and indicating composite)
I believe Mlucas, mprime/prime95, and Gpuowl PRP file formats are not compatible. Also not tested.
GpuOwL has switched from LL to PRP type 4 and PRP type 1, and no-proof, proof V1, and proof V2, which are incompatible.
For the same computation type, GpuOwL has limited compatibility between versions. See
https://www.mersenneforum.org/showpo...7&postcount=12
Most applications will support their current file format and one previous version.
Cert
Only mprime/prime95 >v30.0 compute certifications.
ECM Elliptic Curve Method factoring (used in an effort to fully factor tiny Mersennes)
Among the software that can perform ECM are mprime/prime95, and GMP-ECM. There is reference in the Mlucas source code to ECM also, but I think it is not functional.
While not useful for GIMPS prime hunting wavefront and above, mprime/prime95 can perform ECM, and there is a facility for mprime/prime95 stage 1 results being used in GMP-ECM for greater stage 2 efficiency. Read the prime95 documentation, as that's what I did. Search for "Kruppa" in prime95's undoc.txt.
P+1 factoring
P+1 is not sufficiently productive to be of interest for GIMPS prime hunting wavefront and above.
As far as I know, only mprime/prime95 or GMP-ECM do P+1 factoring currently.
Neutral Exchange Format
There is a separate thread about development of a neutral exchange format standard for Mersenne number related software and data interchange.
https://www.mersenneforum.org/showthread.php?t=23428
I've written a CUDAPm1 export program for it. Looking at the prime95 P-1 save file source code, it appeared to me that they use different data structures to do the same computation, so it's more complicated than just file format differences, and moving a computation in progress from CUDAPm1 to prime95 may not be feasible. I had hoped to be able to complete in prime95, some of the many test runs that could not be completed in CUDAPm1.
Similarly, going from CUDAPm1 to GMP-ECM's P-1 capability looked intractable. Even assuming that the CUDAPm1 files are not corrupted somehow.
There is also a
CUDALucas neutral export program. It has a -headeronly option for decoding just the header, to check things like exponent, last iteration, res64.
Top of this reference thread:
https://www.mersenneforum.org/showpo...89&postcount=1
Top of reference tree:
https://www.mersenneforum.org/showpo...22&postcount=1