[MITgcm-devel] Re: downslope pkg
Jean-Michel Campin
jmc at ocean.mit.edu
Tue Sep 9 11:20:53 EDT 2008
Hi Martin,
I think that regarding point 3, it's fine to keep kTopC,
but adding 2 comment lines (in header file & where it's computed)
which tell how different it is from kSurfC, could not be bad.
point 2 would be good to change (the sooner the better, since more
people are likely to try to use this relatively new pkg),
and it's not a bad idea to add this parameter (SHELFICEfile)
to Chris's list of retired params.
You can keep the same name, can change it, or pick the one you want,
no preference.
And regarding point 1, it's not urgent, but would make thing cleaner.
I would propose a S/R name like shelfice_update_mask(s) :
- closely related to ini_masks_etc (called from there)
- shelfice_update_hfac would be fine too, but since it really
dry some grid-cell (=> modify the mask) and not only change
hFac by a small fraction (like in update_r_star.F), a small
preference for the former.
May be passing hfacC as argument (not to have to include "GRID.h"),
would it be a good idea ?
Cheers,
Jean-Michel
On Tue, Sep 09, 2008 at 04:23:06PM +0200, Martin Losch wrote:
> Jean-Michel,
>
> can I just move the parameter SHELFICEfile from PARAMS.h to SHELFICE.h
> (and maybe rename it to SHELFICEtopoFile)? or would you like me to retire
> SHELFICEfile properly and introduce a new parameter? I don't think that
> this is necessary, since only Michael (and I) is using this feature at
> the moment, and we don't want to make things too simple for Michael, do
> we?
>
> Martin
>
> On 9 Sep 2008, at 14:57, Martin Losch wrote:
>
>> Hi Jean-Michel,
>>
>> I agree with everything you said. I have nothing to say in my defense,
>> except that I THOUGHT that packages_readparms was called after
>> ini_depths etc. I was probably not attending class when this change was
>> done, me culpa. However, packages_init_fixed is still done after
>> ini_masks_etc, so that's probably the reason why I put the depth file
>> into PARAMS.h/ini_depths.F to avoid having two shelfice_ini_* files.
>> But as you say, we can:
>>
>> 1. replace the code in ini_masks_etc by a subroutine
>> shelfice_ini_depth_etc (or so) which
>> a. reads the topography file ( code from ini_depths.F )
>> b. modifies hFacC (code from ini_masks_etc.F)
>> I don't think that that's pretty, but the present version isn't,
>> either.
>> 2. move shelficeFile from PARAMS.h to SHELFICE.h and data.shelfice
>> 3. think about replacing kTopC with kSurfC, but as far as I remember,
>> it is a little tricky as kTopC=0 (dry column) corresponds to
>> kSurfC=Nr+1 and there is code such as
>> K = MAX(1,kTopC(I,J,bi,bj))
>> but otherwise these fields are identical.
>>
>> I can do this (item 3 was on my internal list anyway, but way down the
>> list), but what would be good name for such as subroutine?
>> shelfice_ini_depths.F
>> shelfice_ini_hFacC.F
>> ???
>>
>> Martin
>> On 9 Sep 2008, at 00:12, Jean-Michel Campin wrote:
>>
>>> Hi Martin,
>>>
>>> I added something similar to what you proposed, testing for kSurfC
>>> which does not seem so different from kTopC, apart where the column
>>> is empty, but is available in standard GRID.h header file.
>>>
>>> I looked briefly to the interface between shelfice pkg and the
>>> main code, and think that with 1 more shelfice S/R call
>>> from the middle of ini_mask_etc.F (where hFacC is modified by
>>> R_shelice), we could remove the pieces of code in ini_depth.F and in
>>> ini_mask_etc.F and put them in this new S/R (just need to break
>>> the bi,bj loops in 2 blocks, in ini_mask_etc.F);
>>>
>>> Also, why is shelfIceFile in PARAMS.h and appears in parameter file
>>> "data" ?
>>> A more logical place would be in SHELFICE.h and data.shelfice.
>>> At the time when shelfice pkg was checked-in, we already have (Oct
>>> 2004)
>>> moved packages_readparms call before ini_depth call in
>>> initialise_fixed.F
>>>
>>> Cheers,
>>> Jean-Michel
>>>
>>> On Fri, Sep 05, 2008 at 10:41:16PM +0200, Martin Losch wrote:
>>>> Hi Jean-Michel,
>>>> the masking is absolutely necessary for the shelfice package in the
>>>> current implementation (who gave this package this stoopid name,
>>>> some
>>>> German idiot!), because otherwise the model integrates some
>>>> ridiculous
>>>> density (for Theta=Salt=0, or even worse from some other arbitrary
>>>> Theta
>>>> and Salt) from the top for phiHyd. When useShelfice=.true. you are
>>>> supposed to provide a reference pressure at the bottom of the ice
>>>> shelf
>>>> and integrating phiHyd from the very top (k=1) is not necessary.
>>>> JMD95P
>>>> and MDJFW should work with shelfice, too, for this reason. I
>>>> don't know
>>>> about the downSlope package. That one was not around, when I
>>>> implemented
>>>> shelfice.
>>>> Without the masking, one would have to use if statements in the
>>>> ij-loops
>>>> for the phiHyd intergration to determine, where the real
>>>> intergration of
>>>> phiHyd is supposed to start; not good. Alternatively, one could
>>>> only mask
>>>> alphaRho in the ice shelf, like this:
>>>> IF ( useShelfIce ) THEN
>>>> DO j=jMin,jMax
>>>> DO i=iMin,iMax
>>>> IF ( kTopC(I,J,bi,bj) .GE. k ) alphaRho(i,j) = alphaRho
>>>> (i,j)*maskC(i,j,k,bi,bj)
>>>> ENDDO
>>>> ENDDO
>>>> ENDIF
>>>> Do you have a better idea?
>>>>
>>>> Martin
>>>>
>>>> On 5 Sep 2008, at 18:31, Jean-Michel Campin wrote:
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> I found a problem with shelfice & down_slope pkgs:
>>>>> looks like useShelfIce is masking the density (in CALC_PHI_HYD)
>>>>> so that we will have a problem when using an EOS directly function
>>>>> of pressure (e.g.: JMD95P). I looked to
>>>>> MITgcm_contrib/high_res_cube/data.hr
>>>>> and it's not the case (EOS=JMD95Z).
>>>>> Can you confirm that you are not using an EOS directly function
>>>>> of pressure ?
>>>>>
>>>>> Otherwise, how is the test going ?
>>>>>
>>>>> I cc this to the devel list, so that Martin will know why I will
>>>>> bother him to remove this masking with useShelfIce ...
>>>>>
>>>>> Cheers,
>>>>> Jean-Michel
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list