[MITgcm-support] bugs in ctrl pkg?

[Charlotte Breitkreuz]

Hi Matt,

thanks for your answer! To use gentim2d for the other ctrl variables is 
a good idea. I also found a different way: As my genarr3d variables are 
three initial tracer fields I just implemented two new control tracers 
following the example of ALLOW_TR10_CONTROL. So far this works fine. But 
I keep your idea in mind, if problems come up.

Regards,

Charlotte


Am 01.09.2016 um 00:26 schrieb Matthew Mazloff:
> Hi Charlotte
>
> Yes, this is confusing. I think the idea is to either strictly use the 
> generic controls or not. So if you want to use ALLOW_GENARR3D_CONTROL 
> then you should control atemp using ALLOW_GENTIM2D_CONTROL.
>
> In data.ctrl you would have something like:
>
>  xx_gentim2d_weight(1) = 'EIG_tmp2m_degC_wt_SO3.bin',
>  xx_gentim2d_file(1)='xx_atemp_anom',
>  xx_gentim2d_startdate1(1)=20080101,
>  xx_gentim2d_startdate2(1)=30000,
>  xx_gentim2d_period(1)=1209600.0,
>  xx_gentim2d_preproc(1,1)='rmcycle',
>  xx_gentim2d_preproc_i(1,1)=1,
>  xx_gentim2d_preproc(2,1)='smooth',
>  mult_gentim2d(1) = 1.0,
> #
>  xx_gentim2d_weight(2) = 'EIG_tmp2m_degC_wt_SO3.bin',
>  xx_gentim2d_file(2)='xx_atemp_mean',
>  xx_gentim2d_startdate1(2)=20080101,
>  xx_gentim2d_startdate2(2)=30000,
>  xx_gentim2d_period(2)=1209600.0,
>  xx_gentim2d_preproc(1,2)='docycle',
>  xx_gentim2d_preproc_i(1,2)=1,
>  xx_gentim2d_preproc(2,2)='smooth',
>  mult_gentim2d(2) = 1.0,
>
>
> Will that work for you?
>
> -Matt
>
>
>
>> On Aug 30, 2016, at 2:23 AM, Charlotte Breitkreuz 
>> <cbreitkreuz at marum.de <mailto:cbreitkreuz at marum.de>> wrote:
>>
>> Dear MITgcm developers,
>>
>> this concerns only the ctrl pkg. I think there are two things that 
>> possibly need to be changed in the control pkg - if I'm not wrong. 
>> And I also have one question.
>>
>> Consider a configuration where the exf fields atemp, aqh, precip, 
>> uwind, vwind  are used as control variables and also some 3d generic 
>> variables, for example initial tracer fields, are additional control 
>> variables. Therefore it is set #define ALLOW_ATEMP_CONTROL,..., and 
>> #define ALLOW_GENARR3D_CONTROL, and hence ctrlUseGen = TRUE (see 
>> ctrl_readparms.F).
>>
>> Two problems arise in this setting:
>>
>> In exf_getffields.F (from line 480) it is:
>>
>> if (.NOT.ctrlUseGen) then
>>
>> #ifdef ALLOW_ATEMP_CONTROL
>>       CALL CTRL_GET_GEN (
>>      &     xx_atemp_file, xx_atempstartdate, xx_atempperiod, ....
>>
>> ....
>>
>> endif
>>
>> and so on. So ctrl_get_gen is never called for these exf fields 
>> (atemp, aqh, precip. swdown, lwdown) if I use a generic 
>> controlvariable at the same time. Is this on purpose? Why?
>>
>>
>> And the second problem is that again in exf_getffields.F (from line 573)
>>
>> CALL CTRL_GET_GEN (
>>      &     xx_uwind_file, xx_uwindstartdate, xx_uwindperiod, ....
>>
>> is called. Then in ctrl_get_gen (from line 115):
>>
>>       if ( (optimcycle .ge. 0).AND.ctrlUseGen ) then
>>         ilgen=ilnblnk( xx_gen_file )
>>         write(fnamegen(1:80),'(2a,i10.10)')
>>      & xx_gen_file(1:ilgen),'.effective.',optimcycle
>>       endif
>>
>> ....
>>
>> call active_read_xy( fnamegen, ....
>>
>> ....
>>
>> This will occur as problem at run time, because xx_uwind.effective* 
>> was never written. The xx_*effective* file is just written for the 
>> generic control variables in ctrl_map_ini_genarr.F. So this problem 
>> again only comes up when the exf fields (uwind,vwind,evap,...) are 
>> used together with ctrlUseGen=TRUE.
>>
>>
>> And then I have one more question. What is this xx*effective*  even 
>> for? Why not use the normal xx* name as it is done for not-generic 
>> control variables?
>>
>>
>> Best wishes,
>>
>> Charlotte
>>
>>
>> -- 
>> *Charlotte Breitkreuz*, M. Sc. Technomathematik
>> PhD Student
>> Research Group 'Geosystem Modeling'
>>
>> *MARUM* - Center for Marine Environmental Sciences, University of Bremen
>> *FB5* - Department of Geosciences, University of Bremen
>> Klagenfurter Straße 2
>> 28359 Bremen, Germany
>> Room 5420
>>
>> Tel: +49(0)421 - 218 65448
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20160901/d89605d9/attachment-0001.htm>