Update docs/howto/full_simulation.rst

docs/howto/full_simulation.rst

@@ -103,4 +103,36 @@ One can use dd_web_display to actually just save root geometry
 
 .. code:: bash
 
-    dd_web_display --export athena.xml  # will create a .root file with the geometry
\ No newline at end of file
+    dd_web_display --export athena.xml  # will create a .root file with the geometry
+
+
+FAQ
+---
+
+> How does the XML file in the compact directory know which c++ file to load when we include the respective XML file in the main athena.xml file? 
+
+1. Xml compact files has `<detector ...></detector>` tag which has `type` attribute that tells which C++ type to use: 
+
+   .. code:: xml
+
+        <detector id="ForwardRICH_ID" name="DRICH" type="athena_DRICH" ... >
+
+2. C++ file usually has `createDetector(...)` function and `DECLARE_DETELEMENT` macro which binds the function to the name used in xml `<detector>` type attribute. C++ code looks like this:
+
+   .. code:: c++ 
+
+       static Ref_t createDetector(Detector& desc, xml::Handle_t handle, SensitiveDetector sens) {
+           // ...
+       }
+
+       DECLARE_DETELEMENT(athena_DRICH, createDetector)
+
+3. How DD4Hep finds and loads compiled components? 
+
+   > This is going into technical details which users usually don't need. Installation paths and environment variables are set by container/spack and should work out of the box. 
+
+   DD4Hep uses modular plugin mechanism to load C++ code. When athena C++ is compiled, two files are created:
+   - `athena.components` - a text file stating what components one can find in athena.so. From our example, there will be a record like `v2:libathena.so:athena_DRICH` among other records. 
+   - `libathena.so` - compiled C++ library with all detectors from athena repo
+
+   So when the type of the detector is given, like `athena_DRICH`. DD4Hep uses `LD_LIBRARY_PATH` to look through .components files and then figures out what .so file to load to get the correct C++ code executed.