[MITgcm-devel] Re: downslope pkg

Martin Losch Martin.Losch at awi.de
Wed Sep 10 12:09:19 EDT 2008 

I agree, that putting the new subroutines all into  
shelfice_init_varia.F is a bit stupid and I am willing to change  
that, but in the end I felt it was more consistent to read the  
topography, where all topographies are read, and modify the hfacs in  
a different routine. Maybe we talk about this some more tomorrow,  
need to mow the lawn now ...

Martin

On 10 Sep 2008, at 17:58, Jean-Michel Campin wrote:

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

More information about the MITgcm-devel mailing list