[MITgcm-devel] new salt_plume param?

[An T Nguyen]

hi Gael,

Let's discuss about this when I come in on Monday? I made some more 
adjustments in a version which we did not check in yet that might also 
address some of the things you wanted to do. -An

On 5/27/11 7:58 AM, Gael Forget wrote:
> Hi Dimitris,
>
> I am glad that you sympathize with the idea.
>
> I appreciate the capability of turning off pkg/salt_plume by setting
> useSALT_PLUME=.TRUE. and PlumeMethod=5. And, in the same
> logic, I see that I could modulate the intensity of saltplumeFlux by
> computing weighted averages of PlumeMethod=5 and the others.
>
> But my suggested code would readily do this for any of the available
> PlumeMethod's, at the expense of one code line.
>
> I don't see why we would want to make it more complicated than that.
> I don't see either why applying the proposed factor to saltplumeFlux
> in seaice_growth would be an inappropriate place, since this is
> precisely where saltplumeFlux is set. Seems transparent to me.
>
> Anyway, I can leave this out of the main trunk if you prefer.
>
> Cheers,
> Gael
>
> On May 27, 2011, at 12:20 AM, Menemenlis, Dimitris (3248) wrote:
>
>> Gael, if I understand your suggestion correctly, you are trying to add a redistribution
>> that would leave (1-SaltPlumeIntensity) in the surface level, in addition to whatever
>> is left there by the particular "PlumeMethod" that has been selected.
>> I think this is a good suggestion but a cleaner way to implement would be to
>> add one or more PlumeMethod distributions to salt_plume_frac.F in addition
>> to the ones that are already there.  For example, the current PlumeMethod=5
>> is  equivalent to your SaltPlumeIntensity=0 and the other PlumeMethod
>> distributions all leave behind some percentage of salt in the surface level.
>>
>> Another argument against adding a constant SaltPlumeIntensity in seaice_growth.F
>> is that conceptually this parameter should not be everywhere constant.  Instead it
>> should probably be modulated by the fraction of lateral vs bottom freezing occurring
>> in each grid cell at a particular moment in the integration.  Again, salt_plume_frac.F
>> would be a better location to carry out such calculation rather than seaice_growth.F
>>
>> Dimitris Menemenlis
>>
>> On May 26, 2011, at 12:55 PM, Gael Forget wrote:
>>
>>> Hi An and co,
>>>
>>> my understanding is that the current set of parameters
>>> allows various redistribution profiles shape and reach.
>>>
>>> I was surprised not to find one to tune, not the shape,
>>> but the very intensity of the parameterization.  Did I miss it?
>>>
>>> In my tests I added the following, which seems to provide for an
>>> easy tuning of the salt plume parameterization strength.
>>> I thought it could be of interest to other users. So, do you mind if
>>> I introduce a SaltPlumeEfficiency factor in seaice_growth.F to do
>>>             saltPlumeFlux(I,J,bi,bj)=
>>>     &             HEFFM(I,J,bi,bj)/SEAICE_deltaTtherm
>>>     &             *(1-SIsalFRAC)*salt(I,j,kSurface,bi,bj)
>>>     &             *tmpscal1*SEAICE_rhoIce
>>>     &             *SaltPlumeIntensity
>>> It would range from 0 to 1, and have a default of 1. I believe the
>>> above snippet would be a correct way to do this. Isn't it?
>>>
>>> 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

-- 
An T Nguyen, Ph.D.<atnguyen at mit.edu>
MIT Bldg 54-1410
77 Massachusetts Ave, Cambridge MA 02139, USA
Phone: 617 253 2443; Fax: 617 253 4464