Knödlseder JürgenUpdated almost 10 years ago by
This page summarizes ctools benchmarks that may give the user some guidance on how to organize his science analysis.
The following benchmark has been performed using the benchmark_cta_analysis.py script in the ctools examples folder. The script compares the CPU time need for executing an unbinned, a binned and a cube-style analysis pipeline, comprising event simulation, event selection or binning, exposure and PSF cube preparation for cube-style analysis, and maximum likelihood fitting. A single CTA pointing has been considered with a total observation duration that varied between 0.5 and 256 hours. The model comprised the Crab as the only point source on top of a radial acceptance background model. Free parameters were the Prefactor and spectral index of the Crab spectrum, as well as the sigma parameter and the Prefactor and spectral index of the background model. For binned and cube-style analysis, a cube of 200x200x20 bins was used with a spatial binning of 0.02 deg. The energy range for all analyses covered 0.1-100 TeV.
Results are shown below. The left plot has been obtained on a MacBook Pro (2.66 GHz Intel Core i7, 4 GB, OS 10.6), the right plot on a Dell PowerEdge R815 (2.20 GHz AMD Opteron 6174 12 core, 256 GB, CentOS 5). Analysis on the MacBook Pro is substantially faster than the analysis on the Dell PowerEdge. The solid lines show the total CPU time spent for the analysis, the dashed lines show the time spent for the ctlike run. Overall, cube-style analysis is somewhat faster than the original binned analysis (the difference being that cube-style uses exposure and PSF cubes for response computation, while the original binned analysis accesses the instrumental response functions). Unbinned is faster than binned or cube-style for durations shorter than 20-30 hours. The CPU time spent in binned and cube-style ctlike runs is independent of the observation duration. However, CPU time spent for event simulation and analysis preparation increases with observation duration.
 |
 |
Updated over 8 years ago by
This page summarizes the steps for a code release. A code release can only be performed by an authorized code integrator.
To start with a code release, first create a clone of the ctools repository using:
git clone https://cta-gitlab.irap.omp.eu/<user>/ctools
Here, user is your usual user name on the CTA IRAP platform.
Now you can step into the ctools directory, switch to the devel branch (just in case you’re not already there), and create a release branch:
cd ctools git checkout devel git branch release
Using this release branch you will now perform extended code testing. The code testing procedure is still TBW.
Before releasing the code, you have to modify a number of files to incorporate release information in the code distribution and to update the code version number. The command sequence for updating release information is:
git checkout release nano configure.ac AC_INIT([ctools], [0.4.0], [jurgen.knodlseder@irap.omp.eu], [ctools]) nano ctools.pc.in Version: 0.4.0 Requires.private: GammaLib >= 0.5.0 nano ChangeLog nano NEWS nano README git add * git commit -m "Set release information for release X.Y.Z."
The nano commands will open an editor (provided you have nano installed; otherwise use any other convenient editor). The lines following the nano command indicate which specific lines need to be changed. Changes in the files ChangeLog, NEWS and README need some more editing. Please take some time to write all important things done, as ctools users will later rely on this information for their work!
Now you can merge the release branch into the master branch using the commands:
git checkout master git merge release
We do now the same thing for merging the release into the devel branch. In that way we make sure that the devel branch incorporates all modifications that were made during the code release procedure.
git checkout devel git merge release
You now should being the devel branch ahead of the release branch. This means that the devel branch should have an additional commit with respect to the release branch. This is not mandatory, but it assures later that the master branch and the devel branch will never point to the same commit. In that way, git clone will always fetch the devel branch, which is the required default behavior.
To bring the devel branch ahead, execute following commands:
git checkout devel nano AUTHORS git add AUTHORS git commit -m "Bring develop branch ahead of master branch after code release."
The nano AUTHORS step opens the file AUTHORS in an editor. Just add or remove a blank line to make a file modification.
At this stage you do not need anymore the release branch, and you should delete it now to avoid pushing the release branch to the central repository:
git branch -D release
Before pushing all modifications to the central repository you need to tag the release using
git checkout master git tag -a ctools-00-04-00 -m "ctools release 0.4.0"
We use here an annotated tag with a human readable tag message. Please use always the same format. In the above example, the ctools version X.Y.Z was 0.5.0.
Now you can push all modifications in the central repository using
git push --tags https://user@cta-git.irap.omp.eu/gammalib
user is again your usual user name on the CTA IRAP platform. The --tags option makes sure that you tag is also pushed towards the central repository.
Now you’re done!
Updated over 11 years ago by
This page summarizes the status of the ctools code.
Cppcheck is a static analysis tool for C/C++ code. Unlike C/C++ compilers and many other analysis tools it does not detect syntax errors in the code. Cppcheck primarily detects the types of bugs that the compilers normally do not detect. The goal is to detect only real errors in the code (i.e. have zero false positives).
In the frame below you find the latest Cppcheck result for ctools.
SLOCCount is a set of tools for counting physical Source Lines of Code (SLOC) in a large number of languages of a potentially large set of programs.
In the frame below you find the latest SLOCCount result for ctools.
Updated over 3 years ago by
To advance the ctools and GammaLib capabilities and to build a developer community we regularly organize week-long coding sprints. Why not joining the next? It’s really fun!
Updated over 8 years ago by
This page explains how you can contribute to the development of the ctools library.
If some of the software is not yet installed on your system, it is very likely that you can install it through your system’s package manager. On Mac OS X, you may use the Homebrew or MacPorts package managers. Make sure that you install the development packages of cfitsio, Python and readline as they provide the header files that are required for compilation.
ctools uses Git for version control.
To learn how Git is used within the ctools project, please familiarize yourself with the Git workflow.
The central ctools Git repository can be found at https://cta-gitlab.irap.omp.eu/ctools/ctools.git. A mirror of the central repository is available on GitHub at https://github.com/ctools/ctools. Both repositories are read-only, and are accessed using the https protocol. Both on Gitlab and GitHub you may fork the ctools repository and develop your code using this fork (read Git workflow to learn how).
The default branch from which you should start your software development is the devel branch. devel is ctools’s trunk. The command
$ git clone https://cta-gitlab.irap.omp.eu/ctools/ctools.gitwill automatically clone this branch from the central ctools Git repository.
Software developments are done in feature branches. When the development is finished, issue a pull request so that the feature branch gets merged into devel. Merging is done by the ctools integration manager.
After cloning ctools (see above) you will find a directory called ctools. Before this directory can be used for development, we have to prepare it for configuration. If you’re not familiar with the autotools, please read this section carefully so that you get the big picture.
Step into the ctools directory and prepare for configuration by typing
$ cd ctools $ ./autogen.sh
There is a single command to configure ctools:
$ ./configure
configure is a script that has been generated previously by the autoconf step. A typical output of the configuration step is provided in the file attachment:configure.out.
ctools is compiled by typing
$ make
The ctools unit test suite is run using
$ make check
To be written
To be written
To be written
You have to execute the additional make install step and source the ctools-init.sh setup file so that you’ll actually use the new version of ctools:
$ export CTOOLS=<wherever you want> $ ./configure --prefix=$CTOOLS $ make install $ source $CTOOLS/bin/ctools-init.sh
To be written.
To be written.
To be written.
Updated over 11 years ago by
cspull creates pull distributions for model parameters.
Updated over 11 years ago by
cssens computes sensitivity curves for CTA.
Updated over 11 years ago by
cstsdist computes TS distributions.
Updated over 11 years ago by
ctbin bins events from an event list into a counts map.
Updated over 11 years ago by
ctlike performs maximum likelihood fitting of models.
Updated over 11 years ago by
ctmodel creates model counts maps.
Updated over 11 years ago by
ctobssim simulates event lists for observations.
Updated over 11 years ago by
ctpoisson simulates counts maps from model maps generated by ctmodel.
Updated over 11 years ago by
ctselect selects events from event list files.
Updated over 11 years ago by
ctskymap creates a sky map from event lists.
Updated almost 10 years ago by
src and copy an existing ctool, e.g. cp -r ctselect ctnewtoolcd ctnewtool) and rename all files to the new namesMakefile.am to the new namessrc and add the new tool in Makefile.am: add a line to SUBDIRS with the name of the new subdirectory, and add the corresponding library to libctools_la_LIBADDctools root directory and add a entry to AC_CONFIG_FILES list in the configure.ac script (at the end of the section) (here the entry to be added would be src/ctnewtool/Makefile./autogen.sh./configuremakeUpdated over 11 years ago by
This page summarizes development notes for the ctools software.
Please use these pages to track your developments and any information related to your coding. For example, note the basic assumptions that have been made in implementing a tool. Or note a kluge that was used. Also, specify if things need to be improved further.
If you add a new page, please put
{{lastupdated_at}} by {{lastupdated_by}}
in the first line of the Wiki page so that the modification date and the person who did the modification is visible at top of the page.
Updated almost 10 years ago by
The Eighth ctools coding sprint will take place at IRAP, Toulouse in the week 9-13 October 2017. A detailed schedule will be uploaded in the near future.
Follow us on twitter (hash tag #ctools8).
Everyone is welcome; if you have used ctools for CTA science simulations or IACT data analysis, if you are interested in contributing to the ctools and GammaLib software code development, or if you are already an experienced developer, you can contribute. You will need programming skills in Python or C++, best is of course if you are experienced in both. We will split into groups and work onto a number of issues. Bring your laptop. If possible, install git before coming and git clone ctools and GammaLib. For new folks: you can get a head start also by making an account on Redmine and taking a look at the code documentation (http://cta.irap.omp.eu/ctools/ and http://cta.irap.omp.eu/gammalib/).
If you plan to attend, simply add your name to the list below:
The meeting will take place at IRAP-Roche, information of how to reach the location can be found at http://cta.irap.omp.eu/toulouse2011/practical.html (the bus schedule may be a bit outdated! Take the bus 78 from Faculté de Pharmacie and exit at stop LAAS, then it’s less then 5 min walk to IRAP).
A suggestion of possible hotels is on http://cta.irap.omp.eu/toulouse2011/accomodation.html (also this information dates back to 2011, but I guess most hotels are still there). Note that since recently we have a tramway connection to the airport. You may take the tram to go to the terminus (Palais de Justice) and from there take the metro to Faculté de Pharmacie (direction Ramonville) to go to the lab.
Another link with information about IRAP is here: http://www.irap.omp.eu/en/presentation/infos-pratiques
This will be updated later
Contact Jürgen if you would like to host a future coding sprint!
Post your ideas for possible projects to work on during the coding sprint here:
csphagen script to produce XML/PHA/ARF/RMF data to be fed into ctlike, csspec
GSkyRegionMap to handle exclusion regionsGCTAOnOffObservationGCTAOnOffObservationctlike, csspec, ctulimit, ctbutterflycssens improvements
cssenscssensUpdated about 10 years ago by
TBW
Updated about 3 years ago by
The fifth coding sprint took place at DESY, Zeuthen in the week 29 February - 4 March. We will start around noon on the first day and stop around noon on the last day so that you can travel on the same day to Berlin/Zeuthen (we may adapt the exact time of start on stop to your travel schedule).
Follow us on twitter (hash tag #ctools5).
You can follows us on Monday on SeeVogh (ctools coding sprint, pwd: ctools5)
Please add your name to the list below in case you plan to participate:
The meeting will take place in DESY Zeuthen. Directions described in:
http://www.desy.de/ueber_desy/anfahrt/zeuthen/index_ger.html
The meeting will take place in Seminar room 5 in the Villa (you can find a map of DESY Zeuthen under the above link)
If you want to sleep in Zeuthen, the cheapest option is to stay at the DESY guest house:
https://guest-services.desy.de/hostel_in_zeuthen/index_eng.html
If you want to stay in Berlin, the most convenient location is near Ostkreuz:
http://www.booking.com/landmark/de/bahnhof-ostkreuz.en-us.html?aid=318615;label=New_German_DE_5226378745-4PqgouiDMvCrJSLEuoHaTQS73336367425%3Apl%3Ata%3Ap1%3Ap2%3Aac%3Aap1t1%3Aneg;sid=5b32733dbd17f4318a1ca36a7b26464e;dcid=12;inac=0&;lang=en-us
Another possibility is to stay in Prenzlauer Berg. Here there are also many hotels, one we can recommend is:
http://schall-und-rauch.de/hotel-pension/
From both locations the train S8 will you in about 30-45 min to Zeuthen.
http://www.bvg.de/en/
If you have any questions please contact rolf.buehler@desy.de or michael.mayer@physik.hu-berlin.de.
Wifi will be available over Eduroam. In case you don’t have that, best send us the MAC address from your Laptop beforehand.
See you soon!
The dinner will be Wed 19:30 at Cafe Datscha http://cafe-datscha.de/
I hope by the time of the coding sprint we have a good draft of our release paper ready. We may work on analysis examples for the release paper. But we can also address new features needed and discuss the next steps.
Just list below what you would like to do during the sprint:
¶Updated over 8 years ago by
The fourth coding sprint will take place at IRAP, Toulouse in the week 29 June - 3 July. We will start around noon on the first day and stop around noon on the last day so that you can travel on the same day to Toulouse (we may adapt the exact time of start on stop to your travel schedule).
The meeting will take place at IRAP-Roche, information of how to reach the location can be found at http://cta.irap.omp.eu/toulouse2011/practical.html. A suggestion of possible hotels is on http://cta.irap.omp.eu/toulouse2011/accomodation.html. Note that since recently we have a tramway connection to the airport. You may take the tram to go to the terminus (Palais de Justice) and from there take the metro to Faculté de Pharmacie (direction Ramonville) to go to the lab.
I propose that the main goal of the 4th coding sprint would be to get the gammalib and ctools release 1.0 out. There are all couple of outstanding issues (see GammaLib and ctools roadmaps), probably non of these issues should be blocking. We can then focus on fixing remaining issues, doing science verification and writing pending documentation. We should also start to work on the paper.
Besides this, here a list of issues that can be addressed:Updated over 8 years ago by
We are using git as version control system for the ctools code and GitLab to manage the git repositories.
Every developer will have an own copy of the ctools code in the git repository, hence there is no need (and even no possibility) to push to the ctools repository. As a developer you will fork the ctools project, create a feature branch and add some new code (or correct a bug), and issue a pull request so that your change gets included in the trunk. This is identical to the workflow that you will follow when using GitHub.
master branch that holds the latest releasedevel branch that is the trunk on which development progressesintegration branch that is used for code integrationA temporary release branch is used for hotfixes and generally for code testing prior to any release. As developer you will fork the ctools repository in your private GitLab area and work on temporary feature branches.
 |
As the first step you need to create a fork of the project. Connect to GitLab with your Redmine user name and password (your user name on Redmine and GitLab is identical), select the ctools project and click on “Fork” (highlighted by the red box below):
 |
This brings you to a screen that invites you to fork (i.e. copy) the project to your user account. Click on your user (highlighted by the red box below):
 |
 |
After a short while a fork will be created that now is under your ownership. You can access this fork through the HTTPS protocol at the address https://cta-gitlab.irap.omp.eu/<user>/ctools.git where <user> needs to be replaced by your user name (your user name on Redmine and GitLab is identical). For the example below, you create a clone by typing in a shell:
$ git clone https://cta-gitlab.irap.omp.eu/jknodlseder/ctools.git
We recommend adding the main ctools repository as a remote repository named upstream so that you can fetch the latest code version before you start a new feature:
$ git remote add upstream https://cta-gitlab.irap.omp.eu/ctools/ctools.git
To work on a feature or to correct a bug you step in the ctools directory that was created after cloning and you create a new feature branch using
$ git pull upstream devel $ git checkout -b 9101-correct-nasty-bugThe first command pulled in the latest changes from the main ctools repository. Note that a branch name should always start with the number of the issue you work on and a short description what you actually are planning to do.
Suppose that there is a bug in the src/ctselect.cpp file. After correcting the bug you need to stage the change for commit using
$ git add src/ctselect.cppand then commit the change using
$ git commit -m "Fixed the nasty bug (#9101)"where the message in hyphens should be as detailed as possible (the example here is definitely not very good). Please also attach the issue number in the commit message. This allows tracking which issues were in fact fixed by a given commit.
Now you can push your change into the git repository using
$ git push origin 9101-correct-nasty-bugNote that the
origin argument specifies where to push the change (origin means to the same repository where you have cloned from), and the 9101-correct-nasty-bug argument gives the name of the branch you want to push.
You can now verify on GitLab that a new branch exists in your project:
 |
After having thoroughly checked your new code, and after having pushed the code into your git repository, you can now issue a pull request so that your change gets merged into the main code base (the so called “trunk”). For this you have to open the relevant issue in Redmine and put the status of the issue to “Pull request”:
 |
In the notes field please indicate where your change is. This means you should provide at least your user name on GitLab and the name of the feature branch. You could also copy/paste the HTTPS URL of your repository.
You should also describe in the notes field the changes or addition you made to the code. Explain what you have done. Say if there is anything you’d like particular attention for - like a complicated change or some code you are not happy with.
If you don’t think your request is ready to be merged, just say so in your pull request message. This is still a good way of getting some preliminary code review.
To delete a branch on GitLab, select the “Branches” tab and click on the wastebasket behind the branch you want to delete:
 |
Last release
Development version
The ninth ctools coding sprint will take place at IRAP, Toulouse in the week 5-9 November 2018. A detailed schedule will be uploaded in the near future.
Follow us on twitter (hash tag #ctools9).
Everyone is welcome; if you have used ctools for CTA science simulations or IACT data analysis, if you are interested in contributing to the ctools and GammaLib software code development, or if you are already an experienced developer, you can contribute. You will need programming skills in Python or C++, best is of course if you are experienced in both. We will split into groups and work on a number of issues and projects! Bring your laptop. If possible, install both the ctools and gammalib packages before arriving (installation instructions are available here). For new folks: you can get a head start also by making an account on Redmine and taking a look at the code documentation (http://cta.irap.omp.eu/ctools/ and http://cta.irap.omp.eu/gammalib/).
If you plan to attend, simply add your name to the list below:
The coding sprint will take place at IRAP-Roche building (address 9 Avenue du Colonel Roche) in room 225-226 (in the basement):
Information of how to reach the location can be found at http://cta.irap.omp.eu/toulouse2011/practical.html (the bus schedule may be a bit outdated!) Toulouse has a decent public transportation system with updated route information available on the Tisseo website (there is also an app, just search for 'Tisseo’).
From the airport (travel time: 1 hour):A suggestion of possible hotels is on http://cta.irap.omp.eu/toulouse2011/accomodation.html (also this information dates back to 2011, but I guess most hotels are still there).
Another link with information about IRAP is here: http://www.irap.omp.eu/en/presentation/infos-pratiques
This coding sprint has concluded. As a testament to just how successful and involved the coding sprint was, here is a collection of all the ctools and GammaLib related issues that were found and/or worked on during the sprint:
https://cta-redmine.irap.omp.eu/issues/2710
https://cta-redmine.irap.omp.eu/issues/2711
https://cta-redmine.irap.omp.eu/issues/2712
https://cta-redmine.irap.omp.eu/issues/2713
https://cta-redmine.irap.omp.eu/issues/2714
https://cta-redmine.irap.omp.eu/issues/2715
https://cta-redmine.irap.omp.eu/issues/2720
https://cta-redmine.irap.omp.eu/issues/2721
https://cta-redmine.irap.omp.eu/issues/2722
https://cta-redmine.irap.omp.eu/issues/2723
https://cta-redmine.irap.omp.eu/issues/2724
https://cta-redmine.irap.omp.eu/issues/2725
https://cta-redmine.irap.omp.eu/issues/2731
https://cta-redmine.irap.omp.eu/issues/2732
https://cta-redmine.irap.omp.eu/issues/2733
Contact Jürgen if you would like to host a future coding sprint!
Updated about 10 years ago by
TBW
Updated about 8 years ago by
Updated over 8 years ago by
Updated almost 10 years ago by
The second ctools/gammalib coding sprint will take place from the 27th to the 31st of January of 2014 at DESY (Zeuthen, Germany). Please watch this page for upcoming information about the date and the goals of the second coding sprint.
See the Coding_sprints page for information on previous / future coding sprints.
Introduction to ctools and GammaLib (presentation for Monday afternoon)
Please register at this page: https://indico.desy.de/conferenceDisplay.py?confId=9237 before January 10th 2014
The current list of participants is here: https://indico.desy.de/confRegistrantsDisplay.py/list?confId=9237
and have a look at http://gammalib.sourceforge.net/
Unless you want to specify installation details or anything non-standard, the following steps should lead to a standard installation of gammalib/ctools for development:
export GIT_SSL_NO_VERIFY=true git clone https://user@cta-git.irap.omp.eu/gammalib # replace 'user' by your user name on the IRAP Redmine system cd gammalib/ ./autogen.sh ./configure make sudo make install cd .. git clone https://user@cta-git.irap.omp.eu/ctools # replace 'user' by your user name on the IRAP Redmine system cd ctools/ ./autogen.sh ./configure make sudo make install # in .bashrc export GAMMALIB="/usr/local/gamma" source $GAMMALIB/bin/gammalib-init.shNote that the
user can be dropped for installation, yet you won’t be able to push some modifications back to the IRAP git server. Thus if you intend to write code, please add your user here.
In case you want to install ctools in a different location (which is possible, but not really recommended), you need an additional configuration step
export CTOOLS="/my/special/ctools/path" source $GAMMALIB/bin/ctools-init.sh(if gammalib and ctools live in the same directory, only the GAMMALIB environment variable and configuration is required).
This area is for brainstorming ... please share your ideas what should be a focus of this coding spring (and gammalib / ctools development in the coming months in general).
Please add you name after the topic(s) your interested in, so we get a feeling on who wants to do what.
pointlike). For this, we probably would have to extend GSkymap to allow different bin sizes.GSkymap functionality might be enhanced to allow smoothing, oversampling etc.Updated about 7 years ago by
The seventh ctools coding sprint will take place at ECAP, Erlangen in the week 3-7 April 2017. We will start around noon on the first day and stop around noon on the last day so that you can travel on the same day to Erlangen (we may adapt the exact time of start on stop to your travel schedule).
Follow us on twitter (hash tag #ctools7).
Everyone is welcome; if you have used ctools for CTA science simulations or IACT data analysis, if you are interested in contributing to the ctools and GammaLib software code development, or if you are already an experienced developer, you can contribute. You will need programming skills in Python or C++, best is of course if you are experienced in both. We will split into groups and work onto a number of issues. Bring your laptop. If possible, install git before coming and git clone ctools and GammaLib. For new folks: you can get a head start also by making an account on Redmine and taking a look at the code documentation (http://cta.irap.omp.eu/ctools/ and http://cta.irap.omp.eu/gammalib/).
If you plan to attend, simply add your name to the list below:
Erlangen can be reached via local (RE/S) and high-speed (IC/ICE) trains in about 15 to 20 minutes from Nuremberg main station.
There are direct ICE connections from Munich and Frankfurt to Nuremberg (travelling about 2 hours).
For all train connections see website of Deutsche Bahn.
The Nuremberg Airport is connected to different international airports and regularily served from Munich International Airport and Frankfurt International Airport. From there the easiest way is to take the subway line U2 to Nuremberg main station and continue from there with the regional trains RE or S to Erlangen (see Deutsche Bahn).
If your flight ends at the airport of Munich or Frankfurt you can take the ICE to Nuremberg and continue from there with the RE or S train to Erlangen (see Deutsche Bahn).
Taxi from Nuremberg Airport to Erlangen City about 28 €.
Erlangen can be reached via Autobahn A73 (exit Erlangen Zentrum) with nearby connections to Autobahn A3 , A6 and A9.
The seventh ctools coding sprint will take place at ECAP Erlangen, room 1.140 (second floor):
Erlangen Centre for Astroparticle Physics (Physikalisches Institut)
Erwin-Rommel-Str. 1
D-91058 Erlangen
Germany
The best way to get there by bus is taking a line ending at station “Sebaldussiedlung”. Bus connections can be found on the vgn webpage. From there it’s a two minutes walk to the ECAP building (see here).
There is also a parking lot in front of the building.
Please find below a hotel list to find easily an accommodation in Erlangen. Of course you may also book in any other hotel in Erlangen you prefer.
The A.B. Hotel is a low budget hotel with reasonable standards; the other ones of the list are roughly in the three star category. Most hotels are located in the city center.
A.B. Hotel, Harfenstr. 1c (http://www.abhotel.de)
Hotel Silberhorn, Wöhrstr. 12 - 14 (http://www.hotelsilberhorn.de/)
Altmann´s Stube, Theaterplatz 9 (http://www.altmanns-stube.de/)
La Brasserie, Nürnberger Str. 3 (http://www.brasserie-erlangen.de/home/frame.php)
Hotelchen, Theaterstr. 10 (http://www.hotelchen-am-theater.de/)
Der Graue Wolf, Hauptstr. 80 (http://www.grauer-wolf.de/)
Rokokohaus , Theaterplatz 13 (http://www.rokokohaus.de/)
Stadthaus, Henkestr. 4 (http://stadthaus-erlangen.de/)
Creativhotel Luise, Sophienstr. 10 (http://www.hotel-luise.de)
Apart from the hotels in the list, there is a number of other hotels, especially also four star hotels: “Hotel Bayerischer Hof” , “NH Hotel” and “Novotel” . Sometimes you can get special rates using booking platforms.
Release notes
Download
Documentation
Science Validation
Coding sprints
Contributing to ctools
Git workflow
Submission guidelines
Development notes
Development HowTo
Benchmarks
Updated over 7 years ago by
The sixth ctools coding sprint will take place at IRAP, Toulouse in the week 3-7 October 2016. We will start around noon on the first day and stop around noon on the last day so that you can travel on the same day to Toulouse (we may adapt the exact time of start on stop to your travel schedule).
Follow us on twitter (hash tag #ctools6).
Everyone is welcome; if you have used ctools for CTA science simulations or IACT data analysis, if you are interested in contributing to the ctools and GammaLib software code development, or if you are already an experienced developer, you can contribute. You will need programming skills in Python or C++, best is of course if you are experienced in both. We will split into groups and work onto a number of issues. Bring your laptop. If possible, install git before coming and git clone ctools and GammaLib. For new folks: you can get a head start also by making an account on Redmine and taking a look at the code documentation (http://cta.irap.omp.eu/ctools/ and http://cta.irap.omp.eu/gammalib/).
If you plan to attend, simply add your name to the list below:
The meeting will take place at IRAP-Roche, information of how to reach the location can be found at http://cta.irap.omp.eu/toulouse2011/practical.html (the bus schedule may be a bit outdated! Take the bus 78 from Faculté de Pharmacie and exit at stop LAAS, then it’s less then 5 min walk to IRAP).
A suggestion of possible hotels is on http://cta.irap.omp.eu/toulouse2011/accomodation.html (also this information dates back to 2011, but I guess most hotels are still there). Note that since recently we have a tramway connection to the airport. You may take the tram to go to the terminus (Palais de Justice) and from there take the metro to Faculté de Pharmacie (direction Ramonville) to go to the lab.
Another link with information about IRAP is here: http://www.irap.omp.eu/en/presentation/infos-pratiques
Probably in Erlangen, during the “Vorlesungsfreie Zeit” (no lectures), somewhere second half of February, beginning March
Updated over 8 years ago by
Submissions should be written in english.
Before submitting a bug notification, please check the list of bugs to see whether your bug is already known. If yes, you may add some information to the known bug using the Update tag.
If the bug is not yet known, please create a new issue using the Bug tracker by specifyingPlease do not assign any priority or person, due date and estimated time, this will be handled by the project manager. You may add files as necessary (e.g. configuration file and output, log files, screen dumps, etc.).
Before submitting a feature request, please check the list of feature requests to see whether your feature request is already filed. If yes, you may add some information to the feature request using the Update tag.
If the feature is not yet files, please create a new issue using the Feature tracker by specifyingPlease do not assign any priority or person, due date and estimated time, this will be handled by the project manager. You may add files as necessary (e.g. configuration file and output, log files, screen dumps, etc.).
When you edit a wiki page to improve its content, make sure that you fill the comment field with a descriptive summary of the changes you’ve made to the page. This way we’ll be better able to “monitor” and “maintain” the quality of the actual wiki content.
If you would like to contribute to the ctools development, please contact jurgen.knodlseder@irap.omp.eu.
The tenth ctools coding sprint was held online in the week of February 1-5 2021.
We anticipate the release of GammaLib and ctools 2.0 in spring 2021. They will feature major upgrades in the response calculation with the aim of speeding-up the computations (e.g., #3328), but this is also an opportunity to add more features and upgrades to the toolkit and to improve the documentation and tutorials. We will gather for a full week in order to work together with developers and users to make this happen. We will have daily meetings every morning at 2PM CET, and for the rest of the time split into groups and work on a number of issues and projects.
Everyone is welcome; if you have used ctools for CTA science simulations or IACT data analysis, if you are interested in contributing to the ctools and GammaLib software code development, documentation, and tutorials, or if you are already an experienced developer, you can contribute. You will need some programming skills in Python and/or C++. If possible, install both the ctools and GammaLib packages before the beginning of the sprint (installation instructions are available here). For new folks: you can get a head start also by making an account on Redmine and taking a look at the code documentation (http://cta.irap.omp.eu/ctools/ and http://cta.irap.omp.eu/gammalib/).
If you plan to attend, simply add your name to the list below (to do so request a Redmine account if you don’t have one yet):To stay in touch it’s also recommended that you joint the ctools mailing list (send an e-mail to ctools-subscribe@irap.omp.eu) and join the ctools Slack workspace and its #coding-sprint channel (ask via the mailing list).
For daily and impromptu calls we will use Zoom. The information to connect has been sent via email and is available on Slack in the #coding-sprint channel.
All times are CET
MondayGModelSpectral for spectral lines #3386 → EirikUpdated over 8 years ago by
Pictures of the 3rd coding sprint can be found at https://www.dropbox.com/sh/z14lr6wtvlkm1z1/AAA7jCZONfLqWYSK46b2FFXTa
The third GammaLib / ctools coding sprint will take place in the second week of July 2014 at MPIK (Heidelberg, Germany).
See the Coding_sprints page for information on previous / future coding sprints.
We will start on Monday (July 7th) at 1:30 pm and finish on Friday (July 11th) before lunch.
If you arrive before 12:30 on Monday you can join us for lunch and of course you can also have lunch on Friday and stay until the afternoon if you like.
You can reach MPIK with bus number 39, get a visitor pass at the MPIK main gate and then go to the “central seminar room” in the library building number 12.
If you haven’t been to MPIK before see here .
The meeting room and cantine are wheelchair accessible.
If you haven’t contributed to Gammalib / ctools before, please have a look at [Contributing_to_GammaLib].
You should have checked out the source code with git, built and installed Gammalib and ctools before you arrive, but of course we’ll help get you started at the coding sprint in case you run into any problems.
A limited number of rooms at the MPIK guesthouse on our premises in the woods above the city (code: Hess) are available: single rooms à 35 Euros (no breakfast! EMBL cafeteria nearby). Please email directly to Guesthouse@mpi-hd.mpg.de to book a room. The guest houses are not wheelchair accessible.
If you’d like to stay in Heidelberg, please find and book a hotel yourself online.
We will have lunch together every day at the EMBL cantine buffet. The price per person is 8 Euro, tap water is free, soft drinks are 1.50 Euro extra.
If you have any questions, please write an email to Christoph.Deil@mpi-hd.mpg.de .
Monday afternoon and Tuesday morning is reserved for an introduction by Jürgen as well as status reports and discussions.
We will then split up in small groups and work on certain issues and features for the rest of the week.
If you would like to present or discuss something (or have been asked to do so), please add it to this list.
MondayI (JK) went over the list of issues and extracted those that might be relevant for the coding sprint (in decreasing order or issue number)
GammaLib:
#1217 - Allow setting Emin and Emax in ctlike
#1205 - Improve computational speed for CTA binned analysis
#1199 - Adding new class GCTAPsfMap
#1198 - Incorrect results for fitting of diffuse models
#1197 - Gammlib should check consistency of model and observation xmls
#1140 - Have consistent units for spectral models
#1135 - Prefactor of GModelSpatialDiffuseMap is ignored in Monte Carlo simulation
#1126 - Add GCTAEdisp2D class (2nd code sprint leftover)
#1125 - Add unit test for 3D interpolation in GCTAResponseTable
#1124 - implement region rotation (linked to ON-OFF method)
#1123 - Implement energy dependent SkyRegion (linked to ON-OFF method)
#1122 - Calculate IRFs for GSkyRegions (linked to ON-OFF method)
#1121 - create GSkyRegionSkyMap class (linked to ON-OFF method)
#1118 - Document CTA energy dispersion in the GammaLib user manual
#1060 - Investigate whether a more precise curvature matrix computation is needed (related to computation of error bars)
ctools:
#1152 - Add ctool for quick look and checks
#1145 - ctobssim should also fill the DETX and DETY columns
#1136 - Allow for energy integration in ctmodel
#1115 - Create pointing simulation tool
#1037 - Implement ctools to combine run-wise IRFs for fast binned likelihood analysis
Confirmed:
(please add your name here if you will come to this coding sprint)
Can’t:
Participants: Andrea Giuliani, Chia-Chun Lu, Christoph Deil, Hubert Siejkowski, Matteo Balbo, Roland Walter, Pierrick Martin, Rolf Buehler, Nathan Kelley-Hoskins, Jürgen Knödlseder
We decided to focus the third coding sprint on science validation and on steering the code towards a gammalib release 1.0 (ideally, the code base should be ready for the release after the coding sprint). Although energy dispersion and on/off analysis were believed to be not central for the gammalib release 1.0, existing code that supports these features will be in the code base, and if possible, should also be tested. We would however release version 1.0 even if these features are nut fully supported.
Some more thinking and discussion is needed before fixing the priorities of the code sprint. A roadmap document needs to be written for gammalib release 1.0 that should help setting the priorities.
The meeting will be divided in three sessions:The purpose of the ctools 00-04-00 release is to provide a software version that is adapted to the analysis of CTA 1DC data.
The following changes have been implemented:
ctools 00-04-00 requires GammaLib-00-06-00.
The following changes have been implemented:
This is a bug fix release. The following bug fixes are included:
Updated over 11 years ago by
The ctools-00-06-00 release includes the following changes:
ctools-00-06-00 requires GammaLib-00-07-00.
Updated over 10 years ago by
The ctools-00-07-00 release includes the following changes:
ctools-00-07-00 requires GammaLib-00-08-00.
Updated about 10 years ago by
This is a bug fix release. The following bug fixes are included:
Updated over 9 years ago by
The ctools version 0.8.0 has been released.
The release includes the following changes:Updated almost 9 years ago by
ctools version 0.9.0 has been release.
This is (hopefully) the final release before ctools version 1.0, and the release implements most of the features and issues that are scheduled for version 1.0. New with this version are the official CTA Instrument Response Functions that are bundled now within ctools.
The following changes have been implemented with respect to the previous release:
ctools version 0.9.0 requires gammalib version 0.10.0.
This page summarizes information on the ctools 1.0.0 release.
Any new features that should be added for the 1.0.0 release should be committed into the pre-release. Between pre-release and 1.0.0 release, no new features should be added (emphasize should be on validation). The bases of the release paper will be the pre-release code, with updates using the 1.0.0 version in case that bugs have been discovered during the validation of the pre-release.
ctools version 1.0.1 has been released.
This is a bug fix for ctools release 1.0.
The following bug fixes have been implemented:Updated over 8 years ago by
ctools is a software package developed for the scientific analysis of Cherenkov Telescope Array (CTA) data. Analysis of data from existing Imaging Air Cherenkov Telescopes (such as H.E.S.S., MAGIC or VERITAS) is also supported, provided that the data and response functions are available in the format defined for CTA.
ctools comprises a set of ftools-like binary executables with a command-line interface allowing for interactive step-wise data analysis. ctools includes also a Python module allowing to control all executables. Creation of shell or Python scripts and pipelines is supported. ctools provides cscripts, which are Python scripts complementing the binary executables. Extensions of the ctools package by user defined binary executables or Python scripts is supported.
ctools are based on GammaLib, a versatile toolbox for the high-level analysis of astronomical gamma-ray data. Besides CTA, GammaLib supports also the analysis of Fermi/LAT and COMPTEL data, and extensions to support further gamma-ray instruments are planned. An interface to virtual observatory ressources is also in preparation. By making use of the GammaLib multi-instrument capabilities, ctools supports the joint analysis of CTA (or any IACT providing data in the CTA format), Fermi/LAT and COMPTEL data.
ctools are developed by a team of enthousiastic gamma-ray astronomers with support from engineers. We regularily organise coding sprints where key developers but also newcomers meet to discuss the developments and next steps, and advance with the coding of the software.
ctools is free software distributed under the GNU GPL license version 3
The actual version of the ctools code can be retrieved from our git repository using
$ git clone https://cta-gitlab.irap.omp.eu/ctools/ctools.git
In case that you get error: SSL certificate problem, verify that the CA cert is OK. you may add
$ export GIT_SSL_NO_VERIFY=truebefore retrieving the code. Before you can build the ctools code obtained using git you have to generate the configuration script using
$ ./autogen.sh
Then you may proceed with the usual
$ ./configure $ make $ make check $ [sudo] make install
The ctools documentation is available on the dedicated web site http://cta.irap.omp.eu/ctools/. This documentation refers to the last ctools release. The documentation corresponding to the current development branch can be found at http://cta.irap.omp.eu/ctools-devel/.
If you need support, please send an e-mail to jurgen.knodlseder@irap.omp.eu.
You may also submit a bug report, a patch or a feature request by using this form. Before submitting a bug report, a patch or a feature request here, please read the Submission guidelines.
If you would like to contribute to the development of ctools, please send an e-mail to jurgen.knodlseder@irap.omp.eu by specifying in which area you would like to contribute.
Once you have a user ID and a password, please read Contributing to ctools before starting your software development.
To help news developers in joining the project we regularly organise Coding sprints.
As ctools are intended for scientific analysis, science validation of the software is an important issue. The Science Validation page summarizes the studies that have so far been done.