Inconsistent land-sea mask among sfc, oro and static information files for control_p8 RT #1423

uturuncoglu · 2022-09-15T04:46:30Z

Description

The land sea mask information used by control_p8 ( and its derivatives such as control_restart_p8) is not consistent between the oro* files, sfc* files and the files that provides static information to the land model (i.e. C96.snowfree_albedo.tile*.nc`). This issue is appeared during the implementation of side-by-side RT for external land component under UFS model.

To Reproduce:

This is tested on NCAR's Cheyenne machine using both Intel and Gnu compilers.
Steps to reproduce the behavior.

checkout UFS code (develop) - git clone --recursive https://github.com/ufs-community/ufs-weather-model.git
run control_p8 RT - ```cd ufs-weather-model/tests; ./rt.sh -k -n control_p8`
check land sea mask (slmsk) in the orography and variable in any file that has static information to see the difference4.

# load required modules
module load nco
module load cdo
module load ncview
# create land-sea mask from variable
ncap2 -O -v -s 'slmsk=-1.0*vegetation_type*0.0;where(vegetation_type > 0) slmsk=1;' C96.vegetation_type.tile1.nc C96.vegetation_type.tile1_mask.nc
# get difference from orography
cdo selvar,slmsk -sub C96.vegetation_type.tile1_mask.nc INPUT/oro_data.tile1.nc diff.nc
# check diff.nc slmsk variable visually to see the land-sea mask difference
ncview diff.nc

there are some points in the static file that has no data (ocean in static file but land in oro file) which cause a crash in the external land component.

Additional context

This issue does not appear in the cpld_control_p8 which seems that the orography and static files are consistent in terms of masking. So, I tried to add following code to the end of fv3_conf/control_run.IN script to overwrite default files from coupled control as a workaround and it seems external land component RT based on control_p8 is working without any issue with this fix.

if [[ $CCPP_SUITE = FV3_GFS_v17_p8 ]]; then
  if [[ $ATMRES == C96 ]]; then
    FV3_DIR=FV3_input_data
  else
    FV3_DIR=FV3_input_data${ATMRES#C}
  fi
  if [[ $ATMRES == C48 ]]; then
     FV3_IC=@[INPUTDATA_ROOT]/${FV3_DIR}/INPUT_L127_mx${OCNRES}/${SYEAR}${SMONTH}${SDAY}${SHOUR}
  else
     FV3_IC=@[INPUTDATA_ROOT]/${FV3_DIR}/INPUT_L127_mx${OCNRES}
  fi
  cp -r ${FV3_IC}/sfc_data*.nc ./INPUT
  cp -r ${FV3_IC}/gfs_data*.nc ./INPUT
  cp -r @[INPUTDATA_ROOT]/FV3_fix_tiled/@[ATMRES]/oro_@[ATMRES].mx@[OCNRES].tile1.nc INPUT/oro_data.tile1.nc
  cp -r @[INPUTDATA_ROOT]/FV3_fix_tiled/@[ATMRES]/oro_@[ATMRES].mx@[OCNRES].tile2.nc INPUT/oro_data.tile2.nc
  cp -r @[INPUTDATA_ROOT]/FV3_fix_tiled/@[ATMRES]/oro_@[ATMRES].mx@[OCNRES].tile3.nc INPUT/oro_data.tile3.nc
  cp -r @[INPUTDATA_ROOT]/FV3_fix_tiled/@[ATMRES]/oro_@[ATMRES].mx@[OCNRES].tile4.nc INPUT/oro_data.tile4.nc
  cp -r @[INPUTDATA_ROOT]/FV3_fix_tiled/@[ATMRES]/oro_@[ATMRES].mx@[OCNRES].tile5.nc INPUT/oro_data.tile5.nc
  cp -r @[INPUTDATA_ROOT]/FV3_fix_tiled/@[ATMRES]/oro_@[ATMRES].mx@[OCNRES].tile6.nc INPUT/oro_data.tile6.nc
fi

But this change breaks the control_restart_p8 and causes error in CCPP/noahmp (see attached trace collected by DDT). The error does not appear if I use the original file (not from coupled control). I am not sure why CCPP/noahmp does not have issue with inconsistent land sea mask and missing static information.
I think that the control_p8 should use the same atmosphere ICs as the cpld_control_p8, this includes the gfs_data*, oro_data* and sfc_data*. They are both using same static files such as C96.slope_type.tile*.

Output

Screenshots
Plots for mask from static file, orography and the difference,

The text was updated successfully, but these errors were encountered:

rsdunlapiv · 2022-09-19T15:45:10Z

@uturuncoglu

But this change breaks the control_restart_p8 and causes error in CCPP/noahmp (see attached trace collected by DDT).

It looks like the CCPP/Noah MP DDT trace was not posted. Can you please include that in the issue so we can get some help debugging?

uturuncoglu · 2022-09-19T15:50:48Z

@rsdunlapiv Here is the DDT trace. Also note that I changed its extension from html to txt since GitHub does not support it when attaching the file to the issue. Anyone who would like to check the trace, please change its extension to html.
myjob.txt

rsdunlapiv · 2022-09-19T16:08:06Z

So the failures are:

Memory error detected in module_sf_noahmplsm::csnow (module_sf_noahmplsm.f90:2565):
null pointer dereference or unaligned memory access.

This is failing at this line.

Memory error detected in csnow_glacier (module_sf_noahmp_glacier.f90:760):
null pointer dereference or unaligned memory access.

This is failing at this line.

@junwang-noaa do you have anyone on your side who can look into this issue? Or do we need to try to debug this as part of the external land model project?

uturuncoglu · 2022-09-19T16:13:48Z

@rsdunlapiv BTW, this is just for restart run. The initial run has no issue with those files (copied over coupled simulation input directory). Maybe something going on wrong with the restart files and mismatched in the land-sea mask. As I know from @junwang-noaa, there is a code in FV3 side that sets the land sea mask.

https://github.com/NOAA-EMC/fv3atm/blob/develop/atmos_model.F90#L3156

uturuncoglu · 2022-10-18T04:34:22Z

@junwang-noaa @barlage JFYI, I did some testing in new external NoahMP model and I tried to define the mask like following (frac is coming from land_frac variable in oro files and vegtype is coming from vegetation_type variable in static vegetation_type files),

    where (noahmp%domain%frac(:) > 0.0_r8 .and. vegtype(:) >= 0)
       noahmp%domain%mask(:) = 1
    elsewhere
       noahmp%domain%mask(:) = 0
    end where

Then, model seems working without modification that I done previously in fv3_conf/control_run.IN. So, this trick seems to solve the issue of inconsistent land sea mask issue. It could be an alternative solution if you don't want (or have time or resource) to fix the input files and make them consistent in the short term (personally, i still prefer to fix input files). Also, this solution does not change answer for existing RTs that uses FV3_GFS_v17_p8 CCPP suite (see the changes in fv3_conf/control_run.IN) like the one modifies fv3_conf/control_run.IN.

BTW, i also checked the mask calculation in following line as an alternative method to use exactly same mask with the FV3,

https://github.com/NOAA-EMC/fv3atm/blob/2458535f9cdfb120f9bcf51dd01907e8d36eab00/io/FV3GFS_io.F90#L1371

but could not reproduce same mask in the external land component side since it requires additional variables like lake_frac and changes based on selected option line frac_grid etc.

Anyway, I still need to test solution that defines mask in NoahMP side for the restart case (control_restart_p8 but with external land component and side-by-side configuration) but newly added RTs are fine with it.

junwang-noaa · 2022-10-19T13:55:38Z

@uturuncoglu I think it is good to define the noahmp mask using noahmp%domain%frac and vegtype. Please confirm with @barlage.

jkbk2004 · 2022-10-19T14:01:10Z

@barlage can you add some comment on this issue? so that we can move on with pr #1443

uturuncoglu · 2022-10-19T15:37:26Z

@junwang-noaa @barlage @jkbk2004 I think the most less complicated short term solution will be option 3. It is your decision.

DeniseWorthen · 2022-10-19T19:31:18Z

@uturuncoglu Did you ever try the control_p8 test case with frac_grid=.false.?

uturuncoglu · 2022-10-19T20:14:36Z

@DeniseWorthen no I did not

uturuncoglu · 2022-10-20T17:07:11Z

I switch to easier solution by modifying land-sea mask code in NoahMP NUOPC cap and removing modifications that uses some files from coupled RT for control under UFS (commit: a8b669d). Note that this is just a temporary solution and those input files needs to be fixed but this fix will allow us to work on this issue and address in near future with separate PR.

uturuncoglu · 2023-01-04T23:42:20Z

@junwang-noaa @barlage I back to this issue again when I try to implement the fully coupled configuration (fv3+noahmp). At this point, I am both checking land fraction as well as the data in vegetation_greenness file and if land fraction is greater than 0 and vegetation_greenness has data over that point (not -999) then I am defining that point as land. But now issue with this logic. For example, in tile 3 the point (27,27) and (42,1) is defined as land if you look at oro file (the value is greater than 0) but vegetation_greenness has -999 for them. So, the external land model assign those point are water but in FV3 output (sfc* files) the land variable (land sea mask) show them as land. So, when I send this data to CCPP/physics these two points have unrealistic data since external land component does not calculate fluxes for those. I think we need to take action for land sea mask inconsistency across the input files otherwise it would be hard for me to make progress in fully coupled -land configuration. If you need I could provide more information. Is there any plan to make input files consistent interns of land sea mask? What do you suggest to proceed with this issue?

uturuncoglu · 2023-01-05T04:38:45Z

@junwang-noaa @barlage I think the control_p8 is not reading those static information from static files but from sfc_data.tile* files. So, maybe the ccpp version noahmp is fine since all the information is coming from sfc_data.tile* files. Am I right? I'll try to setup configurations that uses active atmosphere to read static information from the sfc_data.tile* to see what happens.

uturuncoglu · 2023-01-05T05:53:56Z

@junwang-noaa @barlage I tested the idea and get the static information from sfc_data.tile* files. It seems it fixed the consistency issue and I have no any missing points since all the information uses consistent land sea mask but I have a question. The information in sfc_data.tile* files are masked based on slmsk but there are some grid points set as water but have land fraction > 0 (if you look at oro* files you will see that some points in the coastline has no zero land fraction bu it set as water). How those points handled in the compositing step in ccpp/physics. Maybe ccpp/physics just get data from land when slmsk = 1 and other grid points from atm, ocn or ice. If you don't mind can you clarify this. I don't want to do anything wrong when composting fluxes coming from different components.

uturuncoglu · 2023-01-05T07:22:39Z

Maybe I am wrong. It seems that control_p8 copies static information from @[INPUTDATA_ROOT]/FV3_fix_tiled/ (tests/fv3_conf/control_run.IN) and we need to get the static information from those files. If so, we still need to fix the land sea mask consistency issue in the input files and also recreate sfc_data* and gfs_data* files that are consistent with the new land sea mask information. Anyway, let me know what you think.

junwang-noaa · 2023-01-05T14:24:43Z

@uturuncoglu my understanding is that the slmsk is a composite variable with value 0 or 1 for ocean and land. For fraction grid runs, it might be good to use land_fraction >0 (means grid box has land, in oro, Sfcprop(nb)%landfrac ) to check land point and the corresponding land features such as veg greenness. I think the land fields in sfc file and fix files are created from oro data, so they should be consistent.

barlage · 2023-01-05T17:16:11Z

@uturuncoglu @junwang-noaa The sfc_data tile files should (need to) be fully consistent with the oro files. I have some scripts here (hera:/home/Michael.Barlage/data/check/consistency) that I use to confirm this since inconsistencies happen if one doesn't use the same fix files through the process. We want to run the land model on any point that has landfrac > 0 (in the fractional grid case) so the sfc_data files need veg/soil/etc on each of those points even though the lsmsk may not be land. If the same oro files are used throughout the process, there shouldn't be a problem. Note that this check script will report at the end if there are any defined land points that don't have soil/veg information.

All that said, now I'm confused at what is happening in control_p8. The result of the C96 using the fix, oro and sfc files that I had from a control_p8 are shown below. What I see is that the oro slmsk and sfc veg/soil are consistent so these files will work in a non-fractional case. The fix files have 18322 valid veg types which is consistent with the most recent C96 fractional grid, but there are definitely some mismatches for the fractional grid using these files.

number of cumulative fix_oro_slmsk = 1        : 16196
number of cumulative fix_oro_land_frac (0,1]  : 19333
number of cumulative fix_oro_land_frac = 1    : 6209
number of cumulative fix_oro_land_frac [0.5,1]: 16204
number of cumulative valid fix veg type                    : 18322
number of cumulative valid fix soil type                   : 18322
number of cumulative missing fix veg type with land_frac>0 : 1253
number of cumulative missing fix soil type with land_frac>0: 1253
number of cumulative fix land type = 17                    : 0
number of cumulative sfc_slmsk = 1      : 16196
number of cumulative valid sfc veg type : 16196
number of cumulative valid sfc soil type: 16196
number of cumulative sfc veg  type >0  : 16196
number of cumulative sfc soil type /=14: 16196
number of cumulative sfc veg  type =0  : 39100
number of cumulative sfc soil type =0  : 39100
number of cumulative sfc veg  type =17 : 0
number of cumulative sfc soil type =14 : 0
number of cumulative mismatch veg between fix and sfc  : 2147
number of cumulative mismatch soil between fix and sfc : 2147
number of cumulative mismatch fix_veg and sfc_soil     : 2147
number of cumulative mismatch fix_soil and sfc_veg     : 2147
number of cumulative mismatch oro_slmsk and sfc_veg    : 0
number of cumulative mismatch oro_slmsk and sfc_soil   : 0

uturuncoglu · 2023-01-05T17:19:26Z

@junwang-noaa The sfc and oro files are consistent in terms of masking. I setup land cap to create its mask base on the mask information that is found in oro file (I did not use land fraction for this case) but i think I have still some issue.

I could not set mask in land component based on land fraction because if I do so, I would end up having some points that land_fraction >0 but it is marked as water (in land se mask) and for those points I could not provide static information such as veg greenness (I am assuming to get it from sfc* file too) and land model would not work.

Also, I could not get veg greenness from the static files (C96.vegetation_greenness.) since the land sea mask is not consistent with oro and sfc* files. This was my previous approach and I end up to have missing values for point (27,27) and (42,1) in tile 3.

Anyway, I enabled debug output in CCPP side (aux2d) and look at fields that I am sending to CCPP from external land component. It seems that I have some unrealistic large values over coastlines. I think this is expected since I setup mask in external land component just by taking account the slmsk. I am trying to figure out the issue at this point but I think it is an issue related with the inconsistent land-sea mask across the input files.

uturuncoglu · 2023-01-05T17:23:09Z

@barlage Thanks for the extra information. Yes, there are some mismatch issue in fractional grid case which prevents me to run the external land component all the points that has land fraction > 0. It is strange that CCPP/physics has no problem with it even if there is a mismatch for fractional grid case. Maybe there is an issue but nobody realized it until this point. Not sure.

barlage · 2023-01-05T17:27:19Z

@uturuncoglu Based on the numbers I'm seeing in my output, it might be that the oro/fix/sfc files have not used the same processing. My understanding is that the goal is that the fix/sfc files should have the same veg/soil and that these should have the same count as land_frac>0 in the oro files. That way the sfc files can be used in both the fractional and non-fractional cases. I'm tagging @HelinWei-NOAA since he helped to create these fix files, I believe.

HelinWei-NOAA · 2023-01-05T20:24:38Z

@uturuncoglu @junwang-noaa @barlage I found an inconsistent issue. control_p8 still used the old oro_data in /scratch1/NCEPDEV/nems/emc.nemspara/RT/NEMSfv3gfs/input-data-20221101/FV3_input_data/INPUT_L127. We have couple of updates on the oro data, but the data over that directory never get updated. However the land-sea mask or other fixed fields like veg types used by control_p8 were created based on the updated oro data.

uturuncoglu · 2023-01-05T21:11:14Z

@HelinWei-NOAA Do you think that updating the oro_data* files will fix the problem? In the external land component I am creating mask by using following code,

       where (noahmp%domain%frac(:) > 0.0_r8 .and. vegtype(:) >= 0)
          noahmp%domain%mask(:) = 1
       elsewhere
          noahmp%domain%mask(:) = 0
       end where

this ensures that the grid point will have both land fraction > 0 and also static data such as veg greenness. Since, land fraction is coming from oro_data file and vegtype from static file, inconsistencies in those files creates issue for me and lead to less land cells then used in CCPP/Physics. BTW, do we also need to create sfc_data* file from scratch.

junwang-noaa · 2023-01-05T21:29:46Z

@HelinWei-NOAA Do you have the new oro data? I can make a new data input directory with the updated data (oro, sfc, veg etc) for testing before we update it in ufs-weather model.

HelinWei-NOAA · 2023-01-05T21:45:08Z

@junwang-noaa You can copy the latest oro data from /scratch1/NCEPDEV/nems/emc.nemspara/RT/NEMSfv3gfs/input-data-20221101/FV3_fix_tiled/C96/

uturuncoglu · 2023-01-05T21:48:50Z

@junwang-noaa Is it possible test in my case? I am working on Cheyenne and not have access to Hera. So, If you could copy the fixed files to Cheyenne and let me know what needs to be changed, then I could also test in my end.

uturuncoglu · 2023-01-05T22:09:59Z

@barlage @HelinWei-NOAA I am not sure but gfs_data.* need to be consistent too.

HelinWei-NOAA · 2023-01-05T22:11:28Z

@barlage I think the ICs also need to be recreated with the right oro data

junwang-noaa · 2023-01-06T01:28:12Z

@HelinWei-NOAA @barlage @yangfanglin May I ask who can help create the new sfc_data from the new oro data? The current sfc_data is under: /scratch1/NCEPDEV/nems/emc.nemspara/RT/NEMSfv3gfs/input-data-20221101/FV3_input_data/INPUT_L127. Thanks!

HelinWei-NOAA · 2023-01-06T02:36:50Z

@junwang-noaa Bing Fu created all ICs including sfc_data for prototype tests. Who created the current sfc_data file? George?

HelinWei-NOAA · 2023-01-06T14:11:46Z

Here is the procedure how to create sfc_data created by Fanglin

yangfanglin · 2023-01-06T15:39:36Z

I thought all the "fix" files saved under, for instance on Cactus at /lfs/h2/emc/global/noscrub/emc.global/FIX/fix/orog/20220805, have followed the procedure and are all consistent. The UFS_UTIL/CHGRES has been pointing to the latest fix files as well.

junwang-noaa · 2023-01-06T15:50:54Z

@yangfanglin The input data for RT control_p8 test is still using the old oro/sfc files. I am going to follow your document to create new sfc_data from the updated oro data. By the way, where are the oro_data_ls.tileX.nc and oro_data_ss.tileX.nc fix files? I do not find them under /lfs/h2/emc/global/noscrub/emc.global/FIX/fix/orog/20220805/C96/. Thanks

yangfanglin · 2023-01-06T15:56:38Z

@junwang-noaa Here the "X" represents 1,2 ...6 tiles. You can find them under /lfs/h2/emc/global/noscrub/emc.global/FIX/fix/ugwd/20220805

HelinWei-NOAA · 2023-01-06T15:58:49Z

@junwang-noaa for these two oro data used for the gravity wave drag scheme, I don't think they have any update corresponding to the oro_data update.

yangfanglin · 2023-01-06T16:05:30Z

I had once talked with Mike Toy about recreating the fix files for uGWD.v2. But Mike said there is no need to do this since the GWD code was written to following the "model" grids/masks. It should not cause any inconsistency.

HelinWei-NOAA · 2023-01-06T16:14:50Z

@junwang-noaa You only need to do the step C. Also I don't know for your case if you have to run that script twice (once with ceil oro data, once with ceil oro data)(step C1). You can ask Bing if you have any questions.

@yangfanglin The input data for RT control_p8 test is still using the old oro/sfc files. I am going to follow your document to create new sfc_data from the updated oro data. By the way, where are the oro_data_ls.tileX.nc and oro_data_ss.tileX.nc fix files? I do not find them under /lfs/h2/emc/global/noscrub/emc.global/FIX/fix/orog/20220805/C96/. Thanks

HelinWei-NOAA · 2023-01-06T16:17:17Z

@junwang-noaa Also I remember the sfc_data for the coupled RTs was created by Bing. Maybe it is better to let him create for the uncoupled RTs as well.

HelinWei-NOAA · 2023-01-06T16:19:24Z

sfc_data for coupled and uncoupled is different? or just different initial time?

yangfanglin · 2023-01-06T18:00:05Z

@HelinWei-NOAA That is a good question. I do see under /lfs/h2/emc/global/noscrub/emc.global/FIX/fix/orog/20220805 there are three different directories for, for instance C768,

C768
C768.mx025
C768.mx025_frac

Can someone check if the files under the three directories are different ?

I think for unification and consistency we should be using the C768.mx025_frac for both coupled or uncoupled, and for both fractional and non-fractional grid options.

uturuncoglu · 2023-03-07T16:46:19Z

@junwang-noaa @HelinWei-NOAA @barlage I just wonder if we have any progress in this issue. Are we plaining to update input files for standalone cases soon?

junwang-noaa · 2023-06-27T12:29:15Z

Just a update on this issue. Mike is leading project to update the script to create new ICs, once the script is ready, we can create consistent fix files and ICs for the test case.

DeniseWorthen · 2024-02-06T15:59:16Z

@junwang-noaa Is this related to George's current PR #2005 ?

uturuncoglu · 2024-07-01T22:33:13Z

@junwang-noaa @DeniseWorthen @barlage Just to update about this old issue. As I mentioned before, I have still issue with the land component even if I use V2 sfc/oro files. I first write a very basic NCL script to check number of land and ocean points for all the input files of control_p8_atmlnd test (after fixing issue that overwrites the v2 files) that I am using.

begin
  lst = (/ (/ "C96.slope_type.tile1.nc"           , "slope_type"               /), \
           (/ "C96.snowfree_albedo.tile1.nc"      , "visible_black_sky_albedo" /), \
           (/ "C96.soil_color.tile1.nc"           , "soil_color"               /), \
           (/ "C96.soil_type.tile1.nc"            , "soil_type"                /), \
           (/ "C96.substrate_temperature.tile1.nc", "substrate_temperature"    /), \
           (/ "C96.vegetation_greenness.tile1.nc" , "vegetation_greenness"     /), \
           (/ "C96.vegetation_type.tile1.nc"      , "vegetation_type"          /), \
           (/ "C96.maximum_snow_albedo.tile1.nc"  , "maximum_snow_albedo"      /), \
           (/ "oro_data.tile1.nc"                 , "land_frac"                /), \
           (/ "sfc_data.tile1.nc"                 , "vtype"                    /) /)

  nfiles = dimsizes(lst(:,0))

  do i = 0, nfiles-1
    nc = addfile(lst(i,0), "r")
    rank = dimsizes(dimsizes(nc->$lst(i,1)$))
    if (rank .gt. 2) then
       var = nc->$lst(i,1)$(0,:,:)
    else
       var = nc->$lst(i,1)$
    end if
    if (isfilevaratt(nc, lst(i,1), "_FillValue") .or. isfilevaratt(nc, lst(i,1), "missing_value")) then
      nlnd = sum(where(ismissing(var), 0, 1))
      nocn = sum(where(ismissing(var), 1, 0))
    else
      nlnd = sum(where(var .gt. 0.0, 1, 0))
      nocn = 1
      dims = dimsizes(var)
      do j = 0, dimsizes(dims)-1
        nocn = nocn*dims(j)
      end do
      nocn = nocn-nlnd
    end if
    print(lst(i,1)+" - nlnd, nocn = "+nlnd+" "+nocn)
    delete([/ nc, var, nlnd, nocn /])
  end do
end

This basically prints out

(0)	slope_type - nlnd, nocn = 3804 5412
(0)	visible_black_sky_albedo - nlnd, nocn = 3804 5412
(0)	soil_color - nlnd, nocn = 3804 5412
(0)	soil_type - nlnd, nocn = 3804 5412
(0)	substrate_temperature - nlnd, nocn = 3804 5412
(0)	vegetation_greenness - nlnd, nocn = 3804 5412
(0)	vegetation_type - nlnd, nocn = 3804 5412
(0)	maximum_snow_albedo - nlnd, nocn = 3804 5412
(0)	land_frac - nlnd, nocn = 3804 5412
(0)	vtype - nlnd, nocn = 3804 5412

It looks like number of land and ocean points are same. But, I think this is not correct way to check the land and sea points. Then, I used simple script that you can find in the description of this issue and try to look at mask difference with it. For oro file (as an example tile 1), it looks like the oro file mask is not matching with fixed files around coastline (based on slmsk variable),

Then, I did same with but in this case with surface file (again using same variable slmsk). It strangely match with the fixed files and I am not seeing any issue with the mask. I double check that in my run directory is V2 but maybe it is not consistent with oro file. To be sure, I plot the difference of slmsk variable between sfc and oro files and it seems I am correct and they are not matching. You could see it from following plot,

I think maybe I need to switch back to use original files and not to use V2 file for initial conditions for land coupled configurations. At this point, the active atmosphere coupled RTs seems to use V2 but not actually since @DeniseWorthen found a issue - #2267 and the configurations are running since they are still using original files due to a bug in

ufs-weather-model/tests/fv3_conf/noahmp_run.IN

Line 36 in e784814

cp -r @[INPUTDATA_ROOT]/${inputdir}/INPUT_L127/sfc_data.tile*.nc ${targetdir}/.

(this needs to be consistent with control_run.IN -

ufs-weather-model/tests/fv3_conf/control_run.IN

Line 23 in e784814

elif [ "$V2_SFC_FILE" = "true" ]; then

and have v2 mods) that overwrites v2 files.

Anyway, if there is a oro file which is consistent with V2 surface file, I could also try with it. Let me know what you think? Maybe fv3 is updating the mask internally and writes to sfc file and then there is no way to have land-sea mask consistent with the oro file but now sure.

uturuncoglu · 2024-07-01T22:36:51Z

@junwang-noaa @DeniseWorthen @barlage JFYI, The component land model calculates its mask using land fraction coming from orography file and vegetation type fining from fixed file (https://github.com/NOAA-EMC/noahmp/blob/ec38ea3d902644cd4519d5fe060316859ccdc108/drivers/nuopc/lnd_comp_domain.F90#L245). So, those two needs to be consistent to have correct masking that matches with sfc file since fully coupled configurations are using sfc file for initial conditions. So, land component model needs to have consistent view of land sea mask for those files (oro, fixed files and sfc file) to function properly.

uturuncoglu added the bug Something isn't working label Sep 15, 2022

uturuncoglu mentioned this issue Sep 15, 2022

Test restart for side-by-side configuration esmf-org/noahmp#9

Closed

This was referenced Sep 30, 2022

Add support for external land component NOAA-EMC/fv3atm#591

Merged

Bring external land component support to UFS #1443

Merged

jkbk2004 assigned barlage Oct 19, 2022

junwang-noaa added this to EMC backlog Feb 13, 2023

junwang-noaa self-assigned this Mar 27, 2023

junwang-noaa moved this to Todo in EMC backlog Mar 27, 2023

junwang-noaa moved this from Todo to In Progress in EMC backlog Mar 27, 2023

junwang-noaa added this to GFSv17/GEFSv13 model infrastructure FY23Q3 Mar 27, 2023

junwang-noaa moved this to Todo in GFSv17/GEFSv13 model infrastructure FY23Q3 Mar 27, 2023

junwang-noaa removed this from EMC backlog Apr 24, 2023

uturuncoglu mentioned this issue Jun 27, 2023

Land surface upgrades for HR2 #1777

Merged

35 tasks

junwang-noaa moved this from Todo to Blocked in GFSv17/GEFSv13 model infrastructure FY23Q3 Jul 3, 2023

This was referenced Mar 8, 2024

add export of cpl_scalars NOAA-EMC/noahmp#8

Merged

Land component model configurations that has active atmosphere component are not working in debug mode #2189

Closed

Inconsistent land-sea mask among sfc*, oro* and static information files for control_p8 RT #1423

Inconsistent land-sea mask among sfc*, oro* and static information files for control_p8 RT #1423

Comments

uturuncoglu commented Sep 15, 2022

Description

To Reproduce:

Additional context

Output

rsdunlapiv commented Sep 19, 2022

uturuncoglu commented Sep 19, 2022

rsdunlapiv commented Sep 19, 2022 • edited Loading

uturuncoglu commented Sep 19, 2022

uturuncoglu commented Oct 18, 2022 • edited Loading

junwang-noaa commented Oct 19, 2022

jkbk2004 commented Oct 19, 2022

uturuncoglu commented Oct 19, 2022

DeniseWorthen commented Oct 19, 2022

uturuncoglu commented Oct 19, 2022

uturuncoglu commented Oct 20, 2022 • edited Loading

uturuncoglu commented Jan 4, 2023

uturuncoglu commented Jan 5, 2023

uturuncoglu commented Jan 5, 2023 • edited Loading

uturuncoglu commented Jan 5, 2023

junwang-noaa commented Jan 5, 2023

barlage commented Jan 5, 2023

uturuncoglu commented Jan 5, 2023

uturuncoglu commented Jan 5, 2023

barlage commented Jan 5, 2023 • edited Loading

HelinWei-NOAA commented Jan 5, 2023 • edited Loading

uturuncoglu commented Jan 5, 2023

junwang-noaa commented Jan 5, 2023

HelinWei-NOAA commented Jan 5, 2023

uturuncoglu commented Jan 5, 2023

uturuncoglu commented Jan 5, 2023

HelinWei-NOAA commented Jan 5, 2023

junwang-noaa commented Jan 6, 2023

HelinWei-NOAA commented Jan 6, 2023

HelinWei-NOAA commented Jan 6, 2023

yangfanglin commented Jan 6, 2023

junwang-noaa commented Jan 6, 2023

yangfanglin commented Jan 6, 2023

HelinWei-NOAA commented Jan 6, 2023

yangfanglin commented Jan 6, 2023

HelinWei-NOAA commented Jan 6, 2023

HelinWei-NOAA commented Jan 6, 2023

HelinWei-NOAA commented Jan 6, 2023

yangfanglin commented Jan 6, 2023

uturuncoglu commented Mar 7, 2023

junwang-noaa commented Jun 27, 2023

DeniseWorthen commented Feb 6, 2024

uturuncoglu commented Jul 1, 2024

uturuncoglu commented Jul 1, 2024

Inconsistent land-sea mask among sfc, oro and static information files for control_p8 RT #1423

Inconsistent land-sea mask among sfc, oro and static information files for control_p8 RT #1423

rsdunlapiv commented Sep 19, 2022 •

edited

Loading

uturuncoglu commented Oct 18, 2022 •

edited

Loading

uturuncoglu commented Oct 20, 2022 •

edited

Loading

uturuncoglu commented Jan 5, 2023 •

edited

Loading

barlage commented Jan 5, 2023 •

edited

Loading

HelinWei-NOAA commented Jan 5, 2023 •

edited

Loading