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

Patrick Heimbach heimbach at MIT.EDU
Thu May 22 00:21:43 EDT 2008


Hi Suneet,
your description and suggested fix below seem correct.
Good job!
-Patrick

On May 22, 2008, at 12:11 AM, Suneet Dwivedi wrote:

> 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
>>
>>
>>
>> <the_main_loop.F>

---
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





More information about the MITgcm-support mailing list