[MITgcm-devel] Re: downslope pkg

Martin Losch Martin.Losch at awi.de
Wed Sep 10 05:34:50 EDT 2008 

Hi Jean-Michel,

as you can see, I have fixed points 1 and 2. I also split  
shelfice_init into two files. The second one (shelfice_init_varia.F)  
contains the new subroutines. I know that depth and hfacs are  
normally not "varia", but I was thinking about have the topography as  
adjoints variables. If this is completely stupid, then we can move  
these routines to shelfice_init_fixed.F (or put them into new files,  
but because we already have so many files ...).

kTopC stayed. I just added a comment about it's relation to kSurfC.

Martin

On 9 Sep 2008, at 17:20, Jean-Michel Campin wrote:

> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list