[MITgcm-support] ptracer BOTTOM boundary condition

[Samar Khatiwala]

Petter:

Martin is right. Your source terms can simply be put in 
GCHEM_CALC_TENDENCY. Of
course if you have topography, you want to make sure you are using the 
correct
'bottom' cell (not necessarily K=Nr).

Samar

On May 26, 2005, at 3:46 AM, Martin Losch wrote:

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