[MITgcm-devel] diffusion in pkg/seaice
Martin Losch
Martin.Losch at awi.de
Fri May 27 04:07:52 EDT 2011
Hi Jean-Michel,
On May 26, 2011, at 6:30 PM, Jean-Michel Campin wrote:
> Hi Martin and Gael,
>
> Martin, thanks for your input.
> I would propose the following:
> 1) I can fix conservation for DIFF1 > 0 in SEAICEuseFluxForm
> and Gael can experiment with diffusivity (hopefully He will get the
> units right) by changing seaice_diffusion.F
> 2) will switch more test-exp to use SEAICEuseFluxForm, and have at least
> one which test seaice_diffusion.F ;
> can keep 1 lab_sea test (1 fwd + 1 ad) unchanged.
> 3) change default DIFF1 to simply DIFF1=0
>
> One question:
> Do we want to rename the old subroutines (would make things more clear),
> for example:
> advect.F -> seaice_old_advect.F
I don't like "old" here, because it's still being used, and the fluxform part is not old. What I should probably do is replace this routine with something that fits better into the general scheme and use gad_c2_adv_* instead.
> ??? cost_ice_test.F ???
seaice_cost_test?
> diffus.F -> seaice_old_diffus.F
Don't rename this routine, rather we should strive for removing/replacing it altogether, as soon as it is no longerl needed for adjoint simulations? (I am actually using this in this context, but would be happy to change to some thing different)
I am a little against renames the bgrid code because you loose all cvs-history and gain little. I agree that the names do not tell us anything, but there are many comments in the code that should make things clear (?).
> lsr.F -> seaice_bg_lsr.F
> dynsolver.F -> seaice_bg_dynsolver.F
> ostres.F -> seaice_bg_ostres.F
> or something else ?
M.
>
> Cheers,
> Jean-Michel
>
> On Thu, May 26, 2011 at 09:25:52AM +0200, Martin Losch wrote:
>> Hi Gael,
>>
>> to me, diffusion of sea ice is an unphysical concept: I cannot imaging any type of small scale mixing that can be represented by a down gradient coarse graining approach. The diffusion is only in there for numerical reasons (in advect/diffus) and the value of diff1=0.001 or 0.002 or whatever it is (note the beautiful variable name), and the double application of s/r diffus is probably the result of some long ago tuning exercise of Jinlun. I added the possibility of diffusion to the other advection for consistency (and in case they are needed). My personal choice for an advection scheme is 33 or 77, so stable flux-limited schemes that do not require any explicit diffusion, and based on that I would be happy to get rid of diffusion alltogether if one of these were default.
>>
>> If it weren't for the adjoint ... as long as the 2nd order advection in advect is still required for some configurations, you need the diffusion. But I would be happy to
>> 1. get rid of diffus and diff1, replace it with a single call to seaice_diffusion and diffKhArea/Heff etc. (which all should default to 0 in analogy to diffKhT/S/Ptr)
>> 2. get rid of the original non-flux form advection or at least change the default of the corresponding parameter so that it is not used be default
>> 3. get rid of the min(dx,dy) factor, which is really unintuitive and non-conservative.
>> All of this is code that I never use, and that I would not advise to use either.
>>
>> The only reason I did not do this yet is that I do not want to tune up the verification experiments (and possibly running systems). I suggest, if you start changing this, do it radically. At least change the defaults to something useful:
>> SEAICEuseFluxForm = .TRUE.
>> diff1 = 0.
>> advectionScheme = 77 (although this is debatable and I see why this may not be the best choice because of analogy)
>>
>> Martin
>>
>> On May 26, 2011, at 3:04 AM, Gael Forget wrote:
>>
>>> Dear Martin and co,
>>>
>>> with regard to seaice_diffusion.F, after discussing the issue with Jean Michel, I am preparing
>>> to add a diffKh argument, whose units will be m/s2 (as a standard Laplacian diffusion)
>>> and that will be used instead of DIFF1*MIN( _dxF(I,J,bi,bj), _dyF(I,J,bi,bj)).
>>>
>>> Each tracer will be associated with a specific diffusivity (SEAICEdiffKhArea etc.) that will
>>> be specified alongside the advection scheme in data.seaice, and whose default will be 0.
>>>
>>> In the single-dimensional advection scheme case, when advect.F and diffus.F are
>>> used, I am not going to change anything for now. There are several options, and
>>> I am looking for opinions. We could for example add a call to seaice_diffusion.F
>>> in seaice_advdiff.F with an "if diffKhXXX.NE.0 and diff1.EQ.0" condition. Would this work?
>>>
>>> Cheers,
>>> Gael
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list