Zonal Wind Maker

[rgcosentino]

A new module to be named but will still with winds/zonal/ will read in zonal wind profiles from observations from published text files with wind velocities from cloud tracking as a function of latitude. The user will then be prompted or be given examples of how to build a zonal wind cube after supplying a latitude and longitude grid spacing. The vertical dimension will be in log pressure space to start, with later including the conversion of km above the 1 bar atmospheric level as an additional axis. Vertical wind shear will be available to allow a zonal wind profile to vary with height.

This is similar to how the general circulation model EPIC initializes a model domain where the wind velocity below the clouds is an explored parameter. Additional features to add the flexibility to probe stratospheric or thermospheric jets was added for exoplanet studies with solar system analogues that now might be useful for upcoming wind research and analysis of observational data from ALMA.

[emolter]

Hi Rick, this sounds like a great idea, but let me make sure I understand it right. Basically, you want to implement support for reading in synthetic 3-D (lat/lon/pressure) wind profiles and comparing them with observations - is that right? Let's talk more about this ASAP, as it seems like the planet models in the navigation module might help out here with translating the lat-lon grid into the observation geometry. We also need to decide if this functionality lives in the same wind_map class as we talked about implementing for the observed data, or if it should have a separate wind_model class.

[emolter]

Following up on the meeting @rgcosentino and I just had:

The proposed functionality would take a 3-D grid (latitude, pressure, wind velocity) and project it onto a planet in a given observation geometry. Since the difference in planet radius between the pressure levels is (for now) much less than one pixel in all the use-cases we are considering, it's ok for this to rely on the pre-existing geometry inside pylanetary.navigation.

The suggested implementation is to write pylanetary.atmosphere.WindModel(body, lat, P, windspeed) as a superclass of navigation.ModelBody. The input windspeed would have shape (nlat, nP). As a superclass of ModelBody, WindModel would have access to the latitude, longitude, and emission angles for the given observation geometry. WindModel would then compute the observed projected wind speeds at each point. Note that the projection from wind speed as measured on the limb to wind speed projected to the observer benefits from having easy access to the emission angle.

@cmoeckel91 your input would be really helpful here, because I know you already have tools that project temperature maps into observed geometries. Does making that functionality a superclass of ModelBody make sense? Could you please share your implementation with Rick to make it easier for him to do the same with winds?

We agreed that providing atmosphere modeling tools that do not rely directly on observed data deserves its own suite. The proposed name is pylanetary.atmosphere (for consistency with pylanetary.rings). Chris, does this make sense as a namespace for your temperature models, too?

[emolter]

@rgcosentino I just talked with Chris, and he likes the idea of using ModelBody as the parent class, and also the idea of using the pylanetary.atmosphere namespace. So let's go ahead with this!

[rgcosentino]

That's great @emolter. I am moving forward with that but have also used some code in there to get Sarah products she needs too. I probably dont have enough time to play around with super__init__ ModelBody all the way without asking a question or two. Let me get what I have committed for us to review and then we can figure out how to map the "data - wind values" like you mentioned.

[giardiaspace]

I'm not sure if this is helpful or not, but I came up with a "format" for zonal wind profiles with Scott Fleming of the STScI archive branch. The idea is to not only have some info about the data in a header at the top of the human-readable text file, but also to have the metadata be machine-readable. Later on I made some simple IDL routines that can parse these kind of text files, but there might also be an easy way to just modify existing FITS header routines.

Out of all the metadata, the timestamps and the LAT_SYS keywords are probably the most important. I think I started including the LAT_SYS keyword in metadata after a comment a long time ago from Ned.

This was for the WFCJ HLSP site:
Site
Example ZWP file (txt) (Scott wanted corresponding FITS table versions but I don't use them)

Here is what the file looks like for convenience:

# STARTOBS= '2017-01-11T09:20:58' / UT start of sequence (yyyy-mm-ddThh:mm:ss)
# ENDOBS  = '2017-01-12T00:17:45' / UT end of sequence (yyyy-mm-ddThh:mm:ss)
# STARTERR= '2017-01-11T09:20:58' / UT start time for 2D uncertainty correlations
# ENDERR  = '2017-01-12T00:17:45' / UT end time for 2D uncertainty correlations
# MIN_DT  =                   5.0 / Min. separation for correlations (hours)
# MAX_DT  =                  15.0 / Max. separation for correlations (hours)
# LAT_SYS = 'planetographic'      / Latitude system
# LAT_BIN =                   0.5 / Full width of correlation bin (deg. latitude)
# CREATORS= 'Michael H. Wong and Joshua Tollefson' / ZWP data file creators
# PUB_DOI = '10.17909/T94T1H'     / DOI of relevant publication
# TELESCOP= 'HST'                 / telescope used to acquire data
# INSTRUME= 'WFC3'                / identifier for instrument used to acquire data
# PROPOSID=                 14839 / PEP proposal identifier
# DETECTOR= 'UVIS'                / detector in use: UVIS or IR
# FILTER  = 'F631N  '             / element selected from filter wheel
# TUNIT1  = 'degrees'             / Unit of column 1
# TUNIT2  = 'm/s'                 / Unit of column 2
# TUNIT3  = 'm/s'                 / Unit of column 3
##  lat      v_eastward      sigma_v     N_tiepoints
...
   -0.25      7.15e+01      8.13e+00       14304
   -0.20      7.19e+01      8.26e+00       13577
   -0.15      7.25e+01      8.30e+00       12942
   -0.10      7.29e+01      8.28e+00       13679
   -0.05      7.36e+01      8.32e+00       14181
    0.00      7.45e+01      8.46e+00       13484
    0.05      7.50e+01      8.46e+00       12884
    0.10      7.67e+01      8.42e+00       13574
    0.15      7.66e+01      8.48e+00       14022
    0.20      7.67e+01      8.58e+00       13421
    0.25      7.65e+01      8.59e+00       12890
...

[emolter]

Thanks for this comment, Mike! This does indeed look like a good idea of something to add eventually. For now, I think Rick and Sarah can focus on generating the three-column latitude, speed, uncertainty data from EPIC or ALMA data in any format they see fit, and we can support this sort of "advanced I/O" later