philblom
commented
3 years ago 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
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