add pair parameter

[XiaoboLinlin]

This function, structure_factor_pair, is based on previousstructure_factorfunction. The new function added a new parameter pair, which can deal with cases like S(q) of cation vs cation, cation vs anion, anion vs cation and anion vs anion.

[mattwthompson]

From a glance it looks like this is mostly copied code, but for a subset of a trj. IIRC the atom selection language in MDTraj allows you to slice out a trajectory into another trajectory, so the same function would be able to take in the same argument. Is this feasible?

http://mdtraj.org/1.9.3/api/generated/mdtraj.Trajectory.html#mdtraj.Trajectory.atom_slice

[rmatsum836]

From a glance it looks like this is mostly copied code, but for a subset of a trj. IIRC the atom selection language in MDTraj allows you to slice out a trajectory into another trajectory, so the same function would be able to take in the same argument. Is this feasible?

http://mdtraj.org/1.9.3/api/generated/mdtraj.Trajectory.html#mdtraj.Trajectory.atom_slice

I'm pretty sure this would work for pairs of the same type (cation-cation or anion-anion). I think the issue is when unlike pairs are analyzed (cation-anion) because currently we are selecting the pairs for md.compute_rdf through the atom selection string element X.

[rmatsum836]

However, we might still be able to handle this in the same function. What if we had an additional arg or kwarg that appended to the atom selection string? Something like {'custom_atom_arg': ['rename cation', rename anion']}.

Then when the pairs are selected we could do something like this:

if kwargs['custom_atom_arg']:
    selection1 = 'element {}'.format(e1) + ' and {}'.format(kwargs['custom_atom_arg'][0])'
    selection2 = 'element {}'.format(e2) + ' and {}'.format(kwargs['custom_atom_arg'][1])'
else:
    selection1 = 'element {}'.format(e1)'
    selection2 = 'element {}'.format(e2)'

pairs = top.select_pairs(selection1=selection1),
                                          selection2=selection2)

[XiaoboLinlin]

Your comment is good for avoiding making separate gro file, and I will try to implement that latter on. but it looks won’t solve the main issues in the figures I showed you in the slides (slack).