will produce a parameter on the timing model mo.JUMP17 or something. It is not clear how the number 17 is assigned to this JUMP, or whether this is consistent in the face of par file changes (for example re-ordering lines, or adding or removing other JUMPs). This makes comparing par files difficult.
I suggest constructing the names of mask parameters in some more consistent way. Perhaps JUMP_fe_Rcvr_800 for this one? Some care must be taken to ensure that the names are unique and also valid Python identifiers; perhaps just substituting all questionable characters with _ and appending a number if necessary would resolve this.
Such a change would impact user code that relies on naming parameters by number, including all NANOGrav yaml configurations, but that code is almost certainly broken anyway - minor changes can unexpectedly result in renaming JUMPs.
Is there any objection to simply naming them NAME_key_value or NAME_key_value1_value2? Implementation will be a little cumbersome (some values are not acceptable python strings) but can be done.
A parfile line that looks like
will produce a parameter on the timing model
mo.JUMP17
or something. It is not clear how the number17
is assigned to this JUMP, or whether this is consistent in the face of par file changes (for example re-ordering lines, or adding or removing other JUMPs). This makes comparing par files difficult.I suggest constructing the names of mask parameters in some more consistent way. Perhaps
JUMP_fe_Rcvr_800
for this one? Some care must be taken to ensure that the names are unique and also valid Python identifiers; perhaps just substituting all questionable characters with_
and appending a number if necessary would resolve this.Such a change would impact user code that relies on naming parameters by number, including all NANOGrav yaml configurations, but that code is almost certainly broken anyway - minor changes can unexpectedly result in renaming JUMPs.