[MITgcm-devel] obcs and passive

Samar Khatiwala spk at ldeo.columbia.edu
Sun Oct 9 17:01:28 EDT 2005 

Hi Baylor, you make a good point.

But it also depends on how you think about the Dirchlet BC. My  
viewpoint,
guided by the applications I am interested in, is that once the  
tracer equations
have been discretized in space, it is convenient and not incorrect to  
think of
the GCM as a fancy 'box model' with each (finite volume) cell  
representing a box,
and exchanges/transports between boxes being determined by the dynamics.
 From this viewpoint, a "Dirichlet BC" (loosely defined) means  
specifying the
concentration of cells on the boundary. I think this is a perfectly  
legit point
of view and one entirely consistent with the finite volume formulation.

And to respond to Martin's point about why one would want to do this, I
will mention two applications of interest to me: Inversion of tracer  
data for ocean
carbon uptake, and computation of transit-time distributions. These  
are no less
"realistic" applications than any other.

Samar

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