Open-MSS / MSS

A QT application, a OGC web map server, a collaboration server to plan atmospheric research flights.
https://open-mss.github.io
Apache License 2.0
54 stars 68 forks source link

No valid time found #2400

Open dhgkunkel opened 3 weeks ago

dhgkunkel commented 3 weeks ago

Hi, I have data for an MSS Server where I get an error message saying that the file has no valid times. The error message looks like:

mss_error.log:[Thu Jun 06 11:02:21.113523 2024] [wsgi:error] [pid 249713:tid 140591208253184] [remote 134.93.180.60:40034] ERROR:root:layer <mswms_settings.my_class object at 0x7fdd9d172140>/icon_wcb has no valid times!

It is issued by mswms/wms.py and appears when no time steps are found or when the time variable is not correctly labelled ( to my understanding). I attached a file showing output from ncdump -v time of the respective file. Any suggestions are welcome! Thanks, Daniel file_description_with_time_var.log

joernu76 commented 6 days ago

Hi Daniel, do you have the full log of the MSS server startup (what it dumps upon parsing all the files etc) and the configuration of the layer?

dhgkunkel commented 2 days ago

Hi Jörn, find attached a log of the startup and a (shortened) mswms_settings (I removed everything not related to the layer which makes problems).
If you need more information, then just lust me know. mss_error.log msmws_settings_only_wcb_stuff.log

joernu76 commented 5 hours ago

Mmh. this log looks different from ours. there are no DEBUG and INFO messages of MSS. Maybe a different configuration?

When I manually start mswms in the config directory via PYTHONPATH=. mswms --debug I get output containing lines such as

2024-07-03 13:34:00,742 (dataaccess.setup:368): INFO: Opening candidate '20230801_00_clamschem.PHILEAS_grid5.pl.nc'
2024-07-03 13:34:00,928 (dataaccess._add_to_filetree:312): INFO: File '20230801_00_clamschem.PHILEAS_grid5.pl.nc' identified as 'pl' type
2024-07-03 13:34:00,928 (dataaccess._add_to_filetree:313): INFO: Found init time 'None', 2 valid_times and 29 standard_names
2024-07-03 13:34:00,928 (dataaccess._add_to_filetree:320): DEBUG: valid_times='[cftime.DatetimeGregorian(2023, 8, 1, 0, 0, 0, 0, has_year_zero=False)
 cftime.DatetimeGregorian(2023, 8, 1, 12, 0, 0, 0, has_year_zero=False)]' standard_names='['mole_fraction_of_ozone_in_air', 'mole_fraction_of_methane_in_air', 'mole_fraction_of_nitrous_oxide_in_air', 'mole_fraction_of_water_vapor_in_air', 'mole_fraction_of_HCl_in_air', 'mole_fraction_of_ClONO2_in_air', 'mole_fraction_of_ClOx_in_air', 'mole_fraction_of_Cly_in_air', 'mole_fraction_of_NOy_in_air', 'mole_fraction_of_BrO_in_air', 'mole_fraction_of_BrONO2_in_air', 'mole_fraction_of_cfc11_in_air', 'mole_fraction_of_cfc12_in_air', 'mole_fraction_of_OClO_in_air', 'mole_fraction_of_NO2_in_air', 'mole_fraction_of_carbon_monoxide_in_air', 'mole_fraction_of_CH3Br_in_air', 'mole_fraction_of_CH2Br2_in_air', 'mole_fraction_of_CHBr3_in_air', 'mole_fraction_of_H1211_in_air', 'mole_fraction_of_H1301_in_air', 'mole_fraction_of_HCHO_in_air', 'air_potential_temperature', 'eastward_wind', 'northward_wind', 'ertel_potential_vorticity', 'air_temperature', 'equivalent_latitude', 'square_of_brunt_vaisala_frequency_in_air']'

listing the identified times and variables.

This is not in the log file, but should help. The layer contains a list of desired standard_names and using this, one should be able to identify, which standard_name is missing in the data, e.g. if ertel_potential_vorticity is required by the plot, but not given, the error you have will result.

AFAIK, the vertical Generic plots add almost all, by default, PV and THETA, which may be missing in your data. Maybe, this is a mistake for precisely this reason? Either way, you can define simply a new layer via:

for ent in ["relative_humidity_wrt_ice_from_ecmwf",
            "maximum_relative_humidity_wrt_ice_on_backtrajectory",
            "maximum_specific_humidity_on_backtrajectory",
            "maximum_pressure_on_backtrajectory"]:
    mslib.mswms.mpl_hsec_styles.make_generic_class(
        f"HS_GenericStyle_AL_{ent}2",
        ent, "al", [], [])
    mslib.mswms.mpl_vsec_styles.make_generic_class(
        f"VS_GenericStyle_AL_{ent}2",
        ent, "al", [], [])
    register_horizontal_layers.append(
        (getattr(mpl_hsec_styles, "HS_GenericStyle_AL_" + ent + "2"), ["icon_wcb"]))
    register_vertical_layers.append(
        (getattr(mpl_vsec_styles, "VS_GenericStyle_AL_" + ent + "2"), ["icon_wcb"]))     

Not tested, but changing the list in the for loop should do the trick.

I am not sure how a more helpful error message would look like given the data available at the point in the code where it appears. If this is indeed your issue, I will try to improve on this.

dhgkunkel commented 3 hours ago

Thanks Jörn!

The hint with the PV and THETA might be a good one, with your code I can at least register the layers and can access them in msui. They do not show what I want but maybe that is another thing. I'll check on that in the next days and get back with the result.

About the startup of the server, I only get WARNING s dumped. I need to check how to write INFO and DEBUG...

dhgkunkel commented 3 hours ago

General question: For such a case, would you recommend to not use the GenericStyle plot routines but rather write an own style ?

joernu76 commented 3 hours ago

I have to admit that the generic style routines are, historically, our generic style and thus they include sensibly PV and Theta lines, which are often quite useful.

However, this causes issues for quick testing and other models that do not include them. Generally, the make_generic routine as shown above has been designed to facilitate making your "own" classes and offer quite a bit of configurability. So I use that often and I copied that from the live PHILEAS server, where we have a similar issue for some of the data.

I also write my own custom styles, but 98% of our layers are created using the make_generic function.