[MITgcm-devel] obcs and passive

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

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

More information about the MITgcm-devel mailing list