[MITgcm-support] changing from a fixed temperature to fixed heat flux as a boundary condition

[Malte Jansen]

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