Activity for Heimdall
-
Tony Weaver posted a comment on discussion General Discussion
Andrew, I have not tested this recently to see if CUDA 11.8 is still causing an issue. I'm actually about to do some tests with cuda toolkit 12.X so as long as that works I don't really care. Besides, I've built a spack package to build heimdall and in there I've specifically put a requirement to not use 11.8. All that said, I guess this issue can be closed
-
Andrew Jameson posted a comment on discussion General Discussion
Thanks for reporting back Mariano, I'm glad you managed to solve this issue. Tony, I've noticed that no one had replied to your original report - is this still a problem for you?
-
Mariano Muscas posted a comment on discussion General Discussion
I solved the issue by myself. The problem was that in my cluster there are many versions of CUDA, and when I executed 'module load cuda/11.7,' some paths of the default version 12.0 remained.
-
Good morning, I've encountered a similar issue. When I run the program, I get this error: Could not setCudaDevice to 0: system has unsupported display driver / cuda driver combination ERROR: Pipeline creation failed Unknown error. Please contact the author(s). I'm using cuda/11.7 and I have two NVIDIA Ampere 40 GPUs on each node. I don't know how to solve it.
-
Xiaowei Wang posted a comment on discussion General Discussion
Hi Andrew, This time I have tried to re-installed heimdall and dedisp with cuda-toolkit-11.8 and GPU_ARCH=sm_75, and there is no MEMORY allocation error any more. But when I ran 'heimdall -G -f 39.fil', I got following new error: processing beam 1 allocating filterbank data vector for 262144 samples with size 176160768 bytes Allocating GPU... Process 0 using GPU 0 Process 0 setting CPU to spin nchans = 336 dt = 0.00126647 f0 = 1465 df = -1 Creating dedispersion plan... Initialisation complete. Using...
-
Oh, I misunderstood the meaning of the 'heimdall -G' command. Here are the latest output of ‘heimdall -G -f 34.fil’: processing beam 1 allocating filterbank data vector for 262144 samples with size 176160768 bytes Allocating GPU... Process 0 using GPU 0 Process 0 setting CPU to spin nchans = 336 dt = 0.00126647 f0 = 1465 df = -1 Creating dedispersion plan... DEDISP ERROR: Memory allocation failed ERROR: Pipeline creation failed Memory allocation failed
-
And when I tried to install the nvidia-cuda-toolkit in WSL2, CUDA seems to be installed in the path /usr/local/cuda-12.3. So I use './configure --with-cuda-dir=/usr/local/cuda' during the compiling of heimdall. Regards Xiaowei
-
Andrew, 1.The SIGPROC filterbank is download from http://astro.phys.wvu.edu/files/askap_frb_180417.tgz and here is it's header: 1: From the SIGPROC filterbank file '34.fil': Telescope = GMRT Source Name = src1 Obs Date String = 2019-07-18T14:53:15.3638 MJD start time = 58682.62031671037403 RA J2000 = 12:22:54.9282 RA J2000 (deg) = 185.728867385 Dec J2000 = 13:57:24.3873 Dec J2000 (deg) = 13.9567742544 Tracking? = True Azimuth (deg) = 0 Zenith Ang (deg) = 0 Number of polns = 2 (summed) Sample time...
-
Hello Xiaowei Wang, We would need a bit more information in order to help diagnose the issue: Could you please provide the header of the SIGPROC filterbank file you are processing? that might help us reproduce the issue. It would also be useful if you could run heimdall with the -G option which will provide more verbose output from heimdall - again this might provide some insights. What git hash are you using in your dedisp and heimdall builds? Can you advise how you compiled dedisp - i.e. what GPU_ARCH...
-
Hello! I have meet the same problem. What should i do to solve it?
-
And here is the output of 'nvidia-smi'.
-
Hello, I installed Heidall according to the instructions and it was successfully compiled. However when i tried to test it, there was a DEDISP error and i couldn't figure out what's wrong with it. So what should i do now? PS: I'm using Ubuntu-20.04 in WLS2 and CDUA-12.3.
-
The Candidate Time, is the time of the event, after dedispersion, at the highest frequency channel, ins seconds, that is offset from the start of the filterbank file that heimdall is processing.
-
mabaisen posted a comment on discussion General Discussion
OK, thanks for your help. I have one more question: What's the third output of heimdall "Candidate Time (s)" represent? Is it the observation time of one fil file?
-
Unfortunately no, just Sigproc filterbank files.
-
I think you want to be using the trans_gen_overview.py script to generate that plot. However, I'm now recollecting that this script was designed to use a candidates.dat file that was the result of performing co-incidence rejection with other beams (very PKS specific) via the coincidencer application that is part of the heimdall build. So if you are processing a single beam observation, then you would need to do something like: cat 2*.cand > all coincidencer all # this should generate an all_.cand...
-
I use "heimdall -f 2011-02-20-01:52:19.fil" just as shown in your example, and then i got a series of .cand files. I don't know why the .fil file is named 2011-02-20, but the .cand file is named 2011-02-19, for example a file name is "2011-02-19-17:52:19_03.cand". And does each line in the .cand file represent a candidate? There are nine parameters about heimdall's output What's the "Candidate Time (s)" represent？Is it the width of a certain candidate？ And can i cut the .fil file use heimdall? My...
-
xiggystardust modified a comment on discussion General Discussion
I'm talking about making this whole-summary plot... looking at the trans_gen it seems like that doesn't quite make this, but maybe I'm understanding the code wrong: https://a.fsdn.com/con/app/proj/heimdall-astro/screenshots/FRB131222.png/max/max/1 (edit to add: is there a way to generate that plot from within a standard heimdall run or is it always done after-the-fact with a script?)
-
I'm talking about making this whole-summary plot... looking at the trans_gen it seems like that doesn't quite make this, but maybe I'm understanding the code wrong: https://a.fsdn.com/con/app/proj/heimdall-astro/screenshots/FRB131222.png/max/max/1
-
This feature should still be available. If you are using the Scripts/trans_gen_overview.py there is an option called -just_time_dm which is what I think you want.
-
We're trying to output the classic "heimdall graph" with the DM vs time plot along the bottom but can't see a switch to do this in command-line; is this feature still available?
-
Hi, you just need to ensure the csh interpreter package is installed. Alternately, just execute the contents of the bootstrap script directly.
-
When i input ./bootstrap, i have the problem below. bash: ./bootstrap: /bin/csh: bad interpreter:No such file or director Git the code, don't have the file.I don't know how to find the file. Could you please help me see how to solve this problem?
-
Yes, they should be powers, I've checked in a correction to SigprocFile.C - thanks for the error report!
-
Andrew Jameson committed [69a33d] on Code
fix incorrect power calculation in sigproc 32fp unpacker
-
I built heimdall (and all dependencies) using Cuda toolkit 11.8 using a GeForce RTX 3080. All the code builds fine but when I run it I get the following: processing beam 1 allocating filterbank data vector for 262144 samples with size 1476395008 bytes Allocating GPU... Process 0 using GPU 0 Process 0 setting CPU to spin Unknown error. Please contact the author(s). Based on the output, the problem seems to be in pipeline.cu, allocate_gpu, lines 98 and 111 ( in testing I included the yield CPU flag...
-
Kiran Shila posted a comment on discussion General Discussion
On lines 105 and 106 of SigprocFile.C it looks like those ^ operations are supposed to be powers, not XORs. Perhaps they should be replaced with 1LL << 31 and 1 << 28, respectively.
-
Hi Vinay, I've not come across gpuocelot before, so I cannot say anything definitive. It does appear to be an unmaintained project now, and given how old CUDA 5/6 are I doubt it would work easily (or perhaps at all). In order to compile both dedisp and heimdall, a CUDA installation would be required. I'm not sure if it is possible to install CUDA without the full SDK bundle. Cheers, Andrew
-
Vinay posted a comment on discussion General Discussion
Hiiii, I've few questions. Is installing heimdall with GPU Ocelot possible ? https://github.com/gtcasl/gpuocelot I understand that CUDA 6.0 is mandatory, but is it possible with lower CUDA versions ? I'm asking in continuations with the GPU Ocelot because it has been tested till CUDA 5. and Do one needs to install the full CUDA (say 12.0 installation) with NVIDIA nsight and other softwares which gets automatically installed while installing CUDA ? Vinay
-
You should be able to see the change to kernels.cuh in the commit listed below and apply it to your fork of dedisp. https://github.com/ajameson/dedisp/commit/0f763a3bd1c726d9363c63cae855c844e9549d88
-
Hi Joe, I believe the texture related code was only ever intended for use on very old GPUs (compute capability < 2), so I doubt that any users of dedisp would be using that code. To solve the compilation issue, I've added some #ifdefs around the texture code so that it will now compile without any texture calls in cuda12 and above. Hope this solves your problem. Cheers, Andrew
-
Joseph Glaser posted a comment on discussion General Discussion
Hey @ajameson, I am working on getting Heimdall and its pre-req DEDISP installed on one of our GPU nodes which uses Turing architecture on AMD Eypc chips. I nearly have everything set up, but running into an issue that seems to be related to a now protected name in CUDA 12 ("texture"). The following is the output when following the build instructions on this fork of the original (https://github.com/GReX-Telescope/dedisp): (pulsar) [sysadmin@titan build]$ make [ 14%] Building CUDA object CMakeFiles/dedisp.dir/src/dedisp.cu.o...
-
Thanks Shin, That header was very helpful, and it allowed me to reproduce the bug. The issue was that the length of this file, in combination with the block length used by heimdall (262144 samples) resulted in the final block of data being less than the default baselining length (2s). If you were to change the baseline length on the command line (e.g. -baseline_length 1), then the file would be processed without error. I've made the baselining algorithm more robust to this sort of error in a small...
-
Andrew Jameson committed [4e337b]
Prevent baselining from running on too few samples
-
Shinnosuke Hisano posted a comment on discussion General Discussion
Hi Andrew, This is the header of my file. I have installed them about 2 months ago without specifying the versions. When was the most recent versions released? Data file : p2030_53466_44994_0114_G56.60-04.69.N_6.decimated_1.fil Header size (bytes) : 321 Data size (bytes) : 540000000 Data type : filterbank (topocentric) Telescope : Arecibo Datataking Machine : ????? Source Name : G56.60-04.69.N Source RA (J2000) : 19:53:40.1 Source DEC (J2000) : +18:34:00.2 Frequency of channel 1 (MHz) : 1469.804688...
-
Hi Shin, Can you provide the header for the filterbank file you are processing? are you using the most recently available versions of dedisp and heimdall?
-
Hello, I faced a memory issue when I ran this command. heimdall -f p2030_53466_44994_0114_G56.60-04.69.N_6.fil -dm 0 254.4 -boxcar_max 512 terminate called after throwing an instance of 'thrust::system::system_error' what(): transform: failed to synchronize: cudaErrorIllegalAddress: an illegal memory access was encountered This seems to happen when the file produces many candidates. How can I fix this issue? My cuda configuration is: nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2022 NVIDIA...
-
Hello, I faced a memory issue when I ran this command. heimdall -f p2030_53466_44994_0114_G56.60-04.69.N_6.fil -dm 0 254.4 -boxcar_max 512 terminate called after throwing an instance of 'thrust::system::system_error' what(): transform: failed to synchronize: cudaErrorIllegalAddress: an illegal memory access was encountered This seem to happen when the file produces many candidates. How can I fix this issue? My cuda configuration is: nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2022 NVIDIA...
-
Hello, I faced a memory issue when I ran this command. heimdall -f p2030_53466_44994_0114_G56.60-04.69.N_6.fil -dm 0 254.4 -boxcar_max 512 terminate called after throwing an instance of 'thrust::system::system_error' what(): transform: failed to synchronize: cudaErrorIllegalAddress: an illegal memory access was encountered This seem to happen when the file produces many candidates. How can I fix this issue? My cuda configuration is: nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2022 NVIDIA...
-
Leon Houben posted a comment on discussion General Discussion
Hi Andrew, Thanks for the quick reply! Matching the cuda versions has done the trick. Could have thought of that myself as well, but happy that it is now running within a singularity image without any obvious problems. :)
-
I recommend first getting the dedisp and heimdall to work outside of a container. Next I would check that you have compiled the dedisp and cuda for the GPU/CUDA architectures that you will be executing within the container. For dedisp, this is set via the GPU_ARCH variable in the Makefile. For heimdall this is controlled in an environment variable called CUDA_NVCC_FLAGS. I would typically set this to something like "-O2 -gencode arch=compute_75,code=sm_75" Finally I would ensure that your cuda compilation...
-
Hi all, I got the same error message as Felipe after installing heimdall in a docker container: ERROR: Pipeline creation failed Unknown error. Please contact the author(s). The container is converted to a singularity image and runs on a GPU cluster. Output of nvidia-smi: +-----------------------------------------------------------------------------+ | NVIDIA-SMI 460.91.03 Driver Version: 460.91.03 CUDA Version: 11.2 | |-------------------------------+----------------------+----------------------+...
-
Andrew Jameson committed [c3956a]
improving autoconf configuration
-
Hello Everyone, I am working on getting an install of Heimdall onto our GPU subcluster for some of our researchers. However, I am reaching a compile issue that I cannot seem to get around. For some reason, when I follow the install guidelines and do the following: ./configure --prefix=/opt/astro/heimdall --with-dedisp-dir=/opt/astro/dedisp/ --with-cuda-dir=/opt/cuda-11.1/ --with-thrust-dir=/opt/astro/thrust --with-psrdada-dir=/opt/astro/psrdada make install I get the following error code: [jglaser@gpu01...
-
Hello Everyone, I am working on getting an install of Heimdall onto our GPU subcluster for some of our researchers. However, I am reaching a compile issue that I cannot seem to get around. For some reason, when I follow the install guidelines and do the following: ./configure --prefix=/opt/astro/heimdall --with-dedisp-dir=/opt/astro/dedisp/ --with-cuda-dir=/opt/cuda-11.1/ --with-thrust-dir=/opt/astro/thrust --with-psrdada-dir=/opt/astro/psrdada make install I get the following error code: [jglaser@gpu01...
-
Andrew Jameson committed [1475ca]
Reduce the limitation on dedisp to be a modulo 16 requirement
-
Andrew Jameson committed [182e2e]
Add improvement suggested by Ewan to linear_stretch_functor
-
I've updated heimdall with the patches suggested in this thread - thanks for your help.
-
I've updated heimdall with the patches suggested in this thread - thanks for your help.
-
Andrew Jameson committed [d8d6dc]
warning if nchan % 32 != 0
-
Andrew Jameson committed [cd9182]
python3 compatibility
-
Andrew Jameson committed [49bd67]
Remove dependency on psrdada
-
Hi Nathaniel, I believe this error comes from dedisp, which only supports dedispersion with filterbank data with a number of channels that is a multiple of 32. I might add a better error message to heimdall/dedisp to warn of this problem.
-
Nathaniel Fairfield posted a comment on discussion General Discussion
The problem appears to be the number of channels (165 for the file above). If I use 256 channels (some of which are mostly filtered by the bandpass), then I don't get the error.
-
I'm trying to run heimdall on some .fil files I've created from GB 20 Skynet psrfits files. Heimdall seems to run fine on an example file (GBT_Lband_PSR.fil from Scott Ransom's tutorial), but when I run it on my .fil files, I get the error below. I also tried running presto's readfile on my file (see below). Is it just that heimdall doesn't handle 16 bits per sample and I need to downsample? Thanks! processing beam 1 allocating filterbank data vector for 262144 samples with size 173015040 bytes Allocating...
-
I'm trying to run heimdall on some .fil files I've created from GB 20 Skynet data files. Heimdall seems to run fine on an example file (GBT_Lband_PSR.fil from Scott Ransom's tutorial), but when I run it on my .fil files, I get the error below. I also tried running sigproc's readfile on my file (see below). Is it just that heimdall doesn't handle 16 bits per sample and I need to downsample? Thanks! processing beam 1 allocating filterbank data vector for 262144 samples with size 173015040 bytes Allocating...
-
Do you have a GPU? What do you get when you run nvidia-smi?
-
Felipe Corro-Guerra posted a comment on discussion General Discussion
Hello, I installed heimdall acoording to the instructions in the wiki, and the suggestions in this thread. Then I download the example data, but when I try to run heimdall -f 2011-02-20-01\:52\:19.fil I get: Could not setCudaDevice to 0: no CUDA-capable device is detected ERROR: Pipeline creation failed Unknown error. Please contact the author(s). What should I do? I can provide more information if needed.
-
Thanks every one! That last suggestion solved this installation issue!
-
I think you just need to ensure that your LD_LIBRARY_PATH includes the installation directory of the dedisp library. I'm guessing it would be something like /home/felipe/software/dedisp/lib
-
So I made the edits Nathaniel proposed (Thank you very much!), and it seems to have worked, there is no error message, but when I try to run ./heimdall -h in bin it shows: ./heimdall: error while loading shared libraries: libdedisp.so.1: cannot open shared object file: No such file or directory Also this is what make install showed, am I missing something? Making install in Pipeline make[1]: Entering directory '/home/felipe/software/heimdall/Pipeline' make[2]: Entering directory '/home/felipe/software/heimdall/Pipeline'...
-
(sorry to be spammy. I also had to comment out #include "tmutil.h" in Applications/Candidates.C ... which didn't seem to be doing anything.)
-
I was able to fix it by giving a proper relative path to libtool in cudalt.py
-
I was able to fix it by giving a proper relative path to libtool in cudalt.py
-
I'm having the exact same issue (and did the exact same tweak to cudalt.py). FYI, here is a colab notebook that reproduces the issue: https://colab.research.google.com/drive/1Ow3e_GzajjuHEBIvbxuCj7Y2qCCuVG1V?usp=sharing
-
Hello, I used print(command) instead ofprint command in cudalt.py and now it shows the following error. Making install in Pipeline make[1]: Entering directory '/home/felipe/software/heimdall/Pipeline' /bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -I/usr/local/cuda/include -o libhdpipeline.la -rpath /home/felipe/software/heimdall/lib default_params.lo error.lo parse_command_line.lo clean_filterbank_rfi.lo get_rms.lo matched_filter.lo remove_baseline.lo find_giants.lo label_candidate_clusters.lo...
-
Hello, Thanks for your answer. It semm to have changed, but now it shows a different problem in cudalt.py Making install in Pipeline make[1]: Entering directory '/home/felipe/software/heimdall/Pipeline' depbase=`echo default_params.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../Network -I../Formats -I/home/felipe/software/dedisp/include -I/usr/local/cuda/include -I/home/felipe/software/boost_1_76_0 -g -O2 -I/usr/local/cuda/include...
-
Looks like the cudalt.py utility script assumed the python interpreter is always located in /usr/bin/python. I've pushed a commit to heimdall which removes this requirement. Could you try to pull the latest version and recompile?
-
Andrew Jameson committed [dde39d]
Remove unncessary PSRDADA include and fix issue with python intepreter
-
Hi, I think I followed the installation correctly, however I get an error when I run make install after I use ./configure --prefix=$HOME/software/heimdall/linux_64 --with-psrdada-dir=$HOME/software/psrdada --with-dedisp-dir=$HOME/software/dedisp --with-cuda-dir=/usr/local/cuda --with-boost=$HOME/software/boost_1_76_0 I can provide more information if needed. Before hand thanks. This is what the console shows after running make install: Making install in Pipeline make[1]: Entering directory '/home/felipe/software/heimdall/Pipeline'...
-
Ryan Lynch posted a comment on discussion General Discussion
Yes, dedisp seemed to build fine. The library is in /home/pulsar_rhel7/lib and the header is in /home/pulsar_rhel7/include. I'm pointing to each of these with the --with-dedisp-lib-dir and --with-dedisp-include-dir options when I run configure.
-
Hi Ryan, These look like linking errors for dedisp, have you managed to compile dedisp as per the instructions on the Heimdall Wiki? https://sourceforge.net/p/heimdall-astro/wiki/Install/ Cheers, Andrew
-
That helped, but I still run into an error later on. make all-recursive make[1]: Entering directory `/home/pulsar_rhel7/src/heimdall' Making all in Pipeline make[2]: Entering directory `/home/pulsar_rhel7/src/heimdall/Pipeline' depbase=`echo default_params.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../Network -I../Formats -I/home/pulsar_rhel7/src/dedisp/include -I/opt/local/cuda101/include -g -O2 -I/opt/local/cuda101/include...
-
Hi Ryan, This error is due to the lack of C++11 support in the default compiler options for gcc 4.8.5. I think this could have been rectified by adding a -std=c++11 to your CXXFLAGS environment variable. However, I have pushed a commit to the master branch which will allow compilation even without this option. Could you please try it and check? Cheers, Andrew
-
Andrew Jameson committed [e0c1af]
fix compilation issue for older gcc compilers which do not have CXX11 support
-
Hello, I'm trying to install heimdall on a Red Hat 7 system with an nVidia RTX2080 and cuda 10.1. The C compiler is gcc 4.8.5. When running make I get the following error Making all in Pipeline make[2]: Entering directory `/home/pulsar_rhel7/src/heimdall/Pipeline' ../cudalt.py pipeline.lo /opt/local/cuda101/bin/nvcc -Xcompiler "-I. -I.. -I.. -I../Network -I../Formats -I/home/pulsar_rhel7/src/dedisp/include -I/opt/local/cuda101/include " -I/opt/local/cuda101/include --compiler-options=\" -I/home/pulsar_rhel7/include...
-
Andrew Jameson committed [0f195f]
Removed the PSRDADA dependency for key_t type
-
Andrew Jameson committed [798707]
Add option to control how heimdall rescales filtered time series.
-
Use
-
Use
-
Use
-
Maura Pilia posted a comment on discussion General Discussion
Dear Andrew, Thank you for your prompt reply. The data is floating point. We will now try to flatten our bandpass so that the data can be quantised.
-
Dear Maura, When you say you are using 32-bit filterbank files, are these 32-bit unsigned integers or 32-bit floating point. The dedispersion library used by heimdall (dedisp) does not support 32-bit input, so please try using a lower bit-width format filterbank file and compare again. I'm a little surprised that the 32-bit filterbank file ever worked properly.
-
Hello, we have been using heimdall for a while on 32-bit filterbank files of this kind: header /data/20200521_TauA/beam_1590057362.830215_win_fft_av.fil Data file : /data/20200521_TauA/beam_1590057362.830215_win_fft_av.fil Header size (bytes) : 325 Data size (bytes) : 106550394880 Data type : filterbank (topocentric) Telescope : ??????? Datataking Machine : PSPM Source Name : CRABNEBULA Source RA (J2000) : 05:34:31.9 Source DEC (J2000) : +22:00:52.2 Start AZ (deg) : 1.000000 Start ZA (deg) : 1.000000...
-
Parul Janagal posted a comment on discussion General Discussion
Dear Sir, Thank you for the response. It would be of great help if you could tell me how to downsample the number of channels. Thank you, Parul
-
Hi Parul, Dedisp has a hard-coded internal limit of 8192 channels and this filterbank file is exceeding that limit. I'm unsure whether this limit can be increased, but perhaps you could try down sampling the number of channels (by a factor of two) to 7424 channels and try processing it again? Regards, Andrew
-
Dear Sir, I am getting the following error after running heimdall. Is there any limitation to channels etc., for which the program cannot work. $ heimdall -f FRB121102.fil DEDISP ERROR: No. channels exceeds internal limit ERROR: Pipeline creation failed Unknown error. Please contact the author(s). The header information of the .fil file is - $ header FRB121102.fil Data file : FRB121102.fil Header size (bytes) : 348 Data size (bytes) : 53352071168 Data type : filterbank (topocentric) Telescope : GBT...
-
Sorted. It was a path related issue.
-
I've recently installed heimdall on a workstation with Nvidia Quadro P620. Can someone please descibe this error that I'm facing and how can I resolve it? $ heimdall -f BJ0009_02551.fil DEDISP ERROR: Memory allocation failed ERROR: Pipeline creation failed Memory allocation failed
-
Andrew, I tested dedisp/heimdall on two files, one that worked previously and the one the got the memory error and both worked this time (without the need for the no_rfi options). Thank you Tony On Wed, Oct 23, 2019 at 10:29 PM Tony Weaver aweaver1@users.sourceforge.net wrote: Andrew, Thanks for the updates and fixes. I will grab the new software tomorrow and let you know Tony On Wed, Oct 23, 2019 at 9:40 PM Andrew Jameson ajameson@users.sourceforge.net %0Dajameson@users.sourceforge.net wrote: Hi...
-
Andrew, Thanks for the updates and fixes. I will grab the new software tomorrow and let you know Tony On Wed, Oct 23, 2019 at 9:40 PM Andrew Jameson ajameson@users.sourceforge.net wrote: Hi Tony, Devnash, It turns out there was a bug in dedisp which was causing this error with non power of two channelisation in the filterbank files, specifically for situations where (nchan * (nbit / 32)) % 32 != 0 I've checked in a change to dedisp along with some other minor fixes to heimdall that were causing warnings...
-
Hi Tony, Devnash, It turns out there was a bug in dedisp which was causing this error with non power of two channelisation in the filterbank files, specifically for situations where (nchan * (nbit / 32)) % 32 != 0 I've checked in a change to dedisp along with some other minor fixes to heimdall that were causing warnings with cuda-memcheck. Can you please try updating dedisp and heimdall and let me know if this fixes your issue?
-
Andrew Jameson committed [ca4cc0]
Re-introduced check for too few samples in hd_execute
-
Andrew Jameson committed [5b769f]
Allow for out of source builds
-
Andrew Jameson committed [135348]
Merge branch 'master' of ssh://git.code.sf.net/p/heimdall-astro/code
-
Andrew Jameson committed [f3e02b]
Prevent matched filter from reading past the end of the input
-
Ok then probably not the tensor cores. The Titan has twice as many CUDA cores as the 2070. Is it possible the transpose_kernel isn't getting the correct info for the GPU or the calculations are potentially off for cards of that size? I'm wondering if dedisp could be re-worked to use some newer CUDA features like cuBLAS On Wed, Oct 23, 2019 at 11:13 AM Anthony J. Weaver Jr. anthony.weaver@fandm.edu wrote: Could this be a hardware/cuda toolkit issue. The 1070 and 2070 only have CUDA cores, but the...
-
Devansh posted a comment on discussion General Discussion
RTX 2070 also has tensor cores but things work fine on that GPU.
-
Could this be a hardware/cuda toolkit issue. The 1070 and 2070 only have CUDA cores, but the Titan has CUDA cores and Tensor cores. The dedisp package was written a relatively long time ago and really does not seem to have been updated at all (at least based on info in github) On Wed, Oct 23, 2019 at 10:53 AM Devansh devanshkv@users.sourceforge.net wrote: Hi Andew, The large gulp size is because of the low frequency data. I am also running this stuff on a Titan-RTX with 24G RAM. I tried with the...
-
Hi Andew, The large gulp size is because of the low frequency data. I am also running this stuff on a Titan-RTX with 24G RAM. I tried with the smaller (default) gulp size: heimdall -boxcar_max 64 -f L343162_SAP0_BEAM127.fil -dm 10 100 It works on GTX1070 Ti, RTX 2070 but fails on Titan-RTX. It runs on Titan-RTX if I add -rfi_no_broad to the above command. If you check the cuda-memcheck output, its the transpose_kernel which fails, which is in the dedisp library. Regards, Devansh
1 >
