pavalawrf / mpasvala

[kalassak]

for discussing pavalawrf

check out the website here: https://paladinofstorms.net/amc/ (under construction)

[kalassak]

updated the coastline shapefiles



all future plots will now display coastlines representative of revision 251 (from 2022-02-04)

the current run (the "september run") will continue to use land/elevation data from (afaik) revision 225 (from 2019-12-04)

if you want to take a look at the shapefiles:

[kalassak]

got mpas to compile and run properly finally

and figured out a way to plot contours directly using the hexagonal grid (with matplotlib's tricontour) so that it doesn't have to be converted (lossily) to a lat-lon rectangular grid first



now i can start to convert the wrf plotting scripts to use mpas output! though i'm not exactly sure how i'm gonna do winds (where do the wind barbs go?)

for those not up to speed on the current pavala weather/climate simulation situation, we are investigating using mpas instead of wrf because:

1 it's meant for global-scale simulations (wrf is first and foremost a regional model, though it does have an unsupported global setup that it can be run in)
2 wrf was having issues near the poles and i was unable to get much past a week in the "september run" test simulation, probably due to not being meant to run as a global model and the weird "rectangular" grid shapes you get near the poles (very short cell x widths)

but unfortunately this means basically starting over from scratch and rewriting all of my scripts that i had set up already

[kalassak]

mpasvala 2026!!!!!!!!!!!!!!

i think this is the 2nd or 3rd time i've installed mpas (i installed it last year, just picking up where i left off after yet another reset) but anyway we've scrapped the idea of using the native cells at least for most of the graphics there's kinda no point and it makes everything more difficult, so most of the graphics will be converted to a lat-lon grid... perhaps the olr (infrared cloud map) will remain in hexagonal cellular form since it does not need to be contoured or otherwise display any data but filled cell color

today i wrote a script for converting basic colorbars to smooth gradients, now i can create colorbars in text format and load them into the graphics scripts rather than hardcoding them into the individual files and typing out each color! (historically we made do with a limited number of colors per bar most of the time, but now we can have super detailed gradients, check it out!!!)



next steps:
- expand the graphics suite with more types of graphics (temp, dew point, precip, upper air stuff)
- create a git repository to make sure everything is backed up!
- simulate with a 60 km (~half degree) or maybe even 30 km grid mesh (~quarter degree! about 1/3 the number of cells in the tropical mesh we want to use in the real deal)
- maybe test with september 2020 data (what the most recent pavalawrf used)

[kalassak]

quick overview of happenings since the last post:

toward the end of april and through what little available time i had in may i was able to put together the majority of the new graphics suite, with the exception of the 850 hPa theta-e plot (which is kind of a new addition? i have a script i made for wrf, but it was never set up for online use so you won't find it in the old wrf graphics on my website)

while recovering from the europe trip and jumping straight back into working 6 days in a row basically we also ran the model out through through september 2nd (the run i've been working with starts with august 2nd), effectively completing the "august run". this was done with the 48 km uniform mesh so halfway decent resolution (~0.4 deg) compared to the first tests. this allowed me to make more zoomed in sector graphics (though the placement of temperature samples & wind barbs have not really been adapted for this yet). i had to stop and restart the model (from where it left off) a few times, and this limits the data i have but for the final 3 days of the sim the run time was 33550 seconds or about 9.3 hours. that's a rate of about 7.75 simulation days per real day! not too bad

finally, during my current break i have set up the scripts for bulk graphics generation via shell script and uploading to a rudimentary viewer my website (you know the one, if you've looked at the pavalawrf stuff before)

little of what i've described in this post is new technology, most of it has just been porting over scripts that were used for wrf adapted to the current mpas setup. that being said, i hereby present the new, but not very improved mpas model graphics page! check it out here: https://paladinofstorms.net/amc/plots.html it replaces the old link on the main amc page - those graphics can still be accessed via the wrf model runs page on tropicalcyclonedata.net

it's still a work in progress but you can see (at the time of this writing) the first ~15 days of the sim for every plot type except 850 hPa theta-e for the three northern hemisphere sectors. i'm going to need to figure out how to make a better viewer for when there's like a year of mpasvala graphics to look through... but that's a bit down the road still

also the graphics are sloppy and need some work, but anyway

here's hurricane debby in the northwest sector:



and a novel wpac storm in the northeast!!! (there are more in the sim!)



next steps:
- porting over the plasim (!!!) tc tracking algorithm to do some analysis
- back scripts up to github!
- figure out the graph partitioning for the 60-15 km tropical refinement mesh and do a comparison august run with that mesh
- begin to reland?

[kalassak]

spent a lot of time over the last two days trying to get the plasim low/tc tracking algorithm (which tries to track every low and then decide if it's a tc or not) working but it has a lot of problems and i've remembered that i'm going to be personally investigating each tc that comes up in the sim, like... i'm playing with pavala, that's what this is, this isn't my capstone or some scientific paper. so, i think i'm going to revert to the setup i had going with wrf where i had a basic probing script that showed all the lows in the tropics and tried to guess if they were tropical cyclones or not. but that's all it was, it was an overview with data i could use to interrogate myself whether or not a low was worth investigating. if it was, i could then use a tracker that followed a single cyclone to record its path and intensity. i think that method will end up working out a lot better, because then i don't have a bunch of junk lows to sort through and if terrain noise ends up messing with the tracker i can make it a bit more robust by implementing some sort of 850 hPa vorticity following system or something like hwrf/hafs use. additionally, i can add some cyclone phase calculations for use as a guide with assessing the storms' nature myself.

so i think that's gonna be the next thing i work on

also i noticed the temp and dew point graphics were coming from the 240 km run so i regenerated those



much better

[kalassak]

since the last update we have actually accomplished quite a bit despite me feeling like progress has been slow as of late...

last post's plan to just make a basic overview probing script and focus on the tc tracking script seems like it has been a much better idea. the tracker is not fully complete (it's missing a few of the tracking parameters, particularly "wind circulation" and the cyclone phase functionality), but it has shown good success tracking weak features with no surface circulation, including when they are near and over land! it's based on the hwrf tracking algorithm which seems to generally be able to handle that sort of thing, which is why i chose it.

anyway, have a look at the tracker's diagnostic plots:


tc tracking diagnostic for hurricane c1 (debby), a modeled atlantic storm

i also wrote a script to plot storm centered imagery from hourly outgoing longwave radiation (a good proxy for infrared satellite imagery):



this image is from the 48 km run so it's... quite low resolution. the location and info in the top left is read from the track files generated by the tracker, which can also be used to make, well, track maps for each storm:



i'm not sure how i feel about the graphic design of them but. it'll work for now. both these tracks and the storm-centered olr plots are used on the wiki, and the olr plots could make for good simulated satellite imagery videos

regarding the wiki, i've been working on analyzing the tcs from the 48 km august run and that's mostly done, so i went ahead and started on running the tropical mesh simulations. i had to create some graph partition files for that but it was pretty easy. just had to set up the metis util thing. it wouldn't compile from the provided instructions but a thread on the mpas forum had a solution that ended up working out. wasn't too much of a hassle and creates a partition in like less than a second so. ezpz

the preliminary results from the tropical mesh are pretty:





yay 15 km resolution (in the tropics)!

but unfortunately, simulations are slow af... it only ran about 5 days in the time i went to work for a few days and took my short trip to yellowstone (8 days or so total), for a brutal 38.1 hours/sim day... more on that later.

also, i finally backed up the scripts to github

----

yesterday i improved the tracker's runtime about tenfold, as the tracking of carlotta in the preliminary tropical mesh run took. hours. to get through just 6 days of sim data. each center fix for each time step took almost 1200 seconds (20 mins). that's crazy. the speed at 48 km resolution was more reasonable at something like 128 seconds per timestep. with a bit of smart application of numpy (calculating the distance from a point over an entire array vs looping through individual grid elements and calculating one by one) and changing the grid interpolation from cubic to nearest for the winds, which is only used to plot the wind barbs anyway, i got the timestep runtime for even the tropical mesh down to like. negligible (a few seconds). the diagnostic plots now take by far the longest (~100 s for the tropical mesh). which is kind of annoying, but it's quicker than the 48 km tracking was before, and there's not much i can do to speed up the plotting (matplotlib is slow af), so it will have to do.

speaking of timing and benchmarks... i got that idea from my simulation time tests of mpas itself using different core configurations.

hm. does this forum not have table formatting tags? what in the world

ok anyway:

core configuration - 1 day simulation run time
16 cores, (8) hyperthreaded - 7158 s
8 performance cores - 7832 s
8 cores, (4) hyperthreaded - 9098 s
24 cores, (16 e-cores, 8 p-cores) - 9393 s
16 cores, random - 11128 s
16 efficient cores - 11609 s

surprisingly, to me at least, using hyperthreaded 8 cores (the p-, or performance, cores specifically) was pretty significantly the fastest result. it's kind of disappointing because i have 24 cores and 36 threads to work with! what is this stupid processing architecture! i think unfortunately we will probably have to spin up some aws spot instances to really get some quick compute, probably even for the tests (august run, etc), as the sim time for the tropical mesh is still less than 1 sim day per real day. which is not going to be viable if i even want to run like one year of data, and really, we need/want multiple years! so yeah, aws it is probably but i'm not super keen on installing mpas again as it feels a lot like starting over, though it's not, and they made mpas a lot easier to install a few years back (which i was fortunately able to utilize in the current/most recent install of mpas that i am using).

so... where do we go from here?

i kind of want to still compare the tropical mesh results to the 48 km uniform run and get an idea of how 15 km mpas handles tc genesis, though this paper (Michaelis et al 2019) shows that it's pretty good as far as models go (displays some typical biases and the resolution is not quite high enough to get properly strong winds, but sub-900 hPa tcs are capable of being simulated). i think probably some statistical corrections can be applied at least on the latter point to get corrected tc intensities, or perhaps wind speeds could actually just be calculated using empirical pressure-wind relationships? an interesting possibility i had not thought of before.

but to really get anywhere with this we'll need faster computation. so i guess what we will be doing is investigating what sorts of aws machines there are these days and identifying an appropriate one to run mpas on. then, we need to finish up at least the base graphics script suite and tc analysis tools, because we'll need that to identify the minimum required output parameters. that way, when we install mpas on the aws machine, we can configure it to output only what is needed, saving storage space and bandwidth for when we download all that output (cuz that costs $$$ too), and then we'll have all that data locally and i don't have to worry about sending and duplicating really any of the scripts to the Cloud and it can all be processed on mpasmachine on my own time at my own speed.

then, we can do the comparisons of the different resolution runs...

and then, well. the next step really is to get the deland/reland scripts working for mpas. we really are truly quite close to mpasvalearth's return. the thing i need to think about/look into is where these scripts should be applied. i could have them edit the static and/or init files (whichever is necessary), and i think that would work, but it might be more appropriate to actually go in and edit the geography files, which i would need to figure out the format of because they are like. binary files for some reason. but i'm not entirely sure that's the right route to go with, because there might actually be geography data coming from the processing of the gfs initialization files that have to be written over (which would reintroduce themselves in the init file), but i'm not sure...

but yeah it seems like those are the main next steps: setting up an aws environment & re-implementing the deland/reland scripts to insert pavala geography into the simulation

some other things i thought of as well but are less immediate/less necessary are making an improved viewer for the output and investigating whether the physics suite i have been using (i think the default?) is appropriate for tcs. i know that wrf had different suites for like mid-latitude and tropical and the structure of tcs was far more realistic in the latter. then we're going to have to look into modifying the model for pavala's planetary characteristics (radius, gravity, etc), which will be hard, less from a technical perspective and more from the possibility of missing changes to parts of the model that end up creating an unrealistic/unphysical output that could be hard to notice... but i guess that's why we're running test simulations, so that we can see the effects of each difference along the way. also, i still need to actually getting the sst simulator working, as other than geography, or maybe even moreso than geography, ssts are the number one thing that will actually make pavala weather look pavala-like. so. idk. lots of work to do!

----

things to fix/finish/polish:
- 850 hPa plot
- add "wind circulation" parameters to tc tracking algorithm
- add cyclonephase diagnostics to tc tracker
- better configuration option handling for graphics and tc scripts
- plot viewer

next steps:
- aws environment for running the model and nothing else
- deland/reland - what part of the simulation setup?
- ????
- revive sst simulator
- sample point viewer/soundings?