[MITgcm-devel] obcs and passive

[Samar Khatiwala]

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
>