diff --git a/README.md b/README.md index 1cccb2d4..be5d5d38 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@

-k4MarlinWrapper runs [Marlin](https://github.com/iLCSoft/Marlin) procesors as [Gaudi](https://gitlab.cern.ch/gaudi/Gaudi) algorithms. +k4MarlinWrapper runs [Marlin](https://github.com/iLCSoft/Marlin) processors as [Gaudi](https://gitlab.cern.ch/gaudi/Gaudi) algorithms. It provides the necessary converters and interfaces between the file types and formats used between both frameworks: - Python interface to configure Marlin processors - In-memory Event Data Model (EDM) converters between [LCIO](https://github.com/iLCSoft/LCIO) and [EDM4hep](https://github.com/key4hep/EDM4hep) diff --git a/doc/MarlinWrapperIntroduction.md b/doc/MarlinWrapperIntroduction.md index 79228db0..c48f8165 100644 --- a/doc/MarlinWrapperIntroduction.md +++ b/doc/MarlinWrapperIntroduction.md @@ -123,7 +123,7 @@ convertMarlinSteeringToGaudi.py ### Limitations This converter script handles almost everything, but there are a few short-comings which it cannot yet handle: -- Marlin XML steering files can have `include` statments, e.g. ``. These cannot be resolved by the converter script, and it will issue a warning. The easiest way to fix this is to simply run `Marlin -n` to resolve all these statements and then run the converter @@ -190,7 +190,7 @@ give them meaningful names in order to avoid any confusion. ### Configuration options By default each converter tool will try to convert the complete event content -that is currently availble in the transient event store for the corresponding +that is currently available in the transient event store for the corresponding source format. **It will skip the conversion of a collection if the same collection already exists in the other format. This check is done by collection name.** However, it is possible to control the conversion process with a diff --git a/doc/starterkit/k4MarlinWrapperCLIC/CEDViaWrapper.md b/doc/starterkit/k4MarlinWrapperCLIC/CEDViaWrapper.md index f890e4d3..fb327716 100644 --- a/doc/starterkit/k4MarlinWrapperCLIC/CEDViaWrapper.md +++ b/doc/starterkit/k4MarlinWrapperCLIC/CEDViaWrapper.md @@ -27,12 +27,12 @@ The following steps have been tested with the Key4hep nightly builds release whi source /cvmfs/sw-nightlies.hsf.org/key4hep/setup.sh ``` -To get the CLIC detecor description we clone the `CLICPerformance` repository +To get the CLIC detector description we clone the `CLICPerformance` repository ```bash git clone https://github.com/iLCSoft/CLICPerformance ``` -All the following steps assume that the environment is setup like above and that the detector description is in the `CLICPerformance` directory. All commands start from the diretory from which `git clone` has been executed. +All the following steps assume that the environment is setup like above and that the detector description is in the `CLICPerformance` directory. All commands start from the directory from which `git clone` has been executed. ## Creating an input file @@ -51,7 +51,7 @@ ddsim --steeringFile CLICPerformance/clicConfig/clic_steer.py \ You should now have a `gamma_10GeV_edm4hep.root` file containing 10 events. -## Runing the event display +## Running the event display In order to run the event display via the `DDCEDViewer` we use the Marlin wrapper and attach an EDM4hep to LCIO converter to the wrapped processor. In the following we will build the complete Gaudi options file step by step. Here we simply present the most important steps, but do not go over all details of the `DDCEDViewer` configuration, for that it is probably best to directly look at the [CEDViewer repository](https://github.com/iLCSoft/CEDViewer) directly. The complete Gaudi configuration can be found in [`k4MarlinWrapper/examples/event_display.py`](https://github.com/key4hep/k4MarlinWrapper/blob/master/k4MarlinWrapper/examples/event_display.py) which is also installed at `$K4MARLINWRAPPER/examples/event_display.py` @@ -131,8 +131,8 @@ k4run $K4MARLINWRAPPER/examples/event_display.py --EventDataSvc.input=gamma_10Ge The `event_display.py` options file that is used above and that is present in the examples has been produced following these steps: - Using an `.slcio` input file and the desired geometry, run `ced2go` with the desired arguments. - - This produces a Marlin xml steering file on the fly and stores it at `/tmp/ced2go_${USER}_steering.xml` -- Using the `convertMarlinSteeringToGaudi.py` converter script convert this into a gaudi options file + - This produces a Marlin XML steering file on the fly and stores it at `/tmp/ced2go_${USER}_steering.xml` +- Using the `convertMarlinSteeringToGaudi.py` converter script convert this into a Gaudi options file - Exchange the LCIO input reading by the podio input reading (see above) - Attach the `EDM4hep2LcioTool` to the wrapped `CEDViewer` processor diff --git a/doc/starterkit/k4MarlinWrapperCLIC/howtoMultithread.md b/doc/starterkit/k4MarlinWrapperCLIC/howtoMultithread.md index b7e6cf06..5335ce6e 100644 --- a/doc/starterkit/k4MarlinWrapperCLIC/howtoMultithread.md +++ b/doc/starterkit/k4MarlinWrapperCLIC/howtoMultithread.md @@ -40,7 +40,7 @@ Gaudi exposes two main levels of parallelism: - Inter-event parallelism: running multiple events in parallel - Intra-event parallelism: running multiple algorithms in parallel, within an event -The two levels of parallelims can be combined: events can run in parallel, and algorithms within the events can run in parallel. +The two levels of parallelism can be combined: events can run in parallel, and algorithms within the events can run in parallel. ### How to run with inter-event parallelism @@ -50,7 +50,7 @@ The following components are used to achieve parallelism: from Configurables import (HiveWhiteBoard, HiveSlimEventLoopMgr, AvalancheSchedulerSvc) ``` -These 3 components need to be configued to adapt the level of parallelism to the sequence, algorithms and hardware to be used. +These 3 components need to be configured to adapt the level of parallelism to the sequence, algorithms and hardware to be used. - Event Data Service: `HiveWhiteBoard` + *EventSlots*: Number of events that may run in parallel, each with its own EventStore