[MITgcm-devel] Re: downslope pkg

Jean-Michel Campin jmc at ocean.mit.edu
Wed Sep 10 11:58:49 EDT 2008 

Hi Martin,

OK for 2 & 3, but on subject 1, it's not what was discussed 
(I thought you agree in your 1rst answer), and at the
end quiet confusing.
Cheers,
Jean-Michel

On Wed, Sep 10, 2008 at 11:34:50AM +0200, Martin Losch wrote:
> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list