[MITgcm-devel] obcs and passive

[Martin Losch]

Hi Samar,

I have not touched pkg/matrix (in fact, up to now I have never had a 
look at that), but the verification/matrix_example is not affected by 
my changes.

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?

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 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 ...

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