Improve random walk synthetic track generation#688
Conversation
* Ensure get_country_geometries deals correctly with extent crossing the anti-meridian * get_land_gemoetry to rely on get_country_geometries to avoid redundancies * Ensure coord_on_land properly deals with extent of land_geom and lon * Adding a simple unit test for coord_on_land with points beyond the anti-meridian * Fix in case land_geom is empty (no land within extent) * provide keyword arg in unit test test_get_land_geometry_country_pass * u_coord: some refactoring and linting * u_coord: fix tests for get_land_geometry * coordinates: shapely.geometry.Polygon still referenced in `points_to_raster` * test_coordinates: complementary testcases for get_country_geometries Co-authored-by: Thomas Vogt <thomas.vogt@pik-potsdam.de> Co-authored-by: emanuel-schmid <schmide@ethz.ch>
the assertion statement should likely be suppressed for speed's sake; numba.jit compilation would likely also be good
…meters if hist or synth tracks start over land
That is, let us treat ALL landfalls as worth modelling decay for. In practice this is just modifying one warning.
…DA-project/climada_python into feature/tc-synth-new-model
…ames, bugfix landfall index - When creating synthetic tracks, we apply decays to storms at very high or very low latitudes that are at much higher intensities than anything in the historic record. This updates the parameters in tc_tracks_synth so that at tracks always decay when they get beyond the historically observed latitudes in that basin - Add the track modified triggered by the env variable TRACKGEN_TEST_TARGET_PRESSURE_OVER_SEA. When a synthetic track is choosing a target minimum pressure it now uses only frames from the original track that are over the ocean. This prevents it from choosing the first frame after landfall which can be an unintentionally intense value - Change a few of the timing checks to be based on time rather than number of frames, since the time step can't be assumed to be six hours - Update a landfall index calculation which which chose an index off by one - Add more information while debugging on the tracks that are changed or removed
…DA-project/climada_python into feature/tc-synth-new-model
|
Since this is a very large proposed change to a CLIMADA core module, it would be useful to have a report/publication showing the improvements provided by the changes. How good are the generate random tracks for risk assessment? What are the limitations? How is it an improvement over the previous version? Thanks for improving the tropical cyclone track generation! |
Yes working on a paper or at least a validation and documentation report is planed. Might still take some time though. We’ll let you know. |
|
Separate idea: will it be possible after this pull request to generate random tracks with a frequency and intensity shift compared to the historical tracks? Then it could also be used to generate tracks for future climate projections using the Knutson parameters. That would be very neat. |
My initial reply was: But this does not change between the original methodology and this new one, right? I might well misunderstand what your point was though. After looking at the code, I now say: |
|
Sorry to have been unclear. Let me try again. For generating a random track, the algorithm perturbs the direction at each step, and as I understood also the intensity (with this PR). As I understood, this intensity perturbation is also done randomly (not each random track has the same intensity perturbation, and the perturbation is not uniform over the whole track). If this is correct, and only if, one could with the Knutson parameter not just shift entire tracks, but instead shift the distribution of intensity changes used in the random track generation. Then, one would have two different random track sets for the climate today and the climate projection. |
|
This is a thing that confuses me with the way CLIMADA implements Knutsen (raised by @bguillod in #453 ). You can implement a change in event intensities by adjusting the event frequencies. The intensities change as a consequence. CLIMADA could serve the same events in every TC trackset, but with different frequencies, determined by climate change scenario and year. Doing this has a very nice extra benefit: we don't have to scale pre-calculated windfields, which would make any TC modeller shudder. |
Sure. This is because the CLIMADA Knutson parameter implementation is, and was NEVER meant to be an actual tropical cyclone climate model. So, it is great to see that you might be able to elevate it to such as level. |
|
|
||
| # If the parent storm finished as extratropical, kill any extension frames at times beyond the original track end | ||
| original_size = tracks_list[i].time.size | ||
| if hasattr(track, 'nature'): |
There was a problem hiding this comment.
@ChrisFairless Is my understanding correct that with this check, the model would work also with tracks without the 'nature' field but simply would not be apply to cut off the track in such a case?
| # calculate historical track values that are used for synthetic track modelling | ||
| if land_geom is not None: | ||
| # compute minimum pressure occurring on or after each timestep | ||
| if int(os.getenv('TRACKGEN_TEST_TARGET_PRESSURE_OVER_SEA')): |
There was a problem hiding this comment.
Can you explain the rationale behind this @ChrisFairless ?
My understanding is: you only consider the minimum central pressure of only the ocean points after each timestep (including also the last central pressure value, which I guess is to make sure one value is available for each time step but it should be a high pcen value i.e. low intensity anyway).
Why is that? In which case would you expect minimum future central pressure to be lower (i.e. stronger) if we include also land points? And if this case arises, why not accounting for that value?
As part of the track extension, the required size of a vector is estimated using the distance since landfall. When this is tiny a huge vector is allocated, occasionally causing a memory error. This puts a minimum value of 1 km on that timestep which still allows for large vectors to be allocated, just not infinite ones.
|
Due to low activity, this draft pull request will be closed. Please feel free to reopen it at any time! |
|
@emanuel-schmid Can we expect some updates on this? If not, I would close again due to inactivity. |
|
Closing due to inactivity. Feel free to reopen at any time! |
6 participants
*** DRAFT: WORK IS STILL ONGOING! ***
Changes proposed in this PR:
PR Author Checklist
develop)PR Reviewer Checklist