[MITgcm-support] problem solved: bug in the ecco/the_main_loop.F: build error: obcs and ptracers with ecco

Thu May 22 00:11:50 EDT 2008

Hi Patrick,

I guess finally I found the bug in the "pkg/ecco/the_main_loop.F" that
is responsible for the present problem. Here is the description:

In the pkg/ecco/the_main_loop.F; there are the statements:
------------------------------------
# ifdef ALLOW_OBCS
#  include "OBCS.h"
# endif
------------------------------------

These statements do not include information regarding inclusion of
ptracers when ptracers is defined alongwith obcs and ecco. The header
file "OBCS_PTRACERS.h" defined for this purpose is missing in these
statements. The above statements should therefore be modified as
follows:

-----------------------------------------------
#  ifdef ALLOW_OBCS
#   include "OBCS.h"
#   ifdef ALLOW_PTRACERS
#    include "OBCS_PTRACERS.h"
#   endif
#  endif
----------------------------------------------

This little change in routine solved my problem and now i am able to
see the variables OBNptr,  OBNptr0, OBNptr1 etc. in my
"the_main_loop.f" file.

The modified "the_main_loop.F" routine is attached herewith for your perusal.

I hope I did a right exercise this time. Am I right??

Waiting for your response,
Suneet

On Wed, May 21, 2008 at 8:07 PM, Patrick Heimbach <heimbach at mit.edu> wrote:
>
> 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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: the_main_loop.F
Type: text/x-fortran
Size: 41632 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20080522/61154a29/attachment.bin>