[MITgcm-support] ptracer BOTTOM boundary condition

[Martin Losch]

Petter,

as long as you can express your bottom boundary condition as a flux 
that adds something to gchemTendendy=sum of what enters, leaves your 
grid cell (also the last wet grid cell above the bottom), you should be 
fine--I think. Samar does not want to prescribe a flux (v.Neumann BC), 
but the tracer value it self (Dirichlet BC), in which case the 
gchem_forcing_int is not the right place to put his BC.

Martin

On May 26, 2005, at 9:34 AM, Petter Stenström wrote:

> Samar/Martin,
>
> I'm trying to implement a bottom boundary condition in gchem to 
> simulate
> resuspension of sediments. Does the time stepping issues that you 
> discuss
> apply here too, and in particular, inconsistency issues between k=Nr 
> and
> k=Nr-1?
>
> I was not planning to use gchem_forcing_sep, but only 
> gchem_forcing_int,
> as I expect to use the same time step for all dynamics.
>
> The sediment is the regular tracer equation, just with a settling term
> added. The bottom boundary condition is of the form:
>
> C*w_sink - diff_z*(dC/dz) = Q
>
> where Q is the source term that gives sedimentation or resuspension
> depending on the force balances at the bottom.
>
> Have you done this before, or do you have a good idea of difficulties 
> and
> pitfalls?
>
> /Petter
>
>> Martin, I'd forgotten about GCHEM_SEPARATE_FORCING. Thats a 
>> possibility
>> for
>> setting surface a Dirichlet boundary condition, but I'd rather not 
>> mess
>> with my own
>> separate time stepper which may well be inconsistent with the spatial
>> discretization.
>>
>> I have concocted some code to set surface BCs. It seems to work fine
>> and, with a
>> bit of tweaking, could easily be made a part of pkg/gchem. To use it
>> one would set
>> an #ifdef in GCHEM_OPTIONS.h. That is if the MITGCM developers agree.
>>
>> Samar
>>
>> On May 25, 2005, at 2:25 AM, Martin Losch wrote:
>>
>>> Samar,
>>> as far as I can see (and that may not be very far), you can only
>>> specify pTracer-tendencies (in ptracers_forcing_surf.F)
>>> If you use the gchem package, there is the flag
>>> GCHEM_SEPARATE_FORCING. If you do not set that, then you have to
>>> calculate the gchemTendency in gchem_calc_tendency; an example for 
>>> the
>>> is the cfc-pkg, (verification/cfc_example), but again it's all
>>> tendencies and you cannot prescribe the value of the tracer at the
>>> surface.
>>> If you set the CGHEM_SEPARATE_FORCING flag, then the ptracers are
>>> updated a second time after the AB-timestep. In the routine
>>> gchem_forcing_sep you can do, in principle, anyting to the ptracers
>>> you like, for example, ptracer(i,j,1,bi,bj,itracer) = some-value and
>>> you have your Dirichlet-BC, but unless your provide some mechanism in
>>> the routine yourself, this will be inconsistent with the field for 
>>> k>1
>>> at this time (at the end of the timestep, gchem_forcing_sep is called
>>> before do_fields_blocking_exchanges and also before do_the_model_io).
>>> You'll enter the next timestep with this inconsistency at the 
>>> surface.
>>>
>>> Martin
>>>
>>> On May 23, 2005, at 7:46 PM, samar khatiwala wrote:
>>>
>>>> Hello
>>>>
>>>> I would like to perform some ptracer simulations in which the
>>>> ptracer concentration is prescribed at the surface. This could
>>>> be a time-dependent boundary condition. Unfortunately, I don't
>>>> see any simple way to use existing code to prescribe such a BC.
>>>> Simply setting pTracer(...,k=1,..)=BC does not work all that well.
>>>> To make this work robustly (and consistent with the time stepping) I
>>>> have
>>>> to intervene at multiple locations in the code to (re)set pTracer 
>>>> and
>>>> gPtr
>>>> to the BC.
>>>>
>>>> I was wondering if someone has figured out how to do this in a 
>>>> cleaner
>>>> and more consistent manner. Perhaps this could be incorporated into
>>>> the
>>>> gchem package since it seems like a useful capability to have.
>>>>
>>>> Thanks
>>>> Samar
>>>>
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support