infraGA questions - handling of the BL

[wblumberg]

Hi there,

I'm a user of infraGA and very thankful that this open-source package exists! I have a few questions regarding its operation that I haven't found much information about from the manual. My application is doing acoustic ray tracing in a 60 km x 60 km domain with inputs from the WRF model. My lowest grid point is 2 meters above ground level. I sometimes have complex topography in my domain and my source point is always at ground level. I care a lot about the boundary layer propagation, so I'm interested in understanding how infraGA handles the boundary layer. The manual says it's a no-slip condition that's applied (which is great!), but there's not much else. Would you be able to help me?

1.) If I'm reading the code correctly, there's a scaling of u(z), v(z), and w(z) below the PBL height (z_bndlyr) which in the code looks to be hardcoded to be 2 km above the tallest point specified in the topography of the domain (z_max). I ask this because I have PBL information from the WRF model, and I'm concerned that this scaling might be altering the meteorological dataset in unrealistic ways. Can you explain what might be going on here with the scaling and how I might be able to get around this issue (if it is one?)?

2.) If my vertical grid specified in the input files only goes to 2-meters above the ground, how is c(z=0) computed from my temperature profile? Is it extrapolation via the c(x, y, z) spline?

3.) When my acoustic source location is located at a higher elevation (say a mountain) than other places in the domain, how does the non-range dependent program for infraGA compute the propagation conditions (c, u, v, w, etc.) in the lower elevation locations (say a valley)? If no meteorological data is specified "below ground of the mountain", is this accomplished by extrapolation via the splines as well?

4.) Are there any plans to have infraGA use GPUs when parallelizing the ray-tracing? The use of MPI is very useful, and a code that also uses GPUs might be an excellent step upwards.

Thank you so much for your help in advance!

Greg Blumberg

[philblom]

Greg,

Thanks for your use and interest in the software. To answer your questions,

1. I'm attaching a slide deck from the 2017 ASA meeting that had some preliminary discussion of the boundary layer adjustments. Specifically, on Slide 13 you can read through the boundary layer scaling. The \sigma value is hard coded to 100 meters in the software, but you can modify it in the atmo_state.[...].cpp files (topo::bndlyr_param) and make the scaling at the ground sharper. If you do, make sure you also adjust the step size in the solver because the near-ground gradient might become pretty severe. The discussion on Slide 14 has been updated and is in the appendix of the JASA article that was published last year (https://asa.scitation.org/doi/full/10.1121/10.0002128). The 2 km reference is where the methods no longer compute the boundary layer scaling because it's essentially unity, the actual boundary layer is just a few 100 meters.

2. If your specification only goes to 2 meters, then the solver assumes that is the ground elevation. It does not extrapolate.

3. Following the answer from question 2, if you define terrain or an elevated source, it still defines the atmosphere at all altitude points in the file. I'm not sure if checks the lowest terrain point vs. lowest point in the specification, so that might cause some issues actually. Are you including terrain the simulation, defining an effective elevated source, or defining the elevation at the source height? From the description you've given me, I'd recommend generating a terrain file for use in your simulations. I'm still working on them, but there are Python scripts included and one of them will pull a grid from an ETOPO1 file that's immediately usable in the ray tracer.

4. I've read up a little on GPU parallelizing, but don't have any experience with it. The software is rapidly approaching approaching a point where it'd be useful to have a software engineer or actual computational physicist work through it. I'm a physicist with relatively basic computational abilities (I've been told I'm a relatively poor programmer that's quite good at math).

Hope that all helps,

Phil

ASA_Spring2017-psb_opt.pdf

[wblumberg]

Hi @philblom - thank you so much for getting back to me. Shortly after I asked this question work got extremely busy, and I had to put aside getting back to you for a bit. Things are letting up to the point where I can work on this some more. FYI: I'm using this software to investigate launch range safety concerns, with some guidance from the range safety community. I'm using simulations from the WRF to input into infraGA. My terrain files and atmospheric specifications are coming from the WRF grids, and I've written Python scripts to convert it.

Per question 3: I think I'm running into those issues when I run a domain at Vandenberg Air Force Base with the 3D range dependent code. I thought they were due to the PBL scaling, but since turning that off I don't think that's the issue now.
I'm defining the terrain using the xy.topo file for a 60 km x 60 km domain, with 1 km spacing. The terrain is defined in km above mean sea level and comes from the WRF. I'm also specifying the input *.met files in km (also from the WRF) above mean sea level because the PBL scaling code makes me think they should be the same units. When I specify a ground-level explosion source at a launch pad (30 m AGL) the code will set the propagation region limits for the lower bound at 0.26 km (max height is 0.39 km). Even though I have meteorological data specified below this altitude (say out over the ocean), the interpolation code appears not to recognize that. For example, I looped over the 3D grid outputting the meteorological data (see below). You can see x0, y0, z0, and the ground height (z=0; an ocean point):

x0=0 y0=0 z0=0 z=0
c=338.679 v=-0.786714 u=-0.272481 rho=0.0012528
x0=0 y0=0 z0=0.002 z=0
c=338.679 v=-0.786714 u=-0.272481 rho=0.0012528
x0=0 y0=0 z0=0.01 z=0
c=338.679 v=-0.786714 u=-0.272481 rho=0.0012528
x0=0 y0=0 z0=0.029 z=0
c=338.679 v=-0.786714 u=-0.272481 rho=0.0012528
x0=0 y0=0 z0=0.102 z=0
c=338.679 v=-0.786714 u=-0.272481 rho=0.0012528
x0=0 y0=0 z0=0.2 z=0
c=338.679 v=-0.786714 u=-0.272481 rho=0.0012528
x0=0 y0=0 z0=0.326 z=0
c=338.155 v=-2.85649 u=-0.961685 rho=0.00124706
x0=0 y0=0 z0=0.485 z=0
c=337.686 v=-4.67481 u=-0.796937 rho=0.00122717

Maybe I should be specifying the *.met files in km above ground level? Or should I fake some below ground data (e.g., u=0, v=0) so the code recognizes the correct propagation region?

Thank you so much for letting me know about the scaling. I have been able to play around with the code to understand and explore the PBL scaling. Your slides and the publication helped a lot. Regarding the GPU stuff - I don't have any experience either, but I know of some people who do. I would personally love to see a GPU version.

Thank you again for all of your help!