[MITgcm-support] build error: obcs and ptracers with ecco

Wed May 21 20:07:25 EDT 2008

Hi Suneet,

the flag ALLOW_PTRACERS is a CPP option that is evaluated at  
_COMPILE_ time
by a CPP preprocessor to generate .f routine from original .F routine
i.e. if a statement
#define ALLOW_PTRACERS appears in a header file
(which it will based on selected package)
then the .f code will contain this block and will be compiled.

The flag usePTRACERS is a Fortran logical, i.e. appears in statements  
such as
        if (usePTRACERS) then
           ...
        endif
It is evaluated at _RUN_ time.

Your construct should, if things work properly,
EX(!)-clude the code block in question
(which is not what you want)
since nowhere is there (or should there be) a
#define usePTRACERS
statement in the CPP header files.
You can verify, by checking the_main_loop.f
to see whether the code is there.

The exclusion of this piece of code could be benign, or not,
depending on what your adjoint problem looks like.
In one case you'll likely find tons of
"extensive recomputation" warnings in taf_ad.log,
in the other case you won't.

 From STDOUT.0000 it isn't entirely clear what's going on.

-p.

On May 21, 2008, at 7:53 PM, Suneet Dwivedi wrote:

> Hi Patrick and Matt,
>
> Thanks for your comments and suggestions. Here is another solution to
> the same problem which worked for me. Instead of replacing/commenting
> out the statement:
>
> # ifdef ALLOW_PTRACERS
> I added an extra statement:
> # if ( usePTRACERS )
> just below this statement, so that the relevant portion of the
> "obcs_ad_check_lev1_dir.h", for example, reads as:
>
> ---------------------------------------------------------------------- 
> -------------------------
> # ifdef ALLOW_PTRACERS
> # if ( usePTRACERS )
> #
> #ifdef ALLOW_OBCS_NORTH
> CADJ STORE OBNptr  = comlev1, key = ikey_dynamics
> #endif /* ALLOW_OBCS_NORTH */
> #ifdef ALLOW_OBCS_SOUTH
> CADJ STORE OBSptr  = comlev1, key = ikey_dynamics
> #endif /* ALLOW_OBCS_SOUTH */
> #ifdef ALLOW_OBCS_EAST
> CADJ STORE OBEptr  = comlev1, key = ikey_dynamics
> #endif /* ALLOW_OBCS_EAST */
> #ifdef ALLOW_OBCS_WEST
> CADJ STORE OBWptr  = comlev1, key = ikey_dynamics
> #endif /* ALLOW_OBCS_WEST */
> #
> # endif  /* usePTRACERS */
> # endif  /* ALLOW_PTRACERS */
> ---------------------------------------------------------------------- 
> -------------------------
>
> I found that the same kind of statements are used in several fortran
> subroutines relating to ptracers. Also find attached herewith output
> of my simplified model run (which includes obcs/ptracers/ecco
> packages). I guess my current setup is running correctly with these
> packages. Let me know what do you think?
> Waiting for your comments,
> With best regards,
> Suneet
>
> On Wed, May 21, 2008 at 2:57 PM, Matthew Mazloff <mmazloff at mit.edu>  
> wrote:
>> Hi Patrick,
>>
>> I think you're right...i think there are missing headers wrt
>> obcs_ad_check_lev?_dir.h....why doesn't it see ALLOW_PTRACERS?
>> In my simulation I don't use the adjoint of PTRACERS so I can just  
>> comment
>> out  ifdef ALLOW_PTRACERS and make TAF happy (which is what its all
>> about!)...but since there are missing headers the stored OBNptr  
>> may not be
>> correct?  Maybe the appropriate header needs to be added to the main
>> loop....its odd?
>>
>> -matt
>>
>>
>> On May 21, 2008, at 2:23 PM, Patrick Heimbach wrote:
>>
>>>
>>> Hi Suneet,
>>>
>>> good to hear you can now run the model.
>>> However, the change you report below
>>>>
>>>> I just changed the statement
>>>>
>>>> # ifdef ALLOW_PTRACERS
>>>> to
>>>> # ifdef usePTRACERS
>>>
>>> doesn't make sense. A CPP flag "usePTRACERS" does not exist.
>>>
>>> So you may want to check what it is that is now running  
>>> successfully.
>>>
>>> Commenting out "# ifdef ALLOW_PTRACERS" isn't such a good idea  
>>> either,
>>> since it may point to another unsolved problem (missing headers).
>>>
>>> Also, not sure why you should have to add the code
>>>>>
>>>>> #ifdef ALLOW_OBCS_PRESCRIBE
>>>>> CADJ STORE OBNptr0 = tapelev3, key = ilev_3
>>>>> CADJ STORE OBNptr1 = tapelev3, key = ilev_3
>>>>> #endif /* ALLOW_OBCS_PRESCRIBE */
>>>
>>> THis code is part of the obcs_ad_check_lev?_dir.h routines
>>> so shouldn't have to be added.
>>>
>>> -Patrick
>>>
>>>
>>>
>>> On May 21, 2008, at 2:07 PM, Suneet Dwivedi wrote:
>>>
>>>> Hi Matt,
>>>> Sorry, I was out of town yesterday, so couldn't reply you earlier.
>>>> Thanks for telling me about the bug in obcs_ad_check_lev?_dir.h. As
>>>> per your advice, I just changed the statement
>>>>
>>>> # ifdef ALLOW_PTRACERS
>>>> to
>>>> # ifdef usePTRACERS
>>>>
>>>> and it solved my problem with ptracers/obcs package. Now I am  
>>>> able to
>>>> build and run my model setup successfully.
>>>> Thanks again,
>>>> Best regards,
>>>> Suneet
>>>>
>>>> On Mon, May 19, 2008 at 12:48 PM, Matthew Mazloff  
>>>> <mmazloff at mit.edu>
>>>> wrote:
>>>>>
>>>>> Oh...and based on your error you may have to add in
>>>>>
>>>>> #ifdef ALLOW_OBCS_PRESCRIBE
>>>>> CADJ STORE OBNptr0 = tapelev3, key = ilev_3
>>>>> CADJ STORE OBNptr1 = tapelev3, key = ilev_3
>>>>> #endif /* ALLOW_OBCS_PRESCRIBE */
>>>>>
>>>>> for each boundary.....not sure if your code will have that
>>>>>
>>>>> -matt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On May 19, 2008, at 12:23 PM, Suneet Dwivedi wrote:
>>>>>
>>>>>> Hi Patrick,
>>>>>> As per your advice I stripped down my adjoint model code so as  
>>>>>> to run
>>>>>> it on a single processor. As I told you earlier also that it  
>>>>>> works
>>>>>> fine without any error with obcs package but as soon as I try to
>>>>>> include ptracers I get the following TAF error messages so  
>>>>>> that I am
>>>>>> unable to build the adjoint code.
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------- 
>>>>>> -------------------------------------------
>>>>>> 1325411 CADJ STORE OBNptr  = tapelev4, key = ilev_4
>>>>>>                 ^
>>>>>> *ERROR* : identifier not defined
>>>>>> 1325413 CADJ STORE OBNptr0 = tapelev4, key = ilev_4
>>>>>>                 ^
>>>>>> *ERROR* : identifier not defined
>>>>>> 1325414 CADJ STORE OBNptr1 = tapelev4, key = ilev_4
>>>>>>
>>>>>> and similarly for S,W,E boundaries.
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------- 
>>>>>> -----------------------------------------
>>>>>>
>>>>>> Attached herewith is the output of 'make adall' for your kind  
>>>>>> perusal.
>>>>>> Please help me resolve this problem.
>>>>>> Hoping for your reply,
>>>>>> Suneet
>>>>>>
>>>>>> On Fri, May 16, 2008 at 3:03 PM, Patrick Heimbach  
>>>>>> <heimbach at mit.edu>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Suneet,
>>>>>>>
>>>>>>> your error message has nothing to do with ptracers or obcs.
>>>>>>> As I said, without seeing a toy setup, it's not clear what  
>>>>>>> you are
>>>>>>> doing.
>>>>>>> In your case, this kind of compile error typically arises when
>>>>>>> instead of typing
>>>>>>> make adall
>>>>>>> you type
>>>>>>> make
>>>>>>> ("make" doesn't link the adjoint code, whereas "make adall"  
>>>>>>> does).
>>>>>>> -p.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On May 16, 2008, at 1:37 PM, Suneet Dwivedi wrote:
>>>>>>>
>>>>>>>> Hi Everybody,
>>>>>>>> Is this possible to build the adjoint code in which ptracers  
>>>>>>>> package
>>>>>>>> works with open boundary conditions? For me, it failed. I am  
>>>>>>>> able to
>>>>>>>> build the forward code successfully with both ptracers and obcs
>>>>>>>> defined in packages.conf, but my build failed (see error  
>>>>>>>> message
>>>>>>>> below) when I tried to do the same thing for adjoint code (by
>>>>>>>> allowing
>>>>>>>> ecco, autodiff, cost and ctrl in packages.conf).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------------------------------------------- 
>>>>>>>> -----------------------------------
>>>>>>>> the_model_main.o(.text+0x207): In function `the_model_main_':
>>>>>>>> : undefined reference to `adthe_main_loop_'
>>>>>>>> make: *** [mitgcmuv_ad] Error 1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------------------------------------------- 
>>>>>>>> ------------------------------------
>>>>>>>> Is this a TAF problem? Do I need to make some changes in my  
>>>>>>>> code
>>>>>>>> inorder to make it work?
>>>>>>>> Hoping for your reply,
>>>>>>>> Suneet
>>>>>>>> _______________________________________________
>>>>>>>> MITgcm-support mailing list
>>>>>>>> MITgcm-support at mitgcm.org
>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>>>>
>>>>>>> ---
>>>>>>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/ 
>>>>>>> ~heimbach
>>>>>>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA  
>>>>>>> 02139 USA
>>>>>>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE  
>>>>>>> patrick.heimbach
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MITgcm-support mailing list
>>>>>>> MITgcm-support at mitgcm.org
>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>>>>
>>>>>>> <output.txt>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>
>>> ---
>>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>>
>>>
>>
>>
>> <STDOUT.0000>

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach