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

significant_tornado: scalars to ndarrays, clipping, and citation maths #1403

Open
dcamron opened this issue Jul 20, 2020 · 1 comment
Open
Labels
Area: Calc Pertains to calculations Type: Bug Something is not working like it should

Comments

@dcamron
Copy link
Member

dcamron commented Jul 20, 2020

calc.significant_tornado includes the following lines of code:

surface_based_lcl_height = np.clip(atleast_1d(surface_based_lcl_height),
                                              1000 * units.m, 2000 * units.m)
surface_based_lcl_height[surface_based_lcl_height > 2000 * units.m] = 0 * units.m

which will not be able to set values > 2000 m to 0 m after clipping all of those values to = 2000 m. I think this line is unnecessary? The (2000 m - LCL) term, not LCL itself, will go to zero with LCL > 2000 m. If functioning, this line would maximize this term with LCL > 2000 instead of minimize.

Looking into this per #545 also reveals that the normalization value employed here is not documented in the referenced sources, and the cited Thompson 2004b has a fifth term (CIN) not included here. Not sure if these are changed documented somewhere to adapt to surface-based parameters instead of the cited mixed-layer parameters. The cited LCL term is given to be (2000 m - ML LCL) / 1500 m, with the same in the Thompson 2003 formulation, instead of our (2000m - SB LCL) / 1000 m. This and the lower clip of 12.5 m/s instead of 10 m/s for shear appear to be the only changes from the citation, so I might look into that a bit more.

Also, here significant_tornado (and calc.supercell_composite, not sure about others) converts scalar values to ndarrays per #622 and so return those ndarrays inside the resulting Quantity instead of scalars. Makes for inconsistencies in strings (and potentially elsewhere?) as brought up here. Not sure if this behavior will be affected by wrapping from #1353 (guess it's as good a time as any to finally get caught up on all that, huh?) @dopplershift suggested checking for this could end up a part of changes introduced with #1388

I can get rid of the 2000/0 line, but I'm not sure if I should otherwise change up the math and/or address this scalar->ndarray behavior, so I'll look into those some more.

@dcamron dcamron added Type: Bug Something is not working like it should Area: Calc Pertains to calculations labels Jul 20, 2020
@dopplershift
Copy link
Member

ping @mwilson14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Calc Pertains to calculations Type: Bug Something is not working like it should
Projects
None yet
Development

No branches or pull requests

2 participants