Messages issued by TAPENADE :

• Declarations problems:
  

  (DD01)	Cannot combine successive declarations of variable var: Type1 and Type2 (ignored new)
  (DD02)	Cannot combine successive declarations of character array: Type1 and Type2 (ignored new)
  (DD03)	Cannot combine successive declarations of constant const type: Type1 and Type2 (ignored new)
  (DD04)	Double definition of function Func (ignored new)
  (DD05)	Cannot combine successive declarations of function Func (ignored new)
  (DD06)	Cannot combine successive declarations of function Func return type: Type1 and Type2 (overwritten previous)
  (DD07)	Cannot combine successive declarations of function Func kind: kind1 and kind2 (ignored new)
  (DD08)	Double declaration of external function Func
  (DD09)	Double declaration of intrinsic function Func
  (DD10)	Double declaration of the main program: Func1 and Func2 (overwritten previous)
  (DD11)	Double declaration of function Func in library file LibraryFile
  (DD12)	Cannot combine successive declarations of type Type (ignored new)
  (DD13)	Double definition of label label (ignored new)

  
  There are two successive definitions or partial declarations of some symbol, as a variable, constant, type, label or function name. These successive declarations occur in the same scope and do not combine into a coherent declaration for the symbol. TAPENADE therefore chooses either to ignore the new piece of declaration, or to overwrite the previous piece of declaration, as indicated by the message. For DD08 and DD09, the two choices are equivalent.
  
  Why should you care? TAPENADE chooses to ignore the indicated declaration or part of your original program. Therefore the types considered by TAPENADE may not be the ones you expect, or the program actually differentiated may differ from the program you think. In particular when types are concerned, remember that differentiation occurs only on REAL (or COMPLEX) typed variables. Therefore some variable may have no derivative whereas you think it should have one. Also for DD13 or DD10, the flow of control may be different from what you think, or from what your local compiler used to build. Also for DD11, some information that you give about an external function may be ignored and replaced by another one.
  
  What can you do? Remove the declaration or definition in excess, or modify conflicting declarations so that they combine well into the type that you expect. For DD11, clean up the library file by merging the data about a given function into one single entry.
  


• Type problems:
  

  (TC01)	Expression is expected to be numeric, and is here Type
  (TC02)	Expression is expected to be boolean, and is here Type
  (TC03)	Expression is expected to be a record, and is here Type
  (TC04)	Expression is expected to be a pointer, and is here Type
  (TC05)	Expression var is expected to be an array, and is here Type
  (TC06)	Loop index is expected to be integer, and is here Type
  (TC07)	Loop bound is expected to be integer, and is here Type
  (TC08)	Loop times expression is expected to be integer, and is here Type
  (TC09)	Real part of complex constructor is expected to be numeric, and is here Type
  (TC10)	Imaginary part of complex constructor is expected to be numeric, and is here Type
  (TC11)	Argument of arithmetic operator is expected to be numeric, and is here Type
  (TC12)	Array index is expected to be numeric, and is here Type
  (TC13)	Triplet element is expected to be numeric, and is here Type
  (TC14)	Substring index is expected to be numeric, and is here Type
  (TC15)	Argument of logical operator is expected to be boolean, and is here Type

  
  The indicated expression is used in a context which requires some type. Using the available declarations, the type-checker found that this expression actually has a different type, indicated in the message.
  
  Why should you care? This may be the sign of an error in the program. Even if this original program actually compiles and runs well, remember that differentiation occurs only on REAL (or COMPLEX) typed variables. If some sub-expression becomes of another type, there will be no derivative associated, even if you think there should be one. Remember also that these problems make the program non-portable.
  
  What can you do? Check the types. You may also use the appropriate conversion functions. Be aware that when you convert a REAL into an INTEGER, the differentials are reset to zero.
  
  

  (TC16)	Type mismatch in assignment: Type1 receives Type2
  (TC17)	Type mismatch in case: Type1 compared to Type2
  (TC18)	Type mismatch in comparison: Type1 compared to Type2

  
  The two terms in the assignment or comparison, or the switch and case expressions, must have compatible types. Otherwise, the meaning of the instruction is not well defined, and not portable.
  
  Why should you care? This can be the indication for a standard type error and, like above, this can lose derivatives.
  
  What can you do? Check the types. Use conversion functions when appropriate.
  
  

  (TC19)

  Equality test on reals is not reliable

  
  Equality and non-equality are not well defined between REAL's, because they are defined only up to a given "machine precision". Equality test can yield different results on different machines.
  
  Why should you care? As far as AD is concerned, equality tests on REAL's are sometimes used as the stopping criterion for some iterative process. Then it relates to a well-known problem: do the derivatives converge when the function does, and if yes, do they converge at the same speed?
  
  What can you do? Check that this does not impact differentiation. Take care to perform the usual validation tests on the computed derivatives.
  
  

  (TC20)	Variable var is not declared
  (TC21)	No implicit rule available to complete the declaration of variable var
  (TC22)	Variable var, declared implicitly as Type1, is used as Type2
  (TC23)	Symbol var, formerly used as a variable, now used for another object
  (TC24)	Wrong number of dimensions for array Array: n2 expected, and n1 given
  (TC25)	Dimensions mismatch in vector expression, Type1 combined with Type2
  (TC26)	Incorrect equivalence
  (TC27)	End of common /COMMON/ reached before variable var
  (TC28)	Variable var cannot be added to common /COMMON1/ because it is already in common /COMMON2/
  (TC29)	Common /COMMON1/ declared with two different sizes: s1 vs s2
  (TC30)	Type mismatch in argument Arg of function Func, expects Type1, receives Type2
  (TC31)	Type mismatch in argument Arg of function Func, declared Type1, previously given Type2
  (TC32)	Wrong number of arguments calling Func: n2 expected, and n1 given

  
  These messages indicate conflicts between declaration and usage of some variable. Message TC25 occurs in the context of vectorized programs. Messages TC26 to TC29 indicate a problem in EQUIVALENCE's and COMMON's. Recall that variables in a COMMON are stored contiguously, so that their relative order cannot be changed, and extra variables cannot be inserted occasionaly. Also a variable cannot be in two different COMMON's, and one cannot set an EQUIVALENCE between two variables that already have their own, different, memory space allocated. Messages TC30 to TC32 indicate a mismatch between the formal and actual parameters of a function. Recall that the standards require that formal and actual parameters match in number and size.
  
  Why should you care? In general, if you let the system choose the type of a variable, you run the risk that it becomes REAL while you don't want, or the other way round. And this in turn impacts differentiation. Messages TC24, and TC26 to TC32 are even more serious: They can indicate that the code relies on FORTRAN weak typing to perform hidden equivalence's between two arrays, or to resize, reshape, or split an array into pieces. Since TAPENADE cannot possibly understand what is intended, it might not propagate differentiability and derivatives from the old array shape to the new array shape.
  
  What can you do? Declare variables explicitly. Try to avoid the "implicit" declaration facility. Declare arrays with their actual size (not "1"). Never resize, reshape, or split arrays implicitly through parameter passing, and avoid to do so across COMMON's
  
  

  (TC33)	Intrinsic function Func is not declared
  (TC34)	External function Func is not declared

  
  These messages indicate that you did not provide TAPENADE with the sources of the indicated procedures.
  
  Why should you care? If TAPENADE doesn't see the source of a called procedure, it is obliged to make several worst-case assumptions about it. Moreover, it this procedure must be differentiated, TAPENADE can't do it. You will have to do it yourself. In some cases this can be profitable because an expert user can do a better job than TAPENADE.
  
  What can you do? If you just forgot the procedure's source file, add it to the list of source files. If the procedure is missing for a good reason, first give TAPENADE type and data-flow information about the missing procedures, using either a dummy source procedure, or using our library mechanism. This can only make things better, as the conservative worst-case assumptions often have a negative impact. Then think about these missing procedures: if it turns out they will have a derivative, you will have to provide this derivative: message AD09 will remind you of that later. In the best situation, you are able to write an analytic differentiated code yourself. In the worst situation, you may use divided differences for the derivative of this unknown procedure, but this will loose some accuracy!
  
  

  (TC35)	Subroutine Func used as a function
  (TC36)	Type function Func used as a subroutine
  (TC37)	Return type of Func set by implicit rule to Type

  
  These messages indicate conflicts between declaration and usage of some function. Programs with messages TC35 and TC36 should not compile.
  
  Why should you care? In general, if you let the system choose the return type of a function, you run the risk that it becomes REAL while you don't want, or the other way round. And this in turn impacts differentiation.
  
  What can you do? Insert the correct declaration.
  
  

  (TC38)

  Recursivity: Func1-->Func2-->...-->FuncN

  
  Recursivity is when a subroutine Func1 calls a subroutine Func2, which itself calls a subroutine Func3, and so on, and when this eventually leads to calling Func1 again. In other words this is a cycle in the call graph. Basically, this is not an error, although FORTRAN77 used to forbid recursive programs.
  
  Why should you care? It is just a matter of time. Recursive programs are harder to analyze. We are progressively updating TAPENADE analyses so that they cope with recursivity.
  
  What can you do? In the meantime, check that the resulting derivatives are correct, using the classical tests.
  
  

  (TC40)	No field named name in Type
  (TC41)	Recursive type definition

  
  These are illegal uses of types. TC40 says the program looks for a field name which does not exist, and TC41 that some types directly contains a field of the same type, thus yielding an infinite size!
  
  Why should you care? It is surprising is the original program actually compiles! Differentiation is undefined.
  
  What can you do? Rewrite the definitions of these types.
  
  

  (TC42)

  Definition of type Type comes a little too late

  
  The definition of the type came after it was used. This is just a warning, because TAPENADE will do as if the definition was done in due time. But you should better fix this.
  
  

  (TC50)	Label label is not defined
  (TC51)	Label variable var must be written by an ASSIGN-TO construct
  (TC52)	Variable var used in assigned-GOTO is not a label variable

  
  These are illegal uses of labels, or label variables.
  
  Why should you care? If labels are misunderstood, the final flow of control that TAPENADE understands and regenerates might not be the one you expect. Therefore TAPENADE does not differentiate the program you expect.
  
  What can you do? Define the labels you use. Use the correct constructs to manipulate label variables.
  
  


• Control flow problems:
  

  (CF01)	Irreducible entry into loop
  (CF02)	Computed-GOTO without legal destinations list
  (CF03)	This assigned-GOTO to var goes nowhere
  (CF04)	This assigned-GOTO to var only goes to label label
  (CF05)	This assigned-GOTO to var is possibly undefined

  
  These messages indicate problems in the flow of control of the program. Message CF01 comes from jumps that go from outside to inside a loop, without going through the loop control header. The meaning of this is not well defined and is probably implementation dependent.
  
  Why should you care? Of course a bad control of a program yields a bad control of its differentiated programs.
  
  What can you do? Avoid irreducible loops. Avoid jumps into loops and into branches of a conditional structure. Try to use structured programming instead. If an assigned-GOTO goes to only one place, at least replace it by a GOTO.
  


• Data flow problems:
  

  (DF01)	Illegal non-reference value for output argument Arg of function Func
  (DF02)	Potential aliasing in calling function Func, between arguments arguments
  (DF03)	Variable var is used before initialized
  (DF04)	Variable var may be used before initialized

  
  These problems are detected through the built-in interprocedural data-flow analysis of TAPENADE.
  
  Why should you care? Programs with DF01 usually provoke segmentation faults. Aliasing (DF02) is a major source of errors for DIfferentiation in the reverse mode, as described in more detail in the "Aliasing" section of the FAQ. Uninitialized variables lead to uninitialized derivatives.
  
  What can you do? Output formal arguments of a subroutine must be passed reference (i.e. writable) actual arguments. It is better to avoid aliasing. When aliasing is really a problem, one can easily avoid it by introducing temporary variables, so that memory locations of the parameters do not overlap. Variables should be initialized before they are used.
  


• Automatic Differentiation problems:
  

  (AD01)	Actual argument Arg of Func is active while formal argument is non-differentiable
  (AD02)	Actual output Arg of Func is useful while formal result is non-differentiable

  
  These two messages are usually associated. They indicate the following situation: Some programs implicitly convert REAL's to INTEGER's during a function call, then these INTEGERS follow their way through the code, and finally are converted back into REAL's during another function call.
  
  Why should you care? If the original REAL's are active, i.e. depend on the independent input variables, and the final REAL's are useful, i.e. influence the dependent output variables, then this temprary conversion into INTEGER's has lost differentiability and derivatives. Differentiability is lost, derivatives are wrong!
  
  What can you do? REAL's must remain REAL's. If absolutely necessary, there is a "secret" option in TAPENADE to actually differentiate these strange REAL-INTEGER's...
  
  

  (AD03)	Active variable var written by I-O to file file
  (AD04)	Useful variable var read by I-O from file file

  
  This is comparable to the above AD01 and AD02. These two messages are usually associated or, to put it differently, if the two messages occur for the same differentiation session, then there is a risk. The risk occurs in the following situation: Some programs write intermediate REAL values into a file and later on, read back these REAL values from this file. This process looses differentiability.
  
  Why should you care? If the written value is active, i.e. depends on the independent input variables, and the corresponding (equal) value read is useful, i.e. influences the dependent output variables, then this temporary storage into a file has lost differentiability and derivatives. Differentiability is lost, derivatives are wrong!
  For instance if the code looks like:

  
        subroutine TOP(x,y,fileno)
        real x,y,tmp
        integer fileno
        write(fileno,*) x
        ...
        read(fileno,*) tmp
        y = 2.0*x + tmp
        end
  

  Tapenade cannot find the dependency path that goes from the input x through de file "fileno" and finally to the output y. if xd is 1.0 yd will be 2.0, whereas the correct answer should be 3.0.
  
  What can you do? Do not use files as temporary storage. Use arrays instead. You may also use TAPENADE "Black-box" mechanism to disconnect differentiation on the calling subroutines, and differentiate them by hand, with an ad-hoc mechanism to propagate derivatives.
  
  

  (AD05)

  Active variable var overwritten by I-O

  
  This reminds you that a variable that was active has been overwritten by an I-O operation
  
  Why should you care? The derivative is of course reset to zero. Maybe this is not what you expected?
  
  What can you do? Check that it is OK. Otherwise try to put all I-O operations outside the part of the program you are actually differentiating.
  
  

  (AD06)	Differentiate of function Func needs to save undeclared side-effect variables: variables
  (AD07)	This call needs to save undeclared side-effect variable: extern-var
  (AD10)	call to Proc2 in differentiation of procedure Proc1 need to save and restore the I-O state

  
  These messages all indicate that the checkpointing mechanism is not certain that it can do a correct job. These messages point at (a collection) of procedure calls in the program, e.g. all calls to Func, or one particular call, or procedure (i.e. subroutine or function) Proc1 calling another procedure (i.e. subroutine or function) Proc2.
  
  In reverse mode, the standard strategy of Tapenade is to checkpoint all procedure calls (cf a quick description of checkpointing, or Tapenade User's guide for something more technical). Checkpointing a call to Proc2 inside Proc1 means that the reverse differentiated subroutine of Proc1 is going to call Proc2 twice, or more precisely the original Proc2 once and then the differentiated Proc2. Roughly speking, these two calls must be made with the same inputs, so that the 2nd call is an exact duplication of the 1st call. To do this, a minimal "environment" needs to be stored just before the 1st call to Proc2 and restored just before the 2nd call. We know how to save and restore most variables, e.g. the formal parameters of Proc2, but also the globals known by Proc1 and Proc2. On the other hand, we don't know how to save and restore hidden SAVE variables, or private global variables of a module, or a COMMON which is not declared at the calling subroutine level, or the position of the read/write pointer inside an opened file which is being read/written, or the very open/close status of a file, and several other things... These messages just signal such (possibly) nasty situations.
  
  Why should you care? Checkpointing cannot restore the environment before the second call to Proc2. Therefore the differentiated program might be wrong.
  
  What can you do? Either make absolutely sure that this is not a problem in the present case, because you know that the second call to Proc2 will behave just like the 1st one, at least as far as differentiation is concerned. You need to know the code for that because errors will be hard to track down. For instance, one favorable situation is when the (AD10) message corresponds only to prints of messages on the screen. The messages will appear twice, but derivatives should be correct.
  Or modify your code so that the problem disappears, for instance insert the COMMON declaration at the level of the calling subroutine. or transform the SAVE variables into elements of a COMMON that everyone can see, or take the file I/O or dynamic memory allocation or deallocation outside the code to differentiate,
  Or (more high-tech!) tell Tapenade not to checkpoint the calls that raise the problem using the "nocheckpoint" directive.
  
  

  (AD08)

  Don't know the size of dimension n of array array, which must be saved

  
  In some cases, for example in reverse-mode AD, the differentiated function must save some variables, to restore them later. If one such variable is an array, and the size of this array is dynamic, TAPENADE must know this size to actually do the save.
  
  Why should you care? If you don't give this size, the differentiated program will not compile.
  
  What can you do? Define the value of the PARAMETERS that TAPENADE requests, in a special include file. You may also explicitly give this size in the original file, so that the message does not show up!
  
  

  (AD09)

  Please provide a differential of function Func for arguments arguments

  
  You must provide the differentiated program with a new function, differentiated from Func with respect to the input and output parameters of Func specified in the arguments. Probably Func is an external function, for which TAPENADE has no source, and therefore it couldn't differentiate it.
  
  Why should you care? If you don't give this new function, the differentiated program will probably not compile.
  
  What can you do? Define this new function. You have the choice of the method. Maybe you know explicitly the derivative mathematical function, which can be implemented efficiently. Maybe you have the source and you may use AD again, with TAPENADE or with another tool. Maybe you just want to run a local "divided differences" method, knowing that this might slightly degrade the precision of the derivatives. In any case, make sure that you provide a differentiated function in the correct mode (tangent, reverse...), and which adheres to the conventions of TAPENADE about the name of the function and the order of its parameters.
  
  

the developers of Tapenade