Dear All,
Dear users of PyTROLL/Satpy

OPS recently announced that they will start trial distributing NWC SAF data of Metop-C on Basic Service. We currently get those LEO data from NOAA-19 and Metop-B in channel "E1B-RDS-1". There is corresponding GEO data from MSG4 in channel "E1B-GEO-4". Richard Osborne has explored all kinds of SAF data under Windows and has written an interesting article in the GEO newsletter Nr. 72.

http://leshamilton.co.uk/GEO/PDF/geoq72.pdf

I'm only interested in what I can do with PyTROLL/Satpy. Indeed Satpy has readers for both types of data. You can read the LEO data with 'nwcsaf-pps_nc' and the GEO data with 'nwcsaf-geo'. The files have colour palettes inside that are read and used by Satpy. That said you can generate palette based images out of the box using composite 'cloudtype'. The composite works for both DAY and NIG. So you can use two passes per day over any POI and reproject (resample) as usual. There is more data you can use to generate composites 'cloud_top_height', 'cloud_top_temperature', 'cloud_top_pressure' or 'cloud_mask' but I found only 'cloudtype' appealing and interesting for amateur meteorologists. I extracted the 'cloudtype' palette under Python using 'ncdump' which is in the (pytroll) environment and made a seperate legend image with IM. Apparently all this LEO and GEO data use the same palette. Richard Osborne showed a slightly different legend. My legend has the order and strings found in current files.

Happy hacking,
Ernst

Dear All,

the slight difference in my 'Cloud Type Palette' above compared to the legend Richard Osborne has published in geoq72 apparently is due to a new version of the NWCSAF (V2021) software package:

https://www.nwcsaf.org/ct_v2021

There also existed a problem with EUMETCast distributed 1 minute NOAA19 NWCSAF granules that had only 351 instead of 360 scanlines. TBH I cheated in my post above overpainting some gaps by setting the resampling radius_of_influence=6000. But the problem could not be overlooked on full resolution images. I reported this problem to OPS some days back and EUMETSAT has now fixed the issue yesterday (see my not cheated :-) images before and after the fix below).

I attach the latest PyTROLL/Satpy 'cloudtype' scripts I use under GNU/Linux. These should be easy to adapt for Windows (Graham Woolf might help). It should be noted that NOAA-19 is a rather old bird, probably near EOL now. His planned and initial orbit was for LTAN=14:00 (2009) but now apparently even crossed the terminator and has LTAN=19:43 (May 2022) increasing app. 0.77 minutes per month. My scripts assume LTAN/LTDN to be "constants" for sun synchronous satellites though they do not rely on every single minute.

Best regards,
Ernst

OK it's me again

Windows CMD.exe has some problems to understand filenames that contain commas ','. EUMETSAT even uses 2 commas in the respective cloudtype filenames. You have to hyphenate " " these names.
I woke up my (pytroll) environment under Windows 10 from a 15 months sleep and updated everything including TLEs. Here are the scripts that work under Windows 10. In my Starter Kit you will have to add a xnoaa19 tmp directory and a  Noaa-19 image directory first. Then adapt for your segdir and things should work. As a reference for your 'cloudtype' images I add my "Cloud Type Palette" in full size.

Good luck,
Ernst

Hi Graham,

EUMETSAT said to start trial dissemination (available for users with 'manufacturer' status) of Metop-C EARS-NWCSAF data tomorrow 2022 May 24. IIRC you should get this data too. So your next step will be to make the Windows MetopB-NoD-cloudtype script ready for MetopC.

Here is another little homework: We still get the 45 minute Sentinel-3X OLCI ERR passes on HVS-2. While this is not a terrific format and certainly no replacement for the OLCI EFR segments we unfortunately lost, it's at least additional global LEO data like EUMETCast Metop-X GDS. I wrote a little GNU/Linux script ...

Happy hacking,
Ernst

Hi Ernst

Im not sure that I have manufacturer status - I will check tomorrow to see if the data is coming though

I have already prepared a METOP-C script and will have a go at the Sentinel data too

Kind Regards

Graham

Manu,

+ '-gravity west -background rgb\(245,245,245\) -splice '+EffSplice+'x0 '\
under GNU/Linux parantheses must be escaped for Bash \(  \).  Change above to:

+ '-gravity west -background rgb(245,245,245) -splice '+EffSplice+'x0 '\
Hope this helps,
Ernst

Manu,

having a closer look at the script you published I doubt the image in your tmp directory is from this script.

Todo:
-- Delete the files the Windows way in your tmp directory
-- Untar the files the Windows way using 7za.exe

See how this has been done in an earlier Sentinel-3X_DAY_stack.py script for Windows.

Good luck,
Ernst

Hi Ernst

It looks as if I dont have manufacturer status as I dont see any METOP-C cloud files

Kind Regards

Graham

Graham,

This was the e-mail announcement for 'manufacturers' that came in 12.05.2022 14:38

<cite>

Dear Manufacturer,

 

We are planning to start a trial dissemination of Metop-C EARS-NWC products on 24 May 2022, in view of expanding the EARS-NWC service.

 

Metop-C data will be added to the following:

 

-          EARS Cloud Mask: https://navigator.eumetsat.int/product/EO:EUM:DAT:MULT:EARS-RCMA

-          EARS Cloud Type: https://navigator.eumetsat.int/product/EO:EUM:DAT:MULT:EARS-RCTY

-          EARS Cloud Top Temperature & Height: https://navigator.eumetsat.int/product/EO:EUM:DAT:MULT:EARS-RCTTH

 

Example filenames:

W_XX-EUMETSAT-Darmstadt,SING+LEV+SAT,METOPC+CMA_C_EUMS_20220510120724_11349.nc.bz2

W_XX-EUMETSAT-Darmstadt,SING+LEV+SAT,METOPC+CT_C_EUMS_20220510224700_24099.nc.bz2

W_XX-EUMETSAT-Darmstadt,SING+LEV+SAT,METOPC+CTTH_C_EUMS_20220510225100_24099.nc.bz2

The products will be distributed on EUMETCast Europe:

Channel: E1B-RDS-1

Multicast address: 224.223.222.1

PID: 500

...
</cite>

EUMETSAT didn't fix an exact start time though. Up to now I don't see any MetopC NWCSAF files either ...

Regards,
Ernst

 

Hi Ernst

I didnt get the email so that sort of confirms it

I dont suppose I qualify as a manufacturer unfortunately

I will have a go at the Sentinel data though as soon as some comes through today - I have just set up for those two cahnnels

Kind Regards

Graham

Graham and Manu,

after a trial period the MetopC NWCSAF data will be available to everybody. Let's wait and see.

The OLCI ERR data is a concatenation of all EFR segments on a sunny descening SEN3A/B pass.
As such it has pixels 1217 cols by 15145 rown which is the reason I havn't looked at it until recently.
It has a data reduction by averaging 4x4 EFR pixels which means ERR resolution of 1.2km at SSP.

Regards,
Ernst

Graham and Manu,

here is a picture of 8 Sen3X ERR passes that explains best what kind of data we get.
You must expect gaps between -40° and +40° latitude. As we have already seen with
EFR segments during summer the coverage is shifted up North while in winter time
we can expect better coverage of Antarctica in the South.

Cheers,
Ernst

Graham,

according to this discussion

https://github.com/paramiko/paramiko/issues/2038

this deprecation warning doesn't seem to be something to be really concerned about.
As I said I have updated my Windows (pytroll) environment and have no such message.

(pytroll) conda list satpy
# Name                    Version                   Build  Channel
satpy                     0.36.0             pyhd8ed1ab_0    conda-forge

You may want to try (make sure to activate env pytroll first !):
(pytroll) conda update satpy

Good luck,
Ernst

Hi Ernst

Just as a matter of interest how many files a day should I get in E2H-S3A-02 and E2H-S3B-02

I have 12 files in 3A since 13:00 yesterday and and 10 in S3B over roughly the same time

Is it the same for you ?

Kind Regards

Graham

Graham,

the second last entry in the TLEs shows the number of revolutions per day. It is 14.26 for Sentinel-3X.
This leads to a (for sun synchronous satellites!) typical nodal period of 1440/14.26 = 101 minutes.

Every ERR file is about 45 minutes showing the sunny side of the orbit (no OLCI data in the dark).

So expect 14 -15 files a day. I even got 16 once but found out that one orbit has been processed and
disseminated twice with slightly different starting times. You may loose files due to reception problems.

Regards,
Ernst

Graham,

different fom what I just said EUMETSAT expects ~18 files per day in the Product Navigator:

https://navigator.eumetsat.int/product/EO:EUM:DAT:SENTINEL-3:OL_1_ERR___NRT?query=&filter=satellite__Sentinel-3&filter=themes__Ocean&s=advanced

So there is room for further investigations ...

Ernst