[MITgcm-devel] Re: downslope pkg

[Jean-Michel Campin]

Martin,

> If you agree, I'll create a new file shelfice_update_masks.F, in which I 
> combine shelfice_update_masks and shelfice_ini_depth and clean up 
> ini_depth.
go for it. There might be also 1 SHELFICE header in ini_mask_etc.F
that is not needed, could be removed (unless I missed something).
Cheers,
Jean-Michel

On Thu, Sep 11, 2008 at 08:47:21AM +0200, Martin Losch wrote:
> Hi Jean-Michel,
>
> basically I agree with you. I had a potiential control variable  
> "R_shelfiice" and an adjoint model in mind, where I thought it would be 
> convenient  to have these things separate.
> Now I had another close look at the ctrl_ini_depth/update_masks_etc and I 
> think it's safe to go ahead as you suggest.
>
> Also, you are right and the upper BC is different from the lower one.  
> Actually, initially I had thought to implement the entire stuff with the 
> help of the surface following coordinates z*, but this would have meant 
> pressure gradient errors and I would have had to deal with them. However, 
> this route would allow a dynamic ice shelf on top of the ocean. We should 
> keep this option in mind (even if it means coding higher order gradient 
> schemes for horizontal pressure).
>
> If you agree, I'll create a new file shelfice_update_masks.F, in which I 
> combine shelfice_update_masks and shelfice_ini_depth and clean up 
> ini_depth.
>
> But I'll wait for your approval before I do that.
> Sorry for the confusion,
> Martin
>
> On 11 Sep 2008, at 03:43, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> In summary, we agree on:
>> * split of shelfice_init in 2: init_fixed & init_varia is a good thing
>> * not good to have those 2 (hidden) S/R :
>>   SHELFICE_INI_DEPTH & SHELFICE_UPDATE_MASKS
>>   in file shelfice_init_varia.F
>>
>> Remaining question: what to do with those 2 subroutines:
>> given that they don't fit into "standard" pkg initialisation
>> (read_params/init_fixed/init_varia)
>> a) keep 2 separate S/R. or
>> b) move SHELFICE_INI_DEPTH (reading of SHELFICEtopoFile into  
>> R_shelfIce array)
>>  at the beggining of SHELFICE_UPDATE_MASKS, so that we end up with  
>> only 1 S/R.
>>
>> I prefer option (b):
>> - it minimizes the number of non-standard shelfice entry in the
>>   initialisation part.
>> - don't see the upper BC (ice-shelf base) as being so much related to 
>> ini_depth
>>   (dealing with fixed lower BC). In fact, from a dynamical point of  
>> view,
>>   it's more the mass of the ice-shelf which would be the upper BC. And 
>> would
>>   probably have to deal with mass if a dynamical ice-shelf component
>>   was considered.
>>   The code is not ready for that, but since the link to ini_depth is 
>> not
>>   so clear, the simpler (just 1 call) might be better.
>> - none of those S/R is very long, sothat it's little bit easier to  
>> follow
>>   what's going on all together in 1 S/R.
>> but if you insist on having 2 S/R (in the same file or not), it's not a
>> big deal (as long as they are not hidden with a 3rd S/R, it's fine  
>> with me).
>>
>> Cheers,
>> 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
>>>
>> _______________________________________________
>> 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