Coder Social home page Coder Social logo

astroaccelerateorg / astro-accelerate Goto Github PK

View Code? Open in Web Editor NEW
41.0 14.0 15.0 5.79 MB

AstroAccelerate is a many-core accelerated software package for processing time-domain radio-astronomy data.

Home Page: https://www.oerc.ox.ac.uk/research-groups/astroaccelerate/

License: GNU General Public License v3.0

C 1.88% Makefile 0.48% Cuda 31.81% Shell 0.65% C++ 63.37% CMake 1.00% Python 0.70% Meson 0.10%
gpu cuda radio-astronomy

astro-accelerate's Introduction

Repository for Astro-Accelerate Code

Introduction

This documentation summarises the content of the Astro-Accelerate software.

Please also refer to the wiki pages.

Publications

If you use AstroAccelerate, please cite the code using the following DOI and the relevant papers:

If you use de-dispersion please also cite:

  • Novotný, J., Adámek, K., Clark, M. A., Giles, M., and Armour, W., “Accelerating Dedispersion Using Many-core Architectures”, The Astrophysical Journal Supplement Series, vol. 269, no. 1, IOP, 2023. doi:10.3847/1538-4365/acfef6. Accessible from: https://iopscience.iop.org/article/10.3847/1538-4365/acfef6.

If you use single-pulse detection please also cite:

  • Adámek, K. and Armour, W., “Single-pulse Detection Algorithms for Real-time Fast Radio Burst Searches Using GPUs”, The Astrophysical Journal Supplement Series, vol. 247, no. 2, IOP, 2020. doi:10.3847/1538-4365/ab7994. Accessible from: https://iopscience.iop.org/article/10.3847/1538-4365/ab7994

If you use Fourier domain acceleration search please also cite:

  • Dimoudi, S., Adamek, K., Thiagaraj, P., Ransom, S. M., Karastergiou, A., and Armour, W., “A GPU Implementation of the Correlation Technique for Real-time Fourier Domain Pulsar Acceleration Searches”, The Astrophysical Journal Supplement Series, vol. 239, no. 2, IOP, 2018. doi:10.3847/1538-4365/aabe88. Accessible from: https://iopscience.iop.org/article/10.3847/1538-4365/aabe88

Other:

Features

Astro-Accelerate is used for real-time astronomy data processing. Its features include:

  • Acceleration Searching
  • Zero DM
  • RFI Mitigation

Python Interface

After following the steps below, consider using the Python interface. An example is provided in the python/ folder. Configurating pipelines using the Python interface is otherwise identical to an input_file (described below).

Software Inputs and Outputs

The software input is a sample data file. To process the data file, astro-accelerate makes use of a configuration file. Please see the section Creating An Input Configuration File for instructions on how to create a configuration file to process an input data file. The software output is dependent on the choice of analysis component that is run.

Checking the Configuration of the Graphics Processing Unit (GPU) and Support for CUDA

In a terminal window, type

nvidia-smi

The output will look similar to the following example

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.20                 Driver Version: 375.20                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla P100-PCIE...  On   | 0000:02:00.0     Off |                    0 |
| N/A   32C    P0    26W / 250W |      0MiB / 16308MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  Tesla P100-PCIE...  On   | 0000:03:00.0     Off |                    0 |
| N/A   34C    P0    25W / 250W |      0MiB / 16308MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                              
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

If no output is shown, or if an error appears, then it may indicate that a GPU has not been detected, or that the CUDA toolkit is not properly installed.

Selecting the Graphics Processing Unit (GPU) in the case of a system with more than one GPU

If you have a multi-GPU system, you need can select the card by setting it in the input_file. The setting to add to the input_file is

selected_card_id X

where X is a non-negative integer number which corresponds to the ID number of the GPU on your machine.

Software Pre-Requisites

CUDA: CUDA 8.0 (see https://developer.nvidia.com/cuda-downloads)

C/C++ (version): As supported and required by CUDA.

Compiler: As supported by CUDA, but requiring also OpenMP support (compiler support can be found here).

Creating An Input Configuration File

An example input configuration file is shown below:

range    0    150  0.1  1 1
range    150  300  0.2  1 1
range    300  500  0.25 1 1
range    500  900  0.4  2 2
range    900  1200 0.6  4 4
range    1200 1500 0.8  4 4
range    1500 2000 1.0  4 4
range    2000 3000 2.0  8 8
sigma_cutoff     6
analysis
-acceleration
-periodicity
-output_dmt
-zero_dm
-zero_dm_with_outliers
-rfi
fdas_custom_fft
-fdas_inbin
fdas_norm
debug
file /home/wa78/filterbank/ska-mid-b2.fil`

Features can be turned on or off by adding a character at the beginning of the line (here "-" is used).

Setting range

range tells the code to dedisperse and has input.

The format for the range parameter is range dm_low dm_high dm_step downsampling_in_input_time downsampling_in_output_time where dm_low, dm_high, dm_step, downsampling_in_input_time, and downsampling_in_output_time are to be replaced with suitable numerical values. For example, a valid input for the range parameter is

range 500  900  0.4  2 2

astro-accelerate will parse this input and dedisperse from a dm of 500 to a dm of 900 in steps of 0.4 (making (900-500)/0.4 dm trials), with input data downsampled in time by 2 (e.g. 64 uS would be binned into 128 uS samples).

Setting sigma_cutoff

sigma_cutoff is the Signal-to-Noise Ratio (SNR) cutoff for your single pulse search.

Setting analysis

analysis this tells the code to analyse the dedispersed data, outputting data into the output directory. The output data are binary files and so which can be read in gnuplot and python.

For example, you could use python as follows splot "./57663_22588_B0531+21_000007.fil/global_analysed_frb.dat" binary format="%float%float%float%float" u 1:2:3 palette

Setting acceleration

acceleration this does a Fourier domain acceleration search on the data.

Setting periodicity

periodicity sets a search for periodic objects.

Setting output_dmt

output_dmt outputs the entire dedispersed data to a file (in ASCII).

Setting zero_dm

zero_dm you can guess

Setting zero_dm_with_outliers

zero_dm_with_outliers is part of the RFI mitigation routine.

Setting rfi

rfi tries to eliminate RFI. (Astro-Accelerate welcomes developers to supply the team with data that includes RFI, which would be very helpful.)

Setting fdas_custom_fft

fdas_custom_fft runs fourier domain acceleration search with a custom FFT.

Setting fdas_inbin

fdas_inbin performs interbinning on the complex output.

Setting fdas_norm

fdas_norm performs PRESTO block median normalization.

Setting debug debug this gives detailed output.

Setting file Please supply the input data file by using the file setting followed by the path to a valid input data file

file <your input file>

Input data files are by definition assumed to be formatted with 8-bit data. Please contact Astro-Accelerate if you have input data that is not 8-bits let me know (development for support for this is in progress and we may be able to help).

Installation and Usage (Linux)

Step 1: Download the files

Obtain the Astro-Accelerate code by doing git clone https://github.com/AstroAccelerateOrg/astro-accelerate

Step 2: Compile

Ensure you have the correct environment and pre-requisites. Set-up the environment (which will add CUDA to PATH and LD_LIBRARY_PATH)

source setup.sh

setup.sh contains a hardcoded version number and a variable string to identify whether the system is a 64-bit or 32-bit architecture. The user may need to edit setup.sh to suit the CUDA version number, library paths, and the architecture number in order to suit their needs. Users who already have all relevant CUDA paths configured do not need to source setup.sh.

At this point, the user has a choice, they can either 1.) use the pre-configured Makefile that comes with the repository by default, or they can 2.) configure the build system themselves using CMake.

Note that in the case of using CMake, the Makefile that CMake produces will overwrite the default Makefile if the build is performed in source.

To run using the default Makefile, simply type

make

To configure the build system using CMake, create a build directory

mkdir build

and then

cd build/

run CMake

cmake ../

The CUDA architecture can be specified with the -DCUDA_ARCH flag. For example, for architecture 7.0, do

cmake -DCUDA_ARCH="7.0" ../

The software can then be compiled using the generated Makefile. To do so, simply type

make

In both cases, the compilation process indicates which components are being compiled. The result is an executable called

astro-accelerate

in the directory from which the build was performed. In the case of using the default Makefile, the library is compiled as a static library called

libastroaccelerate.a

against which the executable is linked. In the case of using CMake to configure the build system, the library is compiled as a shared object library called

libastroaccelerate.so

against which the executable is linked. In both cases, the library file will be located in the astro-accelerate build directory.

The user or developer may also with to run unit tests as part of the build. In this case, CMake should first be run with -DENABLE_TESTS=ON (the default is OFF) in order to enable the compilation of the tests, as follows

cmake -DCUDA_ARCH="7.0" -DENABLE_TESTS=ON ../

The tests can then be run as follows

make test

The test results will be printed to the console. The test executables are located in a separate folder in the build directory and are separate from the main standalone executable, they do not form a part of the compiled library or standalone astro-accelerate executable.

Step 3: Run

Astro-Accelerate assumes its input is ready and compatible. To obtain compatible input, please follow the steps below. Please also ensure that the aforementioned environment variables have been set.

  1. Run astro-accelerate using the format

     ./astro-accelerate /path/to/input_file.txt
    

By default, the output of astro-accelerate will be located in the same directory in which astro-accelerate was executed. Configuration files may be used to further specify, set, and change options. By default, the astro-accelerate executable looks for a configuration file in the same directory as the executable. A configuration file is required in order to run astro-accelerate. A number of example configuration files are included in the repository.

Step 4: Results

To print results from the analysis and periodicity modules using gnuplot, use the following command

splot "../path/to/output_file.dat" binary format="%f%f%f%f" u 1:2:3 palette

which will plot the raw output data as saved to disk.

Optimisations and Tuning

Astro-Accelerate comes with the facility to tune the software to the input that the user provides.

  1. To do this, cd to the scripts directory. Modify profiling.sh, changing the line that says

     ./astro-accelerate.sh ../input_files/ska_tune.txt
    

    to

     ./astro-accelerate.sh ../input_files/<your input file>
    

    where <your input file> must be replaced by the input configuration file.

  2. The next step is to run the profiler tool that is provided in the repository

     ./profiling.sh
    

    This will create an optimised code for your search and GPU type.

  3. Then, astro-accelerate can be run as usual by doing

     ./astro-accelerate.sh ../input_files/<your input file>
    

    where <your input file> must be replaced by the path to the input configuration file as specified in the previous step.

Further Documentation

More detailed information can be found on the Wiki page of the repository and the Astro-Accelerate webpage.

Using Astro-Accelerate as a library

Astro-accelerate can be compiled and linked against as a library. A good demonstration of the user interface is provided in main.cpp. For more advanced use cases, a good example boilerplate code is provided in aa_pipeline_generic.cpp.

The user interface is centred around the user requesting a series of components that the library will compute as a pipeline. The ordering of the pipeline components is determined by the library, however the user may create a series of pipelines to create their own custom ordering.

Return types are provided as a boolean to indicate whether a method was successful or not. When a method in the pipeline configuration process returns false, the pipeline will not run, and the user should revisit their settings.

When a method returns an object, then if the library cannot create a valid object, it will return an empty or trivial object. When an empty or trivial object is passed to the library at a later point, the relevant method will return false, or provide another empty or trivial object. Such a scenario prevents the astro-accelerate pipeline from running, in which case the user should revisit their settings.

The user can read .fil files or provide a std::vector<unsigned short> or a raw pointer of type unsigned short, but must in either case provide a valid aa_filterbank_metadata object that matches a filterbank data file (sigproc format).

User-side

  • Select components (dedispersion, rfi, zero_dm, threshold,…).
  • Provide settings for the components (plan, strategy).
  • Run the pipeline (run).

Library-Side

  • Astro accelerate decides on the strategy and the component ordering.
  • Data remain inside the pipeline until the end of the pipeline.
  • Validate the user settings beforehand.
  • All components adhere to the same programming idiom (plan, validate, strategy, validate, run).

Contact and Support

If you notice any errors or have suggestions, please contact someone on the astro-accelerate team, or file an issue or bug report on the repository.

Disclaimers and Licensing

A number of code files may be covered by different licences. Please refer to these seperately. Please also refer to the Astro-Accelerate licence file provided.

Copyright © 2018 Astro-Accelerate. All rights reserved.

astro-accelerate's People

Contributors

ccarels avatar celestian avatar jan2nov avatar jsharpe avatar kadamek avatar nassimouannoughi avatar telegraphic avatar wesarmour avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

astro-accelerate's Issues

Purpose of cache_works

Description
The cache_works/ folder contains device_dedisperse.std and device_dedispersion_kernel.works.

What are these files and are they supposed to be compiled? What are the extensions indicating?

Outcome
Clarification.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: N/A.

Expected semantic version number increment category (Please indicate x.y.z): N/A.

Notes
N/A.

Minimum processable samples

Could we please request a minimum_processable_time_samples method on DedispersionStrategy. When called this should return the smallest possible number of timesamples that it can process (given the number of DMs and the register configuration etc.)

Subsume bootstrap into a setup script

Description
A setup.sh script can subsume bootstrap.sh

Outcome
A single setup script.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): y.

Notes
N/A.

Input files must have a file extension

Description
Currently some files in the input_files/ have a .txt extension but some do not.

It would be good to have the code parse the file to look for a common extension.

My feeling is that the files currently under input files function more like macros, being different to actual input files which contain data to be processed.

Therefore, it might be worth considering renaming the input_files/ to macros/ and appending a .macro extension (or similar) instead of .txt, for the avoidance of doubt to the user.

Outcome
Uniform naming scheme for input files, clarification of their purpose to the user.
The code can parse and enforce the file extension.

Timeline
When convenient.

Interfaces
Will this feature result in a backwards-incompatible interface change: Yes. Existing input_files will need to be updated to include the appropriate file extension (as the code will no longer accept files without the correct file extension after this change).

Expected semantic version number increment category (Please indicate x.y.z): x.

Notes
Whatever the outcome of this issue, the interface for macros (currently called input files) must be documented.

Move astro-accelerate to new build system

Description
Use CMake to build astro-accelerate.

Outcome
Using CMake as the build system.

Timeline
Gradually.

Interfaces
Will this feature result in a backwards-incompatible interface change: Yes.

Expected semantic version number increment category (Please indicate x.y.z): x.

Notes
N/A.

Consider moving source and header files

Description
Currently, all code is contained inside lib/.

For a library user, it might make more sense to expect to find the header files in include/ and the library files inside lib/, and of course having the source files in a src/ folder.

Outcome
Code structured in standard way.

Timeline
Gradually.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): y.

Notes
There is some relevance to #64 in that the PPF/ folder must remain in the repository at the current location. If we leave the PPF/ folder inside the lib/ folder, at the very least this makes a clear separation between code that is to be compiled and that which isn't, as PPF/ would not be inside src/ or include/.

This issue is also further to #62.

Bug: During peak-finding or thresholding y grid dimension can overflow

I think both periodicity thresholding and peak-finding are affected. In the analysis this should not be a problem since data are not transposed as they are in periodicity.
Problem is that in periodicity data are in dm x time format, so greater of the two (time) ends in y dimension of the grid which is restricted at the moment to 65535 blocks.

Use of includes and headers

Issue Summary
Header guards are lacking and source files are being included. The current Makefile seems to circumvent these issues, but that is not good practice.

Steps to Reproduce
Try compiling the code with a standard makefile or build system such as CMake.

Expected Outcome
Expect to compile the code.

Actual Outcome
Lots of compiler errors complaining of multiple definitions, not defined, or already defined.

Configuration
N/A.

Notes
This issue must be tackled before #62 or #65 can be properly solved.

Default scripts in repository have external data file dependencies

Description
The default scripts in input_files have a file parameter that points to a data file with a hardcoded path that is an external dependency. This means that at the moment, no one who checks out the code can try it out to see if it works.

For example input_files/test-dp-4.txt

file /mnt/data/filterbank/test-dp-4.fil
has file /mnt/data/filterbank/test-dp-4.fil, where /mnt/data/filterbank/test-dp-4.fil is a file that the user would not reasonably be expected to have when they clone the repository.

Outcome
Suggested strategy:

  • input_files to be called macros to avoid confusion with data files.
  • A new repository under AstroAccelerateOrg to be called MockSourceGenerator (or similar), that contains a software code that can generate small mock source input data files.
  • A new repository under AstroAccelerateOrg that contains macros.
    • If hardcoded paths exist inside this repository, it is still not ideal but more acceptable than having them inside the main code repository.
  • The astro-accelerate repository (this repository) to contain
    • A macro that runs without a data file (a pass-through option).
    • A macro that runs with a data file that can be produced with a mock source from the MockSourceGenerator repository.

The ability to generate small mock source input data files is useful for testing/validation purposes. For example, a quick test if the code runs end-to-end, produces correct physics output.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): y.

Notes
N/A.

Unit test exiting - error in one stops execution of all other unit tests

Running the unit tes executable for astro-accelerate results in an exit.
This stops ALL other unit tests running.

⟫ ./lib/astro-accelerate/test/gtest_AstroAccelerate 
[==========] Running 2 tests from 2 test cases.
[----------] Global test environment set-up.
[----------] 1 test from AstroAccelerateTest
[ RUN      ] AstroAccelerateTest.AstroAccelerate_call
Need input file.

It should run all other unit tests.

Remove images from repository

Description
Binary files should not be in the repository.

Outcome
Remove images.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Support for comments in input_files

Description
Is there support to add comments in input_files?
If there isn't, I think this would be a really useful feature to have.

For example, looking at https://github.com/AstroAccelerateOrg/astro-accelerate/blob/master/input_files/BenMeerKAT.txt, it would be good if there is a way that the user can add comments and notes to the file.

Outcome
The ability to add comments in the input_files.

Timeline
When needed/As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Create a pull request template


name: Feature Request
about: Make a feature request to help us improve


Description
Create a template for performing pull requests (merge request).

Outcome
A template for pull requests.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

mkl support

Description
I can't really find mkl in the Makefile yet there is code under PPF/CPU/CPU_PPF.cpp and PPF/Xeon Phi/PHI_PPF.cpp which includes #include <mkl.h>.

Is this code actually being compiled or being used in the application?

Outcome
Clarification.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: N/A.

Expected semantic version number increment category (Please indicate x.y.z): N/A.

Notes
N/A.

Update README.me in order to use setup.sh

Description
The change to the setup following from setup.sh should be covered in the readme.

Outcome
Updated readme.md to align with new setup.sh

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

AstroAccelerate run_astroaccelerate_sps calls are thread-unsafe

As it currently stands, the main run_astroaccelerate_sps method is unsafe to use in a multi-GPU environment. This is due to class attributes on the associated AstroAccelerate object being set inside the call.

Currently we have a work around that creates a new AstroAccelerate object for each call to each GPU, but this results in unnecessary overheads.

An example of a thread-unsafe portion of the code is the _inc variable which is updated in a loop. This variable is used to determine the start point when reading from a buffer. Thread conflicts here can easily result in out-of-bounds memory accesses.

Add script to set up CUDA environment

Description
Adds environment variables to a new script setup.sh.

The first iteration will be to source the CUDA environment variables.

Outcome
User-friendly setup of environment variables.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): y.

Notes
N/A.

README in markdown with subsections.

Description
Display the readme as markdown with subsections.

Outcome
A more organised readme.

Timeline
As soon as convenient

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
Consider re-creating as "readme.md"

CONTRIBUTING.md in markdown

Description
Upgrade the CONTRIBUTING.md file to use markdown support.

Outcome
CONTRIBUTING.md will contain markdown support.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Update COLLABORATORS list and apply markdown support

Description
Update the COLLABORATORS list, and apply markdown support.

Outcome
See above.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Inputs and Outputs for analysis modules

Description
Let's document the inputs and outputs of the Periodicity Search, FDAS, and SPDT analysis modules. Having this information is important to drafting the interface.

Outcome
A knowledge of module inputs and outputs.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: N/A.

Expected semantic version number increment category (Please indicate x.y.z): N/A.

Notes
Discussion on this topic is welcomed.
I've tagged @KAdamek, @wesarmour, @jan2nov for now, but feel free to tag and include others.

lib/headers/header does not have a file extension

Issue Summary
lib/headers/header does not have a file extension.

Steps to Reproduce
N/A.

Expected Outcome
Expect code files to have a file extension.

Actual Outcome
The file does not have a file extension.

Configuration
N/A.

Notes
N/A.

Move developers_guide.md up directory

Description
developers_guide.md is now the only file in the docs/ directory. It is more consistent to include this document with the already existing documents (e.g. readme and licence) in the root directory of the repository.

The developers_guide.md can simultaneously be renamed to CONTRIBUTING, in line with standard naming conventions.

Outcome
Move developers_guide.md out of docs/ folder and into the root directory of the repository.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Purpose of device_dedispersion_kernel.orig

Description
Is device_dedispersion_kernel.orig a duplicate of device_dedispersion_kernel.cu?

Are both of these to be compiled or just one?

Outcome
Clarification.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Remove large files


name: Feature Request
about: Make a feature request to help us improve


Description
Several large files are in the repository history.
These look like they can be safely removed from the repository history. Removing them will likely greatly reduce the repository size (currently ~20 MB).
This will reduce the time needed to clone the repository.

Outcome
A smaller repository.

Timeline
As soon as convenient.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes

Git Hash Size [bytes] Path
7a3e7bae24582efe205f90836ec7d5d68f2745ff 1378840 build/dedisperse-gpu
5b762a04f6ead030d1f09f665d656bc2dd1ba945 1379120 build/dedisperse-gpu
98fe4f4dcba17de02497af2121883f108a7c6634 1595992 astrolib/libastrolib.a
b13e78e481aace5b1871fcdb30d11e555227479c 1596360 astrolib/libastrolib.a
0ab45b02317c7c7a66c5b0a101c33466914c1c74 1642684 astrolib/libastrolib.a
c1e53623c8d8106a347f9f71313e065bc13f3bf6 1648002 astrolib/libastrolib.a
c6b3a3015029e3432f9447a065aa9988e3209fa4 1670068 astrolib/libastrolib.a
25c87e3aa993c6a26674d461150f5d7a9309c0a8 1707620 astrolib/libastrolib.a
1cdaa6726fdaf552427f5a5c5be9db184a000f9a 1708684 astrolib/libastrolib.a
3ac417c81a541fae7fec141378e258a846c19084 2334346 output/ska_karel/global_analysed_frb.dat
842a639f5999ef921a3303393acdc9c39731ef63 4983646 astrolib/libastrolib.a
8ceb07741645c66a2fdbc52fd8982ab2426e3bd3 4985782 astrolib/libastrolib.a
b3d44079ed1f58cb3cd8f6eddad242ca19fa5506 5154742 astrolib/libastrolib.a
7d58b160ba66e6451f8fca76b64865ebd0bf6476 5329922 astrolib/libastrolib.a
8dc5fa68eea9a0d439741c77564e164ffa3805c7 5331180 astrolib/libastrolib.a
01b19cab3155ef90ee092ab04f0e35e4793965b9 5332954 astrolib/libastrolib.a
ca93011e354642a01ca331c0c54622c75838aba2 5495602 astrolib/libastrolib.a
777bef3bf7be0564885066ccf70d3d7bdfe76b1a 5679988 astrolib/libastrolib.a
3c551f24d65433726a87c6ddc42a30f4590e5c64 5948400 astrolib/libastrolib.a
6da136e45c5493f1b0494f9425c1d46664707ff4 6409622 astrolib/libastrolib.a
68ad848854be0df38707babf4e583c4f5c51eb03 6411278 astrolib/libastrolib.a
5b687580e7cb5313203bc08551c8ba8336d064f6 9265956 astrolib/libastrolib.a
cf1367d491b1550092d37834b7f9050857fbc344 9351644 astrolib/libastrolib.a
a585a902c21b3aeb8298fffbba4c4848259cb5c5 11095766 lib/out.txt.filepart

Remove data files from the repository

Description
Data files should not be in the code repository. If version control is really needed, data files could be placed in a separate repository for data files, which would mean users can check out data only if they need it, and all data can be stored in one location.

If the data is really needed in order for the code to function, then it can stay in the repository.

Specifically test.dat which is 459 KB.

Outcome
test.dat which is 459 KB will be removed from the repository.

The code repository will be more organised and less likely to become large as a result of data files being stored along with the codebase.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Replace exits with std::runtime_error throws

To support integration with Cheetah we need to be able to catch errors from astro-accelerate. Currently in DedispersionStrategy.cpp the code calls exit(n). Could these please be replaced by std::runtime_exception throws.

Binary files should not be in the repository [astrolib/libastrolib.a]

After astro-accelerate compilation, git said binary file astrolib/libastrolib.a was changed. Generally said, it is not good idea to track compiled binary files in git repository. So, I would like to propose solution.

  1. If we remove astrolib/libastrolib.a, compilation fails. It is caused by missing astrolib directory. Unfortunately, git is not able to manage directories. Common solution in this case is bootstrap.sh script which prepares necessary directory, astrolib in our case.
  2. Of course, it is good practise to mention this bootstrap.sh script in README.
  3. And it is necessary to add *.a filter into .gitignore to prevent this could happen again.

I am about to prepare commits for this proposal.

CUDA 8.0 shuffle functions deprecation

Description
NVIDIA changed shuffle function calls in new CUDA 9. Old deprecated function calls creates warnings and might (will) be dicontinued in next CUDA version. Warning also make compilation unreadable.

Outcome
There is two ways of doing this. Either change all shuffle calls to a new format. That is change
__shfl(XX) -> __shfl_sync(mask,XX)
__shfl_up(XX) -> __shfl_up_sync(mask,XX)
__shfl_down(XX) -> __shfl_down_sync(mask,XX)
__shfl_xor(XX) -> __shfl_xor_sync(mask,XX)
This change will however break comatability with older version of CUDA.

Or create inline function :
__device__ __inline__ float shfl_xor(mask, XX){ #if (CUDART_VERSION >= 9000) return(__shfl_xor_sync(mask, XX)); #else return(__shfl_xor(XX)); #endif }
In case of FFT codes I have noticed no or marginal performance impact.

Timeline
Soonish but not critical

Interfaces
Will this feature result in a backwards-incompatible interface change:
Yes/no depending on method

Expected semantic version number increment category (Please indicate x.y.z):
No idea. First we should set some starting point.

Notes

New branch from cmake_build

Please consider creating a new branch out of cmake_build before doing changes, this would avoid unexpected merging conflicts.
Thanks,
Nassim

Build for AA

Add support for install target

make install - should ensure the library is build and put the build products in their rightful place.
library into ${prefix}/lib
include into ${prefix}/include/astroaccelerate
documentation into ${prefix}/share/astroaccelerate/doc
support tools ${prefix}/share/astroaccelerate/tools
where 'prefix' is desired install destination.

Multiple definitions of all __device__ __constant__ variables

Throughout the astro-accelerate code, there are many uses of CUDA constant memory. For example:

/Users/ebarr/Soft/TDT/astro-accelerate/lib/headers/device_dedispersion_kernel.h:
   12  // Stores temporary shift values
   13  __device__ __constant__ float dm_shifts[15500];
   14: __device__ __constant__ int   i_nsamp, i_nchans, i_t_processed_s, i_t_processed_c;
   15  //__device__ __shared__ float fa_line[ARRAYSIZE+1];
   16  __device__ __shared__ float2 fa_line[ARRAYSIZE+1];

/Users/ebarr/Soft/TDT/astro-accelerate/lib/smem_works/device_dedispersion_kernel.cu:
    6  // Stores temporary shift values
    7  __device__ __constant__ float dm_shifts[15500];
    8: __device__ __constant__ int   i_nsamp, i_nchans, i_t_processed_s;
    9  __device__ __shared__ float2 fa_line[ARRAYSIZE+1];
   10  __device__ __shared__ float2 fb_line[ARRAYSIZE+1];

As can be seen above, there are global constant memory blocks that are defined with the same name in many different files. When compiling against the libastro-accelerate.a static library (such as with Cheetah) this results in many linking errors, like below:

../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x0): multiple definition of `c_sqrt_taps'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x20): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0xa0): multiple definition of `fd_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0xc0): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0xfc0): multiple definition of `fc_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0xfe0): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x1ee0): multiple definition of `fb_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x1f00): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x2e00): multiple definition of `fa_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x2e20): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x3d08): multiple definition of `i_t_processed_c'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d28): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x3d0c): multiple definition of `i_t_processed_s'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d2c): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x3d10): multiple definition of `i_nchans'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d30): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x3d14): multiple definition of `i_nsamp'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d34): first defined here
../../libcheetah.a(Dedispersion.cpp.o):(.bss+0x3d20): multiple definition of `dm_shifts'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d40): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x0): multiple definition of `c_sqrt_taps'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x20): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0xa0): multiple definition of `fd_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0xc0): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0xfc0): multiple definition of `fc_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0xfe0): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x1ee0): multiple definition of `fb_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x1f00): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x2e00): multiple definition of `fa_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x2e20): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x3d08): multiple definition of `i_t_processed_c'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d28): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x3d0c): multiple definition of `i_t_processed_s'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d2c): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x3d10): multiple definition of `i_nchans'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d30): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x3d14): multiple definition of `i_nsamp'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d34): first defined here
../../libcheetah.a(PipelineHandlerFactory.cpp.o):(.bss+0x3d20): multiple definition of `dm_shifts'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d40): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x0): multiple definition of `c_sqrt_taps'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x20): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0xa0): multiple definition of `fd_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0xc0): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0xfc0): multiple definition of `fc_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0xfe0): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x1ee0): multiple definition of `fb_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x1f00): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x2e00): multiple definition of `fa_line'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x2e20): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x3d08): multiple definition of `i_t_processed_c'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d28): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x3d0c): multiple definition of `i_t_processed_s'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d2c): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x3d10): multiple definition of `i_nchans'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d30): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x3d14): multiple definition of `i_nsamp'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d34): first defined here
../../libcheetah.a(Sps.cpp.o):(.bss+0x3d20): multiple definition of `dm_shifts'
CMakeFiles/gtest_pipeline.dir/src/DedispersionTest.cpp.o:(.bss+0x3d40): first defined here
collect2: error: ld returned 1 exit status

These errors make it impossible to use libastro-accelerate.a To solve this problem these definitions need to either be moved into a common globals.h (for example) header with appropriate guards, or they need to be hidden in namespaces. Moving these common definitions to a global header would make most sense in this context.

Expand .gitignore list

Description
Expand the list of ignorable objects to the .gitignore list.

Outcome
A more comprehensive list will reduce the likelihood of accidentally committing unneeded and unwanted files into the repository.

Timeline
As soon as convenient.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Create an issue template


name: Feature Request
about: Make a feature request to help us improve


Description
Create an issue template for the repository so that issues can be tracked in a uniform way.

Outcome
A template for tracking issues.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): z.

Notes
N/A.

Error: missing fdas_test_parameters.h

I am currently building the cheetah pipeline via a docker container. When compiling astro-accelerate, I used the following command:

RUN cd /software/astro-accelerate/ &&
git checkout aa_interface &&
mkdir build/ &&
cd build/ &&
cmake -DENABLE_CUDA=true ../ &&
make -j 16 &&
make install

and I am getting the following error after make install:

CMake Error at lib/cmake_install.cmake:57 (file):
file INSTALL cannot find
"/software/astro-accelerate/lib/headers/fdas_test_parameters.h".
Call Stack (most recent call first):
cmake_install.cmake:42 (include)
Makefile:61: recipe for target 'install' failed
make: *** [install] Error 1

Has anyone seen this before. I checked the aa_interface branch and there is no such header file.

Uniform comment structure throughout the codebase

Description
A uniform consistent comment structure is needed throughout.

In order to make a start and to facilitate developers adding comments, empty templates can be added throughout the code, to be filled in with details as time goes on.

Outcome
A basic structure for making comments in the code.

To include methods and functions, as well as variables, and elsewhere as needed.

Comments should be Doxygen compatible.

Timeline
As soon as possible.

Interfaces
Will this feature result in a backwards-incompatible interface change: No.

Expected semantic version number increment category (Please indicate x.y.z): y.

Notes
N/A.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.