GFS, GEFS and FV3 will stop working

[giovaniceotto]

NOAA is starting to push a couple of updates to its Open-source Project for a Network Data Access Protocol (OPeNDAP)
server, which will affect how RocketPy downloads weather forecasts from NOAA, including GFS and GEFS.

The main change is the port used. The standard SSL 443 port will be replace the 9090 port currently in use. Therefore, everywhere in the Environment class code where the string https://nomads.ncep.noaa.gov:9090 appears, it will need to be replaced.

More detail is available at: https://www.weather.gov/media/notification/scn20-13nomads_website.pdf

Furthermore, since FV3 has been merged into GFS, its servers have stopped updating. So no new forecasts are available. This means the FV3 name should be removed from RocketPy.Environment.

[Gui-FernandesBR]

I tested all Atmospheric Models right now and surprisingly some features are still available:

• setAtmosphericModel(type="Forecast", file="GFS" ) -> OK!

• setAtmosphericModel(type="Forecast", file="FV3" ) -> NOT OK (as mentioned earlier, this function will never work again)

• setAtmosphericModel(type="Forecast", file="RAP" ) -> NOT OK (I'm still investigating why)

• setAtmosphericModel(type="Forecast", file="NAM" ) -> OK!

• setAtmosphericModel(type="Ensemble", file="GEFS" ) -> OK!

• setAtmosphericModel(type="Ensemble", file="CMC") -> OK!

However, I will create a new branch for replace the URL mentioned.

[giovaniceotto]

I verify why RAP isn't working.

[giovaniceotto]

I did not find any problems in RAP actually.

Here is the code I ran:

from rocketpy import Environment

Env = Environment(
    railLength=5.2,
    latitude=32.990254,
    longitude=-106.974998,
    elevation=1400
) 

import datetime
tomorrow = datetime.date.today() + datetime.timedelta(days=1)
Env.setDate((tomorrow.year, tomorrow.month, tomorrow.day, 12)) # Hour given in UTC time

Env.setAtmosphericModel(type='Forecast', file='RAP')

Env.info()

Output is:

Launch Site Details

Launch Rail Length:  5.2  m
Launch Date:  2020-08-02 12:00:00  UTC
Launch Site Latitude: 32.99025°
Launch Site Longitude: -106.97500°
Launch Site Surface Elevation: 1491.3 m


Atmospheric Model Details

Atmospheric Model Type:  Forecast
Forecast Maximum Height: 16.691 km
Forecast Time Period: From  2020-08-01 18:00:00  to  2020-08-02 15:00:00  UTC
Forecast Hour Interval:  1  hrs
Forecast Latitude Range: From  16.322011 ° To  58.25097463636 °
Forecast Longitude Range: From  -139.856603 ° To  -57.49840949379 °


Surface Atmospheric Conditions

Surface Wind Speed: 1.81 m/s
Surface Wind Direction: 121.82°
Surface Wind Heading: 301.82°
Surface Pressure: 854.72 hPa
Surface Temperature: 297.21 K
Surface Air Density: 1.002 kg/m³
Surface Speed of Sound: 345.60 m/s

However, notice how the forecast time period is short: Forecast Time Period: From 2020-08-01 18:00:00 to 2020-08-02 15:00:00 UTC. RAP is a RApid Refresh forecast, a new one is generated every hour and can be very useful hours before a launch inside continental US.

Having said that, if the user sets a date outside the forecast time period, an error occurs, which is probably a bug:

----> 1 Env.setAtmosphericModel(type='Forecast', file='RAP')

1 frames
/usr/local/lib/python3.6/dist-packages/rocketpy/Environment.py in setAtmosphericModel(self, type, file, dictionary, pressure, temperature, wind_u, wind_v)
    792                     )
    793                     try:
--> 794                         self.processForecastReanalysis(file, dictionary)
    795                         success = True
    796                     except OSError:

/usr/local/lib/python3.6/dist-packages/rocketpy/Environment.py in processForecastReanalysis(self, file, dictionary)
   1567             raise ValueError(
   1568                 "Chosen launch time is not available in the provided file, which ends at {:%Y-%m-%d %H:%M}.".format(
-> 1569                     fileTimeDate
   1570                 )
   1571             )

TypeError: unsupported format string passed to cftime._cftime.DatetimeGregorian.__format__

I am still looking into that.

[giovaniceotto]

Fixed this last bug described in the comment above, which from what I saw only happens in Linux systems, in the latest commit to master: b665ddd.

Basically, replaced all :%Y-%m-%d %H:%M simply with :. This means seconds are also displayed, but always works.