I ran two similar problems in style, but obviously different in substance given SNAP's reduced features. I think trying to get them to match exactly is more trouble than it's worth. Possibly doable, but requires entering a lot of material cross sections in PARTISN by hand.

I focused only on the Grind Time: time to solve flux for one phase-space variable. That is, it's the total solve time divided by the cells * angles * groups * total number of all inners (sweeps) for all time steps. You could alternatively just divide the time by this total number of inners to get a value on a per mesh sweep basis. The number of inners is reported in both codes.

Ran my proc =64 job a few times and saw the grind time differing by about 10-13%, with SNAP being slightly faster. Note the overall execution time was much slower for SNAP because again it was doing more iterations due to the different material cross sections.

If you're ok with that spread (I am), I've attached the inputs for PARTISN and SNAP scaled up to 1008 procs. Take a look and see if they make sense. You can either use the PARTISN input exactly as is + the attached "macrxs" file. Or you can continue to use the materials you specified for your previous run + macbcd file you must have somewhere. Doesn't matter. The key thing again will be that the size of the problem and how they're run between SNAP and PARTISN are fairly similar, so you can compare grind time. That and the communication patterns should be very similar.

A couple other things that I think are helping them stay similar:

1. nosigf=1 for the PARTISN run, turning off fission operations
2. I've set iitm and iitl in PARTISN to 5 and oitm to 20, which should make SNAP and PARTISN stop to do inner source and outer source calculations at the same frequency.
3. And a bunch of controls on PARTISN time-dependence to ensure they both do 5 time-steps.