AT3-1233 fix InverseFilterbank tests
fix CUDA compilation
AT3-1233 fix dspsr segfault; InverseFilterbank::make_preparations
After reporting the number of seconds Finished, carriage return
ska-pst-dspsr-builder bumped from 0.3.4 to 0.3.5
version changed to 2026-03-31
AT3-1229 updated copyright years and docstrings
AT3-1229 more unit tests fixed after changing the interface to the
AT3-1229 unit tests fixed
AT3-1229 InverseFilterbank instances running in different threads
replace assert with (more informative) throw InvalidRange Error
Hi Emmanuel, thank you for this additional information. I could reproduce the error on my end (tutorial failure) and have just checked in some fixes to psrdada: the psrdada library has been evolving and at some point it stopped understanding the old CPSR2 data files. This backward compatibility has been restored. Could you please git pull the latest version of psrdada and compile and install it? You might also need to recompile dspsr and install it again too.
Hi @straten, Thanks so much for your prompt response! For clarity, I'm basically running dspsr in the same way suggested in this tutorial, i.e., by supplying a key file to dspsr after having run the dada_ utilities described above so that dspsr can process data stored in a ring buffer; the specific dspsr command I use is: dspsr -F 128:D -E 1644-4559.eph -P 1644-4559.polyco dada.info -V So I'm not supplying the 1644-4559.dada test file directly to dspsr, but instead (trying to) load the data into...
Hi Emmanuel, I need to have a closer look at the first error that you reported, but the clue to the second error is ASCIIObservation: failed read HDR_VERSION It appears that your ASCII header contains only the text HDR_SIZE 4096 Does this sound correct to you? DSPSR is expecting HDR_VERSION 1.0 and the required keywords listed above: ASCIIObservation::load required keywords: TELESCOPE SOURCE FREQ BW NPOL NBIT TSAMP UTC_START OBS_OFFSET ... hope this helps!
As a follow-up, I've been trying different things and have a likely related view of the above issue. I tried out the following lines to load test data into a PSRDADA ring buffer and then execute dspsr: dada_db -b 33554432 -n 16 dada_example_writer header.txt dada_diskdb -f 1644-4559.dada & (Using the commands given in the dspsr-DADA tutorial linked above did not work; I can indeed retrieve the header data when running the above and then executing dada_header -v.) When running dspsr, I see the following:...
ipc_alloc errors when trying to have DSPSR run on a DADABuffer
DSPSR compile error
Thank you for confirming!
Hi Willem, Awesome, after a fresh pull, the build goes through just fine. Thank you very much!
Merge branch 'at3-1184-set-obsnchan-to-pipeline-input-nchan'
Thanks, Ramesh! As an optimization, pkg-config is stripping /home/psr/install/include from the PSRCHIVE_CFLAGS that is passed to the dspsr build tools. However, the compiler appears to be ignoring C_INCLUDE_PATH and therefore this include path is getting missed. I've checked in a fix to the dspsr configure.ac file that should disable pkg-config from stripping system include header paths from its output, by defining PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 before calling AX_PKG_CHECK_MODULES # ensure that...
Thanks, Ramesh! As an optimization, pkg-config is stripping /home/psr/install/include from the PSRCHIVE_CFLAGS that is passes to the dspsr build tools. However, the compiler appears to be ignoring C_INCLUDE_PATH and therefore this include path is getting missed. I've checked in a fix to the dspsr configure.ac file that should disable pkg-config from stripping system include header paths from its output, by defining PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 before calling AX_PKG_CHECK_MODULES # ensure that...
Merge branch 'master' of ssh://git.code.sf.net/p/dspsr/code
bugs/133 ensure that system include paths are not stripped by pkg-config
bugs/133 ensure that system include paths are not stripped by pkg-config
Hi Willem, Yes, C_INCLUDE_PATH was set, as reporduced below: root@5b5776898130:~/build/dspsr# echo $PKG_CONFIG_SYSTEM_INCLUDE_PATH root@5b5776898130:~/build/dspsr# echo $C_INCLUDE_PATH /home/psr/install/include BTW, I am building dspsr in a docker container (based on debian:bookworm) - is that something to watch out? Cheers, Ramesh
AT3-1220 update dsp-tools dependency to 0.3.4
Thanks, Ramesh. Could you please check if the PKG_CONFIG_SYSTEM_INCLUDE_PATH environment variable is set on your system, and if it includes /home/psr/install/include? I did the following test on my laptop, which can reproduce the "stripping" of the first -I output e$ pkg-config --cflags-only-I psrchive -I/home/willem/Pulsar/include -I/home/willem/Pulsar/include/epsic $ echo $PKG_CONFIG_SYSTEM_INCLUDE_PATH $ export PKG_CONFIG_SYSTEM_INCLUDE_PATH=/home/willem/Pulsar/include $ pkg-config --cflags-only-I...
AT3-1184 verbosity fix
AT3-1184 LoadToFITS sets OBSNCHAN to the number of channels at the time of detection
Merge branch 'master' into at3-1184-set-obsnchan-to-pipeline-input-nchan
Hi Willem, I get: root@fcfc35493bb0:/home/psrtest/build/psrchive# pkg-config --cflags-only-I psrchive -I/home/psr/install/include/epsic Cheers, Ramesh
AT3-1220 simple fix for GPU Median MAD Rescale Calculator
Thanks for that, Ramesh. Stranger still $ grep PSRCHIVE_.*= Makefile PSRCHIVE_ACLOCAL = /home/psr/install/share/aclocal PSRCHIVE_CFLAGS = -I/home/psr/install/include/epsic PSRCHIVE_INCLUDE = -I/home/psr/install/include/epsic PSRCHIVE_LIBS = <blah blah blah> shows that only the epsic headers folder is included in PSRCHIVE_CFLAGS ... what is returned when you run the following command? pkg-config --cflags-only-I psrchive
Hi Willem, Here is the Makefile. Cheers, Ramesh
Error running ./bootstrap
Excellent! Sounds like things are working. Thanks for the confirmation.
Hi Ramesh, that's quite strange because most of the DSPSR build depends on PSRCHIVE. It's also odd to see /home/psr/install/include/epsic on the compilation command line but not /home/psr/install/include ... Could you please also attach a copy of Kernel/Formats/fits/Makefile from your DSPSR build directory?
Hi Willem, A quick follow up: I used a quick workaround of setting export CXXFLAGS=-I/home/psr/install/include, running configure again and got dspsr to compile. Thanks!
Hi Willem, A quick follow up: I used a quick workaround of setting export CXXFLAG=-I/home/psr/install/include, running configure again and got dspsr to compile. Thanks!
DSPSR compile error
No need to apologize at all, and thanks a lot for not giving up on me. Here are the results of the above suggestions: Step 1: jg168@b22-l-jg168-phy:/opt/prog/psrchive$ grep AC_INIT configure.ac AC_INIT([PSRCHIVE],[2026-02-26],[psrchive-developers@lists.sourceforge.net]) So I think that passes Step 2: `jg168@b22-l-jg168-phy:/opt/prog/psrchive$ make where PSRCHIVE 2026-02-26 will be installed in /opt/prog/pulsar/` So I think that passes as well. So moving onto the make install step: jg168@b22-l-jg168-phy:/opt/prog/psrchive$...
Thanks for attaching the debug output from pkg-config. It confirms that the configuration file is found in what appears to be the expected location found: /opt/prog/pulsar/lib/pkgconfig/psrchive.pc and that the version in this file is as reported added dependency [psrchive = 2025-10-31] to list With apologies for what must feel like running in circles, could you please try the following? In the PSRCHIVE source code directory (/opt/prog/psrchive), run grep AC_INIT configure.ac It should return AC_INIT([PSRCHIVE],[2026-02-26],[psrchive-developers@lists.sourceforge.net])...
Happy to look at it then, and -- again -- thank you for your patience and all of your help.
Sorry: for git pull this is the output: jg168@b22-l-jg168-phy:/opt/prog/psrchive$ git pull Already up to date. And the output is hopefully attached below.
Hi Joseph, your pkg-config question prompted me to write some long-overdue documentation of this feature: https://psrchive.sourceforge.net/pkg-config/ If you have some time after we get to the root of the problem, I'd appreciate your feedback on this documentation.
Hi Joseph, for "Theory A" could you please run git pull in the top-level folder of the psrchive source code? (It looks like you ran this command in /opt/prog/dspsr) Also, for Theory B, you forgot to paste the output of pkg-config --debug psrchive :-)
Thanks. When I did git pull I got the following: jg168@b22-l-jg168-phy:/opt/prog/dspsr$ git pull Already up to date. So that rules out Theory A (unfortunately, I think that would have been an easier fix) For Theory B:, make where returns PSRCHIVE 2026-02-26 will be installed in /opt/prog/pulsar/ but, when I run pkg-config -- debug I get the following (adding the "|" and text afterwards returned nothing, which is why I'm attaching the longer output here. Again, sorry for all the trouble, and thanks...
Hi Joseph, Could you please test the following theories? Theory A: git fetch updates your copy of the remote repository, but it doesn't actually merge the remote copy into your local copy. You could test this by running git pull in the top-level folder of the psrchive source code; if this returns 'Already up to date.' then this theory is debunked. If it shows merging activity, then this could be the issue. Theory B: There might be two installations of psrchive on your system, and pkg-config is picking...
Thanks a lot, this was very helpful. However, I'm now running into a new (psrchive) related issue `checking pkg-config is at least version 0.9.0... yes checking for psrchive >= 2026-02-26 ... no configure: error: Package requirements (psrchive >= 2026-02-26 ) were not met: Package dependency requirement 'psrchive >= 2026-02-26' could not be satisfied. Package 'psrchive' has version '2025-10-31', required version is '>= 2026-02-26'I'm a little puzzled, since installed psrchive on this machine this...
Thanks for uploading the git log output. It shows that the software was almost 8 years old, and I agree that updating dspsr is a wise thing to do, owing to changes in the libraries on which it depends (primarily PSRCHIVE). This leads to the next error. Since 2018, both DSPSR and PSRCHIVE have been updated to manage more third-party package dependencies using pkg-config. This includes the dependency between DSPSR and PSRCHIVE. You can test the version of pkg-config installed on your system with $...
Sorry for another post, but I decided to do a fresh install of dspsr, and ./bootstrap ran just fine, but ./configure gave the following error message: configure: error: Package requirements (psrchive >= 2026-02-26 ) were not met: Package 'psrchive', required by 'virtual:world', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables PSRCHIVE_CFLAGS and PSRCHIVE_LIBS to avoid the...
Thanks a lot for this, and sorry for the delayed reply. Attached is what I get when I run "git log" -- which seems to be much longer than what you pasted above... Hope all is well and stays that way.
release 2026-02-26
make dist bug fix: remove Signal/General from libdspsrmore SOURCES
adapt to breaking changes in psrchive 2026-02-26
Hi Joseph, I checked on my end, and HAVE_MPI no longer appears in Kernel/Classes/Makefile.am. What version of DSPSR are you trying to compile? When I run git log in the top-level of the source code directory, I get commit b8de2313aefd9252ae15fec66c19ec0ea384399b (HEAD -> master, origin/master, origin/HEAD) Author: Willem van Straten <vanstraten.willem@gmail.com> Date: Fri Feb 13 09:53:47 2026 +1300 Cheers, Willem
Error running ./bootstrap
Thanks Willem! I had an issue trying to make the formats listed minimal, as the folder of dspsr appeared as executable for some reason in my installation, instead of just a folder. So I'll try the solution and let you know if it is working for me. Thanks again!
And thanks for the file! I think that I've fixed the S2 bug in commit b8de2313aefd9252ae15fec66c19ec0ea384399b (HEAD -> master, origin/master, origin/HEAD) Author: Willem van Straten <vanstraten.willem@gmail.com> Date: Fri Feb 13 09:53:47 2026 +1300 bugs-131 (fix) tci_file_hdr_init uses [safe] memset instead of [questionable] sprintf to initialize memory
bugs-131 (fix) tci_file_hdr_init uses [safe] memset instead of [questionable] sprintf to initialize memory
bugs-131 (optimization) dsp::Mark4File::find_sync performs one big read instead of many small reads
Thank you for this extra information, which provides a good clue. The last line of output from dspsr before the buffer overflow is detected ("dsp::File::create testing S2") indicates that the S2 file format test code has a bug leading to the buffer overflow. I'll try to fix this, but in the meantime you can work around the problem by removing "s2" from the bandends.list text files in your top-level DSPSR build directory. In fact, I suggest that you remove most of the file formats listed in this file...
Hello Willem, thanks for the fast reply. Here are the outputs of 1. and 2. I also uploaded the file I'm using for this test to Google Drive. Please request access so I can grant you permission to download it: https://drive.google.com/drive/folders/1dZC9w4r6sCoba9RCQ9DkUstHQW3-xV4t?usp=sharing One thing that could came handy is the following: we can fold the files using PRESTO, and we pretty much can use any rutine of it (I haven't encoutered an incompatibility). I was now trying to fold using dspsr,...
Hi Susana, Thanks for the bug report. To help with debugging, could you please try the following? Run digihdr ds8192_J0835-4510_A2_20260206_223701.fil (cut and paste the output to this thread) Run dspsr -V <all other command line options> ds8192_J0835-4510_A2_20260206_223701.fil (and attach the very verbose output to this ticket) If the data are not sensitive, it would be very helpful if you could make the file available somewhere for download and provide the dspsr command line that you run on it....
Question regarfing header of filterbank, possible incompatible
AT3-1184 LoadToFITS sets OBSNCHAN to original/source input nchan
AT3-1114 review comments addressed - part two
AT3-1114 review comments addressed
AT3-1114 ASCIIObservation successfully parses and unloads source names containing spaces
AT3-1114 fixed compilation errors
AT3-1114 ascii_header_get "%S" extension parses strings containing spaces
dspsr fails to apply scales and offsets of contiguous PSRFITS files
dspsr fails to apply scales and offsets of contiguous PSRFITS files
Fix reviewed and merged to the main/master branch on 2025 Dec 10.
AT3-1144 optionally set digifits output path and strftime pattern
declare overrides in SingleThread.h
Merge branch 'at3-1132-implement-weights-fscrunch'
Merge branch 'bugs-130-fix-fits-scloffs'
Merge branch 'at3-1132-implement-weights-fscrunch' of ssh://git.code.sf.net/p/dspsr/code into at3-1132-implement-weights-fscrunch
AT3-1132 feedback on MR addressed
bugs-130 used fused multiply-add (FMA) to apply scales and offsets
Merge branch 'master' of https://git.code.sf.net/p/dspsr/code into HEAD
AT3-1142 LoadToQuantize::set_output_data method added
AT3-1132 revert AT3-1088 DSPSR_BASE_IMAGE ska-pst-psrchive back to ska-pst-dspsr-builder (grasping at straws)
AT3-1132 ensure that input zero weights yield correctly zeroed fscrunched weights
AT3-1132 new unit test verifies WeightedTimeSeries::copy_fscrunch_weights
AT3-1132 in copy_fscrunch_weights, first channel in range initializes weight (not first time sample)
Merge branch 'master' into at3-1132-implement-weights-fscrunch
bugs-130 additional range check and internal documentation
bugs-130 restore the original non-linear scale when unpacking 2-bit data
bugs-130 fix year in copyright notice
AT3-1088 updated oci builder tag from 3.1 to 3.2
AT3-1088 update OCI to SKA CUDA ubuntu 24.04
AT3-1132 draft implementation of WeightedTimeSeries::copy_fscrunch_weights
dspsr fails to apply scales and offsets of contiguous PSRFITS files
Fix implemented on bugs-130-fix-fits-scloffs branch to be reviewed before merging
bugs-130 FITSFile::load_bytes computes the total number of rows and row offset for the entire output BitSeries, not just the buffer that is currently being loaded