Hi Ingo, Thank you for this. When you said “$new is destroyed”, I had no idea you meant you explicitly called its DESTROY method. That is not a thing you are supposed to do, ever.
Nevertheless, I regard it as a bug it SEGV-ed. Until just now, the pdl_destroy procedure was setting the pdl.sv member’s IV to a “clever” number (0x4242). When the proper invocation of DESTROY happened (when your script undef-ed $data), that made a “pdl *” pointer to 0x4242, an invalid address which it tried to access, hence a SEGV. It doesn’t do that now – instead a Perl exception will be thrown, telling you the ndarray address is NULL, which is the only sensible value to indicate this situation. Please have a go with latest “master”. As for when the file should get removed, I don’t think that’s down to PDL to do. You told IO::FlexRaw to “Creat” a file, which it did. If you want that to be ephemeral, there are ways to do that, such a File::Temp – make sure to use CLEANUP=>1 if it’s a convenience function. Best regards, Ed ________________________________ From: Ingo Schmid <ingo...@gmx.at> Sent: Friday, May 31, 2024 1:45:37 PM To: Ed . <ej...@hotmail.com>; perldl <pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL and bart Hi Ed, here you go! On 31.05.24 2:32 PM, Ed . wrote: Hi Ingo, If you make a short script that makes a SEGV every time, I can fix it? I have a strict "no SEGV" for PDL ;-) Best regards, Ed ________________________________ From: Ingo Schmid <ingo...@gmx.at><mailto:ingo...@gmx.at> Sent: 31 May 2024 11:44 AM To: Ed . <ej...@hotmail.com><mailto:ej...@hotmail.com>; perldl <pdl-general@lists.sourceforge.net><mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL and bart Hi Ed, I looked at mapflex. with the Creat option. This maps a file on disk just fine. $new = mapflex ("map_$name.cfl",[{Dims=>$dims,Type=>'cfloat'}],{Creat=>1}) ; Later on, $new is destroyed. Apparently, the file remains and accessing it causes a SEGV. So, when do those files should get removed? Apparently, they don't. Ingo On 15.05.24 4:05 PM, Ed . wrote: Hi Ingo, My best answer to your direct question is a non-answer: only you know what is your easiest workflow. However, if bart does everything via new files for each stage, and you feel (as sounds likely from your description) that the various transformations can be done quicker but still correctly using PDL slicing stuff (especially as, with vaffine transformations like slice and mv, a copy is not made of the data), then you should run with that. Probably you’d want to have PDL write out to a file for stuff that bart is best at. I would note that one of your example bart commands is “nufft”, and PDL has several FFT implementations available that might be useful to compare that to (Slatec, FFTW3, the provided PDL::FFT). PDL::IO::FlexRaw is probably fine for memory-mapping stuff, though I’ve not really used it. I have dabbled with PDL::IO::FastRaw to help with Photonic, and that works fine for stuff that’s too big for RAM. If you find any problems with FlexRaw, please report them here so they can be fixed. Once you have stuff working, I hope you’ll put it on CPAN! Best regards, Ed ________________________________ From: Ingo Schmid via pdl-general <pdl-general@lists.sourceforge.net><mailto:pdl-general@lists.sourceforge.net> Sent: Wednesday, May 15, 2024 2:04:41 PM To: perldl <pdl-general@lists.sourceforge.net><mailto:pdl-general@lists.sourceforge.net> Subject: [Pdl-general] PDL and bart Hi, I both use PDL and recently started using bart (https://mrirecon.github.io/bart/). Documentation is somewhere between non-existent and horribly insufficient, before you ask. It has implementations of MRI reconstruction algorithms and its file format is complex float, very very similar to the FlexRaw format. They come in pairs of binary data cfl and text hdr files. Here's a sample dump, of which only the #Dimensions lines are essential: # Dimensions 200 200 200 1 1 1 1 1 1 1 1 1 1 1 1 1 # Command pics -d 5 -R W:7:0:0.0015 -e -i 100 -S -t traj549 reshData549 sens reco_l1 # Files >reco_l1 <sens <reshData549 <traj549 # Creator BART v0.8.00-196-g5947a32 I intend to wrap readflex/writeflex calls into readcfl/writecfl (there are matlab and python interfaces). Every command reads one or more files and the result is stored in a new one. This, of course, is not always efficient if things are temporary and fit into memory. The good thing is, you can run these from any shell/command prompt. For example > bart transpose 1 11 _tmp _tmp1 reads _tmp, swaps dimensions 1 and 11 (starts at 0) and writes _tmp1 or > bart slice 1 $c1 $eof _eof_c1; creates a slice at position $c1 in dimension 1 and writes that to _eof_c1. These are things done much more efficiently in PDL, for example. Others are very useful (nufft, nlinv), though specific to the field (pics, cc). Now, here comes my question. Do you see a straight-forward workflow to use both bart and PDL in its optimal way? How to best memory map files, possibly directly into a piddle? I am grateful for your input. Best wishes Ingo
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
