[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