This modifies the coordinate state
for all future actions

For both types of trajectories?
by the way, xtalsymm is not a good name for modifying the coordinates. (I don't have name suggestion :D).

xtalsymm is a reasonable name for crystal symmetry stuff, though. Other commands that modify coordinates don't have any special naming convention that indicates coordinates are modified (e.g., rms/rmsd).

IIRC, "xtal" is a commonly-used abbreviation for crystal throughout many places in Amber, so I don't expect this name to cause problems.

. Other commands that modify coordinates don't have any special naming convention that indicates coordinates are modified (e.g., rms/rmsd)

but we have align, rotate, translate, scale, center, strip that indicate to modify coords. :P

IIRC, "xtal" is a commonly-used abbreviation for crystal throughout many places in Amber, so I don't expect this name to cause problems.

I agree. Just the combination "xtalsymm" is an issue to me.

xtalsymm is not a good name for modifying the coordinates.

As Jason indicated, there is currently no command naming convention for indicating coordinate modification. However, in the cpptraj manual the table containing all Action commands has a column that indicates whether the command modifies coordinates, so the information is at least somewhere. In the manual (dating back to ptraj days) the commands actually used to be separated by whether they modify coordinates or not, but that was determined to be more confusing.

Overall, the command names in cpptraj range from OK (e.g. temperature) to borderline OK (e.g. molsurf) to downright confusing (e.g. runavg/runningaverage Action vs runningavg Analysis - yikes!). What I'm trying to say is that absent a better suggestion I think xtalsymm is OK. :-)

The horse is dead but I’ll still beat it.

It’s generally advisable that users should understand exactly what they want to do with a command before they decide to use it. Presumably the fact that xtalsymm modifies coordinates is obvious to anyone that understands why you would use that command in the first place (i.e., the only group of people that should be using it). Given that, the primary purpose of the name should be to be memorable enough that people can either recall it without help or pick it out of a command list quickly. My feeling is that for anybody doing crystal analysis with Amber, this name serves that purpose. The help text in cpptraj and the documentation in the manual should be consulted for clarification.

If we demand that a name be short (as we should), then we can’t demand too much in the way of self-documentation from it.

If we demand that a name be short (as we should), then we can’t demand too much in the way of self-documentation from it.

I could alias the command with a super-long name as a fun easter egg - something like AnActionToSuperimposeSymmetryRelatedPartsOfASimulation

Ugh...

  Action_XtalSymm.cpp
C:\projects\cpptraj\src\Action_XtalSymm.cpp(7644): fatal error C1061: compiler limit: blocks nested too deeply 
[C:\projects\cpptraj\build\src\cpptraj_common_obj.vcxproj]

This is going to require some re-coding here...let me think about the best way to do it. May need to do it in a more object-oriented way...

You mean AnActionToSuperimposeSymmetryRelatedPartsOfASimulationThatChangesCoordinatesForAllFutureActions?

You only got that error on Windows, right?

You only got that error on Windows, right?

Yeah. I think the refactoring I did from multiple if/else to switch should fix it (::knocks on wood::). As a bonus this removes the need to do so many string comparisons deep in a nested loop and the separate code should make it easier to generate the file in case @dscerutti needs to update the symmetry ops with his python script (will require only a little refactoring). Also gave me a chance to squash a compiler warning so all is good.

At last...