Open adrabent opened 2 years ago
Can you look at the images that have been produced already, you might see something obvious? Maybe look at the dirty or intermediate residual, or psf?
Dear @cyriltasse:
I do not see any obvious wrong thing. Here are the images (from the bootstrap step):
restored:
PSF:
mask:
dirty:
Those images look fine to me, but maybe I am overlooking something.
Cheers, Alex
Yeah weird... can you save/check the cubes as well? Adding to you last DDF.py
call --Output-Cubes dp
, will save you dirty and psf cubes as well - there could be an empty slice or something more weird... If not I'll take a look...
Okay, I tried:
/usr/local/bin/DDF.py --Output-Name=image_bootstrap_L823390 --Data-MS=temp_mslist.txt --Deconv-PeakFactor 0.100000 --Data-ColName DATA_DI_CORRECTED --Parallel-NCPU=80 --Beam-CenterNorm=1 --Deconv-CycleFactor=0 --Deconv-MaxMinorIter=1000000 --Deconv-MaxMajorIter=5 --Deconv-Mode SSD --Beam-Model=LOFAR --Beam-LOFARBeamMode=A --Weight-Robust -0.250000 --Image-NPix=6000 --CF-wmax 50000 --CF-Nw 100 --Output-Also onNeds --Image-Cell 4.500000 --Facets-NFacets=11 --SSDClean-NEnlargeData 0 --Freq-NDegridBand 1 --Beam-NBand 1 --Facets-DiamMax 1.5 --Facets-DiamMin 0.1 --Deconv-RMSFactor=3.000000 --SSDClean-ConvFFTSwitch 10000 --Data-Sort 1 --Cache-Dir=. --Cache-DirWisdomFFTW=. --Debug-Pdb=never --Log-Memory 1 --GAClean-RMSFactorInitHMP 1.000000 --GAClean-MaxMinorIterInitHMP 10000.000000 --DDESolutions-SolsDir=SOLSDIR --Cache-Weight=reset --Misc-IgnoreDeprecationMarking=1 --Beam-At=facet --Output-Mode=Clean --Output-RestoringBeam 20.000000 --Weight-ColName=IMAGING_WEIGHT --Output-Cubes I --Freq-NBand=15 --RIME-DecorrMode=FT --SSDClean-SSDSolvePars [S,Alpha] --SSDClean-BICFactor 0 --Mask-Auto=1 --Mask-SigTh=15.00 --Mask-External=bootstrap_external_mask.fits --DDESolutions-DDModeGrid=AP --DDESolutions-DDModeDeGrid=AP --DDESolutions-DDSols=DDS0 --Selection-UVRangeKm=[0.100000,25.750000] --Cache-Dirty forcedirty --Cache-PSF force --GAClean-MinSizeInit=10 --Beam-Smooth=1 --Output-Cubes dp
But I only got those cubes:
image_bootstrap_L823362.cube.int.restored.fits image_bootstrap_L823362.cube.int.restored.pybdsm.srl image_bootstrap_L823376.cube.int.restored.pybdsm_rms.fits
image_bootstrap_L823362.cube.int.restored.fits.pybdsf.log image_bootstrap_L823376.cube.int.restored.fits image_bootstrap_L823376.cube.int.restored.pybdsm.srl
image_bootstrap_L823362.cube.int.restored.pybdsm_rms.fits image_bootstrap_L823376.cube.int.restored.fits.pybdsf.log
But I see that in case of L823362 the last 6 "cube channels" show invalid data. How can I deal with that? Removing these bands?
Alex
Ok cool! getting closer :)
All the data is flagged in these bands?
No.. not really, but the fraction of flagged data is pretty high (~30 .. 45%).
I checked again and the "invalid" data images in casaviewer only appear if I open both cubes (L823362
and L823376
) at the same, i.e., both fields do not have an identical frequency coverage (mostly some bands in the middle are missing).
Could this cause an issue?
Dear all,
I am running the DDF-pipeline on a three-epoch observation. The quality of the data looks pretty good, according to the quality of the produced images. But during the
bootstrap
step of the pipeline, it crashes with the following error message:The extended error message looks like this:
and it finishes with:
followed by Tracebacks just mentioning the occurence of the Runtime Error. I attached the logfile to this ticket: image_bootstrap_L823390.log
What can I do to figure out why DDF fails? Was such a problem seen before?
With kind regards, Alex