[MITgcm-devel] obcs and passive

[Martin Losch]

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