GAHM-based Perturbation Convergence #75
Comments
|
@FariborzDaneshvar-NOAA thanks for pointing this issue out. My initial assessment points to the I'll share more details when I learn more. @WPringle do you have any suggestion of where to look to find the source of issues with convergence? |
|
@SorooshMani-NOAA thanks for looking into this. |
|
It is getting stuck when calculating Where |
|
The issue happens calling |
|
The issue is one item in the test for difference between velocity profiles: @WPringle do you have any suggestions for how to address it? |
|
I had come across this a few times that it didn’t converge but then I addressed it so all the tests were converging. It requires some debugging to work it out properly. Can you let me know how to repeat your example, like what storm and how many ensembles? Thanks!
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Soroosh Mani ***@***.***>
Sent: Tuesday, August 27, 2024 10:36:41 AM
To: oceanmodeling/ondemand-storm-workflow ***@***.***>
Cc: Pringle, William ***@***.***>; Mention ***@***.***>
Subject: Re: [oceanmodeling/ondemand-storm-workflow] prep.sbatch timed out on Hercules (Issue #75)
The issue is one item in the test for difference between velocity profiles: (Pdb) p Vr <Quantity([33. 47134769 51. 17436185 66. 52492666 35. 98759579 53. 71332687 69. 19205481 32. 50896769 50. 13027531 65. 43037453 31. 41401263 48. 92169327 64. 07228195
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
The issue is one item in the test for difference between velocity profiles:
(Pdb) p Vr
<Quantity([33.47134769 51.17436185 66.52492666 35.98759579 53.71332687 69.19205481
32.50896769 50.13027531 65.43037453 31.41401263 48.92169327 64.07228195
29.36840886 46.55199002 61.48399824 28.48452583 44.78573501 30.91440999], 'knot')>
(Pdb) p Vr_test
<Quantity([33.47134769 51.17436185 66.52492666 35.98759579 53.71332687 69.19205481
32.50896769 50.13027531 65.43037453 31.41401263 48.92169327 64.07228195
29.36840886 46.55199002 61.48399824 26.28496988 44.78573501 30.91440999], 'knot')>
(Pdb) p abs(Vr_test - Vr) > tol
array([False, False, False, False, False, False, False, False, False,
False, False, False, False, False, False, True, False, False])
@WPringle<https://urldefense.us/v3/__https://github.com/WPringle__;!!G_uCfscf7eWS!buyz6VzvNJV-8Oew9jpFLQ0F6JkdHA-WTR3C6MVlL9OJaYss3OIw7dYRYdLI8uzqAuVVGFAW-yc8Dzh_j8S-bWwP$> do you have any suggestions for how to address it?
—
Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https://github.com/oceanmodeling/ondemand-storm-workflow/issues/75*issuecomment-2312900312__;Iw!!G_uCfscf7eWS!buyz6VzvNJV-8Oew9jpFLQ0F6JkdHA-WTR3C6MVlL9OJaYss3OIw7dYRYdLI8uzqAuVVGFAW-yc8Dzh_j0vpR_hX$>, or unsubscribe<https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/AFBHFHQYWNHA6Q5YQVEDRZLZTSMITAVCNFSM6AAAAABNGKHUVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSHEYDAMZRGI__;!!G_uCfscf7eWS!buyz6VzvNJV-8Oew9jpFLQ0F6JkdHA-WTR3C6MVlL9OJaYss3OIw7dYRYdLI8uzqAuVVGFAW-yc8Dzh_jwIbjngt$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Shouldn't this line change as the following? - Vr_test[Vr_test < tol] = numpy.nan # no solution
+ Vr_test[abs(Vr_test - Vr) < tol] = numpy.nan # no solution |
We're having trouble with perturbing Irma 2017 for 29 ensembles, using regression RMW and GAHM perturbation method |
|
No I don’t think so. The reason to add that line was that sometimes the Vr_test would just go to zero without converging because there is no possible solution.
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Soroosh Mani ***@***.***>
Sent: Tuesday, August 27, 2024 10:46:13 AM
To: oceanmodeling/ondemand-storm-workflow ***@***.***>
Cc: Pringle, William ***@***.***>; Mention ***@***.***>
Subject: Re: [oceanmodeling/ondemand-storm-workflow] prep.sbatch timed out on Hercules (Issue #75)
Shouldn't this line change as the following? - Vr_test[Vr_test < tol] = numpy. nan # no solution + Vr_test[abs(Vr_test - Vr) < tol] = numpy. nan # no solution — Reply to this email directly, view it on GitHub, or unsubscribe. You are
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Shouldn't this line change as the following?
- Vr_test[Vr_test < tol] = numpy.nan # no solution
+ Vr_test[abs(Vr_test - Vr) < tol] = numpy.nan # no solution
—
Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https://github.com/oceanmodeling/ondemand-storm-workflow/issues/75*issuecomment-2312922978__;Iw!!G_uCfscf7eWS!az4eKj54x23DPcJM7LER0In6T4lCidBS-q2FPoQhrHEGKrQQTduQe25Ypw4rvjYZVjq61pGHcIUVUCXAgXpIdoyW$>, or unsubscribe<https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/AFBHFHSHE5UMTMW7XHHPRBTZTSNMLAVCNFSM6AAAAABNGKHUVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSHEZDEOJXHA__;!!G_uCfscf7eWS!az4eKj54x23DPcJM7LER0In6T4lCidBS-q2FPoQhrHEGKrQQTduQe25Ypw4rvjYZVjq61pGHcIUVUCXAgbfdoStL$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@WPringle It was Hurricane Irma with 48 hour leadtime, 29 ensemble members, using GAHM and regression for RMW. |
|
These are the args to Do you want me to also provide the track file being used? |
SorooshMani-NOAA
changed the title
|
@SorooshMani-NOAA @FariborzDaneshvar-NOAA Thank you, I'll try it out. |
|
Note to self, thanks to @WPringle: https://wiki.adcirc.org/Generalized_Asymmetric_Holland_Model |
|
@WPringle I think I don't understand your bisection method. What specifically my understanding is that bisection method works on intervals and then choosing the new interval boundary based on having a 0 intersect between the new point and one of the old points. Here we're doing something a bit different. Can you please explain what is going on? |
|
@SorooshMani-NOAA You are referring to lines below especially to update Bi-section method terminology is used loosely here but essentially we are updating |
|
@WPringle yes I'm referring to this part of code about |
|
@SorooshMani-NOAA The square is coming from the equation where |
|
This is just a test code to reproduce the issue: import pdb
import tempfile
from datetime import datetime
from pathlib import Path
from stormevents.nhc.const import RMWFillMethod
from stormevents.nhc.track import VortexTrack
from ensembleperturbation.perturbation.atcf import (
MaximumSustainedWindSpeed,
perturb_tracks,
)
if __name__ == '__main__':
irma_track_path = Path(tempfile.gettempdir()) / 'irma.dat'
irma_pert_path = Path(tempfile.gettempdir()) / 'irma_perturb_dir'
if not irma_track_path.exists():
track_irma = VortexTrack.from_storm_name(
'irma',
2017,
file_deck='a',
advisories=['OFCL'],
rmw_fill=RMWFillMethod.regression_penny_2023
)
track_irma.to_file(irma_track_path)
pdb.runcall(
perturb_tracks,
39,
variables=[MaximumSustainedWindSpeed],
directory=irma_pert_path,
storm=irma_track_path,
sample_from_distribution=True,
sample_rule='korobov',
file_deck='a',
advisories=['OFCL'],
start_date=datetime(2017,9,10),
end_date=datetime(2017,9,13,12),
parallel=False,
)Note that I used |
|
In this specific case I see the value of calculated
|
|
@WPringle I feel like the approach we're taking is not necessarily a sound one. The condition of the By the way I still don't understand why we invert the |
|
@WPringle I gave it some more thought and I think I understand now what is happening, please correct me if I'm wrong. As I understand, to adjust alpha, you add half of alpha and half of a "correction factor", in this case That gave me the idea of using a "correcting factor" type of a fix to this. By that I mean to reduce the size of correction (centered around value of where rate = 1 / 2**(i//1000)
alpha[Rrat <= 1] *= 1 + (0.5 * (1 + (Vr / Vr_test)[Rrat <= 1] ** 2) - 1) * rate
alpha[Rrat > 1] *= 1 + (0.5 * (1 + (Vr_test / Vr)[Rrat > 1] ** 2) - 1) * rate Or simply rate = 1 / 2**(i//1000)
alpha[Rrat <= 1] *= 1 + (0.5 * (Vr / Vr_test)[Rrat <= 1] ** 2 - 0.5) * rate
alpha[Rrat > 1] *= 1 + (0.5 * (Vr_test / Vr)[Rrat > 1] ** 2 - 0.5) * rate or actually why all the trouble, why not simply: rate = 1 / 2**(i//1000)
alpha[Rrat <= 1] *= 1 + ((Vr / Vr_test)[Rrat <= 1] ** 2 - 1) * rate
alpha[Rrat > 1] *= 1 + ((Vr_test / Vr)[Rrat > 1] ** 2 - 1) * ratebut this last one doesn't work!! I think I'm rushing it ... but do you agree with my general approach? At least the first one that I know worked?! |
|
I think I got my answer about the last one ... I should start from a factor of Now the question is, is this the right approch? This approach assumes that the higher the iteration the closer to the answer we are, so we reduce the rate to avoid jumping back and forth or diverging. @WPringle can you send me the non-converging cases you had to try with this? If they converge and the current tests pass as well, I think we can go with this for now, right? |
|
@SorooshMani-NOAA Let me check this in more detail, I haven't got to it yet. |
|
You can see my code in https://github.com/noaa-ocs-modeling/EnsemblePerturbation/tree/enhance/gahm_converge |
|
@SorooshMani-NOAA I went through and yes I agree the method may not be ideal but now seems to work. I made some small changes but can't push to the EnsemblePerturbation main directly. I work on adding this branch to my fork. |
|
@WPringle thanks, please create a PR once you're ready! |
|
@WPringle it still fails to converge for Idalia 2023, adding the following in the test cases fails: with |
|
@SorooshMani-NOAA OK thanks for finding this! It's a stubborn problem. |
SorooshMani-NOAA
closed this as completed
in
noaa-ocs-modeling/EnsemblePerturbation#161
Default timelimit for prep.sbatch is 30 minutes. It timed out for Irma on Hercules.
I increased the time limit to 2 hours, but it didn't help. This is what I got in
slurm-***.setup.outThe text was updated successfully, but these errors were encountered: