Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tsout_seriesReader with no specified heights crashes #108

Open
hawbecker opened this issue Aug 24, 2020 · 4 comments
Open

tsout_seriesReader with no specified heights crashes #108

hawbecker opened this issue Aug 24, 2020 · 4 comments
Assignees

Comments

@hawbecker
Copy link
Contributor

When calling tsout_seriesReader with a specified list of heights, the code works as expected. However, when removing a specification for 'heights' in the call, the code crashes with the following error:

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-36-4a42bcaa73f3> in <module>
     40                                                                      select_tower=['FN{}'.format(fino)],
     41                                                                      #heights=[10.0],
---> 42                                                                      height_var='ph'
     43                                                                     )
     44             wrf_twrs[case]['FN{}'.format(fino)].to_netcdf(twr_path)

~/Code/Python/mmctools/mmctools/wrf/utils.py in tsout_seriesReader(fdir, restarts, simulation_start_time, domain_of_interest, structure, time_step, heights, height_var, select_tower)
   1132     dsF = combine_towers(fdir,restarts,simulation_start_time,tower_names,
   1133                          structure=structure, time_step=time_step,
-> 1134                          heights=heights, height_var=height_var)
   1135     return dsF
   1136 

~/Code/Python/mmctools/mmctools/wrf/utils.py in combine_towers(fdir, restarts, simulation_start, fname, structure, time_step, dx, dy, heights, height_var, agl, verbose, **kwargs)
   1041                                height_var=height_var,
   1042                                agl=agl,
-> 1043                                **kwargs)
   1044             data.append(ds)
   1045         data_block = xr.combine_by_coords(data)

~/Code/Python/mmctools/mmctools/wrf/utils.py in to_xarray(self, start_time, time_unit, time_step, heights, height_var, agl, structure, **kwargs)
    641                 time_unit=time_unit, time_step=time_step,
    642                 heights=heights, height_var=height_var, agl=agl,
--> 643                 **kwargs)
    644         ds = df.to_xarray()
    645 

~/Code/Python/mmctools/mmctools/wrf/utils.py in to_dataframe(self, start_time, time_unit, time_step, unstagger, heights, height_var, agl, exclude)
    500             else:
    501                 nz = self.nz
--> 502             datadict = self._create_datadict(varns,unstagger)
    503             if hasattr(self, height_var):
    504                 # heights (constant in time) were separately calculated

~/Code/Python/mmctools/mmctools/wrf/utils.py in _create_datadict(self, varns, unstagger, staggered_vars)
    378                         # don't throw a warning if w is already unstaggered by the code
    379                         # last value is (w(model top) + 0.0)/2.0
--> 380                         assert np.all(tsdata[:,-1] == 0), 'Unexpected nonzero value for '+varn
    381                     # drop the trailing 0 for already unstaggered quantities
    382                     datadict[varn] = tsdata[:,:-1].ravel()

AssertionError: Unexpected nonzero value for qv

For reference, this is called with the following command:

wrf_twrs[case]['FN{}'.format(fino)] = tsout_seriesReader(fdir='/glade/scratch/hawbecke/WRF/MMC/FINO1/20100512_to_20100526/ERA5_MYJ_CHRN_ER5_NOSK_3DOM/',
                                                         restarts=['FINO_2010051212'],
                                                         simulation_start_time=['2010-05-12 12:00:00'],
                                                         domain_of_interest='d03',
                                                         structure='unordered',
                                                         time_step=3.0,
                                                         select_tower=['FN1'],
                                                         #heights=[10.0],
                                                         height_var='ph'
                                                        )

I believe the issue in this is due to the fact that we are checking to make sure the top values for each variable (besides temperature) are at 0.0 assuming that the top of the tslist files is the model top. This is not always the case, however. In this simulation, I am specifying that only the lowest 51 levels should be output to the tslist files. Moving forward, we need to figure out a way to parse / check for interpolation without relying on the top value.

@ewquon
Copy link
Contributor

ewquon commented Aug 24, 2020

@phawbeck you're right. All of these assertions are probably overkill.

@hawbecker
Copy link
Contributor Author

This was addressed in #121 by simply commenting out the assertions, but there probably is a more elegant way to do this... keeping open for now.

@ewquon
Copy link
Contributor

ewquon commented Mar 25, 2021

I think the question is whether or not the assertions, if properly written, would ever catch anything. I had initially put them in because I thought depending on the version of MMC-WRF being run, the output may or may not be destaggered. Is this the case?

@hawbecker
Copy link
Contributor Author

The way it stands now, if WRF is run where tslist is not outputting the full profile (ts_max_level != number of eta levels) then these assertions would not work and there really isn't a good way to determine staggering. Theoretically, you could look in the WRF namelist.input file to see if tslist_unstagger_winds = .true., but there's no guarantee the namelist matches the output. What I could do, though, is add a string into the header of the tslist output saying "staggered" or "unstaggered" depending on the tslist_unstagger_winds param. Then, searching for this flag in the header will be easy and we'd know if we should destagger or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants