Opened 8 months ago

Last modified 3 months ago

#2144 assigned help

Sea ice edge error in UM with custom ancillaries

Reported by: dsergeev Owned by: simon
Priority: highest Component: UM Model
Keywords: ancils, ostia, sst, sea ice Cc:
Platform: Monsoon2 UM Version: 10.2

Description

I'm trying to run the nested UM with "custom" SST and sea ice cover ancillary files created using xancil from the OSTIA dataset.

To let the model use my ancillary files, I added these lines to app/um/rose-app.conf:

[namelist:items(5997b35c)]
ancilfilename='$UM_ANCIL_MASK_DIR/qrclim.sst'
domain=1
!!interval=1
!!period=1
source=2
stash_req=24
update_anc=.false.
!!user_prog_ancil_stash_req=
!!user_prog_rconst=0.0

[namelist:items(9500b563)]
ancilfilename='$UM_ANCIL_MASK_DIR/qrclim.seaice'
domain=1
!!interval=1
!!period=1
source=2
stash_req=31
update_anc=.false.
!!user_prog_ancil_stash_req=
!!user_prog_rconst=0.0

The model runs successfully. However, something goes wrong at the edge of sea ice cover, producing erroneous results, e.g. in sensible heat flux (see the figure attached).

What could be causing the problem?

Cheers,
Denis

Attachments (3)

sea_ice_edge_issue.png (1.5 MB) - added by dsergeev 8 months ago.
sea ice edge issue
seaice_diff_astart_ancil_lampii_on.png (102.2 KB) - added by dsergeev 7 months ago.
seaice550_surf_201303241300.png (803.2 KB) - added by dsergeev 6 months ago.
Example of sensible heat flux field in the experiment with idealised sea ice distribution

Change History (28)

Changed 8 months ago by dsergeev

sea ice edge issue

comment:1 Changed 8 months ago by willie

Hi Denis,

This could be due to the sea ice and sst ancillaries being based on an inaccurate land/sea mask. You need to make sure that the ancillaries are all based on the same land/sea mask.

Regards
Willie

comment:2 Changed 8 months ago by dsergeev

Hi Willie,

Thanks for your reply.

I indeed had an issue with land mask in OSTIA not matching the UM mask, causing the model to crash, but I think I fixed it by "remasking" sea-ice and SST ancillaries with the UM mask.

Besides, there is no land that can be mismatched over the open water (in other words, sea area covered with ice is still sea, not land). Or am I missing something here?

Denis

comment:3 Changed 7 months ago by dsergeev

Update:

As far as I understand the issue appears during the reconfiguration stage. The reconfigured start file (e.g. /projects/accacia/deser/cylc-run/u-aj561/share/cycle/20130324T1200Z/NorwegianSea/km2p2/ukv_default/ics/ukv_default_astart) contains the spurious values near the sea ice edge.

I also ran the same experiment with no ice at all in the nested region. In this case, (I guess, unsurprisingly) the reconfiguration works fine, i.e. the start file also has only 0 values for sea ice area fraction. Consequently, in the model run after a couple of hours surface heat flux seems to be smooth, without any spurious edge or "ribbon".

Could you please help me?
Denis

comment:4 Changed 7 months ago by dsergeev

  • Priority changed from normal to highest

comment:5 Changed 7 months ago by dsergeev

I would really appreciate if somebody helped me with this issue, as I have a deadline next month to present this work.

Can you please give me an estimate of when this ticket could be addressed?

Thanks,
Denis

comment:6 Changed 7 months ago by grenville

Denis

Its a bit tricky to find all the files: please give the full paths to

qrclim.seaice
the original start file
all reconfigured files

I can't give an estimate of a time to solution - I do not have a clear picture of what's happening

Grenville

comment:7 Changed 7 months ago by dsergeev

Grenville,

The rose id is u-aj561 and the cycle is 20130324T1200Z.
So the reconfigured start file is /projects/accacia/deser/cylc-run/u-aj561//share/cycle/20130324T1200Z/NorwegianSea/km2p2/ukv_default/ics/ukv_default_astart

The global start file and boundary conditions are archived on MOOSE (moose:/adhoc/projects/accacia/deser/ic_lbc/20130324T1200Z/glm/).

I'm using ancillary files from this directory: /projects/accacia/deser/custom_ancils/N76E10/km2p2/sic15jun/final/, where all the files are copies of ancillary files from previous run of the suite (run with "Create new ancillaries"), except for ice_new and sst_new which are made from the corresponding .nc files using make_ancil_modified.job script in xancil on Monsoon's postproc node. The netCDF files are made using qrparm.mask file from the same directory so that land mask is consistent.

Note that I use ice_new and sst_new instead of qrclim.seaice and qrclim.sst originally mentioned in the ticket.

Cheers,
Denis

Last edited 7 months ago by dsergeev (previous) (diff)

comment:8 Changed 7 months ago by grenville

Denis

Are you sure about the fields in ice_new — it appears that "FRAC OF SEA ICE…" and "ICE EDGE.." are identical — can that be correct?

Grenville

comment:9 Changed 7 months ago by dsergeev

Grenville,

I think in this case it does not matter because the ice edge value is not being read by the suite (Only item 31 is in stash_req variable, which is "sea ice area fraction".

Denis

comment:10 Changed 7 months ago by grenville

Hi Denis

Just to let you know that we are working on this

Grenville

comment:11 Changed 7 months ago by grenville

Denis

Please try reconfiguring again but with lamipii true in

um → Reconfiguration and Ancil.. → Ancil options

let us knew what happens.

Grenville

comment:12 Changed 7 months ago by dsergeev

Grenville,

Thanks for looking into this.

I rerun the experiment with lamipii=true. But there is still mismatch between the sea ice fraction and thickness in the start file and ancillary file data, although that mismatch along the edge is slightly different. The thickness is still being set to 2 m, even though in the ancillary file it's 1m.

I noticed that in the reconfiguration's job.out file,
Ice Fraction : No of small values reset to zero 0
which was
Ice Fraction : No of small values reset to zero 18576
in the previous run (with lamipii=false).

Denis

comment:13 Changed 7 months ago by grenville

Denis

Thanks - that was a bit of a shot in the dark. We'll keep looking.

Grenville

comment:14 Changed 7 months ago by simon

Hi,

When setting AMIPII updating, you also need to specify the sea ice depth ancillary in the ancil window. This will be calculated internally in the model to make it consistent with the sice and sst ancils. Keep the AMIPII option, and in the Configure ancil section, click on 9500b563 and add sea ice depth, code 32. In the main configure ancils section, there should now be 31,32 in the stash_req column.

Also, you appear to be configuring rather than updating the sice and ssts. Is this deliberate?

Simon.


comment:15 Changed 7 months ago by dsergeev

Hi Simon,

I've rerun the reconfiguration stage with what you suggested, and it did help to initialise the ice thickness correctly (in terms of the magnitude). However, the mismatch along the edge is still there (the figure attached).

you appear to be configuring rather than updating the sice and ssts. Is this deliberate?

My idea was to run experiments with a fixed sea ice concentration throughout the run, since it's only 48 hours. But I'm open for other suggestions of course.

Denis

Changed 7 months ago by dsergeev

comment:16 Changed 7 months ago by simon

There doesn't appear to be a scale on your plot, but if the all the values of sea ice fraction in the start dump have been set to a minimum value of 0.3, then this is expected. It's in the nature of AMIPII updating.

I just wanted to check that you were aware that you are using constant SSTs/SICE, which obviously you are.

Simon.

comment:17 Changed 7 months ago by dsergeev

Hi,

So I was wondering if you had any progress on this issue?

I've just looked at the *astart file again and noticed quite large discrepancy between two temperature fields: sea_ice_temperature and surface_temperature, mainly along the sea ice edge and to the east of Svalbard. Perhaps this would help to identify the root of the problem…

Denis

comment:18 Changed 6 months ago by simon

I was waiting for you to reply about the scale on your plot.

sea ice temp is a JULES prognostic and surface temp is a model prognostic, so I wouldn't expect them to be the same. Do you still get the errors in sensible heat flux with AMIPII updating?

comment:19 Changed 6 months ago by dsergeev

Ah, sorry about that. Do you mean a map scale? The grid step is 2.2 km, and there are 700x600 points in the nested domain, so the area of mismatched sea ice concentration along the edge is about 50 km wide.

And yes, the sensible and latent heat fluxes still have this erroneous "dip" near the edge.

Denis

comment:20 Changed 6 months ago by simon

How confident are you that your ancils are correct? Do you have a corresponding run using different ancils which produces expected output?

comment:21 Changed 6 months ago by dsergeev

I think they are correct - they just contain sea ice and SST from the OSTIA dataset reprojected onto the model grid. And the model does not fail…

I tried running the same case with a completely idealised distribution of sea ice, but the heat fluxes still have odd distribution near the ice edge.

Denis

Changed 6 months ago by dsergeev

Example of sensible heat flux field in the experiment with idealised sea ice distribution

comment:22 Changed 6 months ago by simon

Hmm,

OK. I can think of three possible causes.

1) The reconfiguration is somehow mismanaging the SSTs/SICE when they are configured.

2) You're reading in the SST/SICE fields incorrectly due to incorrect settings on the ROSE suite ancil windows

3) There's a bug in the model code.

1) can be checked relatively easily. If you have a time series of SSTs/SICE available, could you try updating them, rather than configuring them. This will mean that they are processed in the model code rather than the reconfiguration.

If that doesn't work, we need to start investigating options 2) and 3).


comment:23 Changed 3 months ago by willie

Hi Denis,

Is this still a problem?

Regards
Willie

comment:24 Changed 3 months ago by dsergeev

Hi Willie,

Yes, I'm afraid so.

Although this problem is not an urgent one, I would like to solve it. Regarding the option 1) suggested in the previous comment, I don't think it works…

Cheers,
Denis

comment:25 Changed 3 months ago by willie

  • Owner changed from um_support to simon
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.