I compared the Klett and Raman retrievals from Picasso with PicassoPy for the test case 25 August 2024, Mindelo, and found some discrepencies which I would like to discuss.
You can find the results of my comparison here: https://owncloud.gwdg.de/index.php/apps/files/?dir=/PhD/Picasso_QC/Picasso_vs_PicassoPy&fileid=4210731004 (and get personal access to the folder).
E.g., the errors of the raman extinction coefficient are much larger in PicassoPy which leads to very high uncertainties of the lidar ratio (usually more than 100%!!). Do the errors really need to be that large, because this questions the reasonability usability of the lidar ratio generally.
Also, I found that the particle depol is usually a little bit smaller in PicassoPy, which is quite of importance keeping in mind the general discussion about the unexpected low depol at Mindelo and the correctnes of its retrieval.
I also don't understand, why for dedicated profile times the retrieval of the lidar ratio and the particle depol is failing in PicassoPy even though reasonable results were retrieved in Picasso and backscatter and extinction are not too different between Picasso and PicassoPy. E.g.,
- 20:23-20:45 UTC Raman FR 355nm LR and depol
- 15:57-16:57, 16:57-17:57, 19:23-20:23 UTC Klett FR 355nm depol.
Another issue I found is that in the netcdf output of PicassoPy (*profiles.nc, *NR_profiles.nc, etc.), only the variables which are existing and not entirely NaN are stored, i.e., the different nc files of the different averaging periods (and even for the same profile period but looking at FR and NR) contain a different set and a different number of variables while in Picasso the variables which could not be retrieved and properly calibrated are just entirely NaN but still written to the nc file. It seems quite inconsistent to me like it is done now and it's more complicated for the end user. We should discuss this maybe also with the other people, using the PicassoPy profiles. Personally, I also would appreciate to save the Klett extinction and its uncertainty to the nc file as well (and maybe even the lidar ratio), because now, we always have to calculate it on our own.
I compared the Klett and Raman retrievals from Picasso with PicassoPy for the test case 25 August 2024, Mindelo, and found some discrepencies which I would like to discuss.
You can find the results of my comparison here: https://owncloud.gwdg.de/index.php/apps/files/?dir=/PhD/Picasso_QC/Picasso_vs_PicassoPy&fileid=4210731004 (and get personal access to the folder).
E.g., the errors of the raman extinction coefficient are much larger in PicassoPy which leads to very high uncertainties of the lidar ratio (usually more than 100%!!). Do the errors really need to be that large, because this questions the reasonability usability of the lidar ratio generally.
Also, I found that the particle depol is usually a little bit smaller in PicassoPy, which is quite of importance keeping in mind the general discussion about the unexpected low depol at Mindelo and the correctnes of its retrieval.
I also don't understand, why for dedicated profile times the retrieval of the lidar ratio and the particle depol is failing in PicassoPy even though reasonable results were retrieved in Picasso and backscatter and extinction are not too different between Picasso and PicassoPy. E.g.,
Another issue I found is that in the netcdf output of PicassoPy (*profiles.nc, *NR_profiles.nc, etc.), only the variables which are existing and not entirely NaN are stored, i.e., the different nc files of the different averaging periods (and even for the same profile period but looking at FR and NR) contain a different set and a different number of variables while in Picasso the variables which could not be retrieved and properly calibrated are just entirely NaN but still written to the nc file. It seems quite inconsistent to me like it is done now and it's more complicated for the end user. We should discuss this maybe also with the other people, using the PicassoPy profiles. Personally, I also would appreciate to save the Klett extinction and its uncertainty to the nc file as well (and maybe even the lidar ratio), because now, we always have to calculate it on our own.