{"action":"created","issue":{"url":"https://api.github.com/repos/GRIFFINCollaboration/GRSISort/issues/424","labels_url":"https://api.github.com/repos/GRIFFINCollaboration/GRSISort/issues/424/labels{/name}","comments_url":"https://api.github.com/repos/GRIFFINCollaboration/GRSISort/issues/424/comments","events_url":"https://api.github.com/repos/GRIFFINCollaboration/GRSISort/issues/424/events","html_url":"https://github.com/GRIFFINCollaboration/GRSISort/issues/424","id":98443985,"number":424,"title":"GRIF-16 Amplitude-Corrected Timing","user":{"login":"SmithJK","id":10604745,"avatar_url":"https://avatars.githubusercontent.com/u/10604745?v=3","gravatar_id":"","url":"https://api.github.com/users/SmithJK","html_url":"https://github.com/SmithJK","followers_url":"https://api.github.com/users/SmithJK/followers","following_url":"https://api.github.com/users/SmithJK/following{/other_user}","gists_url":"https://api.github.com/users/SmithJK/gists{/gist_id}","starred_url":"https://api.github.com/users/SmithJK/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SmithJK/subscriptions","organizations_url":"https://api.github.com/users/SmithJK/orgs","repos_url":"https://api.github.com/users/SmithJK/repos","events_url":"https://api.github.com/users/SmithJK/events{/privacy}","received_events_url":"https://api.github.com/users/SmithJK/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-07-31T18:13:36Z","updated_at":"2015-07-31T23:24:34Z","closed_at":null,"body":"In anticipation of the implementation of the amplitude-corrected timing word in the GRIF-16s... It will output the low bits of the timestamp at half the amplitude of the signal. This is read out to the Cfd parameter in the fragment tree.\r\n\r\nWe need to figure out how we're going to deal with this from the GRSISort perspective. Some thoughts:\r\n* In many places, the Cfd parameter can be directly substituted for the TimeStampLow parameter. The exception to this is the TreeIndex.\r\n* Rollover of TimeStampLow vs. Cfd will need to be accounted for properly.\r\n* GetTimeStamp_ns now assumes that the Cfd parameter will give us nanosecond resolution. This will need to be changed.\r\n* How do we make this backward compatible? In previous runs, the Cfd value has been random and useless, so we want to keep an option available to *not* use these changes. I suggest some Boolean in the run info: UseCfd or UseTimeStampLow, depending on what makes the most sense when we implement these changes. The default value for this Boolean should be whatever value will be used in the desired normal running conditions.\r\n\r\nNote: I started this post thinking that the Cfd was properly implemented, then figured out that it's not quite in there yet. Regardless, this is a discussion we should have."},"comment":{"url":"https://api.github.com/repos/GRIFFINCollaboration/GRSISort/issues/comments/126834102","html_url":"https://github.com/GRIFFINCollaboration/GRSISort/issues/424#issuecomment-126834102","issue_url":"https://api.github.com/repos/GRIFFINCollaboration/GRSISort/issues/424","id":126834102,"user":{"login":"pcbend","id":433187,"avatar_url":"https://avatars.githubusercontent.com/u/433187?v=3","gravatar_id":"","url":"https://api.github.com/users/pcbend","html_url":"https://github.com/pcbend","followers_url":"https://api.github.com/users/pcbend/followers","following_url":"https://api.github.com/users/pcbend/following{/other_user}","gists_url":"https://api.github.com/users/pcbend/gists{/gist_id}","starred_url":"https://api.github.com/users/pcbend/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pcbend/subscriptions","organizations_url":"https://api.github.com/users/pcbend/orgs","repos_url":"https://api.github.com/users/pcbend/repos","events_url":"https://api.github.com/users/pcbend/events{/privacy}","received_events_url":"https://api.github.com/users/pcbend/received_events","type":"User","site_admin":false},"created_at":"2015-07-31T23:24:34Z","updated_at":"2015-07-31T23:24:34Z","body":"Additional if the new timing value is not being used to actually generate\nthe trigger, build from it could get sketchy\nOn Jul 31, 2015 7:20 PM, \"Peter\" <pcbend@gmail.com> wrote:\n\n> Currently the random access is a needed to ensure time ordered data.  The\n> large window (1us) is also needed to properly do background subtraction.\n>\n> How much is the \"cfd\" going to change the time stamp?  For the\n> subscription above it sounds like it will be on the order of 5-10 clock\n> ticks... I wonder if this will really effect building.\n>\n> Changing the build method of course is completely possible, we just need\n> to through the fragments into a ring buffer before writing and ensure the\n> ring is large enough to safely catch even the slowest events.  Additional\n> we can set the fragment tree out put limit(automatic root function) smaller\n> which should easy the virtual memory parameter a but\n> On Jul 31, 2015 7:12 PM, \"Ryan Dunlop\" <notifications@github.com> wrote:\n>\n>> The tree index also takes up a lot of memory. The new runs need somewhere\n>> between 10 and 16 GB of space to be able to efficiently randomly access the\n>> data.\n>>\n>> > On Jul 31, 2015, at 7:02 PM, Vinzenz Bildstein <\n>> notifications@github.com> wrote:\n>> >\n>> > While it is true that we don't need to change anything in the event\n>> building when we use a 2us window, we might want to make this window\n>> narrower at some point (especially if the cfd timing makes our coincidence\n>> peak much narrower).\n>> >\n>> > In that case it's not an easy change, as we need to use different\n>> criteria depending on the detector type (GRIF-16: TimeStampHigh and Cfd,\n>> 4G: TimeStampHigh and TimeStampLow MINUS Cfd). This also affects what we\n>> write to the analysis tree. For GRIF-16s it's fine to write a 64bit\n>> timestamp that incorporates the cfd value (if a flag is set to use the cfd\n>> value), but for the 4G we need the timestamp (which can incorporate some\n>> information from the cfd value) plus an interpolation between the timestamp\n>> ticks (the rest of the cfd value).\n>> >\n>> > I think we should\n>> >\n>> > definitely add a flag to the run info that decides whether we use the\n>> cfd value or not (default should be to use it),\n>> > have GetTime handle the timestamp and cfd information properly based on\n>> that flag (returning the time as floating point number in ns, even if the\n>> GRIF-16 timing is in 10ns steps), and\n>> > decide whether we keep the event building limited to large windows for\n>> now, of if we want to move away from the TreeIndex method (we could use a\n>> multiset instead, as we've discussed before).\n>> > —\n>> > Reply to this email directly or view it on GitHub.\n>> >\n>>\n>> —\n>> Reply to this email directly or view it on GitHub\n>> <https://github.com/GRIFFINCollaboration/GRSISort/issues/424#issuecomment-126832306>\n>> .\n>>\n>\n"}}