[MITgcm-support] MITgcm-support Digest, Vol 151, Issue 5

weijianfen1988 at 163.com weijianfen1988 at 163.com
Mon Jan 11 08:58:53 EST 2016


 Dear all,

 I am trying to calculate the sea ice export through Fram Strait using daily ice concentration and ice velocity modelled by MITgcm. However, I found that the simulated sea ice motion is much stronger than satellite observations (data from NSIDC) in most areas of Arctic Ocean including Fram Strait, especially in summer. As a result, the averaged annual sea ice area export is also much higher than observations (about three times as that of observations). The ice-air and ice-ocean drag coefficients are set in 'data.seaice' as follows: SEAICE_drag=0.0012, SEAICE_waterDrag=5.5510. 

 I just want to know if anyone encounterd this problem before. What caused the overestimation of Arctic sea ice motion and how to improve the model results.

Thank you for your time.

Jianfen



weijianfen1988 at 163.com
 
From: mitgcm-support-request
Date: 2016-01-08 01:00
To: mitgcm-support
Subject: MITgcm-support Digest, Vol 151, Issue 5
Send MITgcm-support mailing list submissions to
mitgcm-support at mitgcm.org
 
To subscribe or unsubscribe via the World Wide Web, visit
http://mitgcm.org/mailman/listinfo/mitgcm-support
or, via email, send a message with subject or body 'help' to
mitgcm-support-request at mitgcm.org
 
You can reach the person managing the list at
mitgcm-support-owner at mitgcm.org
 
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MITgcm-support digest..."
 
 
Today's Topics:
 
   1. Re: changing from a fixed temperature to fixed heat flux as a
      boundary condition (Martin Losch)
   2. Re: R/W pickup (Martin Losch)
   3. Re: changing from a fixed temperature to fixed heat flux as a
      boundary condition (Malte Jansen)
 
 
----------------------------------------------------------------------
 
Message: 1
Date: Thu, 7 Jan 2016 09:56:49 +0100
From: Martin Losch <Martin.Losch at awi.de>
To: MITgcm Support <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] changing from a fixed temperature to
fixed heat flux as a boundary condition
Message-ID: <E46453D5-9586-49DA-A155-816A25B7BF8C at awi.de>
Content-Type: text/plain; charset="utf-8"
 
Hi Julian,
 
I think you already gave the answer yourself. 
As far as I know there is no implementation for specifying a flux at a lateral boundary, but you can easily hack the code. I would use the the code in rbcs_add_tendency.F, e.g. for temperature
          gTendency(i,j) = gTendency(i,j)
     &       - RBC_mask(i,j,k,bi,bj,irbc)*rec_tauRlx
     &        *( theta(i,j,k,bi,bj)- RBCtemp(i,j,k,bi,bj) )
which gives you the relaxation tendency in units of temperature over time. You could use the RBCtemp field to read the heat flux (instead of the relaxation temperature) you want to precribe and then just add it to gTendency(i,j) making sure that you use the correct units, so it would be the easiest, if you just have
gTendency(i,j) = gTendency(i,j) + RBC_mask(i,j,k,bi,bj,irbc)*RBCtemp(i,j,k,bi,bj)
where RBCtemp(i,j,k,bi,bj) is now ( theta(i,j,k,bi,bj)- RBCtemp(i,j,k,bi,bj) )/tauRelax diagnosed from some previous run.
For heat flux in W/m^2 you?d have to multiply by recip_Cp*mass2rUnit(=1/rho)* someLength(not clear what length that would be, probably dyG=cell thickness normal to boundary).
 
Martin
 
 
> On 06 Jan 2016, at 21:19, Julian Mak <j.mak at ed.ac.uk> wrote:
> 
> Dear all,
> 
> I am quite new to using MITgcm and have been trying to implement something in a channel; this question is about implementing boundary conditions and it seems like it should be a fairly trivial thing to do but I am still a bit confused, so any help would be appreciated.
> 
> Set up: re-entrant channel in x, walls on y, z being vertical, to mimic a part of the ACC. Surface and northern boundary is relaxed to some specified temperature profile (no salinity here) using the "rbcs" package with appropriate masking and short-ish restoring time.
> 
> Problem: Change over to a Neumann condition on both the surface and northern boundary, to specify the heat flux instead of the temperature instead. Rationale is that a Dirichlet condition specifying the temperature pins the ends of the isotherms and we would like to relax this, so the eddies have more freedom to move the isotherms around. The idea would be to diagnose the heat flux from the Dirichlet condition runs (I checked today that "TFLUX", "Trelax" and "surForcT" all give me the same thing***) and put it back in as the boundary conditions for the Neumann runs.
> 
> So I can see changing over to the surface one is fairly trivial, by specifying surfQfile. The northern one though is stumping me: I am thinking I probably need to hack "rbcs" and do something to add the tendencies in accordingly? I just thought there would be an easier way to do this, or I may have missed something obvious? I know there are other implementations to relax the pinning on the isotherms on the northern boundary but a flux condition seems like it should be easy to put in.
> 
> Thanks for your time,
> Julian
> 
> *** I am not entirely clear on what the differences and relations relations between "TFLUX", "Trelax", "surForcT" and "oceQnet" are, even after reading a previous archived e-mail on this, so if someone could clarify I would be thankful. I think I understand why the first three are the same in this case (although I am guessing the relation). These quantities are presumably different if restoring is not used on its own or at all, and when salinity is involved (so "oceQnet" would be something like "TFLUX" + "SFLUX" + ... ?)
> 
> -- 
> Julian Mak,
> School of Mathematics,
> The University of Edinburgh,
> James Clerk Maxwell Building,
> The King's Buildings,
> Edinburgh, EH9 3FD
> e-mail: j.mak at ed.ac.uk
> tel: +44 131 650 5040
> www: https://sites.google.com/site/julianclmak/home
> 
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
 
 
 
 
------------------------------
 
Message: 2
Date: Thu, 7 Jan 2016 10:02:37 +0100
From: Martin Losch <Martin.Losch at awi.de>
To: MITgcm Support <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] R/W pickup
Message-ID: <BA0234AB-F219-41C4-8FA6-7A53E5F574CF at awi.de>
Content-Type: text/plain; charset="utf-8"
 
Hi Chen
 
you can just use rdmds.m (and rdmeta.m) in utils/matlab
p = rdmds(?pickup?,yourIter);
will give you a 3D field (nx,ny,nn)
then you?ll have to determine, which of the nn levels belong to which field (see pickup*.meta for a list of files in pickup*.data)
after modifying p, you can write it like this:
fid=fopen(?pickup.withNewName.data?,?w?,?b?);
fwrite(fid,p,?real*8?);
fclose(fid);
 
Martin
 
 
> On 06 Jan 2016, at 14:59, Chen Cheng <cc2713206 at 163.com> wrote:
> 
> Dear all,
>  
> I am trying to set up a regional coupled ice shelf-ocean-sea ice experiment in the Prydz Bay with MITgcm. However, the model has blown up after nearly 3-years integration. Right now, I want to make some modifications on the pickup files to continue running. If possible, could you provide the relevant executable source codes encapsulated in m-files for Matlab to read or write the pickup files.
>  
> Thanks, and happy new year.
>  
> Chen Cheng
> 
> 
>  
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
 
 
 
 
------------------------------
 
Message: 3
Date: Thu, 7 Jan 2016 15:35:56 +0000
From: Malte Jansen <mfj at uchicago.edu>
To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] changing from a fixed temperature to
fixed heat flux as a boundary condition
Message-ID: <30DE1BF6-6F75-4059-977E-3CA204896888 at uchicago.edu>
Content-Type: text/plain; charset="utf-8"
 
Julian,
 
This may not be the most elegant solution, but you can also always just make use of the fact that a restoring condition converges to a fixed flux condition in the limit of infinite restoring time. So in practice you can get a fixed flux condition by choosing an extremely slow restoring to a correspondingly large temperature. E.g. if you set T_restoring=10^20 C and tau_restoring= 10^24s you get (to within machine precision, and for any reasonable range of ocean temperatures) a temperature tendency of  1K/10^4s. As Martin was saying, you can translate any heat flux to a temperature tendency given the heat capacity, density and grid-scale. Since these are all constant, you can do this conversion offline beforehand.
 
Good to hear that you are working on this. I had been thinking about maybe having my student do something similar.
 
Cheers,
Malte
 
 
------------------------------------------------------
Malte F Jansen
Assistant Professor
Department of the Geophysical Sciences
The University of Chicago
5734 South Ellis Avenue
Chicago, IL 60637 USA
 
> On Jan 7, 2016, at 2:56 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> 
> Hi Julian,
> 
> I think you already gave the answer yourself. 
> As far as I know there is no implementation for specifying a flux at a lateral boundary, but you can easily hack the code. I would use the the code in rbcs_add_tendency.F, e.g. for temperature
>          gTendency(i,j) = gTendency(i,j)
>     &       - RBC_mask(i,j,k,bi,bj,irbc)*rec_tauRlx
>     &        *( theta(i,j,k,bi,bj)- RBCtemp(i,j,k,bi,bj) )
> which gives you the relaxation tendency in units of temperature over time. You could use the RBCtemp field to read the heat flux (instead of the relaxation temperature) you want to precribe and then just add it to gTendency(i,j) making sure that you use the correct units, so it would be the easiest, if you just have
> gTendency(i,j) = gTendency(i,j) + RBC_mask(i,j,k,bi,bj,irbc)*RBCtemp(i,j,k,bi,bj)
> where RBCtemp(i,j,k,bi,bj) is now ( theta(i,j,k,bi,bj)- RBCtemp(i,j,k,bi,bj) )/tauRelax diagnosed from some previous run.
> For heat flux in W/m^2 you?d have to multiply by recip_Cp*mass2rUnit(=1/rho)* someLength(not clear what length that would be, probably dyG=cell thickness normal to boundary).
> 
> Martin
> 
> 
>> On 06 Jan 2016, at 21:19, Julian Mak <j.mak at ed.ac.uk> wrote:
>> 
>> Dear all,
>> 
>> I am quite new to using MITgcm and have been trying to implement something in a channel; this question is about implementing boundary conditions and it seems like it should be a fairly trivial thing to do but I am still a bit confused, so any help would be appreciated.
>> 
>> Set up: re-entrant channel in x, walls on y, z being vertical, to mimic a part of the ACC. Surface and northern boundary is relaxed to some specified temperature profile (no salinity here) using the "rbcs" package with appropriate masking and short-ish restoring time.
>> 
>> Problem: Change over to a Neumann condition on both the surface and northern boundary, to specify the heat flux instead of the temperature instead. Rationale is that a Dirichlet condition specifying the temperature pins the ends of the isotherms and we would like to relax this, so the eddies have more freedom to move the isotherms around. The idea would be to diagnose the heat flux from the Dirichlet condition runs (I checked today that "TFLUX", "Trelax" and "surForcT" all give me the same thing***) and put it back in as the boundary conditions for the Neumann runs.
>> 
>> So I can see changing over to the surface one is fairly trivial, by specifying surfQfile. The northern one though is stumping me: I am thinking I probably need to hack "rbcs" and do something to add the tendencies in accordingly? I just thought there would be an easier way to do this, or I may have missed something obvious? I know there are other implementations to relax the pinning on the isotherms on the northern boundary but a flux condition seems like it should be easy to put in.
>> 
>> Thanks for your time,
>> Julian
>> 
>> *** I am not entirely clear on what the differences and relations relations between "TFLUX", "Trelax", "surForcT" and "oceQnet" are, even after reading a previous archived e-mail on this, so if someone could clarify I would be thankful. I think I understand why the first three are the same in this case (although I am guessing the relation). These quantities are presumably different if restoring is not used on its own or at all, and when salinity is involved (so "oceQnet" would be something like "TFLUX" + "SFLUX" + ... ?)
>> 
>> -- 
>> Julian Mak,
>> School of Mathematics,
>> The University of Edinburgh,
>> James Clerk Maxwell Building,
>> The King's Buildings,
>> Edinburgh, EH9 3FD
>> e-mail: j.mak at ed.ac.uk
>> tel: +44 131 650 5040
>> www: https://sites.google.com/site/julianclmak/home
>> 
>> 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
 
 
------------------------------
 
_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org
http://mitgcm.org/mailman/listinfo/mitgcm-support
 
 
End of MITgcm-support Digest, Vol 151, Issue 5
**********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20160111/fe54b215/attachment-0001.htm>


More information about the MITgcm-support mailing list