If area units on source grid file are in sq deg, convert to sq radians #2022
Conversation
This just applies to source grid files in the scrip format. Without this fix, areas were assumed to be in sq radians, which led to mapping weights that were off by about a factor of 3000 if areas were actually in sq degrees.
|
@alperaltuntas - @mnlevy1981 suggested that we start adding you as a reviewer for runoff mapping-related changes, so I have done that here. I also went ahead and made you the assignee. Let me know if you have questions about the process of being an assignee, because it looks like this may be the first cime PR for which you're the assignee. |
There was a problem hiding this comment.
What happens if units is not an attribute in the netCDF file? (Should you check rcode of the nf_get_att_text call before checking the value of units?) I would be okay with treating a missing unit attribute as "square radians", since it seems like that matches previous behavior.
Also give a more helpful message if grid_area has unrecognized units
|
Good catch. I have just pushed a commit that aborts if no units are found. I'm more comfortable with this conservative approach rather than assuming units of square radians. |
|
@billsacks -- I'm okay with aborting if no units are found, but I'd like to wait until cheyenne is back up and test this by re-generating |
|
@mnlevy1981 The r05, r01 and rx1 mappings do not enter the block of code modified in this PR, because they use 'rtm'-formatted files (for r05 and r01) or 'obs'-formatted files (for rx1). The two As an aside: In looking into this, I noticed that (if I'm reading the code correctly) incorrect areas and mapping weights will currently be used if you try to generate mappings with the r01 grid, because 'rtm'-formatted files use this block of code, which assumes a 0.5 deg grid: map%area_a(n) = 0.5 * 0.5 * cos(lat*DEGtoRAD) * DEGtoRAD * DEGtoRAD |
There was a problem hiding this comment.
@billsacks I was 99% sure this block of code was not run with our current runoff maps, but thanks for verifying.
Is the r01 grid used at all? I have a vague memory of noticing the hard-coded 0.5 in the line you mentioned, but I didn't do anything about it because I figured it was only encountered with the r05 grid. Another possible fix would be to add rtm_cell_width_deg or something similar to the namelist (with default value of 0.5) and instructions to set it properly when the runoff grid is rtm-formatted.
|
@mnlevy1981 I'm pretty sure we had problems with the r01 grid and hence haven't used it. There is a 8th degree grid for MOSART, but that hasn't been a standard grid that we run with either. Collin Z. used it in some high res. simulations that he did, but there were problems with it. So I don't know that we have any working high resolution ROF grids. But, I do think there is a need for this for high resolution work. So we might want to check with scientists on the need for it. |
We have old mapping files from r01 to gx1v6 It feels like the best solution would be to require rtm-formatted files to have the necessary metadata on them. That would require making a new version of the r05 (and r01) file with this metadata added. I'm also okay with your proposed namelist option, though - as long as the default is some 'unset' value so that it is required to be set explicitly. I think this should be deferred to a separate issue (as opposed to folding it into this PR). |
Oh, that's a clever solution
I agree |
Because the CPU processors in Titan's login, sevice and compute nodes are different, the "aprun" command is always required even if the model is compiled in mpi-serial. This PR is to add the "aprun" command before "acme.exe" in the batch script on Titan when the model is compiled in mpi-serial. It will fix the issue #2022 [BFB] - Bit-For-Bit
…#2023) Because the CPU processors in Titan's login, service and compute nodes are different, the "aprun" command is always required even if the model is compiled in mpi-serial. This PR is to add the "aprun" command before "acme.exe" in the batch script on Titan when the model is compiled in mpi-serial. It will fix the issue #2022 [BFB] - Bit-For-Bit
Because the CPU processors in Titan's login, sevice and compute nodes are different, the "aprun" command is always required even if the model is compiled in mpi-serial. This PR is to add the "aprun" command before "acme.exe" in the batch script on Titan when the model is compiled in mpi-serial. It will fix the issue #2022 [BFB] - Bit-For-Bit
…#2023) Because the CPU processors in Titan's login, service and compute nodes are different, the "aprun" command is always required even if the model is compiled in mpi-serial. This PR is to add the "aprun" command before "acme.exe" in the batch script on Titan when the model is compiled in mpi-serial. It will fix the issue #2022 [BFB] - Bit-For-Bit
This just applies to source grid files in the scrip format.
Without this fix, areas were assumed to be in sq radians, which led to
mapping weights that were off by about a factor of 3000 if areas were
actually in sq degrees.
Test suite: Tested runoff_map tool with a source file with units in sq
degrees; confirmed that area_a and S values now have the
right order of magnitude. Also tested with a source file
with units in sq radians, and confirmed that the resulting
mapping file is the same as before.
Test baseline: n/a
Test namelist changes: none
Test status: bit for bit
Fixes #2018
User interface changes?: none
Update gh-pages html (Y/N)?: N
Code review: