[MITgcm-support] data precision

[Matthew Mazloff]

Hi Renske,

Here is what I think.....maybe wrong....but off the top of my head  
this makes sense to me

pressure, and thus eta, is not solved for on the boundaries.  One  
prescribes U,V,T, and S.  Since pressure is not solved for, there is  
no need to determine eta, and eta remains zero.  I believe if you  
consider the dynamics of the model interior, eta (and pressure) on  
the open boundary will never enter the equations.  If W is needed  
this will come from the divergence of the tangential velocity (the  
normal velocity is made divergenceless).

hope this makes sense,
Matt





On Jan 12, 2009, at 12:43 AM, Renske Gelderloos wrote:

> Hi,
>
> With the large number of questions in this discussion the question  
> about
> eta being 0 at open boundaries is still unanswered. As I've been
> wondering about this myself I'm very curious about the reason  
> behind it.
> Could anyone explain please? Thanks.
>
> Renske
>
>
> 名 徐 wrote:
>> Hi Martin
>> Thank you for your answer.It is unfortunate that I still couldn't  
>> open
>> the web
>> http://ecco2.jpl.nasa.gov/data1/arctic/run_template_cube81/ 
>> mk_run_template.m
>>
>> What has happened,I don't know?Now,I have modified the routine
>> "solve_for_pressure.F " to minus the sea level raise mean afer some
>> calculate steps.But I couldn't confirm it is reasonable.
>> In addition,the eta=0 on open boundary always,why?
>> PS: My name write in Chinese not in English,so you can't transcribe.
>>
>>
>>
>>
>>
>>
>>     Hi 名 徐,
>>
>>     (I still cannot transcribe your name (o:)
>>
>>     the readBinaryPrec flag pertains only to input data (such as  
>> bathymetry, inital
>>     conditions, open boundary values, forcing fields, grid fields  
>> etc.) If you use
>>     the pkg/exf, then those fields can be handled separately.  
>> Likewise
>>     writeBinaryPrec controls the precision of the output fields  
>> that the model will
>>     produce for you.
>>
>>     Regardless of these flags, all floats are defined and handled  
>> as real*8 (there
>>     is a macro in the code "_RL" that expands to real*8 and one
>>     "_RS" that also expands to real*8, unless you redefine it, but
>>     that's not really recommended), and you cannot/must not/do not  
>> have any
>>     sensible reason to change that. All *_R8/RL routines handle  
>> _RL variables and
>>     all *_R4/RS handle _RS variables, but for most (nearly all)  
>> people _RL and _RS
>>     are really the same (that is, real*8). So nothing to worry about.
>>
>>     Martin
>>
>>     PS. Thinking about your obcs balance problem, balancing the  
>> inflow offline will
>>     be far more effective, if your input fields are real*8  
>> (readBinaryPrec=64), in
>>     fact I recommend doing it that way.
>>
>>     On 8 Jan 2009, at 05:40, 名 徐 wrote:
>>
>>> Dear all
>>>      The default value of readBinaryPrec(writeBinaryPrec) is 32  
>>> in data
>>     PARM01.Does it imply the input data  precision must be 32(single
>>     precision,real*4).But many subroutines have been call on  the  
>> program read data
>>     on double precision(64,real*8) ,such as global_sum_R8 in  
>> cg3d.F.Is it a bug?How
>>     can I conform it!
>>>
>>> Thanks
>>>
>>> 好玩贺卡等你发，邮箱贺卡全新上线！
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>     _______________________________________________
>>     MITgcm-support mailing list
>>     MITgcm-support at mitgcm.org
>>     http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> 好玩贺卡等你发，邮箱贺卡全新上线！
>> <http://cn.rd.yahoo.com/mail_cn/tagline/card/*http:// 
>> card.mail.cn.yahoo.com/>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>
>
> -- 
>
>
> Ir. Renske Gelderloos
> KNMI
> P.O. Box 201
> 3730 AE De Bilt
> The Netherlands
> +31 30 2206361
> gelderlo at knmi.nl
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support