-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zero sst issue in low resolution s2s test run #149
Comments
From Mariana: It would be good for us to duplicate Phil's problem on cheyenne and then see if modifying the mapping call fixes it. From Jun: From Mariana: The reason you want to scale with either the ocean fraction or the ice fraction is summarized in the CEMPS documentation https://escomp.github.io/CMEPS/versions/master/html/esmflds.html#exchange-of-fields Fractional normalization is needed to improve the accuracy of field exchanges between ice and ocean and atmosphere. Consider the case where one cell has an ice fraction of 0.3 and the other has a fraction of 0.5. Mapping the ice fraction to the atmospheric cell results in a value of 0.4. If the same temperatures are mapped in the same way, a temperature of -1.5 results which is reasonable, but not entirely accurate. Because of the relative ice fractions, the weight of the second cell should be greater than the weight of the first cell. Taking this into account properly results in a fraction weighted ice temperature of -1.625 in this example. This is the fraction correction that is carried out whenever ocean and ice fields are mapped to the atmosphere grid. Note that time varying fraction corrections are not required in other mappings to improve accuracy because their relative fractions remain static. If you look at the NEMS code you will see that all ice->atm mapping is done with ice fraction normalization. The same "should" hold for ocn->atm mapping. I believe that in the fractional configuration this should be no problem - but it seems to sometimes be the case in the non-fractional configuration. We can confirm this. The reason that lfrac and lfrin are zero is that you have no land model communicating with the mediator. The land model sends lfrac and lfrin. In addition, you are doing all of the merging from the ocean, ice and internal FV3 land inside FV3 - not in the mediator. The merging done in the mediator for nems is in the prep_ocn and prep_ice only. So these fractions are set to zero. Please let me know if that makes sense. |
From Mariana: I'd like to keep Denise in the loop on our exchanges - to avoid a lot of pair-wise communication. I am happy to give you the one line change for you to try on hera or whatever machine you are using. It might be easier than working on cheyenne (although you could do that also). in esmFldsExchange_nems_mod.F90 - change This is my hypothesis as to the problem - but of course I might be wrong. But that said, in my opinion moving forward we really should be working with the fractional configuration - since that one is the correct way to proceed. |
@mvertens May I ask how the ofrac is created in mediator? |
@junwang-noaa - this is documented in https://escomp.github.io/CMEPS/versions/master/html/fractions.html.
|
@mvertens that fixes the problem, but is also changes the answer around the ice-edge, which I suppose is why we can the ofrac in there. |
@pjpegion - great to hear that this works. I'm not sure what you mean by "can the ofrac there". |
oops, I suppose I should read what I write. What I meant to say is I suppose this is why we should have the ofrac in there. |
@pjpegion - thanks for the clarification. This now duplicates what NEMS is doing. This should not be a problem in the fractional configuration since the masks should be consistent between the ocean and fv3 and at that point you should scale by |
@mvertens sounds good. Hopefully we can get the fractional grid working soon. |
@pjpegion - the fractional grid configuration should be working in other resolutions. I believe that @DeniseWorthen and I are waiting for Shan (not sure what her github name is) to give us initial data that we can use for the 1 degree ocean. |
it is @shansun6 |
@mariana Vertenstein <mvertens@ucar.edu> So according to the document,
Frac(compatm)[ofrac] = map ocn -> atm Frac(compocn)[ofrac], how does CMEPS
handle mismatched grid points? E.g. ocn thinks it's a land point and
atmosphere thinks it's an ocean point. Also I'd like to check with you what
is the definition of fractional grid in CMEPS. In fv3, non-fractional grid
only means land and ocean do not co-exist in the same grid box, but in a
single grid box, there could be ice fraction and ocean fraction coexisting.
Also I think the fractional grid should be always used in mediator even
though atm itself (or other component) is non-fractional grid because as
you said one atmosphere ocean grid box may cover partial of two ocean grid
boxes, when doing field mapping, the temperature on the fv3 ocean grid
point needs to be computed using the ocean fraction and temperature in the
two ocean grid boxes. May I ask how sst is computed in mediator for atmos
grid box (could also be partial ocean and partial ice) when "none" map type
is used? Thanks
…On Thu, Jul 30, 2020 at 3:13 PM Phil Pegion ***@***.***> wrote:
oops, I suppose I should read what I write. What I meant to say is I
suppose this is why we should have the ofrac in there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TPEZMVE4GBZQIMMD3LR6HA4NANCNFSM4PN5BFJA>
.
|
@junwang-noaa - the fix I provided @pjpegion means that CMEPS is doing exactly what NEMS was doing in the non-fractional configuration. The ocean SST is simply mapped from the ocean to the atm with conservative nearest neighbor. In the fractional grid implementation, the ocean always sets the mask - and FV3 is responsible for ensuring that internally its land fraction is consistent with that ocean mask. The only difference in the CMEPS between the fractional and non-fractional configuration is whether that ocn->atm and ice->atm mapping is conservative or conservative nearest neighbor. |
@mariana Vertenstein <mvertens@ucar.edu> I am not sure if FV3 can ensure
it's land fract to match with mediator's ocean mask (or other different
masks from other components like wave) even for fractional grid. FV3 itself
does have consistent land/ocean fract, but if FV3 thinks it's s fractional
ocean grid but ocean thinks it's complete land point, then it's fv3's
responsibility to figure out how to compute the sst itself? I thought the
current strategy is that every component sends its mask to mediator,
mediator will remap data to each component grid. I think it is critical to
have consistent grids among components, but it would be hard for one
component to handle missing information from other components.
…On Thu, Jul 30, 2020 at 3:59 PM mvertens ***@***.***> wrote:
@junwang-noaa <https://github.com/junwang-noaa> - the fix I provided
@pjpegion <https://github.com/pjpegion> means that CMEPS is doing exactly
what NEMS was doing in the non-fractional configuration. The ocean SST is
simply mapped from the ocean to the atm with conservative nearest neighbor.
In the fractional grid implementation, the ocean always sets the mask - and
FV3 is responsible for ensuring that internally its land fraction is
consistent with that ocean mask. The only difference in the CMEPS between
the fractional and non-fractional configuration is whether that ocn->atm
and ice->atm mapping is conservative or conservative nearest neighbor.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TP6QW4QABL6NFLROBDR6HGH5ANCNFSM4PN5BFJA>
.
|
I thought with fractional grid, the ocean model dictates what the land/sea mask is and then the atmospheric grid is made to match. That was my understanding. @shansun6 is that correct? |
@JessicaMeixner-NOAA - that is exactly what I thought as well. |
I don't see how ocean grid is used to create atmosphere land sea mask grid in fractional grid. |
@junwang-noaa I think that's why @shansun6 was asking for the ocean grid land/sea mask (of whatever resolution) mapped onto the atmosphere grid, to be used as input when creating the oro data. |
@JessicaMeixner-NOAA - I agree. When the ocean model dictates the mask - the ocean fraction on the atm mesh is obtained by mapping the ocean mask to the atm mesh. |
Then the issue should be resolved in non-fractional grid as well, as in the current s2s RT fv3 c96 grid is matching mediator ofrac grid, so there is no zero sst issue. But in Phil's run they do not match, therefore we see 0 sst. @pjpegion how do you create mom6 one degree grid? The issue we see in your test case may not show up if you recreate oro data then, atmosphere grid after you created 1 degree ocean grid, this way you don't need the fix in CMEPS. |
@Junwang - the problem is that we were normalizing by ofrac in the non-fractional grid and that was causing the problem. Once @pjpegion put in my fix not to do that - everything worked. And its consistent with the NEMS approach for the non-fractional configuration. I believe that we do need to normalize by ofrac for the fraction configuration and I will validate this with @DeniseWorthen. |
MOM6 1x1 degree grid file is from GFDL
https://github.com/NOAA-GFDL/MOM6-examples/blob/dev/gfdl/ice_ocean_SIS2/OM_1deg/INPUT/grid_spec.nc
…On Thu, Jul 30, 2020 at 4:51 PM Jun Wang ***@***.***> wrote:
Then the issue should be resolved in non-fractional grid as well, as in
the current s2s RT fv3 c96 grid is matching mediator ofrac grid, so there
is no zero sst issue. But in Phil's run they do not match, therefore we see
0 sst. @pjpegion <https://github.com/pjpegion> how do you create mom6 one
degree grid? The issue we see in your test case may not show up if you
recreate oro data then, atmosphere grid after you created 1 degree ocean
grid, this way you don't need the fix in CMEPS.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGAS5RMR3PI6C2DPFK5TLR6HMK3ANCNFSM4PN5BFJA>
.
--
Jiande Wang
IMSG at NOAA/NWS/NCEP/EMC
cubic 2088
jiande.wang@noaa.gov
phone:3016833725
|
I think it would be helpful if Mariana and I could take some time to a) verify that the non-fractional grid is now working w/ the fix and then b) turn our attention to the fractional grid for low res once we have the required input. I also think it might be helpful maybe for us to have time set aside at one of the Friday technical calls to get everyone on the same page as to how fractional grid should work etc. |
@mvertens I feel the issue is not about ofrac, it's the mismatching of grid between atmos/ocean. In fractional grid test, if there is mismatching points, I believe the ofrac normalizing would still be a problem because the ocean thinks it's complete land (ofrac=0) while fv3 is waiting for sst. I think we need to have consistent grid (fractional or non-fractional) . Basically if ocean grid is changed (in Phil's case), we need to regenerate atm grid to match that. |
@junwang-noaa Jiande gave me the grid file, and I am using the oro_data file that you have me, which you said is from @shansun6. One potential issue is that the oro data file has a slmsk in it, but that one is ignored, and the slmsk in the sfc_data.tile*nc files is used. |
I think we need to make sure the 1x1 ocean grid file I gave to Phil is
identical to what @Shansun used when she generated the oro file.
…On Thu, Jul 30, 2020 at 5:22 PM Phil Pegion ***@***.***> wrote:
@junwang-noaa <https://github.com/junwang-noaa> Jiande gave me the grid
file, and I am using the oro_data file that you have me, which you said is
from @shansun6 <https://github.com/shansun6>. One potential issue is that
the oro data file has a slmsk in it, but that one is ignored, and the slmsk
in the sfc_data.tile*nc files is used.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGASZJBHBEVFIIBXGZYXLR6HP65ANCNFSM4PN5BFJA>
.
--
Jiande Wang
IMSG at NOAA/NWS/NCEP/EMC
cubic 2088
jiande.wang@noaa.gov
phone:3016833725
|
you can ignore my previous comment about the slmsk. I tried initial conditions that pointed to the new oro file, and had the same problem. |
I think both oro files are not matching with the new 1 degree ocean mask. The oro files I got from Shan (and the oro files in current RT) are matching with current s2s C96 RT test 1/4 degree ocean grid mask. @phil Pegion @jiande Wang - NOAA Affiliate Maybe you can provide the new 1 degree ocean file to Shan (@shansun6), She can help to create new oro files and sfc ICs from that. |
@jun Wang - NOAA Federal <jun.wang@noaa.gov> this solved my puzzle. I
recall long time ago I provided 0.25x0.25 ocean grid file to @shan Sun -
NOAA Federal <shan.sun@noaa.gov> , coarse resolution setting is something
we just talked about one month ago and I haven't touched 1x1 degree grid
before. The 1x1 grid file I provided to @philip Pegion - NOAA Affiliate
<philip.pegion@noaa.gov> is from GFDL which I downloaded ~3 weeks ago.
If @shan
Sun - NOAA Federal <shan.sun@noaa.gov> created oro data before this time,
it is highly possible that they will not match.
@shan Sun - NOAA Federal <shan.sun@noaa.gov> : the 1x1 grid file is on
Orion at: /work/noaa/marine/Jiande.Wang/For-Phil/1x1/INPUT
…On Thu, Jul 30, 2020 at 6:48 PM Jun Wang ***@***.***> wrote:
I think both oro files are not matching with the new 1 degree ocean mask.
The oro files I got from Shan (and the oro files in current RT) are
matching with current s2s C96 RT test 1/4 degree ocean grid mask. @phil
<https://github.com/phil> Pegion @jiande <https://github.com/jiande> Wang
- NOAA Affiliate Maybe you can provide the new 1 degree ocean file to Shan (
@shansun6 <https://github.com/shansun6>), She can help to create new oro
files and sfc ICs from that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGAS2JPZMRJRAEJCGRJTTR6H2DRANCNFSM4PN5BFJA>
.
--
Jiande Wang
IMSG at NOAA/NWS/NCEP/EMC
cubic 2088
jiande.wang@noaa.gov
phone:3016833725
|
The "ocean grid" file downloaded from gfdl at any given destination resolution is actually the supergrid---ie, 2x desired resolution. It is the grid that MOM reads in at run time (ocean_hgrid.nc). It cannot be used directly. You can however use the land_mask.nc in that directory. |
@shansun6 have you tried to generate a C96 orography based on the 1-degree ocean grid file? We would like to test this file to see if it fixes our issue. If you don't have time to do it, can you please let me and @HenryWinterbottom-NOAA know where the code is to generate the new oro file? Thanks |
Hi -
Could you please give it a try of oro, sfc and gfs data
at /scratch1/BMC/gsd-fv3-dev/fv3data/c96.mx100_frac/? The ICs are for Oct.
3 2016. It should work with both frac_grid=T or F. Please let me know
how it goes.
Thanks,
Shan
…On Thu, Aug 13, 2020 at 11:43 AM Phil Pegion ***@***.***> wrote:
@shansun6 <https://github.com/shansun6> have you tried to generate a C96
orography based on the 1-degree ocean grid file? We would like to test this
file to see if it fixes our issue. If you don't have time to do it, can you
please let me and @HenryWinterbottom-NOAA
<https://github.com/HenryWinterbottom-NOAA> know where the code is to
generate the new oro file? Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVVT3ORBJWVEXE7NRTLSAQQ45ANCNFSM4PN5BFJA>
.
|
@shansun6 we will give it a try. |
@shansun6 @junwang-noaa using the correct orography file from Shan works. I think this issue can be marked as resolved. |
This fixes it without the one-line change Mariana provided? |
yes |
Thanks, Phil. Good to know that the ICs of C96+1deg are working fine with
no change in the CMEPS source code. -Shan
…On Thu, Aug 13, 2020 at 1:47 PM Phil Pegion ***@***.***> wrote:
yes
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVQRN5Y7DJNML2HLA6TSAQ7NXANCNFSM4PN5BFJA>
.
|
@shansun6 Can you please provide the code that was used to make these changes to the FV3 oro_data files? |
We should have a plan to have several people test and vet the procedure and then move the instructions to the ufs-s2s-model wiki in a public place. This will be needed for the s2s public release. @arunchawla-NOAA what do you think? |
Denise has the code to generate the ocean fraction. She is making it
available somewhere. We have a PR in UFS_UTIL to commit the code to
calculate the lake fraction/depth. Then we calculate the land fraction (and
slmsk) based on the given ocean fraction and lake fraction and use them to
replace the land_frac/slmsk values currently in the oro data.
Hope this helps. Let me know if you have any other questions.
Shan
…On Fri, Aug 14, 2020 at 9:55 AM Henry R. Winterbottom < ***@***.***> wrote:
@shansun6 <https://github.com/shansun6> Can you please provide the code
that was used to make these changes to the FV3 oro_data files?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVRJSDDC62XPVOAZZ6DSAVM6ZANCNFSM4PN5BFJA>
.
|
We have started a document for how to set up the ICs for the S2S model for posting to the UFS-S2S-model wiki. |
@rocky Dunlap <dunlap@ucar.edu> We are preparing the document,
https://docs.google.com/document/d/1HwPjeQHlQe0kYOsXFLv9Wrd0c0shdNUDZeVGE9cZ6CQ/edit#
also Denise's WeightGen script and Shan's orography maker updates will be
committed to UFS_Utils repository. Please let us know if we missed
anything. Thanks
…On Sat, Aug 15, 2020 at 7:37 AM Denise Worthen ***@***.***> wrote:
Mapping ocean mask to FV3 grid is done with two scripts in this repo:
https://github.com/DeniseWorthen/WeightGen
The script generate_frac_land_weights.sh creates the regridding weights to
go from the ocean tripole grid to the FV3 tiles. It loops over a given set
of source and destination files to define 7 resolution pairs. Once the
weights are created, the NCL script make_frac_land.ncl uses the weights to
map the ocean land mask to each FV3 tile. It also loops over all 7
resolution pairs.
The scripts read a SCRIP format file for the ocean tripole grid at each
resolution. Current versions are located here:
/scratch2/NCEPDEV/climate/Denise.Worthen/TTout.
They are generated using fortran code and/or NCL scripts located in the
same WeightGen repo.
The scripts read the FV3 grid mosaic file located here:
/scratch1/NCEPDEV/global/glopara/fix/fix_fv3_gmted2010
Shan Sun compared the existing mapped ocean mask (created via the NEMS
mediator procedure) and found that the difference was no more than 0.01%
for the value of "frac_land" using the new procedure.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TLB5IPECMEDECRGHLDSAZXN3ANCNFSM4PN5BFJA>
.
|
I will close this issue. The transfer of the required tools is in ufs-utils #143 |
Phil Pegion reported that when running the 1 degree low resolution test, he found an issue that there are some lakes in Northern Canada. Based on the coupler file (ufs.s2s.cold.cpl.hi.2012-01-01-03600.nc), it looks like the atmosphere think's these points are ocean, but the ocean model does not have anything at those points. And the result is a tmpsfc=0.0 at these points.
Phil provided test case on hera at:
/scratch2/BMC/gsienkf/Philip.Pegion/UFS-coupled
test1_1deg_cold
test1_1deg_cold.nems
test1_1deg_warm
test1_1deg_warm.nems
The CMEPS build code is in /scratch2/BMC/gsienkf/Philip.Pegion/ufs-s2s-model_1deg/
and NEMS build code is in /scratch2/BMC/gsienkf/Philip.Pegion/ufs-s2s-model_1deg.nems/NEMS/
The text was updated successfully, but these errors were encountered: