Updated FAQ (markdown)

2025-04-22 07:08:50 -04:00 · 2022-10-01 23:04:56 -04:00 · 2022-10-01 23:04:56 -04:00 · ca38670108
parent bfa80d73da
commit ca38670108
1 changed files with 1 additions and 1 deletions
--- a/FAQ.md
+++ b/FAQ.md
@ -8,4 +8,4 @@
 * **My data file is huge! How do I manage all of this data?** If your data file seems rather large, there are a few things to think about. First you can check the size of the outputed file against the size of the raw binary archive. If they are roughly the same size, it's just that each run has a very large amount of data. If you are actively running an experiment you may want to consider taking shorter runs so that the event-building for each run is faster. If they are not of comparable sizes, this means that the event builder is appending a bunch of extraneous data. Most commonly this occurs when the analysis option is used. If the size is untenable for the amount of storage available, several solutions exist. One can remove some of the data members from the analyzed structures, which reduces the size of each event written to disk. This is certainly possible for some experiments, such as FP only data sets where all of the SABRE data is extraneous. Alternatively, one can pipe the data to a larger external storage periodically. 
-* **ROOT throws a bunch of warnings about a dictionary when I open my output ROOT files. Is this an issue?** The answer is both yes and no. Our data is saved using a ROOT dictionary (see [ROOT's documentation](https://root.cern.ch/root/htmldoc/guides/users-guide/AddingaClass.html) on this for deep details), which allows us to save our custom data structures. This is very important for optimizing the data storage and workflow, but comes at the cost that we have to tell ROOT how to understand our data in some cases. If you are just looking to examine the file using something like a TBrowser, this is in general not an issue. Sometimes ROOT has strange behavior with `std::vector` objects, but generally one can still use the majority of the ROOT interpreter's functionality. However, if you want to use your own macro or compiled program, you will need to provide a copy of the dictionary to link against, as well as the appropriate header files to include. The event builder automatically generates a shared library for the dictionary for use in other programs and ROOT macros, and all of the data structures are found in the file `DataStructs.h`. 
+* **ROOT throws a bunch of warnings about a dictionary when I open my output ROOT files. Is this an issue?** The answer is both yes and no. Our data is saved using a ROOT dictionary (see [ROOT's documentation](https://root.cern/manual/io_custom_classes/) on this for deep details), which allows us to save our custom data structures. This is very important for optimizing the data storage and workflow, but comes at the cost that we have to tell ROOT how to understand our data in some cases. If you are just looking to examine the file using something like a TBrowser, this is in general not an issue. Sometimes ROOT has strange behavior with `std::vector` objects, but generally one can still use the majority of the ROOT interpreter's functionality. However, if you want to use your own macro or compiled program, you will need to provide a copy of the dictionary to link against, as well as the appropriate header files to include. The event builder automatically generates a shared library for the dictionary for use in other programs and ROOT macros, and all of the data structures are found in the file `DataStructs.h`.
`@ -8,4 +8,4 @@`

	* My data file is huge! How do I manage all of this data? If your data file seems rather large, there are a few things to think about. First you can check the size of the outputed file against the size of the raw binary archive. If they are roughly the same size, it's just that each run has a very large amount of data. If you are actively running an experiment you may want to consider taking shorter runs so that the event-building for each run is faster. If they are not of comparable sizes, this means that the event builder is appending a bunch of extraneous data. Most commonly this occurs when the analysis option is used. If the size is untenable for the amount of storage available, several solutions exist. One can remove some of the data members from the analyzed structures, which reduces the size of each event written to disk. This is certainly possible for some experiments, such as FP only data sets where all of the SABRE data is extraneous. Alternatively, one can pipe the data to a larger external storage periodically.	* My data file is huge! How do I manage all of this data? If your data file seems rather large, there are a few things to think about. First you can check the size of the outputed file against the size of the raw binary archive. If they are roughly the same size, it's just that each run has a very large amount of data. If you are actively running an experiment you may want to consider taking shorter runs so that the event-building for each run is faster. If they are not of comparable sizes, this means that the event builder is appending a bunch of extraneous data. Most commonly this occurs when the analysis option is used. If the size is untenable for the amount of storage available, several solutions exist. One can remove some of the data members from the analyzed structures, which reduces the size of each event written to disk. This is certainly possible for some experiments, such as FP only data sets where all of the SABRE data is extraneous. Alternatively, one can pipe the data to a larger external storage periodically.

	* ROOT throws a bunch of warnings about a dictionary when I open my output ROOT files. Is this an issue? The answer is both yes and no. Our data is saved using a ROOT dictionary (see [ROOT's documentation](https://root.cern.ch/root/htmldoc/guides/users-guide/AddingaClass.html) on this for deep details), which allows us to save our custom data structures. This is very important for optimizing the data storage and workflow, but comes at the cost that we have to tell ROOT how to understand our data in some cases. If you are just looking to examine the file using something like a TBrowser, this is in general not an issue. Sometimes ROOT has strange behavior with `std::vector` objects, but generally one can still use the majority of the ROOT interpreter's functionality. However, if you want to use your own macro or compiled program, you will need to provide a copy of the dictionary to link against, as well as the appropriate header files to include. The event builder automatically generates a shared library for the dictionary for use in other programs and ROOT macros, and all of the data structures are found in the file `DataStructs.h`.	* ROOT throws a bunch of warnings about a dictionary when I open my output ROOT files. Is this an issue? The answer is both yes and no. Our data is saved using a ROOT dictionary (see [ROOT's documentation](https://root.cern/manual/io_custom_classes/) on this for deep details), which allows us to save our custom data structures. This is very important for optimizing the data storage and workflow, but comes at the cost that we have to tell ROOT how to understand our data in some cases. If you are just looking to examine the file using something like a TBrowser, this is in general not an issue. Sometimes ROOT has strange behavior with `std::vector` objects, but generally one can still use the majority of the ROOT interpreter's functionality. However, if you want to use your own macro or compiled program, you will need to provide a copy of the dictionary to link against, as well as the appropriate header files to include. The event builder automatically generates a shared library for the dictionary for use in other programs and ROOT macros, and all of the data structures are found in the file `DataStructs.h`.