[MITgcm-support] ptracer BOTTOM boundary condition

[Petter Stenström]

Thanks for the replies. Did you mean GCHEM_FORCING_INT, or is there a new
gchem subroutine that I don't know of?

Petter

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