Bugfix/gahm converge3

[WPringle]

Fix for convergence issue regarding #165

[WPringle]

I'm still wondering about if should limit Rrat to be always < 1 (0.95) or to allow it to be greater than 1 also. The issue is sometimes the provided 64-kt isotachs of (mainly) western quadrants are < Rmax. In our assumption this doesn't make sense but it can be real because the Rmax for that quadrant may be smaller than the overall Rmax.
Let me rethink the theory.

[SorooshMani-NOAA]

@WPringle I'm not sure if I fully understand; when you say:

Rmax for that quadrant may be smaller than the overall Rmax

Do you mean with a given ATCF row (as defined in ATCF forecast) where RAD is equal to 64, the RAD3 and RAD4 columns could be smaller than RMW column?

What is the problem then with going with the abs value difference like before instead of limiting to be less than 0.95? is 1.05 going to cause the same convergence issue? I thought we only want to avoid 1 ratio, right?

[WPringle]

@SorooshMani-NOAA Yeah originally, the idea was just to avoid close to one which gives instability problem. We can also do the 1.05 limit as well. But when I compare the test output files there are some cases that < 0.95 seems more reasonable, may other cases allowing > 1.05 more reasonable. So just want to think more about assumptions and how to edit for consistency.

[SorooshMani-NOAA]

@WPringle may I ask what is your criteria when saying

seems more reasonable

? Is it comparing it against results from the current main branch approach? Or something else? Like looking at the full distribution and calculating something on it?

[WPringle]

@SorooshMani-NOAA Basically yeah how the perturbation values change from the current main branch approach, and thinking about what makes more sense from a physical perspective. It is perhaps a somewhat subjective judgement I admit.

[WPringle]

@SorooshMani-NOAA I decided that it makes sense to limit Rrat <= 1, and we can do that through a Rankine vortex assumption, that is, V = Vmax*RMW/r for r > RMW.
therefore Rrat = RMW / R64 = Vr(R64) / Vmax

[WPringle]

@SorooshMani-NOAA Some changes based on looking into the GAHM code and literature further. Overall, the effects are mostly minimal, with changes usually about 1 n mi to isotach radii here and there.

[SorooshMani-NOAA]

@WPringle if there's no rush, I will merge this when I get back from HFIP

[WPringle]

Latest change makes the isotach radii more consistent with those provided by NHC. For example if the only non-zero isotach radii value is in the SEQ then the update keeps it to the SEQ. Previously, due to assumed rotation of translation speed towards the NEQ, the isotach radii would shift from the SEQ to the NEQ in this case.

[WPringle]

@SorooshMani-NOAA Not sure why failing as the test files were updated and ran on my side fine..

[SorooshMani-NOAA]

@WPringle let me run it locally on my side as well to see what happens

[SorooshMani-NOAA]

@WPringle I see the same change in my local.. I'm updating the test reference here: 1403d99. Feel free to push this to your branch if all looks good! Then I can merge to main

[WPringle]

@WPringle I see the same change in my local.. I'm updating the test reference here: 1403d99. Feel free to push this to your branch if all looks good! Then I can merge to main

Interesting thanks! I'll take another look on my local and see if can work it out.

[SorooshMani-NOAA]

@WPringle are you running your tests on a mac? Maybe there's a difference between results in mac vs linux that is causing the issue!

[WPringle]

@SorooshMani-NOAA No it's linux. I think it is a tricky precision issue based on package versions etc. Looking further so we could avoid the problem.

[SorooshMani-NOAA]

@WPringle I remember in one of the other packages we had something like this about the precision caused by numpy version ... I'm not sure what we did there ... but I guess I pinned the version of numpy ... which is a short term solution!

[WPringle]

@SorooshMani-NOAA So what version of numpy you have?

[SorooshMani-NOAA]

$ pip list | grep "\(numpy\|scipy\)"
numpy                1.26.4
scipy                1.12.0

[WPringle]

$ pip list | grep "\(numpy\|scipy\)"
numpy                1.26.4
scipy                1.12.0

Thanks, I still get different result with the same versions of these packages. What other packages could be important I wonder.

[SorooshMani-NOAA]

@WPringle I'm not sure, maybe python version and underlying numpy c libraries(?!). btw do you delete your data/output every time before running?