ESCOMP / CMEPS

NUOPC Community Mediator for Earth Prediction Systems
https://escomp.github.io/CMEPS/
24 stars 79 forks source link

Issue with So_t field under ATM+DOCN configuration #414

Open uturuncoglu opened 1 year ago

uturuncoglu commented 1 year ago

@jedwards4b @mvertens I think there is something wrong in the following piece of code in CMEPS,

https://github.com/ESCOMP/CMEPS/blob/04e2f6bc98959ec9b062de8fde06197c8a64c0e1/mediator/esmFldsExchange_cesm_mod.F90#L1364C11-L1364C93

In my case, I am tying to run WRF+DOCN configuration (CMCC regional coupling work) and it seems that So_t is not passed to WRF correctly. The mediator history file shows that field read in from DOCN correctly (ocnImp_So_t looks fine) but atmExp_So_t has all zeros. Initially, I think that maybe something wrong with the mask values but I could not find any issue over there. So, I changed it like following,

   if (fldchk(is_local%wrap%FBexp(compatm), 'So_t', rc=rc)) then
      call addmap_from(compocn, 'So_t', compatm, mapnstod_consf, 'ofrac', ocn2atm_map)
      call addmrg_to(compatm, 'So_t', mrg_from=compocn, mrg_fld='So_t', mrg_type='copy')
   end if

and now atmExp_So_t looks fine. BTW, i am using mapnstod_consf but maybe this could be mapbilnr_nstod. mapconsf does not fill the coastline since we have land-sea mask difference between atmosphere and ocean.

Anyway, I am not sure why this is not catched before. Maybe the configurations were always using land and ice too (even with data ones) and atm+docn is not tested under CEMS framework. Let me know what you think. This is just one line fix and I could create a PR about it. I am not sure this requires testing or not.

BTW, it seems this is correct in nems side,

https://github.com/ESCOMP/CMEPS/blob/04e2f6bc98959ec9b062de8fde06197c8a64c0e1/mediator/esmFldsExchange_nems_mod.F90#L240

Also, we might need to correct masking for the interpolation. At this point following masking is used from ocean to atmosphere,

 (module_med_map: med_map_routehandles_initfrom_field) creating RH consd for ocn to atm srcMask =          0 dstMask =    -987987

but maybe we need to mask out land in the atmosphere side side this is SST. So maybe we could set dstMask in ocean->atmosphere configuration to 0 (land) to prevent extrapolation through land like following (atmExp_So_t) field after interpolation. It is fine over ocean but it looks weird over land.

Screenshot 2023-10-13 at 11 53 23 PM

To fix it, I could add following

       if (n1 == compocn .and. n2 == compatm) then
         srcMaskValue = 0
         dstMaskValue = 0
      endif

to med_map_routehandles_initfrom_field() call under cesm section. This will fix the field like following,

Screenshot 2023-10-14 at 12 20 19 AM

in this case, the extrapolation also affects lake in WRF side but this is masking issue in WRF cap and I'll fix it.

I am not sure this changes will lead baseline change or not. I don't think since this configuration seems not tested under CESM. Maybe there is no need to play with mask and we could go with the original field (extrapolated also over land). Anyway, let me know what you think.

mvertens commented 1 year ago

@uturuncoglu - thanks for finding this. For CESM when we run a case with CAM/CLM/DOCN/CICE-prescribed - we almost always use a grid where CAM/CLM/DOCN/CICE are on the atm grid (there is no regridding). The land/ocn mask on the lnd/ice/docn grid is obtained by mapping the specified mask mesh to that target grid. So you are right - this configuration is not tested under CESM and I think you found a real bug. It would be good to test an F compset where the ocean/ice is on a different grid with your changes.

uturuncoglu commented 1 year ago

@mvertens What do you think about the changes in the masking? It is working in my case but not sure how affects other CESM configurations. I could not be sure about it. I could run aux_cmeps tests under CMEPS. Do you think that it would be sufficient.

mvertens commented 1 year ago

@uturuncoglu - the prognostic atm in CESM alway assumes that there are valid points everywhere. I think the masking you are suggesting would effect CESM configurations. Could you try a fully active case with your proposed masking - I would be surprised if the answers were not different.

mvertens commented 1 year ago

@jedwards4b - do you agree with my conclusion?