Overlap corrected products

[HolgerPollyNet]

Hi I had a look at the OC output of PXT_TROPOS and i realized that the extinction looked very strange, while the extinction separately of NF and FR look good. For example

Digging into the code I found in pollyxt_overlap.m the following lines e.g. 243-244: data.signal387OverlapCor = squeeze(data.signal(config.isFR & config.is387nm, :, :)) ./ repmat(overlap355Sm, 1, size(data.signal, 3)); data.bg387OverlapCor = squeeze(data.bg(config.isFR & config.is387nm, :, :)) ./ repmat(overlap355Sm, 1, size(data.signal, 3));

Interpreting these lines it look to me that you do an overlap correction for the raw signal (dead time corrected) and for the background (which is supposed to be constant). As the overlap correction can only be applied on background corrected profiles, I understand why you do this. Performing the overlap correction separately it bridges somehow this issue in many follow on functions and prevents for major code changes, right?

But do you think it could be possible that this causes problems in the near range where the overlap is well below 1 and the background is a small number?

At least there must be a reason for the overestimation of the extinction…

[ZPYin]

Thanks for reporting this issue. Please see my answers below:

Interpreting these lines it look to me that you do an overlap correction for the raw signal (dead time corrected) and for the background (which is supposed to be constant).

data.signal is background-substracted and deadtime-corrected signal. Instead, data.rawSignal is actually what you meant. Meanwhile, background signal didn't play a role in Raman retrievals as long as the signal was background-substracted. So the issue should not be caused by the lines you refered to.

The reason why I designed the background signal in this way is the thinking that this might be useful for taking into account the influence of overlap correction in error analysis. Because the constant background is already in data structure, there is no need to do the same calculations here.

I just have a quick investigation into this by looking at the results of overlap-corrected signal @ 387 nm with calculated overlap function from 355 nm (This is the way used in the auto overlap correction scheme). But, the result seems not very good at near surface (< 300 m) (see figure below). There might be two reasons for this:

1. different overlap function at 355 nm and 387 nm
2. not perfect deadtime correction for near-range signal @ 355 nm (less likely).

signal 355 nm

signal 387 nm

signal 387 nm (but for PollyXT-TJK)

PS: On the contrary, overlap correction at 607 nm looks better

So, the solution would be using separate overlap functions for 355 and 387 nm (the same for 532 and 607 nm). What do you think?

[HolgerPollyNet]

Thanks for the response. I comletely agree, if we use the near-field-far-field overlap correction mode, the we should use sepate function for the elastic and raman channels! I hope this is the reason!

Let me see if this is easy to implement. Best and take care

[HolgerPollyNet]

I included now this in the poverlap module, but obviously it does not work well.:

Do you have the time for a quick check? I pushed it to holger.

[ZPYin]

I also have a similar result. This is caused by the signal gluing, because Raman extinction retrieval is very sensitive to signal distortion.

Right now, I'm trying to implement a similar signal gluing in SCC. Hope this can work.

[ZPYin]

I take the weighted-mean of far-range and near-range signal to build a merged signal, similar to the algorithm described in sect 2.3 (EARLINET Single Calculus Chain – technical – Part 1), but without the slope test.

Seems it works to some degree.

See the new overlap corrected extinction for the same case as below:

But signal @ 607 nm is noiser than 387 nm, which leads to the strange behavior at the gluing range (700 - 1000 m).