[MITgcm-devel] new verification experiment?

[Martin Losch]

Hi,
I found that if I use real*8 input files the results don't  change at 
all (on my Apple PowerBook).
However, I thought that I would at the same time add an open boundary 
conditions for salinity, which is effectively a passive tracer as well, 
this would change the results for salinity.

Also, why not have real*4 input fields, even if they change the 
results? Will the results be more fragile across different platforms? I 
don't think so. But real*4 would decrease the download-size.

My plan is to have the same open boundary condition for ptracer and 
salinity at the western boundary and different conditions at the other 
(salinity is set to sRef, while ptracer has this nearly homogeneous 
v.Neumann condition.), just to show different options.

I'll go ahead and modify exp4 soon (this afternoon).

Martin

On Oct 11, 2005, at 2:49 AM, Jean-Michel Campin wrote:

> Hi Martin,
>
> Personally, I don't have any problem with removing
> exp4/code/obcs_calc.F
> Do you have an idea of how much the results change (cg2d_ini...) ?
>
> Jean-Michel
>
> On Mon, Oct 10, 2005 at 08:21:15AM +0200, Martin Losch wrote:
>> Hi,
>> now that I have checked in the OBCS-Ptracer code, I would like to have
>> the code tested.
>> I could invent a new verification experiment, but I could also modify
>> an existing experiment:
>> A hot candidate is "exp4" (channel flow over bump), where I could add 
>> a
>> ptracer and use the "prescribe option" (reading OBs from a file).
>> However, exp4 has it's own copy of obcs_calc.F, where time dependent
>> OBs for uVel are computed:
>>>            OBEu(J,K,bi,bj)=Uinflow
>>>     &       *cos(2.*PI*futureTime*recip_TimeScale)
>>>     &       *max(futureTime*recip_TimeScale,1.0 _d 0)
>> so that, unless I read an open boundary field every time step, I will
>> never be able to reproduce the exact results (because of futureTime).
>> But, recip_TimeScale is set to zero anyway, so that OBEu=UinFlow
>> always.
>> If no-one objects, I would like to get rid of this local copy of
>> obcs_calc and read the OBs from file instead. However, this will
>> probably change the results slightly because of prescision. What do 
>> you
>> think? Or would you rather have a new experiment (not really 
>> necessary,
>> I believe)?
>>
>> 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