[MITgcm-support] ptracer BOTTOM boundary condition

[Martin Losch]

Hi Petter,
last November I changed some parts of the gchem-pkg, so that 
gchem_forcing_int is now replaced by gchem_calc_tendency (called from 
forward_step) and gchem_add_tendency (called from ptracers_forcing), in 
order to disentangle the packages ptracers and gchem (CPP-flags etc) 
and make things a little more consistent. These changes do not affect 
the results of cfc_example and dic_example (as far as I remember).
But Samar is right, in the end you need tendencies added to gPtracer, 
which happens in ptracers_forcing (or in your version of the code 
gchem_forcing_int), whether you do this within ptracers or gchem is up 
to you.

Martin

On May 26, 2005, at 10:23 PM, Petter Stenström wrote:

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