[MITgcm-devel] more seaice

[Martin Losch]

Hi,

I am pretty certain, that the timestep in growth.F must be 
deltaTtracer, because the heat and fresh water fluxes that are computed 
there need to be in sync with the tracer equations. I am not so sure 
about the timestep in lsr and advect. Here, and particularily after 
Jinlun's message:
> I would prefer keeping DELTAT for sea ice in case we want asyncronized 
> runs.
the timestep should probably be deltaTmom. Or, Jinlun, did I 
misunderstand you and everything should be deltaTmom? But then, 
asynchronous time stepping would be impossible. Does it make sense to 
do asynchronous time stepping in the sea ice model, in a similar way it 
is done in the ocean model? At least for the advection it seem to be 
necessary to have small time step=deltaTmom, doesn't it (CFL)?
In general, I agree, there should be a deltaTice, but maybe there 
should be two: deltaTice=deltaTtracer and deltaTiceAdvect=deltatTmom?

I will not be in the office tomorrow, so good luck with this (o:

To Dimitris:
> Martin, I am a bit confused about masking issue.
> Neither external_fields_load nor external_forcing_surf
> mask empmr.  This gets done later by the external_forcing
> routine.  So why should pkg/seaice mask the fields the
> fluxes that it generates?
When useRealFreshWaterFlux=.true., and in particular with the nonlinear 
free surface, EmPmR is explicitly (and not surfaceTendencyS, because 
the may contain restoring contributions) added as a contribution to the 
sea surface height, in more than one place: solve_for_pressure and 
integr_continuity, and update_etah. Over land this is never used, but 
because there is no evaporation over land (bulk formulae), the 
precipitation (m/s) accumulates in eta over time. (I had never seen 
that before when using "realFreshWaterFlux", because I always used 
explicity balanced E-P fluxes, and in orde to balance them over the 
ocean I had masked out the land values in the data already.)

Martin


On Thursday, April 29, 2004, at 08:02 PM, Chris Hill wrote:

> All,
>
>  Quick comment - sorry if I have misunderstood, I haven't been reading 
> this
> thread that carefully.
>
>  We should have a separate sea-ice time step. In many cases, including
> high-res cube, we may want to call sea-ice every n thermodynmics time 
> steps.
>
>  From Martin's description it sounds like the default for deltatseaice
> should be deltattracer.
>
> BTW - Alistair and I still find it hard to believe sea-ice can't just 
> return
> tendencies. Martin, if you can show it could work with just tendencies 
> that
> would be great!
>
> Chris
>
>> -----Original Message-----
>> From: mitgcm-devel-bounces at mitgcm.org
>> [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Jinlun Zhang
>> Sent: Thursday, April 29, 2004 1:54 PM
>> To: Martin Losch
>> Cc: MITgcm-devel at mitgcm.org
>> Subject: Re: [MITgcm-devel] more seaice
>>
>>
>>
>> Hi Martin,
>>
>> Martin Losch wrote:
>>
>>>
>>> The timestep issue, I am not that clear about. I have made
>> all changes
>>> in growth, but I think all deltaT should replaced by either
>> deltaTmom,
>>> deltaTfreesurf or deltaTtracers. What do the code czars think?
>>> (I won't have time to do this until next week, anyway)
>>
>> I would prefer keeping DELTAT for sea ice in case we want
>> asyncronized runs.
>>
>>>
>>>
>>>> Forgot to mention, NPSEUDO is only used for ADI, and as I
>> said ADI
>>>> does not work properly.  Jinlun, should we just get rid
>> of it from
>>>> the main branch of the code to avoid confusion?
>>>> It will still be there in the CVS archive.
>>>
>>> What does npseudo do for lsr, because I noticed that if
>> npseudo > 1,
>>> lsr will be called npseudo times, and the "error"-print out
>> in stdout
>>> reduces with each call.
>>
>> npseudo is generally used for ADI solver. Since LSR is more
>> suitable for MITgcm, we can just get rid of it.
>> Jinlun
>>
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel