Skip to content
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

landfast ice parameterisation with lateral drag #741

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

mjlosch
Copy link
Member

@mjlosch mjlosch commented Jun 27, 2023

What changes does this PR introduce?

New feature, lateral drag parameterization for landfast ice following Liu et al 2022, JGR

What is the current behaviour?

What is the new behaviour

Compiled with new flag SEAICE_ALLOW_SIDEDRAG and turned on by setting runtime parameter SEAICEsideDrag \=0, this parameterisation replaces the no-slip boundary condition for sea ice by a tunable lateral drag. If available, sub-grid-scale coastline information can be used (to be specified in tow files u/vCoastLineFile) to determine the lateral drag coefficient. Should work with all solvers, but only tested thoroughly with the default Picard/LSR solver.

Does this PR introduce a breaking change?

No

Other information:

This is a slightly modified version of @yqliu11's work, based on her seaice_lateraldrag_v3 branch.
Some details, like names can be discussed, I guess. Documentation is minimal.
No AD code yet, because the AD dynamics is not stable anyway.
Here's the paper: https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2022JC018413

Suggested addition to tag-index

o pkg/seaice: add new lateral drag parameterisation for landfast ice (Liu et al 2022, JGR)

@antnguyen13
Copy link
Collaborator

how exciting!

@antnguyen13
Copy link
Collaborator

antnguyen13 commented Feb 29, 2024

i think it would help to provide some kind of quick script to produce an easy set of [u,v]coastlinefile following , for example, the easy form factor F1 (fig. 1b of Liu et al 2022). Otherwise, it requires quite a bit of work , even for me, to read and sort out the x,y dir and to understand the explanation of how these two files are read in, and understand what the meaning of "Coast line length "normal" to the X/Y dir" parameters NcoastX/Y inside seaice_init_fixed.F is. I've made some quick test using hfac[S,W] for the drag form factor in u,v dir, and still am a bit confused whether i mult with the correct dxG,dyG (to then be centered and div by dxC,dyC in seaice_init_fixed.F...

this is how i generate the ucoastlineFile field, does this make sense to you?

(matlab syntax):
read in hfS top layer only,
read in dxG
tmp=1-hfS (so that land is 1, ocean is 0)
tmpr=0.*tmp;
tmpx(:,2:end-1) = tmpr(:,1:end-2)+tmpr(:,2:end-1)+tmpr(:,3:end) ; %so i get values of 1 or 2, note sum is in y-dir
tmpx=tmpx.*dxg;
write this to a binary file , to be read in under the name ucoastlinefile and assigned to LcoastX in seaice_init_fixed.F

So that NcoastX is now computed by centering the field above, then div by dxC.

@mjlosch
Copy link
Member Author

mjlosch commented Feb 29, 2024

@antnguyen13 for the simple version you don't need to do anything. It is computed from the "model" coastline in seaice_init_fixed.F. If you want something more complicated, I can provide input files for the 36km arctic config.

@mjlosch
Copy link
Member Author

mjlosch commented Feb 29, 2024

In general, the "coast line length" is somewhat arbitrary. In the end it becomes some kind of roughness parameter and it really doesn't matter what it is based on. For @yqliu11 paper, we found it useful to derive this "roughness" from sub grid scale coastline as the projection onto I and J directions. There is a python script that does this for a particular coastline product. That should (have been) also be part of the publication, but it's not. I can try to find it and post it here.

@antnguyen13
Copy link
Collaborator

Thanks Martin, if you could find the python script? I get the idea, as you said, you want the drag to act on a certain number of grid points starting from the coast line, more next to coast, less further away. I was just trying to come up with something very crude using hFac as a guide (given that all we have to do is blur the hFac toward the ocean side, then we'd get the coast points and then play with it.. the i/j are always a bit confusing to try to document.. i found from experience that it might be easier to use terminology "tangential" and "normal" ( i did this for the iceplume, after it was also called x/y, and then the user got it mixed up with XC, YC, which can be a disaster for where XC is not x-dir)

COMMON /SEAICE_PARM_C/
& AreaFile, HsnowFile, HsaltFile, HeffFile,
& uIceFile, vIceFile
& uIceFile, vIceFile, uCoastLineFile, vCoastLineFile
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest putting the new fields ([u,v]CoastLIneFile, and others relevant to this PR) inside ifdef block the same way you have elsewhere

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think our convention is to have all parameters (that can be specified in a namelist) always defined (so we can catch if they are set even if the corresponding CPP-flags are not defined). So I'll keep this as it is. Similar for the related comments.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, I should probably add more code that checks if these flags (in particular uCoastLineFile and vCoastLineFile) are set consistently.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see commit 8db339f

@@ -508,6 +517,7 @@ C
_RL SEAICE_drySnowAlb_south, SEAICE_wetSnowAlb_south, HO_south
_RL SEAICE_cBasalStar, SEAICEbasalDragU0
_RL SEAICEbasalDragK1, SEAICEbasalDragK2
_RL SEAICESideDrag
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment as above, put inside ifdef block

@@ -566,6 +576,7 @@ C
& SEAICE_drySnowAlb_south, SEAICE_wetSnowAlb_south, HO_south,
& SEAICE_cBasalStar, SEAICEbasalDragU0,
& SEAICEbasalDragK1, SEAICEbasalDragK2,
& SEAICESideDrag,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@@ -163,6 +163,7 @@ SUBROUTINE SEAICE_READPARMS( myThid )
& SEAICE_drag_south, SEAICE_waterDrag_south,
& SEAICE_dryIceAlb_south, SEAICE_wetIceAlb_south,
& SEAICE_drySnowAlb_south, SEAICE_wetSnowAlb_south, HO_south,
& SEAICESideDrag, uCoastLineFile, vCoastLineFile,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggest putting inside ifdef block

@@ -394,6 +395,7 @@ SUBROUTINE SEAICE_READPARMS( myThid )
SEAICE_drag = 0.001 _d 0
OCEAN_drag = 0.001 _d 0
SEAICE_waterDrag = 0.0055 _d 0
SEAICESideDrag = 0.0 _d 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@@ -509,6 +511,8 @@ SUBROUTINE SEAICE_READPARMS( myThid )
HeffFile = ' '
uIceFile = ' '
vIceFile = ' '
uCoastLineFile = ' '
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@mjlosch
Copy link
Member Author

mjlosch commented Mar 12, 2024

@yqliu11 do you think you can share the python script that produces the u/vCoastLineFile?

@yqliu11
Copy link
Contributor

yqliu11 commented Mar 12, 2024

compute_coastline_for_grid.zip
here is the jupyer notebook file to calculate the input grid from coastline.

@@ -188,6 +188,19 @@ C CbobC :: (linear) bottom drag coefficient for basals stress param.
_RL CbotC (1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
# endif /* SEAICE_ALLOW_BOTTOMDRAG */

# ifdef SEAICE_ALLOW_SIDEDRAG
C NcoastX/Y :: coast line roughness (w/out units) in X and Y direction,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

marking suggested swapping of X/Y to U/V (which i'll also put in the comment)

C computed from the coastline length at corner points,
C interpolated to U/V points, and scaled by the grid cell
C width
C SideDragX/Y :: drag coefficients for lateral drag a parameterisation
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

@@ -324,6 +324,10 @@ C HsaltFile :: File containing initial sea ice salt content
C HeffFile :: File containing initial sea-ice thickness
C uIceFile :: File containing initial sea-ice U comp. velocity
C vIceFile :: File containing initial sea-ice V comp. velocity
C u/vCoastLineFile :: Files containing the length of the coastline (in m)
C normal to the u/v direction per grid cell
C at corner points (XG,YG) as a measure of
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

be careful , remove language tying to [X,Y]G here. also the fact that u/v CoastLineFile is "normal" to u/v direction, that's also confusing...

Copy link
Member Author

@mjlosch mjlosch Apr 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I find it very important that we know where the values contained in u/vCoastLineFile are defined, so we need the reference to correct coordinates which are (for corner points) (XG,YG). I see no way of changing that. One can ask, why they are defined at corner points and not at, say, centers or at U/V points. The reason is this: the tangential points for the slip conditions is a the corner points (e.g. for u you have uIce(i,j)+uIce(i,j-1) = 0 for no slip on the corner point). In the model we then average to U/V-points. I agree that this can be confusing.

The files contain a measure of roughness. This can be anything that you may want to specify. In the specific case of @yqliu11's paper, we assumed that the coastline normal to the velocity creates an obstacle (no flow) and computed the the roughness from the projection of the (sub-grid scale) coastline on the plane normal to the velocity (eq 9 and 10 in https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2022JC018413). I am not sure how to express this in the short description here. @antnguyen13 Do you have a better suggestion? We can just say "roughness in m" or "roughness length in m" (although that's maybe not so good, because "roughness length" has defined meaning in turbulent boundary layer dynamics).

LOGICAL readCoastLineFields
C Coast line length normal to the X and Y direction in meters
C read from file and used to compute rough parameters NcoastX/Y
_RL LcoastX(1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

X/Y to u/v

ENDIF

CALL EXCH_UV_XY_RL( NcoastX, NcoastY, .FALSE., myThid )
CALL WRITE_FLD_XY_RL( 'Nlized_coastX', ' ', NcoastX,-1, myThid )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

X/Y to u/v

_RL uIceloc (1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
_RL vIceloc (1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
_RL AREALoc (1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
_RL SideDragXloc(1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

X/Y to u/v

_RL AREALoc (1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
_RL SideDragXloc(1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
_RL SideDragYloc(1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
_RL NcoastXloc (1-OLx:sNx+OLx,1-OLy:sNy+OLy,nSx,nSy)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above

DO j=1-OLy+1,sNy+OLy-1
DO i=1-OLx+1,sNx+OLx-1
IF ( AREALoc(i,j,bi,bj) .GT. 0.01 _d 0 ) THEN
tmpx = 0.5 _d 0 * ( uSpd(i,j) + uSpd(i-1,j) )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

x/y to u/v

@mjlosch
Copy link
Member Author

mjlosch commented Apr 4, 2024

In principle, I like the suggestion to rename the internal variables from X/Y to U/V.
There are many variables in pkg/seaice that are X/Y where they could be U/V, e.g. FORCEX/Y. Do you think that this should be changed, too?

@jm-c
Copy link
Member

jm-c commented Apr 4, 2024

@mjlosch I will take a look in the coming days (for a second thought on variable names). Could you can hold on changes until then ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants