Bug fix release

Fix of issue #127, now optical photons will cause hits on photocathode surfaces in the correct way.

Bug fix release

This release fixes issue #133 and increases multithreading stability in setting beam/target class.

Bug fix release

For recent enough Geant4 (>= 4.10.03-p01) variable input is now always done in double precision. This ensures that issue #130 is resolved and that setting variables with units to their default values using a macro does not differ from mere default running.

Bug fix release

Single thread only for external generator, fixes for tar ball creation

Bug fix release

Fixed units in external generator.

Bug fix release

This changes the macros to use the proper geometry in the geometry folder.

Bug fix release

Issue #92 is fixed in this release.

Small bug fixes that were made to master from develop

I suspect the fixes went directly into master instead of develop by accident. Some were little bug fixes (related to geometry locations and crashes when sorting). All is in develop too, though :-)

New IO, pion detector, spin tracking

This v2 version is macro API and output file incompatible with the v1 versions. Although that may sound bad, there's not too many changes :-)

As a reminder, I'm appending the semantic versioning scheme and organized branching model.

Released versions will have a version number vX.Y.Z where:

• Major revision X is incremented whenever the macro API changes, i.e. changes in behavior of existing messenger commands or changes to existing fields in the output ROOT trees. With these changes, users should expect that their remoll macros and analysis macros may not work. Note that the addition of messenger commands and the addition of output variables is backwards compatible and does not require an update to the major revision number.
• Minor revision Y is incremented whenever there are substantial feature changes, such as a substantial change in geometry, addition of an event generator, etc.
• Patch revision Z is incremented whenever there is a bug fix that can't wait until the next release (e.g. event generator is throwing pions when you thought it was throwing electrons).

The released versions will have reasonable default settings to ensure reasonable running time. This means no optical photon simulations and no large shower simulations. The experimental configuration in released version will be set, by default, to the MOLLER default running mode: electron-electron scattering with detectors in parity-mode locations. A set of benchmark simulations will be automatically run on every released version. If you are merely interested in running simulations, not in developing them, you should only ever need a released version.

The branching model will change slightly to be closer to the model described in A successful Git branching model, and graphically summarized below:

This model will allow for keeping the master branch stable and reliable, while giving feature branches a path towards integration and release into the master branch. There's no expectation that you will read the document above, though it may help you understand the philosophy behind it. Some of the conventions in the model description (e.g. branch naming, fast-forward avoidance) are not at the core of what we are trying to achieve, so they will not be enforced.

The master branch will reflect the latest released version. Thus, a git clone of the repository will always give you a sensible starting point for simulations, and no breakage should typically be expected when doing a git pull (only exceptions are major revision changes). It speaks for itself that code in master must always compile and run without issues. Issues should be raised and bugs will be fixed promptly by creating hotfix branches (i.e. not by committing changes directly into master).

A new develop branch will reflect the most up-to-date integrated code from feature branches and continuous development. Periodically, feature branches will be merged back into develop, from where they will be merged into a release-vX.Y.Z branch, and finally into master. Code in develop should compile and run without issues, but stability of APIs is not always to be expected. It serves mainly as a mechanism for code integration.

Bugfix release, fixes #52

Merge pull request #56 from JeffersonLab/hotfix-random-seed

Hotfix random seed