https://wiki.anl.gov/wiki_gsdaq/api.php?action=feedcontributions&feedformat=atom&user=Tlauritsen 2026-06-05T13:52:08Z User contributions MediaWiki 1.43.8 https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2432 2022-03-18T16:34:24Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> <br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 as user dgs and check whether the server is already running (try ps ax | grep piserver | grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the network booted raspberry pi's (RPs).<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window - where you can now enable it. Next, cycle the power of the RP again and it should come up as a client of the piserver. Be aware that it takes a while for the RP to boot up.<br /> <br /> . To modify the OS of the RPs, click on software in the piserver, then click on the OS. After that the 'shell' is available, click on it. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs, the default user we have on the network booted RPs. (For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs). You shuld not have to use raspi-config on the individual RPs. Note that you are root for the RPs in this shell.<br /> <br /> . The network booted RPs cannot see world outside of onenet (not sure why they restrict network access like that). So to, e.g., install a new version of the DGS EPICS softIOC do<br /> <br /> ssh rpdgs@piserver<br /> svn export .....<br /> <br /> You will be in /home/rpdgs on piserver1 which is the shared home directory for all the RPs. Don't try to compile etc there. To compile, go to any of the network booted RPs and and do it from there. You only need to do it on one of the RPs because the home diretory is shared.<br /> <br /> . Because the RPs share the home directory we have set them up to execute unique setup files based on the IP of the RPs. E.g., on sbxpp the file (in the shared home directory) softIOC.192.168.203.149 is executed. In this file we can start the softIOC with the EPICS databases appropriate for this RP.<br /> <br /> . Note that the RPs get their IP from the onenet DHCP server, not from the piserver. Thus, you need to register the RPs using onereg.phy.anl.gov.<br /> <br /> . We have not been able to make autologon work on the network booted RPs. Thus to start the softIOC on the RPs you should, from an xterm, ssh into the individual RPs. We will automatically start the softIOC when you ssh in. Before the automtic start of the softIOC, it will check to make sure that a softIOC is not already running. If someone else ssh into the RP, another softIOC will not be started. This system is not unlike when we have to start the softIOC on the DAQs of dgs, dfma, dub1 and xa.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2431 2022-03-18T16:33:36Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 as user dgs and check whether the server is already running (try ps ax | grep piserver | grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the network booted raspberry pi's (RPs).<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window - where you can now enable it. Next, cycle the power of the RP again and it should come up as a client of the piserver. Be aware that it takes a while for the RP to boot up.<br /> <br /> . To modify the OS of the RPs, click on software in the piserver, then click on the OS. After that the 'shell' is available, click on it. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs, the default user we have on the network booted RPs. (For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs). You shuld not have to use raspi-config on the individual RPs. Note that you are root for the RPs in this shell.<br /> <br /> . The network booted RPs cannot see world outside of onenet (not sure why they restrict network access like that). So to, e.g., install a new version of the DGS EPICS softIOC do<br /> <br /> ssh rpdgs@piserver<br /> svn export .....<br /> <br /> You will be in /home/rpdgs on piserver1 which is the shared home directory for all the RPs. Don't try to compile etc there. To compile, go to any of the network booted RPs and and do it from there. You only need to do it on one of the RPs because the home diretory is shared.<br /> <br /> . Because the RPs share the home directory we have set them up to execute unique setup files based on the IP of the RPs. E.g., on sbxpp the file (in the shared home directory) softIOC.192.168.203.149 is executed. In this file we can start the softIOC with the EPICS databases appropriate for this RP.<br /> <br /> . Note that the RPs get their IP from the onenet DHCP server, not from the piserver. Thus, you need to register the RPs using onereg.phy.anl.gov.<br /> <br /> . We have not been able to make autologon work on the network booted RPs. Thus to start the softIOC on the RPs you should, from an xterm, ssh into the individual RPs. We will automatically start the softIOC when you ssh in. Before the automtic start of the softIOC, it will check to make sure that a softIOC is not already running. If someone else ssh into the RP, another softIOC will not be started. This sustem is not unlike when we have to start the softIOC on the DAQs of dgs, dfma, dub1 and xa.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2430 2022-03-18T16:30:21Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 as user dgs and check whether the server is already running (try ps ax | grep piserver | grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the network booted raspberry pi's (RPs).<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window - where you can now enable it. Next, cycle the power of the RP again and it should come up as a client of the piserver. Be aware that it takes a while for the RP to boot up.<br /> <br /> . To modify the OS of the RPs, click on software in the piserver, then click on the OS. After that the 'shell' is awailable, clck on it. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs, the default user we have on the network booted RPs. (For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs). You shuld not have to use raspi-config on the individual RPs.<br /> <br /> . The network booted RPs cannot see world outside of onenet (not sure why they restrict network access like that). So to, e.g., install a new version of the DGS EPICS softIOC do<br /> <br /> ssh rpdgs@piserver<br /> svn export .....<br /> <br /> You will be in /home/rpdgs on piserver1 which is the shared home directory for all the RPs. Don't try to compile etc there. To compile, go to any of the network booted RPs and and do it from there. You only need to do it on one of the RPs because the home diretory is shared.<br /> <br /> . Because the RPs share the home directory we have set them up to execute unique setup files based on the IP of the RPs. E.g., on sbxpp the file (in the shared home directory) softIOC.192.168.203.149 is executed. In this file we can start the softIOC with the EPICS databases appropriate for this RP.<br /> <br /> . Note that the RPs get their IP from the onenet DHCP server, not from the piserver. Thus, you need to register the RPs using onereg.phy.anl.gov.<br /> <br /> . We have not been able to make autologon work on the network booted RPs. Thus to start the softIOC on the RPs you should, from an xterm, ssh into the individual RPs. We will automatically start the softIOC when you ssh in. Before the automtic start of the softIOC, it will check to make sure that a softIOC is not already running. If someone else ssh into the RP, another softIOC will not be started. This sustem is not unlike when we have to start the softIOC on the DAQs of dgs, dfma, dub1 and xa.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2429 2022-03-18T16:28:33Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 as user dgs and check whether the server is already running (try ps ax | grep piserver | grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the network booted raspberry pi's (RPs).<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window - where you can now enable it. Next, cycle the power of the RP again and it should come up as a client of the piserver. Be aware that it takes a while for the RP to boot up.<br /> <br /> . To modify the OS of the RPs, click on software in the piserver, then click on the OS. After that the 'shell' is awailable, clck on it. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs, the default user we have on the network booted RPs. (For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs). You shuld not have to use raspi-config on the individual RPs.<br /> <br /> . The network booted RPs cannot see world outside of onenet (not sure why they restrict network access like that). So to, e.g., install a new version of the DGS EPICS softIOC do<br /> <br /> ssh rpdgs@piserver<br /> svn export .....<br /> <br /> You will be in /home/rpdgs on piserver1 which is the shared home directory for all the RPs. Don't try to compile etc there. To compile, go to any of the network booted RPs and and do it from there. You only need to do it on one of the RPs because the home diretory is shared.<br /> <br /> . Because the RPs share the home directory we have set them up to execute unique setup files based on the IP of the RPs. E.g., on sbxpp the file (in the shared home directory) softIOC.192.168.203.149 is executed. In this file we can start the softIOC with the EPICS databases appropriate for this RP.<br /> <br /> . Note that the RPs get their IP from the onenet DHCP server, not from the piserver. Thus, you need to register the RPs using onereg.phy.anl.gov.<br /> <br /> . We have not been able to make autologon work on the network booted. Thus to start the softIOC on the RPs you should, from an xterm, ssh into the individual RPs. We will automatically start the softIOC when you ssh in. Before the automtic start of the softIOC, it will check to make sure that a softIOC is not already running. If someone else ssh into the RP, another softIOC will not be started.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2428 2022-03-18T16:17:53Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 as user dgs and check whether the server is already running (try ps ax | grep piserver| grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the RPs<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window where you can enable it. now cycle the power of the RP again and it should come up as a client of the piserver<br /> <br /> . To modify the OS of the RPs, click on software in the piserver and then click on the OS. After that the 'shell' is awailable. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs the default user we have on the network booted RPs. (For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs). You shuld not use raspi-config on the individual RPs.<br /> <br /> . The network booted RPs cannot see world outside of onenet (not sure why they restrict network access like that). So to e.g., install a new version of the DGS EPICS softIOC do<br /> <br /> ssh rpdgs@piserver<br /> svn export .....<br /> <br /> You will be in /home/rpdgs on piserver1 which is the shared home directory for all the RPs. Don't try to compile etc there. To compile, go to any of the network booted RPs and and do it from there. You only need to do it on one of the RPs because the home diretory is shared.<br /> <br /> . Because the RPs share the home directory we have set them up to execute unique setup files based on the IP of the RPs. E.g., on sbxpp the file (in the shared home directory) softIOC.192.168.203.149 is executed. In this file we can start the softIOC with the EPICS databases appropriate for this RP.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2427 2022-03-18T16:10:29Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 as user dgs and check whether the server is already running (try ps ax | grep piserver| grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the RPs<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window where you can enable it. now cycle the power of the RP again and it should come up as a client of the piserver<br /> <br /> . To modify the OS of the RPs, click on software in the piserver and then click on the OS. After that the 'shell' is awailable. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs the default user we have on the network booted RPs. (For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs). You shuld not use raspi-config on the individual RPs.<br /> <br /> . The network booted RPs cannot see world outside of onenet (not sure why they restrict network access like that). So to e.g., install a new version of the DGS EPICS softIOC do<br /> <br /> ssh rpdgs@piserver<br /> svn export .....<br /> <br /> You will be in /home/rpdgs which is the shared home directory for all the RPs. Don't try to compile there. To compile, go to any of the network booted RPs and and do it from there. You only need to do it on one of the RPs because the home diretory is shared.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2426 2022-03-18T15:22:46Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 and check whether the server is already running (try ps ax | grep piserver| grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> The piserver window will show up. In this window you can control the 'environment' of the RPs<br /> <br /> . To add another raspberry pi to be under the control of the piserver, click on the clients on the piserver, then click add. Power off RP your want to add, take out the SD card and power it up again. It should show up with its mac address in the window where you can enable it. now cycle the power of the RP again and it should come up as a client of the piserver<br /> <br /> . To modify the OS of the RPs, click on software in the piserver and then click on the OS. After that the 'shell' is awailable. E.g., to run raspi-config you would type<br /> <br /> SUDO_USER=dgs raspi-config<br /> <br /> where the first part signifies that we change something in the OS for user rpdgs the default user we have on the network booted RPs. For reasons we don't understand, we cannot use the user name 'pi' for a user on these RPs</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2425 2022-03-17T18:44:05Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 and check whether the server is already running (try ps ax | grep piserver| grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> . To add another raspberry pi to be under the control of the piserver,</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Expert_Documentation&diff=2424 2022-03-17T18:43:23Z

<p>Tlauritsen: </p> <hr /> <div>== [[ANL Digitizer Firmware for Experts]] ==<br /> This document presupposes that the reader is already familiar with the overall design of the firmware and associated terminology.<br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''<br /> <br /> == [[ piserver instructions]] ==<br /> <br /> . The piserver runs on the Ubuntu machine called piserver1. To start the server: log in on piserver1 and check wheter the server is already running (try ps ax | grep piserver| grep -v grep). If it is not and you want to start it, type<br /> <br /> sudo piserver &amp;<br /> <br /> . To add another raspberry pi to be under the control of the piserver,</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Typical_DGS_run_procedures&diff=2158 2021-08-31T21:13:29Z

<p>Tlauritsen: /* Calibrations for bin_dgs in GEBSort_nogeb */</p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> dfmadata/ <br /> dgsdata/<br /> xadata/<br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to /dk/fs2/dgs<br /> tar -zxvf dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> This creates the two directories: trackMain and GEBSort. Even though DGS does not<br /> need the tracking code, it is best to create it and make the links below<br /> <br /> # make links to the crmat files which we keep in trackMain<br /> # but are needed here as well for GEBSort<br /> #<br /> (cd GEBSort; rm GANIL_AGATA_crmat.dat; ln -s ../trackMain/GANIL_AGATA_crmat.dat GANIL_AGATA_crmat.dat)<br /> (cd GEBSort; rm GSI_AGATA_crmat.dat; ln -s ../trackMain/GSI_AGATA_crmat.dat GSI_AGATA_crmat.dat)<br /> (cd GEBSort; rm crmat.LINUX; ln -s ../trackMain/crmat.LINUX crmat.LINUX)<br /> <br /> This option does not create all the directories and script files you need.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directories in individual virtual screens<br /> and do:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> It is best to do that on another machine to not upset the receivers.<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> If you have the tape-station, you should also add these lines<br /> <br /> #------------------------------------------------------<br /> # Parameters for tape station/beta decay<br /> # At least one must be enabled for tape <br /> # station spectra to be generated.<br /> <br /> # beta-gamma coincidence window<br /> decay_station_bg -10 40<br /> <br /> # max time bt gammas in decay station 2D matrices<br /> decay_station_ggdt 20<br /> <br /> # gg decay time gate<br /> # the time window in which we see decays vrt to last tape move<br /> decay_station_gt1 10 617<br /> decay_station_gt2 620 892<br /> decay_station_gt3 1000 3000<br /> #------------------------------------------------------<br /> <br /> <br /> A number of extra 1D and 2D spectra will then be produced. If they are<br /> commented out, only the usual bin_dgs spectra will be produced.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code:<br /> <br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile first)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration (last parameter) will in this case be 1keV/ch.<br /> The second last parameter specifies the lowest channel the program will search for peaks in to avoid any noise and x-rays at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2150 2020-07-11T16:22:05Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receivers, do the following<br /> <br /> cd to where you want to compile the gtReceiverN programs<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here is an example of how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 (see http://gretina.lbl.gov/tools-etc/gebheaders for the official list of GEB header IDs) , and write the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it (much) easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. When the size of the file reaches this limit, the file is closed and another file is used.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> The only things the receiver does is to<br /> <br /> get the data from the IOC<br /> extract the timestamp from the data<br /> extract the lenght of the data<br /> extract the board ID<br /> <br /> After that, the receiver constructs a GEB header that has this form<br /> <br /> struct gebData {<br /> int type; /* type of data following */<br /> int length;<br /> long long timestamp;<br /> };<br /> <br /> Once constructed, the receiver writes this header to disk followed by the data it received from the IOC. Thus, the data is a series of GEB headers and data, also referred to as the headers and payloads. It is important to recognize that the receiver does not otherwise interpret the data! This makes the receiver simple, universal and fast. Interpretating the date is the task of GEBSort which acts on the data after the merging.<br /> The data is stored in individual files based in the channel ID. Thus, if four digitizers are serviced by one IOC, four files are opened. This make the merging of the data easier.<br /> <br /> These are the fields that the receiver relies on:<br /> <br /> board_id = ((hdr[0] &gt;&gt;= 4) &amp; 0xfff); bits:4...15<br /> <br /> packet_len = ((hdr[0] &gt;&gt;= 16) &amp; 0x000007ff); bits:16...26<br /> <br /> Geb.timestamp = (unsigned long long int) hdr[1];<br /> ulli1 = (unsigned long long int) (hdr[2] &amp; 0x0000ffff);<br /> ulli1 = (ulli1 &lt;&lt; 32);<br /> Geb.timestamp += ulli1;<br /> <br /> In the full data from the IOC that also contains the 0xaaaaaaaa, hdr[0|1|2] would be hdr[1|2|3] <br /> The board_id is also referred to as the &quot;USER PACKET DATA&quot; field and uniquely identifies the digitizer.<br /> <br /> NOTE: Please use gtReceiver4 for now. <br /> gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> To get the GEBMerge program,<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> To get the GEBSort program,<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2126 2020-05-30T16:22:07Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receivers, do the following<br /> <br /> cd to where you want to compile the gtReceiverN programs<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here is an example of how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 (see http://gretina.lbl.gov/tools-etc/gebheaders for the official list of GEB header IDs) , and write the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it (much) easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. When the size of the file reaches this limit, the file is closed and another file is used.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> The only things the receiver does is to<br /> <br /> get the data from the IOC<br /> extract the timestamp from the data<br /> extract the lenght of the data<br /> extract the board ID<br /> <br /> After that, the receiver constructs a GEB header that has this form<br /> <br /> struct gebData {<br /> int type; /* type of data following */<br /> int length;<br /> long long timestamp;<br /> };<br /> <br /> Once constructed, the receiver writes this header to disk followed by the data it received from the IOC. Thus, the data is a series of GEB headers and data, also referred to as the headers and payloads. It is important to recognize that the receiver does not otherwise interpret the data! This makes the receiver simple, universal and fast. Interpretating the date is the task of GEBSort which acts on the data after the merging.<br /> The data is stored in individual files based in the channel ID. Thus, if four digitizers are serviced by one IOC, four files are opened. This make the merging of the data easier.<br /> <br /> These are the fields that the receiver relies on:<br /> <br /> board_id = ((hdr[0] &gt;&gt;= 4) &amp; 0xfff); bits:4...15<br /> <br /> packet_len = ((hdr[0] &gt;&gt;= 16) &amp; 0x000007ff); bits:16...26<br /> <br /> Geb.timestamp = (unsigned long long int) hdr[1];<br /> ulli1 = (unsigned long long int) (hdr[2] &amp; 0x0000ffff);<br /> ulli1 = (ulli1 &lt;&lt; 32);<br /> Geb.timestamp += ulli1;<br /> <br /> In the full data from the IOC that also contains the 0xaaaaaaaa, hdr[0|1|2] would be hdr[1|2|3] <br /> The board_id is also referred to as the &quot;USER PACKET DATA&quot; field and uniquely identifies the digitizer.<br /> <br /> NOTE: Please use gtReceiver4 for now. <br /> gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> To get the GEBSort program,<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2125 2020-05-30T16:10:40Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receivers, do the following<br /> <br /> cd to where you want to compile the gtReceiverN programs<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here is an example of how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 (see http://gretina.lbl.gov/tools-etc/gebheaders for the official list of GEB header IDs) , and write the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it (much) easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. When the size of the file reaches this limit, the file is closed and another file is used.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> The only things the receiver does is to<br /> <br /> get the data from the IOC<br /> extract the timestamp from the data<br /> extract the lenght of the data<br /> extract the board ID<br /> <br /> After that, the receiver constructs a GEB header that has this form<br /> <br /> struct gebData {<br /> int type; /* type of data following */<br /> int length;<br /> long long timestamp;<br /> };<br /> <br /> Once constructed, the receiver writes this header to disk followed by the data it received from the IOC. Thus, the data is a series of GEB headers and data, also referred to as the headers and payloads. It is important to recognize that the receiver does not otherwise interpret the data! This makes the receiver simple, universal and fast. Interpretating the date is the task of GEBSort which acts on the data after the merging.<br /> The data is stored in individual files based in the channel ID. Thus, if four digitizers are serviced by one IOC, four files are opened. This make the merging of the data easier.<br /> <br /> These are the fields that the receiver relies on:<br /> <br /> board_id = ((hdr[0] &gt;&gt;= 4) &amp; 0xfff);<br /> <br /> packet_len = ((tmp &gt;&gt;= 16) &amp; 0x000007ff);<br /> <br /> Geb.timestamp = (unsigned long long int) hdr[1];<br /> ulli1 = (unsigned long long int) (hdr[2] &amp; 0x0000ffff);<br /> ulli1 = (ulli1 &lt;&lt; 32);<br /> Geb.timestamp += ulli1;<br /> <br /> The board_id is also referred to as the &quot;USER PACKET DATA&quot; field and uniquely identifies the digitizer.<br /> <br /> NOTE: Please use gtReceiver4 for now. <br /> gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> To get the GEBSort program,<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2123 2020-05-22T13:39:17Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receivers, do the following<br /> <br /> cd to where you want to compile the gtReceiverN programs<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here is an example of how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 (see http://gretina.lbl.gov/tools-etc/gebheaders for the official list of GEB header IDs) , and write the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it (much) easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. When the size of the file reaches this limit, the file is closed and another file is used.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> The only things the receiver does is to<br /> <br /> get the data from the IOC<br /> extract the timestamp from the data (header)<br /> extract the lenght of the data<br /> <br /> After that, the receiver constructs a GEB header that has this form<br /> <br /> struct gebData {<br /> int type; /* type of data following */<br /> int length;<br /> long long timestamp;<br /> };<br /> <br /> Once constructed, the receiver writes this header to disk followed by the data it received from the IOC. Thus, the data is a series of GEB headers and data, also referred to as the headers and payloads. It is important to recognize that the receiver does not otherwise interpret the data! This makes the receiver simple, universal and fast. Interpretating the date is the task of GEBSort which acts on the data after the merging.<br /> <br /> NOTE: Please use gtReceiver4 for now. <br /> gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> To get the GEBSort program,<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2122 2020-05-22T13:19:15Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receivers, do the following<br /> <br /> cd to where you want to compile the gtReceiverN programs<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here is an example of how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 (see http://gretina.lbl.gov/tools-etc/gebheaders for the official list of GEB header IDs) , and write the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it (much) easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. When the size of the file reaches this limit, the file is closed and another file is used.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> The only things the receiver does is to<br /> <br /> get the data from the IOC<br /> extract the timestamp from the data (header)<br /> extract the lenght of the data<br /> <br /> After that, the receiver constructs a GEB header that has this form<br /> <br /> struct gebData {<br /> int type; /* type of data following */<br /> int length;<br /> long long timestamp;<br /> };<br /> <br /> Once constructed, the receiver writes this header to disk followed by the data it received from the IOC. Thus, the data is a series of GEB headers and data, also referred to as the headers and payloads. It is important to recognize that the receiver does not otherwise interpret the data! This makes the receiver simple, universal and fast. Interpretating the date is the task of GEBSort which acts on the data after the merging.<br /> <br /> NOTE: Please use gtReceiver4 for now. <br /> gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2121 2020-05-22T13:14:47Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receivers, do the following<br /> <br /> cd to where you want to compile the gtReceiverN programs<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here are some examples on how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 (see http://gretina.lbl.gov/tools-etc/gebheaders for the official list of GEB header IDs) , and write the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it (much) easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. When the size of the file reaches this limit, the file is closed and another file is used.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> The only things the receiver does is to<br /> <br /> get the data from the IOC<br /> extract the timestamp from the data (header)<br /> extract the lenght of the data<br /> <br /> After that, the receiver constructs a GEB header that has this form<br /> <br /> struct gebData {<br /> int type; /* type of data following */<br /> int length;<br /> long long timestamp;<br /> };<br /> <br /> Once constructed, the receiver writes this header to disk followed by the data it received from the IOC. Thus, the data is a series of GEB headers and data, also referred to as the headers and payloads.<br /> <br /> It is important to recognize that the receiver does not otherwise interpret the data! This makes the receiver simple, universal and fast. Interpretating the date is done in GEBSort after the data is merged.<br /> <br /> NOTE: Please use gtReceiver4 for now. <br /> gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2120 2020-05-21T13:23:08Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver4==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receiver, do the following<br /> <br /> * cd to where you want to compile the gtReceiverN programs<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> <br /> * make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here are some examples on how to run the programs:<br /> <br /> +---- receiver program<br /> | +---- IP/name of IOC to receive from<br /> | | +---- data file name<br /> | | | +---- max size<br /> | | | | +---- GEB ID<br /> | | | | |<br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 as ID, and put the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> NOTE: use gtReceiver4. gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2119 2020-05-21T13:18:56Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver4==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receiver, do the following<br /> <br /> * cd to where you want to compile the gtReceiverN programs<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> <br /> * make -B<br /> <br /> That should generate the gtReceiver4 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here are some examples on how to run the programs:<br /> <br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> gtReceiver5 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 as ID, and put the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> NOTE: use gtReceiver4. gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2118 2020-01-22T22:06:47Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd gtreceiver; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = Acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save or runxx.info file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ calibration file is generated, <br /> <br /> run GEBSort again<br /> <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_eraw.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> To extract the calibrated spectra<br /> <br /> .x get_ecln.cc<br /> <br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Typical_DGS_run_procedures&diff=2117 2019-12-09T22:13:48Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> dfmadata/ <br /> dgsdata/<br /> xadata/<br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to /dk/fs2/dgs<br /> tar -zxvf dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> This creates the two directories: trackMain and GEBSort. Even though DGS does not<br /> need the tracking code, it is best to create it and make the links below<br /> <br /> # make links to the crmat files which we keep in trackMain<br /> # but are needed here as well for GEBSort<br /> #<br /> (cd GEBSort; rm GANIL_AGATA_crmat.dat; ln -s ../trackMain/GANIL_AGATA_crmat.dat GANIL_AGATA_crmat.dat)<br /> (cd GEBSort; rm GSI_AGATA_crmat.dat; ln -s ../trackMain/GSI_AGATA_crmat.dat GSI_AGATA_crmat.dat)<br /> (cd GEBSort; rm crmat.LINUX; ln -s ../trackMain/crmat.LINUX crmat.LINUX)<br /> <br /> This option does not create all the directories and script files you need.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directories in individual virtual screens<br /> and do:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> It is best to do that on another machine to not upset the receivers.<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> If you have the tape-station, you should also add these lines<br /> <br /> #------------------------------------------------------<br /> # Parameters for tape station/beta decay<br /> # At least one must be enabled for tape <br /> # station spectra to be generated.<br /> <br /> # beta-gamma coincidence window<br /> decay_station_bg -10 40<br /> <br /> # max time bt gammas in decay station 2D matrices<br /> decay_station_ggdt 20<br /> <br /> # gg decay time gate<br /> # the time window in which we see decays vrt to last tape move<br /> decay_station_gt1 10 617<br /> decay_station_gt2 620 892<br /> decay_station_gt3 1000 3000<br /> #------------------------------------------------------<br /> <br /> <br /> A number of extra 1D and 2D spectra will then be produced. If they are<br /> commented out, only the usual bin_dgs spectra will be produced.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code:<br /> <br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration will be 1keV/ch.<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Typical_DGS_run_procedures&diff=2116 2019-12-05T19:15:13Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> dfmadata/ <br /> dgsdata/<br /> xadata/<br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to /dk/fs2/dgs<br /> tar -zxvf dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> This creates the two directories: trackMain and GEBSort. Even though DGS does not<br /> need the tracking code, it is best to create it and make the links below<br /> <br /> # make links to the crmat files which we keep in trackMain<br /> # but are needed here as well for GEBSort<br /> #<br /> (cd GEBSort; rm GANIL_AGATA_crmat.dat; ln -s ../trackMain/GANIL_AGATA_crmat.dat GANIL_AGATA_crmat.dat)<br /> (cd GEBSort; rm GSI_AGATA_crmat.dat; ln -s ../trackMain/GSI_AGATA_crmat.dat GSI_AGATA_crmat.dat)<br /> (cd GEBSort; rm crmat.LINUX; ln -s ../trackMain/crmat.LINUX crmat.LINUX)<br /> <br /> This option does not create all the directories and script files you need.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directories in individual virtual screens<br /> and do:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> It is best to do that on another machine to not upset the receivers.<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> If you have the tape-station, you should also add these lines<br /> <br /> #------------------------------------------------------<br /> # parameters for tape station / beta decay<br /> # One or the other must be enabled for tape <br /> # station spectra to be generated.<br /> <br /> # beta-gamma coincidence window<br /> decay_station_bg -10 40<br /> # lo hi<br /> <br /> # gg_decay time gate<br /> # the time window in which we see decays vrt to last tape move<br /> decay_station_gt 620 1220<br /> # lo hi<br /> #------------------------------------------------------<br /> <br /> A number of extra 1D and 2D spectra will then be produced. If they are<br /> commented out, only the usual bin_dgs spectra will be produced.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code:<br /> <br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration will be 1keV/ch.<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Typical_DGS_run_procedures&diff=2115 2019-12-05T18:22:11Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> dfmadata/ <br /> dgsdata/<br /> xadata/<br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to /dk/fs2/dgs<br /> tar -zxvf dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> This creates the two directories: trackMain and GEBSort. Even though DGS does not<br /> need the tracking code, it is best to create it and make the links below<br /> <br /> # make links to the crmat files which we keep in trackMain<br /> # but are needed here as well for GEBSort<br /> #<br /> (cd GEBSort; rm GANIL_AGATA_crmat.dat; ln -s ../trackMain/GANIL_AGATA_crmat.dat GANIL_AGATA_crmat.dat)<br /> (cd GEBSort; rm GSI_AGATA_crmat.dat; ln -s ../trackMain/GSI_AGATA_crmat.dat GSI_AGATA_crmat.dat)<br /> (cd GEBSort; rm crmat.LINUX; ln -s ../trackMain/crmat.LINUX crmat.LINUX)<br /> <br /> This option does not create all the directories and script files you need.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directories in individual virtual screens<br /> and do:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> It is best to do that on another machine to not upset the receivers.<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> If you have the tape-station, you should also add these lines<br /> <br /> #------------------------------------------------------<br /> # parameters for tape station / beta decay<br /> # One or the other must be enabled for tape <br /> # station spectra to be generated.<br /> <br /> # beta-gamma coincidence window<br /> decay_station_bg -10 40<br /> # lo hi<br /> <br /> # gg_decay time gate<br /> # the time window in which we see decays vrt to last tape move<br /> decay_station_gt 620 1220<br /> # lo hi<br /> #------------------------------------------------------<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code:<br /> <br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration will be 1keV/ch.<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Main_Page&diff=2114 2019-12-05T18:12:11Z

<p>Tlauritsen: </p> <hr /> <div><br /> These are the wiki pages for the Digital and the analog Gammasphere Data Acquisition systems (GS DAQs). Procedures for running the DAQs and the data format will be documented here.<br /> <br /> The GS DAQ serves the Gammasphere detector array (http://www.phy.anl.gov/gammasphere/), located at the ATLAS accelerator (http://www.phy.anl.gov/atlas), home of the CAlifornium Rare Isotope Breeder Upgrade (CARIBU http://www.phy.anl.gov/atlas/caribu/).<br /> <br /> Contact mailto:torben@anl.gov for comments on, and write access to, these wiki pages<br /> <br /> ==Digital Gammasphere==<br /> <br /> o [[intro]]<br /> <br /> o [[typical DGS run procedures]]<br /> <br /> o [[receivers/GEBMerge/GEBsort]]<br /> <br /> o [[computers and networks]]<br /> <br /> o [[Raspberry Pi camera use]]<br /> <br /> o [[handeling removable disks under ESATA]]<br /> <br /> o [[triggers and digitizers]]<br /> <br /> o [[Digitizer Tester]]<br /> <br /> o [[The DGS/DFMA EPICS Implementation]]<br /> <br /> o [[data formats]]<br /> <br /> o [[analysis codes]]<br /> <br /> o [[list of experimental runs/analysis]]<br /> <br /> o [[some problems and their solutions]]<br /> <br /> o [[hint and kinks]]<br /> <br /> o [[firmware documentation]]<br /> <br /> o [[Tim Madden software documentation]]<br /> <br /> ==Analog Gammasphere==<br /> <br /> o [[Analog Gammasphere]]<br /> <br /> o [[LN system]]<br /> <br /> o [[JohnSandbox]]<br /> <br /> ==Experts Only==<br /> <br /> o [[Building the entire system]]<br /> <br /> o [[Linking Systems Together]]<br /> <br /> ==Hardware==<br /> <br /> * [[Attempts at Inventory]]<br /> * [https://wiki.anl.gov/wiki_gsdaq/images/4/40/MyRIAD_User_Manaual.pdf MyRIAD_User_Manaual]<br /> * [https://wiki.anl.gov/wiki_gsdaq/images/1/16/MyRIAD_Abridged_User_Notes.pdf MyRIAD_Abridged_User_Notes]<br /> * [[CrateAndBoardMapping]]<br /> <br /> ===Digitizer hardware features you probably don't know about===<br /> <br /> * The digitizer has a [[DAC output]].<br /> * The digitizer has a buffer amplifier that drives a copy of the analog signal going into channel 9 to outputs on the front panel. This is a simple analog buffer, no shaping, sampling or anything else.<br /> *<br /> <br /> ==contact list==<br /> <br /> Mike Carpenter, mailto:carpenter@anl.gov<br /> <br /> John Anderson, mailto:jta@anl.gov<br /> <br /> Michael Oberling, mailto:moberling@anl.gov<br /> <br /> Torben Lauritsen, mailto:torben@anl.gov<br /> <br /> Darek Seweryniak, mailto:seweryniak@anl.gov<br /> <br /> Pat Copp, mailto:copp@anl.gov<br /> <br /> Amel Korichi, mailto:korichi@csnsm.in2p3.fr<br /> <br /> <br /> {{Template:Standard Footer}}</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2086 2019-08-14T19:20:20Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = Acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save or runxx.info file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ calibration file is generated, <br /> <br /> run GEBSort again<br /> <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_eraw.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> To extract the calibrated spectra<br /> <br /> .x get_ecln.cc<br /> <br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2085 2019-08-14T16:53:55Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save or runxx.info file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ calibration file is generated, <br /> <br /> run GEBSort again<br /> <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_eraw.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> To extract the calibrated spectra<br /> <br /> .x get_ecln.cc<br /> <br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2084 2019-08-14T16:48:52Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save or runxx.info file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, <br /> <br /> run GEBSort again<br /> <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_eraw.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2083 2019-08-13T23:15:05Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2082 2019-08-13T11:44:20Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2081 2019-08-13T11:41:29Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> On less you know what you are doing, do not execute the caput commands<br /> in the .save file. <br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2080 2019-08-13T11:36:55Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2079 2019-08-13T11:35:11Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2078 2019-08-09T23:16:54Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2077 2019-08-05T19:50:56Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2076 2019-08-05T19:49:50Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd GEBSort; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part.<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2075 2019-07-31T17:14:53Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2070 2019-05-08T20:15:56Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to the onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The items in [] may not be needed. The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly.<br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser using thes URL:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in. The streamer leaves a lot of files which needs to be removed to make sure the raspberry pi is happy. Do<br /> <br /> rm /dev/shm/*<br /> <br /> =Configuration of the raspberry pi to use the streaming software=<br /> <br /> There seems to be a nice description at the URL:<br /> <br /> https://pimylifeup.com/raspberry-pi-webcam-server/<br /> <br /> though I haven't tried it. We also have have history log file from when Kalle installed the software.<br /> <br /> =Thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2069 2019-05-06T19:29:36Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to the onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The items in [] may not be needed. The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly.<br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser using thes URL:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =Configuration of the raspberry pi to use the streaming software=<br /> <br /> There seems to be a nice description at the URL:<br /> <br /> https://pimylifeup.com/raspberry-pi-webcam-server/<br /> <br /> though I haven't tried it. We also have have history log file from when Kalle installed the software.<br /> <br /> =Thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2068 2019-05-06T19:20:17Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to the onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser using thes URL:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> There seems to be a nice description at the URL:<br /> <br /> https://pimylifeup.com/raspberry-pi-webcam-server/<br /> <br /> though I haven't tried it. We also have have history log file from when Kalle installed the software.<br /> <br /> =Thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2067 2019-05-03T18:54:29Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code:<br /> <br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Receivers/GEBMerge/GEBsort&diff=2066 2019-05-01T18:09:37Z

<p>Tlauritsen: </p> <hr /> <div><br /> ==gtReceiver4==<br /> <br /> To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.<br /> <br /> To get the gtReceiverN receiver, do the following<br /> <br /> * cd to where you want to compile the gtReceiverN programs<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git<br /> <br /> * make clean<br /> <br /> * make<br /> <br /> That should generate the gtReceiver4 and gtReceiver5 programs as well as the outdated gtReceiver3 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here are some examples on how to run the programs:<br /> <br /> gtReceiver4 ioc1 data_run_001.gtd 2000000000 14<br /> gtReceiver5 ioc1 data_run_001.gtd 2000000000 14<br /> <br /> <br /> Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 as ID, and put the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines.<br /> <br /> The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.<br /> <br /> NOTE: use gtReceiver4. gtReceiver5 is reported to a have a problem.<br /> <br /> ==GEBMerge==<br /> <br /> GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also ''orders'' the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.<br /> <br /> You will use the program as<br /> <br /> GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....<br /> <br /> where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to ''outfile'' and ''file1 file2 file3 file4 .....'' is the list of files to merge.<br /> <br /> GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.<br /> <br /> ==GEBSort==<br /> <br /> GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages <br /> <br /> [https://wiki.anl.gov/gretina_at_anl/Operations#off-line_sorting_with_GEBSort.2C_to_a_root_file]<br /> <br /> ==Running GEBMerge and GEBSort in interactive mode==<br /> <br /> It is possible to merge data and look at the data on-line. The trick we apply is to not close an input file to GEBMerge or GEBSort right away when no more data is available. Instead, through the instructions<br /> <br /> waitfordata 300<br /> <br /> in both the chatfiles of GEBMerge and GEBSort, we instruct the programs to wait 300 seconds, or 5 minutes, before giving up merging or sorting data. Thus, the programs will merge and sort the data as it comes in and you can set GEBSort up to use a map-file to display the data so that you can update/display like we did for GSSort with the analog Gammasphere DAQ. Here is a reminder about how you set up a map-file with GEBSort. First you set up a root session where you will display the data. Keep this root session up.<br /> <br /> rootn.exe<br /> .L GSUtil.cc++<br /> sdummyload(200000000)<br /> <br /> that will tell you the start map address for the given size of the root map-file, in this case 200000000. Now, specify this map address, in this example: 0x9ef6e000, when you start GEBSort as<br /> <br /> ./GEBSort_nogeb \<br /> -input disk merged_data.gtd \<br /> -mapfile c1.map 200000000 0x9ef6e000 \<br /> -chat GEBSort.chat <br /> <br /> where 200000000 is the size of the map file you want and 0x9ef6e000 is the start map addess reported by sdummyload as describes above. Now you can go back into the display root sessiong above and load the mapfile<br /> <br /> sload(&quot;c1.map&quot;)<br /> <br /> Then you will do the usual:<br /> <br /> update()<br /> [display]<br /> <br /> update()<br /> [display]<br /> <br /> If the beam goes away for more than 5 minutes you will have to start the GEBMerge and GEBSort programs again (maybe by starting a new run). At the end of a run, you would kill all the receivers (as usual) and then you can<br /> <br /> pkill -9 GEBmerge<br /> pkill -9 GEBSort<br /> <br /> to stop the programs. In principle, you have now merged the data online and don't need to do that later.</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2065 2019-04-29T21:01:17Z

<p>Tlauritsen: /* To boot the raspberry pi up */</p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to the onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser using thes URL:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> TBD [have history log file]<br /> <br /> =Thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2064 2019-04-29T21:00:59Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser using thes URL:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> TBD [have history log file]<br /> <br /> =Thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2063 2019-04-29T20:59:43Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser as:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> TBD [have history log file]<br /> <br /> =Thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2062 2019-04-29T20:59:22Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> [connect monitor (HDMI)]<br /> [connect keyboard]<br /> [the wireless mouse should already be there]<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The pi user password is now the default DGS password, not the default pi one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser as:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> TBD [have history log file]<br /> <br /> =thanks=<br /> <br /> Thanx to Kalle for setting up this system</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2061 2019-04-29T17:00:16Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> connect monitor (HDMI)<br /> connect keyboard<br /> the wireless mouse should already be there<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> The pi user password is now the default DGS password, not the default one!!<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser as:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> TBD</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2060 2019-04-29T16:39:15Z

<p>Tlauritsen: </p> <hr /> <div><br /> =To boot the raspberry pi up=<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> connect monitor (HDMI)<br /> connect keyboard<br /> the wireless mouse should already be there<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> Booting it up with the cat6 cable attached, is the easiest way to make sure it comes up on onenet.<br /> On some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> =To use the raspberry pi camera to stream data=<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser as:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> =To configure the raspberry pi to use the streaming software do=<br /> <br /> TBD</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2059 2019-04-29T16:34:54Z

<p>Tlauritsen: </p> <hr /> <div><br /> To boot the raspberry pi up,<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> connect monitor (HDMI)<br /> connect keyboard<br /> the wireless mouse should already be there<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> on some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> To use the raspberry pi camera to stream data:<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser as:<br /> <br /> http://192.168.203.2:8081<br /> <br /> You will have to be on onenet to see the the video stream.<br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in<br /> <br /> To configure the raspberry pi to use the streaming software do<br /> <br /> TBD</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Raspberry_Pi_camera_use&diff=2058 2019-04-29T16:32:37Z

<p>Tlauritsen: Created page with &quot; To boot the raspberry pi up, connect cat6 cable to onenet switch (next to it) connect monitor (HDMI) connect keyboard the wireless mouse should already be there co...&quot;</p> <hr /> <div><br /> To boot the raspberry pi up,<br /> <br /> connect cat6 cable to onenet switch (next to it)<br /> connect monitor (HDMI)<br /> connect keyboard<br /> the wireless mouse should already be there<br /> connect the usb power plug<br /> <br /> It should then boot up and connect itself to onenet where it will have the IP<br /> <br /> 192.168.203.2<br /> <br /> on some machines it can also be reached as darekpi02 if DNS is set up properly<br /> <br /> <br /> <br /> To use the raspberry pi camera to stream data:<br /> <br /> sudo service motion stop<br /> ./motion -c motion-mmalcam-both.conf<br /> <br /> that should start a little webserver so that you can see the live stream from a web browser as:<br /> <br /> http://192.168.203.2:8081<br /> <br /> To configure the raspberry pi to use the streaming software do<br /> <br /> TBD<br /> <br /> <br /> When you want to stop the stream, simply type crtl-c in the window you started the stream in</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Main_Page&diff=2057 2019-04-29T16:22:39Z

<p>Tlauritsen: </p> <hr /> <div><br /> These are the wiki pages for the Digital and the analog Gammasphere Data Acquisition systems (GS DAQs). Procedures for running the DAQs and the data format will be documented here.<br /> <br /> The GS DAQ serves the Gammasphere detector array (http://www.phy.anl.gov/gammasphere/), located at the ATLAS accelerator (http://www.phy.anl.gov/atlas), home of the CAlifornium Rare Isotope Breeder Upgrade (CARIBU http://www.phy.anl.gov/atlas/caribu/).<br /> <br /> Contact mailto:torben@anl.gov for comments on, and write access to, these wiki pages<br /> <br /> ==Digital Gammasphere==<br /> <br /> o [[intro]]<br /> <br /> o [[typical DGS run procedures]]<br /> <br /> o [[receivers/GEBMerge/GEBsort]]<br /> <br /> o [[computers and networks]]<br /> <br /> o [[Raspberry Pi camera use]]<br /> <br /> o [[handeling removable disks under ESATA]]<br /> <br /> o [[triggers and digitizers]]<br /> <br /> o [[Digitizer Tester]]<br /> <br /> o [[The DGS/DFMA EPICS Implementation]]<br /> <br /> o [[data formats]]<br /> <br /> o [[analysis codes]]<br /> <br /> o [[list of experimental runs/analysis]]<br /> <br /> o [[some problems and their solutions]]<br /> <br /> o [[hint and kinks]]<br /> <br /> o [[firmware documentation]]<br /> <br /> o [[Tim Madden software documentation]]<br /> <br /> ==Analog Gammasphere==<br /> <br /> o [[Analog Gammasphere]]<br /> <br /> o [[LN system]]<br /> <br /> o [[JohnSandbox]]<br /> <br /> ==Experts Only==<br /> <br /> o [[Building the entire system]]<br /> <br /> ==Hardware==<br /> <br /> * [[Attempts at Inventory]]<br /> * [https://wiki.anl.gov/wiki_gsdaq/images/4/40/MyRIAD_User_Manaual.pdf MyRIAD_User_Manaual]<br /> * [https://wiki.anl.gov/wiki_gsdaq/images/1/16/MyRIAD_Abridged_User_Notes.pdf MyRIAD_Abridged_User_Notes]<br /> * [[CrateAndBoardMapping]]<br /> <br /> ===Digitizer hardware features you probably don't know about===<br /> <br /> * The digitizer has a [[DAC output]].<br /> * The digitizer has a buffer amplifier that drives a copy of the analog signal going into channel 9 to outputs on the front panel. This is a simple analog buffer, no shaping, sampling or anything else.<br /> *<br /> <br /> ==contact list==<br /> <br /> Mike Carpenter, mailto:carpenter@anl.gov<br /> <br /> John Anderson, mailto:jta@anl.gov<br /> <br /> Tim Madden, mailto:tmadden@aps.anl.gov<br /> <br /> Michael Oberling, mailto:moberling@anl.gov<br /> <br /> Shaofei Zhu, mailto:zhu@phy.anl.gov<br /> <br /> Torben Lauritsen, mailto:torben@anl.gov<br /> <br /> Calem Hoffman, mailto:crhoffman@phy.anl.gov<br /> <br /> mailto:seweryniak@anl.gov<br /> <br /> mailto:wilt@phy.anl.gov<br /> <br /> mailto:khoo@anl.gov<br /> <br /> Robert Janssens, mailto:janssens@anl.gov<br /> <br /> mailto:malbers@phy.anl.gov<br /> <br /> Amel Korichi, mailto:korichi@csnsm.in2p3.fr<br /> <br /> &gt;&gt; 'email all' link<br /> <br /> mailto:torben@anl.gov,carpenter@anl.gov,jta@anl.gov,tmadden@aps.anl.gov,moberling@anl.gov,zhu@phy.anl.gov,cjc@anl.gov,crhoffman@phy.anl.gov,seweryniak@anl.gov,malcorta@anl.gov,wilt@phy.anl.gov,khoo@anl.gov,janssens@anl.gov,malbers@phy.anl.gov,korichi@csnsm.in2p3.fr<br /> <br /> <br /> <br /> {{Template:Standard Footer}}</div>

Tlauritsen https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2017 2019-02-16T20:00:38Z

<p>Tlauritsen: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> <br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> <br /> = acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code:<br /> <br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 100 are the M and K values you find in the runxx.save file. Specify the values in 10 nsec units. In this case I saw these lines in the .save file:<br /> <br /> caput GLBL:DIG:d_window 0.06 <br /> caput GLBL:DIG:k_window 0.20 <br /> caput GLBL:DIG:m_window 3.50<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> caput GLBL:DIG:raw_data_window 0.32<br /> caput VME01:SDIG1:k0_window0 0.0<br /> caput VME01:SDIG1:k0_window1 0.0<br /> etc<br /> <br /> for the K value: sum up all the K and D values, in this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the K value also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and<br /> not in the listing above because the user cannot set it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units.<br /> The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ file is generated, remove the energy calibration file if there is one:<br /> <br /> rm dgs_ehi.cal<br /> <br /> so that the calibrations defaults to 0 and 1 for offset and gain and sort again <br /> using the new pz values that were extracted above. <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_ecln.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration will be 1keV/ch.<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''</div>

Tlauritsen