[MITgcm-devel] obcs and passive

Baylor Fox-Kemper baylor at MIT.EDU
Sun Oct 9 13:49:04 EDT 2005 

If you really want good Dirichlet, you could work out the extrapolation 
to the location of the surface with a two-gridpoint deep stencil, or 
with some sort of boundary-layer parameterization (e^-kz).
   -Baylor


On Oct 9, 2005, at 1:42 PM, Baylor Fox-Kemper wrote:

> Hi Samar and Martin,
>   I think having an 'approximate Dirichlet' is OK, but it should be 
> carefully commented, because the model is finite volume (hence bcs are 
> always fluxes) and the tracer gridpoints aren't really at the surface 
> they're one-half cell below it.  This may seem like an unnecessary 
> distinction, but it does mean that these aren't really Dirichlet, and 
> that the approximation only will work if kappaRT>>deltaR**2 / deltaT.
>   My two bits...
>    -Baylor
>
> On Oct 9, 2005, at 4:43 AM, Martin Losch wrote:
>
>> Hi Samar,
>>
>> I shouldn't have spoken for Jean-Michel, sorry about that.
>>
>> The routine ptracers_forcing_surf.F is the place where ptracers 
>> tendencies due to surface fluxes can be specified (similar to 
>> external_forcing_surf.F).
>> My opinion is, that yes, we could probably have code for Dirichlet 
>> BCs; I see that one may want to do keep surface values of ptracers 
>> constant in certain idealized scenarios, although from a physical 
>> point of view I don't see what realistic situation would require 
>> Dirichlet BCs in a realistic scenario.
>> In any case, your new routine should have a name that sets it appart 
>> from ptracers_forcing_surf, maybe ptracers_set_dirichlet_bc. I have 
>> not tried to understand this staggeredTimestep business. Let's wait 
>> what the "code czars" say (o:
>>
>> Martin
>>
>> On Oct 8, 2005, at 9:18 PM, Samar Khatiwala wrote:
>>
>>> Hi Martin
>>>
>>> On Oct 8, 2005, at 2:56 PM, Martin Losch wrote:
>>>
>>>> If you are concerned with a possible interferences of the 
>>>> matrix-pkg with obcs, you should include something like 
>>>> matrix_check, that is called from model/src/packages_check.F (there 
>>>> are many examples, e.g., pp81_check.F, etc) and catches all 
>>>> combinations with matrix-pkg that you can think of, or modify 
>>>> obcs_check.F to include a check that obcs and matrix are not used 
>>>> at the same time. I am not sure which is the better option. What do 
>>>> you think?
>>>
>>> Perhaps matrix_check.F is the way to do it. I'll look into it.
>>>
>>>
>>>> About the surface BC for ptracers. I read your email again, but my 
>>>> changes are not a major reorganization of ptracers (I call 
>>>> obcs_apply_ptracers in a few places), so that I should not 
>>>> interfere with your code. I cannot say much about you code changes, 
>>>> but I guess the general notion is to prescribe fluxes at the 
>>>> surface, and not values. Remembering discussions with Jean-Michel, 
>>>> he would even like to have fluxes (and not values) prescribed at 
>>>> the open boundaries.
>>>
>>> I do not follow JMC's reasoning here. Or rather, since I haven't 
>>> heard it, cannot begin to guess why only
>>> fluxes should be prescribed. Does that mean one should never solve a 
>>> PDE with a Dirichlet BC? Some of us
>>> think that is an important class of problem ...
>>>
>>>> I guess surface BC's for ptracers is an unresolved issue that is 
>>>> not treated in a general way: So far, anyone using surface bc for 
>>>> ptracers was responsible for it him/herself. If you have a look at 
>>>> the packages cfc and dic (and gchem), you'll see how Steph has done 
>>>> it, but only in conjunction with the gchem-pkg. What may be 
>>>> necessary, is a more general solution, so that different 
>>>> gchem-"sub" packages do not have to have the same to code to read 
>>>> input fields. But I have an ecysystem model, that computes surface 
>>>> carbon fluxes from atmospheric partical pressure, ocean carbon 
>>>> concentration (TCO2 or DIC), alkalinity, and salinity. I have no 
>>>> idea how build a general ptracers-surface-bc scheme so that such a 
>>>> model fits in ...
>>>>
>>>
>>> Yes, I have seen this code and found it to be incomplete, in the 
>>> sense of not consistently
>>> applying the surface BC at various stages of the time stepping. It 
>>> is also too specific to
>>> the gchem pkg and not easily applied to a general ptracer simulation 
>>> (like your ecosystem
>>> model). That is what my modifications do. I think any implementation 
>>> should be general only
>>> to the extent that it can apply a user supplied time-dependent BC in 
>>> the right way. Everything
>>> else (reading in the boundary data, etc) should be done by 
>>> user-supplied code. So, unlike the
>>> gchem pkg, your ecosystem code would very easily plug into the 
>>> framework I have implemented.
>>>
>>> I would be happy to check this code in myself, but I am not sure if 
>>> I have the requisite CVS
>>> privilages.
>>>
>>> Samar
>>>
>>>> Martin
>>>>
>>>> On Oct 8, 2005, at 5:19 PM, Samar Khatiwala wrote:
>>>>
>>>>
>>>>> Martin
>>>>>
>>>>> Does your OBCS code impact my pkg/matrix in any way?
>>>>> To be safe, it would be useful to have a config check that
>>>>> generates an error or warning to the effect that one should
>>>>> NOT use the matrix pkg with obcs. (This may change in the
>>>>> future once I figure out how to treat open open boundaries
>>>>> within this framework.)
>>>>>
>>>>> Samar
>>>>>
>>>>> On Oct 8, 2005, at 10:48 AM, Martin Losch wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am now (after almost a year of procrastinating) ready to 
>>>>>> check-in code that allows open boundary conditions for passive 
>>>>>> tracers. This will affect files of the obcs-pkg and the 
>>>>>> ptracers-pkg and the file pkg/generic_advdiff/gad_advection.F. 
>>>>>> Not all parts of the code are thoroughly tested (in particular, 
>>>>>> the obcs_external_fields_load part).
>>>>>> There is still no code to deal with Orlanski boundary conditions 
>>>>>> for passive tracers, and honestly, I don't know if I ever get 
>>>>>> around to doing that. I don't know enough about the Orlanski 
>>>>>> code, and it seems to be too tricky for me to do it on the fly.
>>>>>>
>>>>>> My question: Should I create a new tag (checkpoint57u_post) after 
>>>>>> checking in my code? I am asking because I no longer see a clear 
>>>>>> pattern in when a tag should be created and I don't want to 
>>>>>> interfere with a policy that I maybe should know (but don't) (o:
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> _______________________________________________
>>>>>> MITgcm-devel mailing list
>>>>>> MITgcm-devel at mitgcm.org
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list