AttributeError: 'NoneType' object has no attribute 'data'
Closed this issue · 10 comments
Hello,
I'm using a .yaml file to try and peel a bright source out of a FOV. The routine is based off OxKAT which uses CC to perform the peeling so, I'm just trying to transfer it over to QC.
I've included my .yaml file (which was based on an example provided to me in the CC discussion board and was meant to mimic the OxKAT CC parset), and log report.
The process fails with the a common but uninformative error, I've plotted all of the relevant data columns (i.e., DATA, CORRECTED_DATA, MODEL_DATA, DIR1_DATA) and they all exist and are non-zero so I'm not sure why it's failing.
Any advice?
Cheers,
qc_log.txt
DD_bb.yaml.txt
Andrew
Looks like something weird is going on here, seems to have a non-existent entry in the model list:
in_b = [xds.get(ingredients[op_idx + 1]).data]
│ │ │ └ 0
│ │ └ ['MODEL_DATA', '', 'DIR1_DATA']
│ └ <function Mapping.get at 0x7f654ea47790>
└ <xarray.Dataset>
Dimensions: (row: 41769, chan: 64, uvw: 3, corr: 4, ant: 27)
Coordinates:
ROWID (row) int32 da...
AttributeError: 'NoneType' object has no attribute 'data'
CubiCal requires the +- syntax here:
MODEL_DATA+~DIR1_DATA:DIR1_DATA
but I think for QuartiCal it just needs ~ to do subtraction, so I'd try that.
@IanHeywood That works to prevent the error. Let me expand upon the question because the .yaml script isn't working as expected.
I'm trying to peel this bright source (following the routine from Oxkat). (I'm assuming) the dE calibration is working well for removing the side lobes of the bright source. You can see that the DI self-cal:
Has residual sidelobes that DD self-cal corrects:
Now, this is good (great even). But I'm trying to figure out why it's not removing the source (considering that the script peels out the DIR1 source with CC as a part of the Oxkat routine). Any insight?
Point of clarification as well, the input_model.recipe=MODEL_DATA~DIR1_DATA:DIR1_DATA where MODEL_DATA contains the full sky model and DIR1_DATA contains the model of only the problem source. When I set subtract_directions: [1] does the [1] denote MODEL_DATA~DIR1_DATA (i.e. indexing starting from 1), or does it correspond DIR1_DATA?
As @bennahugo said, the models are zero indexed. As for some part of the source being left in the map, it is not unusual. If you made your solution intervals smaller, I would expect the subtraction to improve. If you have an equivalent result/config with CubiCal, would you mind posting it here? It is important to note that QC and CC are different in many ways so it isn't easy to isolate a specific cause for a change in the results. I am happy to take a look though. One thing I spotted is that you are using complex terms for both G and dE. This isn't a problem per se, but it means that in the absence of a polarized model, there may be a danger of moving polarized flux into stokes I.
@bennahugo was correct, and it was me misreading. The source went from 1.04e-1 -> 1.04e-3 (which is similar to what was happening in CC). I was misreading the exponent, and interpreting is as reducing the side lobes without subtracting any emission from the bright source.
Can I ask a more fundamental question before closing this issue,
What is the difference between corrected_residual and corrected_data, and when do we want to use one or the other? I see the examples in the documentation use both of them.
corrected_data is the original data, with the inverse of DI gain terms applied. Normally you'd use that before you do any DD solutions.
corrected_residual is data minus DI-and-DD-corrupted [subset of] model, with the inverse of DI gain terms applied. The subtract directions parameter controls which subset is subtracted. So that's what you would use if you want to peel away some source(s).
Hope that @o-smirnov and @bennahugo managed to clear that up for you @AKHughes1994. If you need any further assistance, just let me/us know.
@AKHughes1994 can we close this issue?
Yes sorry! I should have closed it.