simputmerge adds 4 bins to pulse profile, in bad order

[matteobachetti]

Hello,

I'm running a large simulation, trying to transform many sources in a field of view into pulsars. For each of them, I create a simput file containing a timing extension with a profile. The files are created correctly using simputfile to assign a spectrum, then simputlc to create the timing extension. I checked that the timing extension has two columns (PHASE, FLUX) describing the pulse profile, plus the correct header keywords (MJDREF, TIMEZERO, PHASE0, PERIOD, etc.).

Now, when I run simputmerge, the timing extensions have 4 more bins in the profiles. If I have 16 bins in the original profile, it creates 20 in the merged one; if I start from 20, it creates 24, etc. Moreover, the phases have some strange values (including negative values).
E.g. in my original file I have 0.025, 0.075, ... 0.975, in the final one I have 0.02499998, -0.025, 0.025, 0.075, ..., 0.975, 1.025, 0.975

runsixt fails with Assertion failed: (stepwidth>0.0), function getSimputPhotonTime, file datahandling.c, line 1667.. That line complains about bad data format, and I think the reason is this weird addition of extra pulse phases

Hope this is clear. I can share the data and the scripts used to generate the pulsations, if needed. Thanks in advance!

[matteobachetti]

This does not happen if phases are defined strictly between 0 and 1, i.e., the first phase is 0 and the last is 1. So I guess I need to define the pulse profiles using edges instead of bin centers!