IAP GITLAB

Skip to content
Snippets Groups Projects
Commit 69caa383 authored by ralfulrich's avatar ralfulrich
Browse files

merge with master, include issue 109

parents 66cf1e75 9cbca6fc
No related branches found
No related tags found
1 merge request!42Resolve "missing rotation between corsika stack and sibyll stack"
Pipeline #132 failed
Stage: build
Hide whitespace changes
Inline Side-by-side
Showing
with 275 additions and 351 deletions
COLLABORATION_AGREEMENT.md
+ 2
− 2
View file @ 69caa383
......@@ -61,7 +61,7 @@ particular branch, but all official releases are normally performed
via the master branch.
If you want to contribute, you need to read
[GUIDELINES](GUIDELINES.md) and comply with these rules, or help to
[the GUIDELINES](CONTRIBUTING.md) and comply with these rules, or help to
improve them.
......@@ -69,7 +69,7 @@ improve them.
The CORSIKA Project panel makes all decisions for the CORSIKA
Project. It can also change the
[COLLABORATION\_AGREEMENT](COLLABORATION\_AGREEMENT.md), the
[GUIDELINES](GUIDELINES.md) or any other structure or document relevant for the CORSIKA Project.
[the GUIDELINES](CONTRIBUTING.md) or any other structure or document relevant for the CORSIKA Project.
The CORSIKA Project *panel* consists (October 2018) of
......
CONTRIBUTING.md
+ 117
− 216
View file @ 69caa383
# Contributing
The CORSIKA project is committed to fostering and preserving a
diverse, welcoming community; all participants are expected to
respect that.
- [Getting Started](#getting-started)
- [Very first steps](#very-first-steps)
- [Opening issues](#opening-issues)
- [Participating in discussions](#participating-in-discussions)
- [Improving and reviewing docs](#improving-and-reviewing-docs)
- [Reviewing and testing changes](#reviewing-and-testing-changes)
- [Proposing and making changes](#proposing-and-making-changes)
- [Finding something to work on](#finding-something-to-work-on)
- [Before you start](#before-you-start-work)
- [Before you open your PR](#before-you-open-your-pr)
- [Review process](#review-process)
- [Getting more involved](#getting-more-involved)
## Getting started
Not sure where to start? If you haven't already, take a look at the
[docs](http://xi-editor.github.io/xi-editor/docs.html) to get a better
sense of the project. Read through some issues and some open PRs, to
get a sense for the habits of existing contributors. Drop by the #xi
channel on [irc.mozilla.org](https://mozilla.logbot.info/xi) to follow
ongoing discussions or ask questions. Clone the repos you're
interested in, and make sure you can build and run the tests. If you
can't, open an issue, and someone will try to help. Once you're up and
running, there are a a number of ways to participate:
### Opening issues
If you have a question or a feature request or think you've found a bug,
please open an issue. When opening an issue, include any details that
might be relevant: for a bug this might be the steps required to
reproduce; for a feature request it might be a detailed explanation of
the behaviour you are imagining, an outline of how it would be used,
and/or examples of how this feature is used in other editors.
#### Before you open an issue
Before opening an issue, **try to identify where the issue belongs**.
Is it a problem with the frontend or with core? The frontend is
responsible for drawing windows and UI, and handling events; the core
is responsible for most everything else. Issues with the frontend
should be opened in that frontend's repository, and issues with
core should be opened in the
[xi-editor](https://github.com/xi-editor/xi-editor/issues) repo.
Finally, before opening an issue, **use github's search bar** to make
sure there isn't an existing (open or closed) issue for your particular
problem.
### Participating in discussions
An _explicit_ goal of xi-editor is to be an educational resource.
Everyone is encouraged to participate in discussion issues (issues with
the 'discussion' or 'planning' labels), and we expect people
participating in discussions to be respectful of the fact that we all
have different backgrounds and levels of experience. Similarly, if
something is confusing, feel free to ask for clarification! If you're
confused, other people probably are as well.
### Improving and reviewing docs
If the docs are unclear or incomplete, please open an issue or a PR to
improve them. This is an especially valuable form of feedback from new
contributors, who are seeing things for the first time, and will be best
positioned to identify areas that need improvement.
### Reviewing and testing changes
One of the best ways to get more familiar with the project is by reading
other people's pull requests. If there's something in a commit that you
don't understand, this is a great time to ask for clarification. Testing
changes is also very helpful, especially for bug fixes or feature
additions. Check out a change and try it out; does it work? Can you find
edge cases? Manual testing is very valuable. For more information on
reviews, see [code review process](#review-process).
## Proposing and making changes
### Finding something to work on
If you're looking for something to work on, a good first step is to browse
the [issues](https://github.com/xi-editor/xi-editor/issues). Specifically,
issues that are labeled
[help wanted](https://github.com/xi-editor/xi-editor/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) and/or
[easy](https://github.com/xi-editor/xi-editor/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy)
are good places to start. If you can't find anything there, feel free to ask
on IRC, or play around with the editor and try to identify something that
_you_ think is missing.
### Before you start work
Before starting to work on an issue, consider the following:
- _Is it a bugfix or small change?_ If you notice a small bug somewhere,
and you believe you have a fix, feel free to open a pull request directly.
- _Is it a feature?_ If you have an idea for a new editor feature that is
along the lines of something that already exists (for instance, adding a
new command to reverse the letters in a selected region) _consider_
opening a short issue beforehand, describing the feature you have in mind.
Other contributors might be able to identify possible issues or
refinements. This isn't _necessary_, but it might end up saving you work,
and it means you will get to close an issue when your PR gets merged,
which feels good.
- _Is it a major feature, affecting for instance the behaviour or appearance
of a frontend, or the API or architecture of core?_ Before working on a
large change, please open a discussion/proposal issue. This should describe
the problem you're trying to solve, and the approach you're considering;
think of this as a 'lite' version of Rust's
[RFC](https://github.com/rust-lang/rfcs) process.
### Before you open your PR
Before pressing the 'Create pull request' button,
- _Run the tests_. It's easy to accidentally break something with even a small
change, so always run the tests locally before submitting (or updating) a PR.
You can run all checks locally with the `xi-editor/rust/run_all_checks`. script.
- _Add a message for your reviewers_. When submitting a PR, take advantage
of the opportunity to include a message. Your goal here should be to help
your reviewers. Are there any parts of your change that you're uncertain
about? Are there any non-obvious explanations for some of your decisions?
If your change changes some behaviour, how might it be tested?
- ***Be your own first reviewer***. On the page where you enter your message,
you have a final opportunity to see your PR _as it will be seen by your
reviewers_. This is a great opportunity to give it one last review, yourself.
Imagine that it is someone else's work, that you're reviewing: what comments
would you have? If you spot a typo or a problem, you can push an update in
place, without losing your PR message or other state.
- _Add yourself to the AUTHORS file_. If this is your first substantive pull
request in this repo, feel free to add yourself to the AUTHORS file.
### Review process
Every non-trivial pull request goes through review. Everyone is welcome to
participate in review; review is an excellent time to ask questions about
code or design decisions that you don't understand.
All pull requests must be approved by an appropriate reviewer before they
are merged. For bug fixes and smaller changes, this can be anyone who has
commit rights to the repo in question; larger changes (changes which add a
feature, or significantly change behaviour or API) should also be approved by
a maintainer.
Before being merged, a change must pass
[CI](https://en.wikipedia.org/wiki/Continuous_integration).
#### Responsibilites of the approving reviewer
If you approve a change, it is expected that you:
- understand what the change is trying to do, and how it is doing it
- have manually built and tested the change, to verify it works as intended
- believe the change generally matches the idioms, formatting rules,
and overall coding style of the relevant repo
- are ready and able to help resolve any problems that may be introduced by
merging the change.
If a PR is made by a contributor who has write access to the repo in question,
they are responsible for merging/rebasing the PR after it has been approved;
otherwise it will be merged by the reviewer.
If a patch adds or modifies behaviour that is observable in the client,
the reviewer should build the patch and verify that it works as expected.
### After submitting your change
You've done all this, and submitted your patch. What now?
_Read other PRs_. If you're waiting for a review, it's likely that other
pull requests are waiting for review as well. This can be a good time
to go and take a look at what other work is happening in the project;
and if another PR has review comments, it might provide a clue to the
type of feedback you might expect.
_Patience_. As a general goal, we try to respond to all pull requests
within a few days, and to do preliminary review within a week, but we
don't always succeed. If you've opened a PR and haven't heard from
anyone, feel free to comment on it, or stop by the IRC channel, to ask
if anyone has had a chance to take a look. It's very possible that it's
been lost in the shuffle.
## Getting more involved
If you are participating in the xi-editor project, you may receive
additional privileges:
_Organization membership_: If you are regularly making contributions
to a xi project, in any of the forms outlined above, we will be happy to
add you to the xi-editor organization, which will give you the ability
to do things like add labels to issues and view active projects.
_Contributor_: If you are regularly making substantive contributions
to a specific xi project, we will be happy to add you as a contributor
to the repo in question. Contributors are encouraged to review and
approve changes, respond to issues, and generally help to maintain
the project in question.
_Maintainer_: If you are making substantive contributions to multiple
repos over an extended period, you are regularly reviewing the work of
other contributors, and you are actively participating in planning and
discussion, you may, (at the discretion of @raphlinus) be invited to
take on the role of _maintainer_. Maintainers are responsible for
coordinating the general direction of the project, resolving
architectural questions, and doing the day to day work of moving the
project forward.
# Guidelines for code development, structure, formating etc.
The CORSIKA Project very much welcomes contributions. Here we outlined
how you can find the right place to contribute, and how to do that.
Connect to http://gitlab.ikp.kit.edu and corsika-devel@lists.kit.edu
or corsika-project@lists.kit.edu to get in touch with the project.
The CORSIKA Project decides on the [GUIDELINES](CONTRIBUTING.md), and can
change them.
# How to contribute
- We organize all development via `Issues` that may be feature requests,
ideas, or bugs fix requests.
- New issues can be created, or existing issues
picked up.
- Issues are discussed in meetings or via corsika-devel@lists.kit.edu within the CORSIKA Project.
- Issues are assigned to milestones.
- The work on issues is performed in `branches` that can be best
created directly via the gitlab web interface.
- Proposed code to close one issue (located in a specific git
branch) is reviewed and eventually discussed, and finally merged
into the master branch to close the issue.
## Code formatting
We rely on `clang-format` for code formatting. This has the tremendous
advantage that definitely all code follows the same formatting rules,
and nobody at any point needs to invest time and effort into code
formatting. We provide a script `do-clang-format.sh`, which can be
very useful. But we urge everybody to integrate `clang-format` already
on the level of your source code editor. See [the official
page](https://clang.llvm.org/docs/ClangFormat.html) for information
about `clang-format` and its editor integration.
The definition of source code format is written down in the file
[.clang-format](.clang-format) and can be changed, if the CORSIKA
Project agrees on it. To see what is possible, check
e.g. [link1](https://clangformat.com/) or
[link2](https://zed0.co.uk/clang-format-configurator/).
## Naming conventions
While `clang-format` does the structural formatting, we still need to agree on naming conventions:
- Classes and structs start with capital letters
- Class member variables start with "f"
- Any static variable has a "g" prefix. A static member variable starts with "fg"
- Class member functions start with capital letters
- Any class getter begins with "Get", and setter with "Set"
- enums should be "enum class", and start with a capital "E", enum entries start with "e"
- We use namespaces to avoid clashes and to structure code
- *Everything* is part of the corsika namespace
- All classes and objects are encapsulated into suited sub-namespaces,
thus corsika::geometry, corsika::processes, corsika::units, etc.
- Namespace names do not use capital letters.
- Every header file is copied during build and install into
"include/corsika/[namespace]" which also means, each header file
can only provide definitions for a _single_ namespace. It is one
main purpose of namespaces to structure the location of header
files.
- Each header file uses an include protection that includes at
least the namespace name, and header file name, thus, `#ifndef
__include_geometry_Point_h__` or `#ifnedf __geometry_Point_h__`,
or similar are acceptable.
- Header files should always be included with `<..>`, thus,
`#include <corsika/geometry/Point.h>` since the build system
will always provide the correct include directives (and files
anyway cannot be found in file-system paths that typically do
not follow the namespace naming conventions outlined
here).
- Header files are named after the main class (or object) they
define. This also means each header file name starts with a
capital letter.
## Coding rules
- Code may not introduce any compiler errors, or warnings
- All unit tests must succeed at all times
- We use C++17 concepts wherever useful and helpful
- On any major error or malfunction we throw an exception. This is needed and required for complex physics and shower debugging.
- We never catch exceptions for error handling, there might be very few special exceptions from this. We need to discuss such cases.
- Everything that should not change should be `const`
- Everything that does not need to be visible to the outside of a class/struct should be `private` or `protected`
- We prefer the use of references, wherever useful
- There cannot be any pointer in the interface of any class or object
exposed to outside users, there might be pointers for very special cases
inside of classes.
- When you contribute new code, or extend existing code, at the same time provide unit-tests for all functionality.
- Code must be documented with `doxygen` commands
## Release versioning scheme
Releases of CORSIKA are thought to be the baseline for larger scale testing, and full production.
The releases are numbered as x.y.z, starting with x=8 form the gitlab c++ version. X will only be incremented
for major design or physics changes. The y index is updated for new official releases that normally contain improved or enhanced physics
performance, and may also contain normal interface changes to accomodate improvements. The z index can be updated frequently for
bug fixes or new features. Changes in z will not contain interface changes, thus, code will remain fully compatible.
Special releases of CORSIKA can also have a tag name from git, e.g. as in the "milestone1" release.
# How to become scientific author of the CORSIKA Project
The CORSIKA Project decides on who becomes scientific author. The
following conditions are clearly sufficient, but not all of them are
required all the time:
- responsibility for a particular functionality or part
- follows these [GUIDELINES](GUIDELINES.md)
- agrees to the [COLLABORATION_AGREEMENT](COLLABORATION_AGREEMENT.md)
- active in the CORSIKA Project, that means responsive to
discussions and problems in corsika-devel@list.kit.edu or on https//gitlab.ikp.kit.edu, of relevant *issues*,
or in (phone) meetings
- the members of the CORSIKA Project panel agree
Documentation/Examples/CMakeLists.txt
+ 1
− 0
View file @ 69caa383
......@@ -28,6 +28,7 @@ target_link_libraries (cascade_example SuperStupidStack CORSIKAunits CORSIKAlogg
ProcessSibyll
CORSIKAcascade
ProcessStackInspector
ProcessTrackWriter
CORSIKAprocesses
CORSIKAparticles
CORSIKAgeometry
......
Documentation/Examples/cascade_example.cc
+ 6
− 4
View file @ 69caa383
......@@ -25,6 +25,8 @@
#include <corsika/process/sibyll/Decay.h>
#include <corsika/process/sibyll/Interaction.h>
#include <corsika/process/track_writer/TrackWriter.h>
#include <corsika/units/PhysicalUnits.h>
#include <corsika/random/RNGManager.h>
......@@ -195,7 +197,6 @@ public:
// The example main program for a particle cascade
//
int main() {
// initialize random number sequence(s)
corsika::random::RNGManager::GetInstance().RegisterRandomStream("cascade");
......@@ -225,9 +226,10 @@ int main() {
corsika::process::sibyll::Interaction sibyll;
corsika::process::sibyll::Decay decay;
ProcessCut cut(8_GeV);
corsika::process::TrackWriter::TrackWriter trackWriter("tracks.dat");
// assemble all processes into an ordered process list
auto sequence = p0 << sibyll << decay << cut;
auto sequence = p0 << sibyll << decay << cut << trackWriter;
// cout << "decltype(sequence)=" << type_id_with_cvr<decltype(sequence)>().pretty_name()
// << "\n";
......@@ -235,7 +237,7 @@ int main() {
// setup particle stack, and add primary particle
setup::Stack stack;
stack.Clear();
const hep::EnergyType E0 = 8_TeV;
const hep::EnergyType E0 = 10_TeV;
double theta = 45.;
double phi = 20.;
{
......@@ -254,7 +256,7 @@ int main() {
particle.SetEnergy(E0);
particle.SetMomentum(plab);
particle.SetTime(0_ns);
Point p(rootCS, 0_m, 0_m, 10_km);
Point p(rootCS, 0_m, 0_m, 0_m);
particle.SetPosition(p);
cout << particle.GetEnergy() / 1_GeV << endl;
}
......
Environment/IMediumModel.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_IMediumModel_h
#define _include_IMediumModel_h
......
Environment/NuclearComposition.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_NuclearComposition_h
#define _include_NuclearComposition_h
......
Framework/Cascade/Cascade.h
+ 12
− 12
View file @ 69caa383
......@@ -57,13 +57,7 @@ namespace corsika::cascade {
}
void Step(Particle& particle) {
using namespace corsika::units::si;
using std::cout;
using std::endl;
using std::log;
cout << particle.GetEnergy() / 1_GeV << endl;
// determine geometric tracking
corsika::setup::Trajectory step = fTracking.GetTrack(particle);
......@@ -80,11 +74,15 @@ namespace corsika::cascade {
<< ", next_interact=" << next_interact << std::endl;
// convert next_step from grammage to length
auto const* currentNode =
fEnvironment.GetUniverse()->GetContainingNode(particle.GetPosition());
if (currentNode == &*fEnvironment.GetUniverse()) {
throw std::runtime_error("particle entered void universe");
}
LengthType const distance_interact =
fEnvironment.GetUniverse()
->GetContainingNode(particle.GetPosition())
->GetModelProperties()
.ArclengthFromGrammage(step, next_interact);
currentNode->GetModelProperties().ArclengthFromGrammage(step, next_interact);
// determine the maximum geometric step length
LengthType const distance_max = fProcessSequence.MaxStepLength(particle, step);
......@@ -116,6 +114,8 @@ namespace corsika::cascade {
particle.SetPosition(step.PositionFromArclength(min_distance));
// .... also update time, momentum, direction, ...
step.LimitEndTo(min_distance);
// apply all continuous processes on particle + track
corsika::process::EProcessReturn status =
fProcessSequence.DoContinuous(particle, step, fStack);
......@@ -127,11 +127,11 @@ namespace corsika::cascade {
return;
}
std::cout << "sth. happening before geometric limit ?"
std::cout << "sth. happening before geometric limit ? "
<< ((min_distance < distance_max) ? "yes" : "no") << std::endl;
if (min_distance < distance_max) { // interaction to happen within geometric limit
// check weather decay or interaction limits this step
// check whether decay or interaction limits this step
if (min_distance == distance_interact) {
std::cout << "collide" << std::endl;
......
Framework/Geometry/RootCoordinateSystem.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_corsika_geometry_rootcoordinatesystem_h_
#define _include_corsika_geometry_rootcoordinatesystem_h_
......
Framework/Geometry/Trajectory.h
+ 4
− 0
View file @ 69caa383
......@@ -43,6 +43,10 @@ namespace corsika::geometry {
assert(t >= 0 * corsika::units::si::second);
return T::ArcLength(0, t);
}
void LimitEndTo(corsika::units::si::LengthType limit) {
fTimeLength = T::TimeFromArclength(limit);
}
};
} // namespace corsika::geometry
......
Framework/Geometry/Volume.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_VOLUME_H_
#define _include_VOLUME_H_
......
Framework/Random/UniformRealDistribution.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_random_distributions_h
#define _include_random_distributions_h
......
Framework/Utilities/Bit.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _corsika_utl_Bit_h_
#define _corsika_utl_Bit_h_
......
Framework/Utilities/Singleton.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _corsika_utl_Singleton_h_
#define _corsika_utl_Singleton_h_
......
GUIDELINES.md deleted 100644 → 0
+ 0
− 117
View file @ 66cf1e75
# Guidelines for code development, structure, formating etc.
The CORSIKA Project very much welcomes contributions. Here we outlined
how you can find the right place to contribute, and how to do that.
Connect to http://gitlab.ikp.kit.edu and corsika-devel@lists.kit.edu
or corsika-project@lists.kit.edu to get in touch with the project.
The CORSIKA Project decides on the [GUIDELINES](GUIDELINES.md), and can
change them.
# How to contribute
- We organize all development via `Issues` that may be feature requests,
ideas, or bugs fix requests.
- New issues can be created, or existing issues
picked up.
- Issues are discussed in meetings or via corsika-devel@lists.kit.edu within the CORSIKA Project.
- Issues are assigned to milestones.
- The work on issues is performed in `branches` that can be best
created directly via the gitlab web interface.
- Proposed code to close one issue (located in a specific git
branch) is reviewed and eventually discussed, and finally merged
into the master branch to close the issue.
## Code formatting
We rely on `clang-format` for code formatting. This has the tremendous
advantage that definitely all code follows the same formatting rules,
and nobody at any point needs to invest time and effort into code
formatting. We provide a script `do-clang-format.sh`, which can be
very useful. But we urge everybody to integrate `clang-format` already
on the level of your source code editor. See [the official
page](https://clang.llvm.org/docs/ClangFormat.html) for information
about `clang-format` and its editor integration.
The definition of source code format is written down in the file
[.clang-format](.clang-format) and can be changed, if the CORSIKA
Project agrees on it. To see what is possible, check
e.g. [link1](https://clangformat.com/) or
[link2](https://zed0.co.uk/clang-format-configurator/).
## Naming conventions
While `clang-format` does the structural formatting, we still need to agree on naming conventions:
- Classes and structs start with capital letters
- Class member variables start with "f"
- Any static variable has a "g" prefix. A static member variable starts with "fg"
- Class member functions start with capital letters
- Any class getter begins with "Get", and setter with "Set"
- enums should be "enum class", and start with a capital "E", enum entries start with "e"
- We use namespaces to avoid clashes and to structure code
- *Everything* is part of the corsika namespace
- All classes and objects are encapsulated into suited sub-namespaces,
thus corsika::geometry, corsika::processes, corsika::units, etc.
- Namespace names do not use capital letters.
- Every header file is copied during build and install into
"include/corsika/[namespace]" which also means, each header file
can only provide definitions for a _single_ namespace. It is one
main purpose of namespaces to structure the location of header
files.
- Each header file uses an include protection that includes at
least the namespace name, and header file name, thus, `#ifndef
__include_geometry_Point_h__` or `#ifnedf __geometry_Point_h__`,
or similar are acceptable.
- Header files should always be included with `<..>`, thus,
`#include <corsika/geometry/Point.h>` since the build system
will always provide the correct include directives (and files
anyway cannot be found in file-system paths that typically do
not follow the namespace naming conventions outlined
here).
- Header files are named after the main class (or object) they
define. This also means each header file name starts with a
capital letter.
## Coding rules
- Code may not introduce any compiler errors, or warnings
- All unit tests must succeed at all times
- We use C++17 concepts wherever useful and helpful
- On any major error or malfunction we throw an exception. This is needed and required for complex physics and shower debugging.
- We never catch exceptions for error handling, there might be very few special exceptions from this. We need to discuss such cases.
- Everything that should not change should be `const`
- Everything that does not need to be visible to the outside of a class/struct should be `private` or `protected`
- We prefer the use of references, wherever useful
- There cannot be any pointer in the interface of any class or object
exposed to outside users, there might be pointers for very special cases
inside of classes.
- When you contribute new code, or extend existing code, at the same time provide unit-tests for all functionality.
- Code must be documented with `doxygen` commands
## Release versioning scheme
Releases of CORSIKA are thought to be the baseline for larger scale testing, and full production.
The releases are numbered as x.y.z, starting with x=8 form the gitlab c++ version. X will only be incremented
for major design or physics changes. The y index is updated for new official releases that normally contain improved or enhanced physics
performance, and may also contain normal interface changes to accomodate improvements. The z index can be updated frequently for
bug fixes or new features. Changes in z will not contain interface changes, thus, code will remain fully compatible.
Special releases of CORSIKA can also have a tag name from git, e.g. as in the "milestone1" release.
# How to become scientific author of the CORSIKA Project
The CORSIKA Project decides on who becomes scientific author. The
following conditions are clearly sufficient, but not all of them are
required all the time:
- responsibility for a particular functionality or part
- follows these [GUIDELINES](GUIDELINES.md)
- agrees to the [COLLABORATION_AGREEMENT](COLLABORATION_AGREEMENT.md)
- active in the CORSIKA Project, that means responsive to
discussions and problems in corsika-devel@list.kit.edu or on https//gitlab.ikp.kit.edu, of relevant *issues*,
or in (phone) meetings
- the members of the CORSIKA Project panel agree
Processes/CMakeLists.txt
+ 1
− 0
View file @ 69caa383
......@@ -2,6 +2,7 @@
add_subdirectory (NullModel)
add_subdirectory (Sibyll)
add_subdirectory (StackInspector)
add_subdirectory (TrackWriter)
add_subdirectory (TrackingLine)
#add_custom_target(CORSIKAprocesses)
......
Processes/Sibyll/Decay.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_corsika_process_sibyll_decay_h_
#define _include_corsika_process_sibyll_decay_h_
......
Processes/Sibyll/Interaction.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _corsika_process_sibyll_interaction_h_
#define _corsika_process_sibyll_interaction_h_
......
Processes/Sibyll/SibStack.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_sibstack_h_
#define _include_sibstack_h_
......
Processes/Sibyll/sibyll2.3c.cc
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#include <corsika/process/sibyll/sibyll2.3c.h>
#include <corsika/random/RNGManager.h>
......
Processes/Sibyll/sibyll2.3c.h
+ 11
− 0
View file @ 69caa383
/**
* (c) Copyright 2018 CORSIKA Project, corsika-project@lists.kit.edu
*
* See file AUTHORS for a list of contributors.
*
* This software is distributed under the terms of the GNU General Public
* Licence version 3 (GPL Version 3). See file LICENSE for a full version of
* the license.
*/
#ifndef _include_sib23c_interface_h_
#define _include_sib23c_interface_h_
//----------------------------------------------
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

data privacy - impressum