Feature request: ABL statistics on level >0

[rthedin]

With the recent ability to output boundary data at multiple levels at the same time, we got the ability to run grids that have coarse level 0, and have refinements towards the bottom of the domain. A problem with that is that the ABL statistics only get computed at the level 0. It would be nice to be able to have ABL stats to be calculated at the finest level for every height.

Additionally, I have recently ran into a problem where the sampling of the ABL stats might have an issue with a domain configured with these refinements. I had a case with 80 m level 0, and 3 refinements setup like so

3
1
-10000 -10000 0 10000 10000 1500
1
-10000 -10000 0 10000 10000 700
1
-10000 -10000 0 10000 10000 400

The potential temperature field had discontinuities, while everything else appears to be okay (including the temperature flux). They appear to happen right around the 400 and 700 m mark, where we have a change in resolution. Could be an issue on the sampling routine. See plot below for illustration

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[ewquon]

This would be useful for a study that Bumseok and I have been working on.

[marchdf]

Hi @rthedin,

If I am reading this right, there seems to be 2 issues going on?

1. statistics on fine levels
2. some discontinuity in the sampling

For 1., this is tricky to define for an AMR code. Defining statistics for potentially moving grid is very tricky. Is that what you would be looking for?

For 2, is this still an issue? Can you share a minimal case that illustrates this?

[rthedin]

That's correct. There are two issues.

For 1, in my typical use case, there is no moving grids. Right now, the statistics are defined at all the different z values of the level 0 cell centers. What I am looking for is some flag to enable it also being defined at all the z values of level x cell centers (with x being maybe highest level, maybe being user-specified, maybe being all available levels-- I'm indifferent there). I understand issues with moving grids and/or more complicated scenarios-- which is why I'm thinking of this being a user-specified flag. Does that make sense?

For 2, I believe it is still an issue. I do not have a case on hand that I know for a fact that happened, but a setup with non-constant potential temperature and 80m level 0 resolution with the static refinements like the first post on this thread should reproduce it. I would imagine the reason I haven't seen this error more frequently is that I've been running neutral boundary layers in the recent months, which have a constant theta.

[mchurchf]

@marchdf, to do as Regis is asking makes sense if we have things set up in a "nice" way in which there is a static mesh with refined levels that span the entire horizontal extent of the mesh. And that's the way we set up our cases when we'd want such a new planar averaging feature. So I wouldn't worry about moving meshes adaptation with irregular shapes for the sake of fool-proofing. You'll never make a code like this fool proof, and if a fool wants to use the code, that's their thing. Also, if it spits out a different planar averaging file for each level, and we stitch it together afterward using our Python analysis scripts, that's completely fine by me.

[marchdf]

Ok I will have to think about this...

For 2, @rthedin this feels like something in the ghost cells that's not initialized maybe. If you can provide an input fille, then I could try to replicate.

[github-actions]

This issue is stale because it has been open 30 days with no activity.