Activity for Mike Keith
-
Mike Keith committed [a81f7f] on Code
Catch another case where object reference isn't tracked
-
Right - I agree that it should work, but I checked the swig generated wrap_psrchive.cxx file and it really just never made the call. Checking a few other calls to constructors it also seemed missing. It does appear in the "factory methods" like load_Archive() etc. I don't think it's a change in swig though as I'm pretty sure it failed with one built using an old swig version. Anyway at least our immediate issue is solved (i.e. we can run our pipelines again) but for sure it would be good to solve...
-
ProfileShiftFit segfaults from python interface (or external code)
-
Surprisingly, the reference tracking feature already exists in the python interface, but it doesn't track the reference to all objects. Explicitly telling it to track ProfileShiftFit fixes the immediate bug, though likely other objects also need to be explicitly tracked. Fixed in 209acda05
-
Fix for bug #495
-
ProfileShiftFit segfaults from python interface (or external code)
-
ProfileShiftFit segfaults from python interface (or external code)
-
Just trying to work out how serious this is in terms of reprocessing large volumes of data for the MeerTime TPA. Can anyone say if this only affects in the frequency direction or might the delays also change with time - e.g. is it possible that different subints will have different offsets. Obviously if there is something that changes from pulse-to-pulse in the single-pulse data then it is more serious than if it's just that the dedispersion is wonky +/- 1 bin. (though probably we should reprocess...
-
So the FrontendCorrection is important if anyone wants to calibrate data using the python interface. We use it in the meertime singlepulse pipeline, but really I think it is widely needed. However, I think the most important thing is to be able to call the calibrate(Archive) method, as this is what actually applies the calibration. The python interface is a bit of a mess as it is developed piecemeal, so for sure I have no objection to just removing functions that return a Jones object. Probably someone...
-
remove_chan crashes thinking there are zero subints and changes channel number before loading data
-
I have made the committed the change in d2c905bef6e72c40be00d84a3f9e630f371b33d2. It fixes the bug in the python code, and nothing amazingly bad seemes to have happened...
-
I haven't tried it, but I guess I could - maybe I will have a look tomorrow. But yeah - my worry is that it will introduce some other bug...
-
remove_chan crashes thinking there are zero subints and changes channel number before loading data
-
Hmmm... the thing is that I have these defined in my config.h for epsic... so it's like it is getting the wrong config file somehow. /* define if the compiler finds best partial specialization */ #define HAVE_BEST_PARTIAL_SPECIALIZATION /**/ /* define if partial specialization accepts default template arg */ #define HAVE_DEFAULT_PARTIAL_SPECIALIZATION /**/ EDIT - ah sorry I think I misunderstood the logic - these have to not be defined for it to work I think.
-
Hmmm... the thing is that I have these defined in my config.h for epsic... so it's like it is getting the wrong config file somehow. /* define if the compiler finds best partial specialization */ #define HAVE_BEST_PARTIAL_SPECIALIZATION /**/ /* define if partial specialization accepts default template arg */ #define HAVE_DEFAULT_PARTIAL_SPECIALIZATION /**/
-
To partially answer my own question - I could get it to compile by adding #define PROMOTE_TRAITS_SPECIALIZE 1 to Util/epsic/src/util/PromoteTraits.h However, this is an automatically generated file and the logic for why it gets this definition added is not clear to me (seems to depend on #if !defined(HAVE_BEST_PARTIAL_SPECIALIZATION) | !defined(HAVE_DEFAULT_PARTIAL_SPECIALIZATION) Which... well I stoped going down the rabit hole given I was able to compile it. @straten - I hope this might help you...
-
Did you find a fix for this - I am getting the same issue on macosx with gcc 11.2 as well.
-
Circular dependancies in Utils
-
Awesome, thanks willem, can confirm that this builds ok now!
-
Circular dependancies in Utils
-
ephio.f has not been changed since 2007, but I'm pretty sure I've seen a similar issue elsewhere. I think it was related to picking up the wrong version of libgfortran relative to the compiler used. This may occur because you've updated your GCC but still somehow linking a system gfortran, but can also occur because of things like anaconda having it's own paralell version of system libraries (such as libgfortran). In fact, I'm pretty sure it was anaconda that was the problem for me as it had a newer...
-
Frequency append (e.g. psradd -R) and subint freuqency
-
For the record - We belive this is due to a calls to the cfitsio routine fits_execute_template which is not thread safe. I have made a patched version of cfitsio that fixes it, but also likely that we don't really need to call fits_execute_template every time we write a file and perhaps it would be better for psrchive to cache a empty psrfits file in memory.
-
I had the same thought - but copying a .sf file to my laptop and using a locally compiled version of cfitsio with the --enble-reentrant didn't seem to fix it, though I will try with the new module on ozstar. I started debugging on my laptop but it really is not very clear what's going on. The errors are very "random" and seem to be from bits of memory being overwritten (e.g. sometimes it has an array of pointers to dereference but they have 'silly values' like 0x16 - so I think the actual error occurs...
-
I have done a tiny bit more research into this bug, which still exists as of 0abe673a7566691b527df4ab28e22bb6a3a6dd02. In particular it "goes away" if you Don't use psrfits as an output option, OR Use the -A to append to a single archive. I suspect the issue is that something is not being initialised correctly in the output archiver that is causing a null or invalid pointer to be passed to cfitsio. I'm not sure why single pulses causes it in particular though...
-
I have done a tiny bit more research into this bug, which still exists as of 0abe673a7566691b527df4ab28e22bb6a3a6dd02. In particular it "goes away" if you Don't use psrfits as an output option, OR Use the -A to append to a single archive. I suspect the issue is that something is not being initialised correctly in the output archiver that is causing a null or invalid pointer to be passed to cfitsio. I'm not sure why single pulses causes it in particular though...
-
singlepulse + threads = errors and segfaults
-
I have an update for this bug. I believe that this is not actually a bug in dspsr, but for future reference and in case someone else has a similar issue here is my current understanding. After some investigation of the code and more carefull looking at the files I have determined that although dspsr does write the same start time to some files, these files also get a large OFFS_SUB in the "subint" header, which puts the start time of bin zero at the correct place. This is caused when the phase of...
-
single pulse - incorrect start time in output headers
-
Hello. Not much to go on, but I'm pretty sure this is unrelated to this 2012 bug regarding telescope site codes. Your bug seems to be tempo2 crashing when trying to make a predictor from your pulsar in dspsr. I would suggest to manually run the tempo2 command on your ephemeris (replace pulsar.par with your ephemeris) to see if any errors are thrown, and if that works ok, check the directories in /tmp to verify that the ephemeris and stuff there makes sense. If you can't resolve the issue, this should...
-
Match frequency channels when applying ManualPolnCalibrator
-
Python fixes and additions
-
I can confirm that this fix works! Thanks Willem.
-
psrplot preprocessing does not work with overlay
-
Add ROACH backend for digifil
-
Merge commit 'eef82490'
-
Merge branch 'master' of ssh://git.code.sf.net/p/dspsr/code
-
This is also an issue for me. Still fails to build on MacOSX 10.11 as of 50643a71cdc30081fb9809a79e674ef9e57a3dbf . Rumour has it that this is fixed in the latest version of MacOSX, but I haven't been brave enough to upgrade and break everything else yet.
-
This is also an issue for me. Still fails to build on MacOSX 11 as of 50643a71cdc30081fb9809a79e674ef9e57a3dbf . Rumour has it that this is fixed in the latest version of MacOSX, but I haven't been brave enough to upgrade and break everything else yet.
-
Converting to psrfits produces unreadable files
-
Fixed in 61641d. I merged the logic of how to get the reference epoch with the decision to make a temporary hdr_ext object. This seems to have fixed it the main issue, and the files are now readable. I note that there are other parameters that are left undefined in the FITS header when converting from timer archives that might confuse other software later on, but I suspect this is largely unavoidable.
-
Fix for bug #421.
-
Added some extra logic to correctly label JBO data
-
I believe that this bug is caused from the fix to bug #420. In particular, in FITSArchive.C hdr_ext is now always created with dummy values, but later on in the code (around line 1008) it assumes that if a hdr_ext exists then the reference epoch can be read from that header so it never calls the routines that set the reference epoch when the header is blank. I think this could be fixed by setting the start time in the temporary hdr_ext object when it is created.
-
The problem is that the STT parameters are set to zero in the bad file. STT_IMJD= 0 / Start MJD (UTC days) (J - long integer) STT_SMJD= 0 / [s] Start time (sec past UTC 00h) (J) STT_OFFS= 0. / [s] Start time offset (D) STT_LST = 0. / [s] Start LST (D) END c.f. good file: STT_IMJD= 58250 / Start MJD (UTC days) (J - long integer) STT_SMJD= 50838 / [s] Start time (sec past UTC 00h) (J) STT_OFFS= 0.000725930702174082 / [s] Start time offset (D) STT_LST = '* ' / [s] Start LST (D) END
-
Converting to psrfits produces unreadable files
-
Merge branch 'psrfits-6.0'
-
Fails to compile after redefinition of long long in psrfitsio.h
-
Link with openmp flags
-
*** empty log message ***
-
*** empty log message ***
-
Added CRITICAL checks for the file and block number before trying to write to tape.
-
Needs AC_PROG_CXX to compile c++ code
-
Added support for multiple -f options in dada_diskdb
-
Modifying Makefiles so that make dist works.
-
I have comitted a potential fix for this bug [f6fc0b], though I'm not sure why it was crashing or why the fix works. I don't think that it breaks anything else, so hopefully it's safe to commit.
-
Possible fix for Bug #60 - segfault when using -s
-
I am also facing this bug. Quite frustrating. Ramesh - did you ever find a solution to this?
-
Change to 1 weight per frame
-
Tiny fix for single-pol emerlin reader
-
Fix to allow emerlin reader to read single polsarisation data.
-
Incorrectly comparing pointer to integer
-
Apparently cstdint is a C++11 extension that is not supported on older compilers.
-
Missing makefile for emerlin data type
-
Merge branch 'mjk'
-
Correctly deal with end of file for merlin data.
-
Added emerlin data format reader. Zero weight bad samples.
-
fmemopen not in many non-linux systems
-
Modernised configure scripts. Added HDF5 for LOFAR
-
Incorrect syntax in makefile for hdf5 libraries
-
Added hdf5 file that was missing from previous ...
-
Added hdf5 m4 for dspsr (copied)
-
Added JBO MKII telescope
-
Merge branch 'master' of ssh://git.code.sf.net/...
-
Correct handling of tempo2 aliases file. Allow ...
-
Merge branch 'master' of ssh://git.code.sf.net/...
-
Updated pdv to use standard routines for L and P
-
Use tempo2 for site names if avaliable
-
Merge branch 'master' of ssh://git.code.sf.net/...
-
Fix to allow dspsr to compile with default back...
-
Fails to compile when CFITSIO present but no fits in backend list
-
Added options to print unbiased L and P for -t
-
Moved PhaseFreq and PhaseTime plots so text doe...
-
Error with Makefile.am in ./More/
-
Need to make sure to include install_with_githa...
-
Need range.h in source distribution
1 >
