[MITgcm-devel] Re: downslope pkg

Jean-Michel Campin jmc at ocean.mit.edu
Wed Sep 10 12:23:35 EDT 2008 

Martin,

Yes, let's clear up our views on the subject by tomorrow,
and decide then what to do.

Jean-Michel

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

More information about the MITgcm-devel mailing list