update cube_to_target to calculate orographic shape parameter

[whannah1]

This update allows the cube_to_target tool provide the data to support the new orographic drag schemes introduced in PR #6667.

The new output is an optional feature that can be enabled with the "--add-oro-shape" command line flag.

[BFB]

[brhillman]

These changes require passing the shape parameter arrays even if we are not calculating/writing them. One alternative might be to add a separate function to write these to the output file, but maybe that's not worth the effort. Just an idea.

[whannah1]

yea, I struggled with this. I think this approach is better than adding a new routine. This is partly because I worry about appending to a file, I've never done that and I'm not sure how to ensure the file is closed before opening it again. Alternatively, I could open/close the file outside the routines that define variables and write the data, but that sounds like a lot more work.

The current approach just passes the flag used to trigger the shape parameter calculation, so it will ignore those extra (unallocated) variables when the shape parameters are not requested.

[whannah1]

@jinboxie The current version works to produce a topo file with the shape parameter data. How can we verify that it's being correctly?

[jinboxie]

@jinboxie The current version works to produce a topo file with the shape parameter data. How can we verify that it's being correctly?

The easier way is to compare with the current topo data used in BFB test of orodrag.

[whannah1]

@jinboxie The current version works to produce a topo file with the shape parameter data. How can we verify that it's being correctly?

The easier way is to compare with the current topo data used in BFB test of orodrag.

It might be difficult to ensure BFB with this. I think the actual cube_to_target calculations "should" be BFB, but if I understand correctly, you made the topo file with an outdated version of cube_to_target, and the general/recommended topo workflow has evolved, so I have no idea how to recreate the file you made in a BFB way.

Is there any way we can check if the data look reasonable? Would visual inspection of the shape parameter fields be adequate?

[rljacob]

@whannah1 you still need @brhillman or @jinboxie to approve this.

[whannah1]

@rljacob actually I need more time on this. Despite my best efforts to not affect the methods it appears that I'm introduced a bug somewhere. I was just plotting up the raw data from a topo file I created against one that @jinboxie created and the fields don't look the same (see figure below).

I'll ping @brhillman for a quick review after I've resolved the problem.

[jinboxie]

@jinboxie The current version works to produce a topo file with the shape parameter data. How can we verify that it's being correctly?

The easier way is to compare with the current topo data used in BFB test of orodrag.

It might be difficult to ensure BFB with this. I think the actual cube_to_target calculations "should" be BFB, but if I understand correctly, you made the topo file with an outdated version of cube_to_target, and the general/recommended topo workflow has evolved, so I have no idea how to recreate the file you made in a BFB way.

Is there any way we can check if the data look reasonable? Would visual inspection of the shape parameter fields be adequate?

@rljacob actually I need more time on this. Despite my best efforts to not affect the methods it appears that I'm introduced a bug somewhere. I was just plotting up the raw data from a topo file I created against one that @jinboxie created and the fields don't look the same (see figure below).

I'll ping @brhillman for a quick review after I've resolved the problem.

Hi Walter,
I was moving and just settled this week at my new home. I think you are currently doing the right comparison by drawing the things out with the old data. I'm not sure how this bug is put in. OA seems to resemble, but other two are weird. I remember OC has some large values at times, so there was a threshold or things in the code to preventing it going too high (I have vague memories on this). OL is weird.
Do you have a package of old code to reproduce the old data to begin with?
Best,
Jinbo

[whannah1]

Do you have a package of old code to reproduce the old data to begin with? Best, Jinbo

I have your old code - but it doesn't include some updates to cube_to_target that happened while you were developing the new OD schemes. Merging them via git is too difficult, so I would need to either roll back specific changes to the "new" version or manually update the "old" version to make them directly comparable, both of which would be difficult.

My plan is to keep scanning the new code looking for issues that could explain the discrepancies. I think that's going to be more efficient.